Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Apr 11, 2012 at 6:30 AM, Ming Lei tom.leim...@gmail.com wrote: On Tue, Apr 10, 2012 at 5:51 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Tue, Apr 10, 2012 at 2:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Apr 10, 2012 at 02:27:36PM +0530, Santosh Shilimkar wrote: On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? You might have missed the earlier comments on the thread. High resolution GP timer(sysclk) will stop in deeper power states and hence it can't be used with PM enabled usecases. Which means folk should be given the choice at boot time between running with the deeper power states and having a higher resolution timing source, rather than denying them the higher resolution timing source when PM is enabled. Good point. My point is such facilities is already part of the kernel and there is no need to add a new one. The last proposal was allowing user to choose gptimer as a clocksource and then you already have facility to disable C-state now so, all should work in general 'nohlt' in boot cmd should work to prevent CPU from entering deep C-state, which looks enough to make gptimer working well if system suspend isn't considered. That's another good option Looks like we get all the needed flexibility with the reworked patch from Vaibhav to choose the command like option for high res. timer source. 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 v4 04/12] ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
On 04/11/2012 02:35 AM, Paul Walmsley wrote: Also interesting is that drivers/usb/host/ohci-nxp.c contains a stub for ocpi_enable() - perhaps the NXP chips use a similar OCPI IP block? I'd rather suspect a copy-paste error here since ocpi_enable() is unused in ohci-nxp.c and the extern declaration looks like an incomplete but intended removal. Will probably just remove this reference in my DT patchset. Roland -- 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] ARM: OMAP2+: remove redundant sysconfig context restore
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 652139c..15e7882 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -82,8 +82,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer-context.tiocp_cfg,
- timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
if (timer-revision == 1)
__raw_writel(timer-context.tistat, timer-sys_stat);
--
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] ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
Modified the $SUBJECT to include *dmtimer* as per convention.
arch/arm/plat-omap/dmtimer.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 652139c..15e7882 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -82,8 +82,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer-context.tiocp_cfg,
- timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
if (timer-revision == 1)
__raw_writel(timer-context.tistat, timer-sys_stat);
--
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
Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
Hi Omar,
On 4/11/2012 2:16 AM, Ramirez Luna, Omar wrote:
Hi,
On Wed, Dec 14, 2011 at 5:55 AM, Rajendra Nayakrna...@ti.com wrote:
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
...
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 63b5416..a508ed5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
- omap_serial_init();
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
--
1.7.1
I'm fairly new to DT and I'm trying to boot it with pandaboard and
k3.3, however above hunk deletes omap serial initialization, which
causes a panic on boot, because pdata is NULL:
static void serial_omap_start_tx(struct uart_port *port)
{
...
if (pdata-set_noidle)
Perhaps because this change skips the following path:
omap_serial_init-omap_serial_board_init-omap_serial_init_port
Where pdata is built in omap_device_build.
I'm just trying to confirm that I'm not alone or doing some silly
thing before getting in depth with the code.
Yes, it is a known issue and the fix was unfortunately was not merged
during -rc phases but is fixed in 3.4 and should be fixed in 3.3 stable
branch as well. I received the notification from Greg KH 2 weeks ago
about the stable: Patch tty: serial: OMAP: Fix oops due to NULL pdata
in DT boot has been added to the 3.3-stable tree
You should just switch to 3.4-rc2 or get the patch if you are stuck to 3.3.
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] ARM: OMAP2+: remove redundant sysconfig context restore
CC'ing LAKML
On Wed, Apr 11, 2012 at 2:04 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 652139c..15e7882 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -82,8 +82,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer-context.tiocp_cfg,
- timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
if (timer-revision == 1)
__raw_writel(timer-context.tistat, timer-sys_stat);
Looks good to me.
Acked-by: Santosh Shilimkar santosh.shili...@ti.com
--
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 RESEND] Input: omap-keypad: dynamically handle register offsets
Hi Dmitry,
On Tue, Apr 10, 2012 at 9:53 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Hi Sourav,
On Tue, Apr 03, 2012 at 10:52:26AM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
In addition to Felipe's comments.
@@ -76,11 +81,66 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+ unsigned int revision;
+ u32 irqstatus;
+ u32 irqenable;
u32 reg_offset;
and you probably won't need revision field.
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ return __raw_readl(keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ return __raw_readl(keypad_data-base + offset + 0x10);
+
+ return -ENODEV;
Instead do:
return __raw_readl(keypad_data-base + keypad_data-reg_offset +
offset);
+}
I have a couple of doubts on this:
1. Before using kbd_readl/kbd_write anywhere we
need to populate the keypad_data-reg_offset with the register address
which we need to read or write.
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32
value)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ __raw_writel(value, keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ __raw_writel(value, keypad_data-base + offset + 0x10);
__raw_writel(value,
keypad_data-base + keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_revision(struct omap4_keypad *keypad_data, u32
offset)
+{
+ int reg;
+ reg = __raw_readl(keypad_data-base + offset);
+ reg = 0x03 30;
+ reg = 30;
+
+ switch (reg) {
+ case 1:
+ return KBD_REVISION_OMAP5;
+ case 0:
+ return KBD_REVISION_OMAP4;
+ default:
+ return -ENODEV;
-EINVAL? -EIO?
Hmm, -EINVAL looks more apt here.Will change.
+ }
+}
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +151,11 @@ static irqreturn_t omap4_keypad_interrupt(int irq,
void *dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, keypad_data-irqenable,
+ OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base +
OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +180,13 @@ static irqreturn_t omap4_keypad_interrupt(int irq,
void *dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base + OMAP4_KBD_IRQSTATUS),
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
+ kbd_write_irqstatus(keypad_data, keypad_data-irqstatus,
+ kbd_read_irqstatus(keypad_data, keypad_data-irqstatus));
/* enable interrupts */
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN |
OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, keypad_data-irqenable,
+ OMAP4_DEF_IRQENABLE_EVENTEN |
+ OMAP4_DEF_IRQENABLE_LONGKEY);
return IRQ_HANDLED;
}
@@ -139,16 +199,30 @@ static int omap4_keypad_open(struct input_dev
*input)
disable_irq(keypad_data-irq);
- __raw_writel(OMAP4_VAL_FUNCTIONALCFG,
- keypad_data-base + OMAP4_KBD_CTRL);
- __raw_writel(OMAP4_VAL_DEBOUNCINGTIME,
- keypad_data-base + OMAP4_KBD_DEBOUNCINGTIME);
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN |
OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
- __raw_writel(OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA,
- keypad_data-base + OMAP4_KBD_WAKEUPENABLE);
+ keypad_data-revision = kbd_read_revision(keypad_data,
+ OMAP4_KBD_REVISION);
switch()
Ok. Will covert that to switch statement.
+ if
Re: [PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
On Wed, Apr 11, 2012 at 02:19:48PM +0530, Poddar, Sourav wrote:
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ return __raw_readl(keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ return __raw_readl(keypad_data-base + offset + 0x10);
+
+ return -ENODEV;
Instead do:
return __raw_readl(keypad_data-base + keypad_data-reg_offset +
offset);
+}
I have a couple of doubts on this:
1. Before using kbd_readl/kbd_write anywhere we
need to populate the keypad_data-reg_offset with the register address
which we need to read or write.
no no... keypad_data-reg_offset would be 0 or 0x10 depending on the
scheme you decode from revision.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
Hi Felipe,
On Wed, Apr 11, 2012 at 2:26 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Apr 11, 2012 at 02:19:48PM +0530, Poddar, Sourav wrote:
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ return __raw_readl(keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ return __raw_readl(keypad_data-base + offset + 0x10);
+
+ return -ENODEV;
Instead do:
return __raw_readl(keypad_data-base + keypad_data-reg_offset +
offset);
+}
I have a couple of doubts on this:
1. Before using kbd_readl/kbd_write anywhere we
need to populate the keypad_data-reg_offset with the register address
which we need to read or write.
no no... keypad_data-reg_offset would be 0 or 0x10 depending on the
scheme you decode from revision.
Ohk. Got it. Will make the necessary changes.
Thanks.
~Sourav
--
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
Re: [PATCH v4 10/12] ARM: OMAP1: board files: deduplicate and clean some NAND-related code
On Wednesday 11 April 2012, Paul Walmsley wrote:
+void omap1_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+
+ mask |= (unsigned long)this-IO_ADDR_W;
+
+ writeb(cmd, (void __iomem *)mask);
+}
IO_ADDR_W is always a page aligned pointer AFAICT, so you can actually
remove both casts and make it more readable at the same time by writing
the last two lines as
writeb(cmd, this-IO_ADDR_W + mask);
Arnd
--
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 v4 01/12] ARM: OMAP2+: declare file-local functions as static
On Wednesday 11 April 2012, Paul Walmsley wrote: Several function declarations used only in the files in which they're declared should include the static keyboard, but don't: ^^^ ??? The patch looks good otherwise, Acked-by: Arnd Bergmann a...@arndb.de -- 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
query about _setup() in omap_hwmod.c
Hi,
I had a query about the _setup() function in
arch/arm/mach-omap2/omap_hwmod.c:
The function enables slave clocks right in the beginning, and based on
the value of postsetup_state, it either calls _idle(), _shutdown() or
does nothing.
Now, for the case of _idle() or _shutdown(), I guess it's the job of
_disable_clocks() to disable the slave clocks before we exit _setup().
If we compare how the slave clocks are enabled and disabled in _setup()
and _disable_clocks() respectively:
static int _setup(struct omap_hwmod *oh, void *data)
{
...
...
if (os-flags OCPIF_SWSUP_IDLE) {
/* XXX omap_iclk_deny_idle(c); */
} else {
/* XXX omap_iclk_allow_idle(c); */
clk_enable(c);
}
}
...
...
}
static int _disable_clocks(struct omap_hwmod *oh)
{
...
...
if (c (os-flags OCPIF_SWSUP_IDLE))
clk_disable(c);
...
...
}
Both these functions are taking different decisions based on whether
os-flags has OCPIF_SWSUP_IDLE or not.
Would this lead to some sort of clk_enable() and clk_disable() mismatch?
If I boot a 3.4-rc1 kernel on beagle with omap2plus_defconfig, I get:
cat /sys/kernel/debug/clock/summary | grep dss
nameparent freq use_count
dss_ickl4_ick 8300 4
dss2_alwon_fck sys_ck 1300 0
dss_96m_fckomap_96m_fck 9600 0
dss_tv_fck omap_54m_fck 5400 0
dss1_alwon_fck dpll4_m4x2_ck 14400 0
dss_ick is the slave clock of all the dss hwmods on omap3. This doesn't
seem to be right, does it?
Thanks,
Archit
--
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] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
--
1.7.1
--
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] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
--
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] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 03:54:28PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
aren't you missing the opening parenthesis ? Or is there a something not
shown in the context ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wednesday 11 April 2012 03:56 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:54:28PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
aren't you missing the opening parenthesis ? Or is there a something not
shown in the context ?
Its the missing context thats confusing :-)
This is how the code looks in the file after the patch.
if ((OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)
(ios-vdd == DUAL_VOLT_OCR_BIT)
/*
* With pbias cell programming missing, this
* can't be allowed when booting with device
* tree.
*/
!host-dev-of_node) {
--
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] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 03:59:55PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:56 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:54:28PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host
*mmc, struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
aren't you missing the opening parenthesis ? Or is there a something not
shown in the context ?
Its the missing context thats confusing :-)
This is how the code looks in the file after the patch.
if ((OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)
(ios-vdd == DUAL_VOLT_OCR_BIT)
/*
* With pbias cell programming missing, this
* can't be allowed when booting with device
* tree.
*/
!host-dev-of_node) {
ok, my bad then. Should've looked at the source code. Sorry for the
noise.
--
balbi
signature.asc
Description: Digital signature
[PATCHv7 16/18] I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
From: Tasslehoff Kjappfot tasskj...@gmail.com i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 666a365..7489eb6 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -431,11 +431,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1060,6 +1055,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430_3530) dev-errata |= I2C_OMAP3_1P153; -- 1.7.4.1 -- 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
[PATCHv7 10/18] I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the wait_for_completion_timeout returns long.
Original patch is
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7bbc736e60c4188a11aaa74bc6e6
Cc : Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 959e97c..121c52e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -502,7 +502,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg, int stop)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
- int r;
+ unsigned long timeout;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -570,12 +570,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ timeout = wait_for_completion_timeout(dev-cmd_complete,
+ OMAP_I2C_TIMEOUT);
dev-buf_len = 0;
- if (r 0)
- return r;
- if (r == 0) {
+ if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_reset(dev);
omap_i2c_init(dev);
--
1.7.4.1
--
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
[PATCHv7 07/18] I2C: OMAP: Optimise the remove code
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3670088..2096726 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1134,8 +1134,7 @@ err_release_region:
return r;
}
-static int
-omap_i2c_remove(struct platform_device *pdev)
+static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
@@ -1228,7 +1227,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
- .remove = omap_i2c_remove,
+ .remove = __devexit_p(omap_i2c_remove),
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
--
1.7.4.1
--
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
[PATCHv7 09/18] I2C: OMAP: Correct I2C revision for OMAP3
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a461097..959e97c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_4430 0x40
+#define OMAP_I2C_REV_ON_3430_3530 0x3C
+#define OMAP_I2C_REV_ON_3630_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } 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
@@ -1051,7 +1051,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP3_1P153;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1069,7 +1069,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
1.7.4.1
--
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
[PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f371d4f..c396cb7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
@@ -1233,7 +1230,7 @@ static struct platform_driver omap_i2c_driver = {
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
- .pm = OMAP_I2C_PM_OPS,
+ .pm = omap_i2c_pm_ops,
.of_match_table = of_match_ptr(omap_i2c_of_match),
},
};
--
1.7.4.1
--
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
[PATCHv7 01/18] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..4f4188d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ 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_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
1.7.4.1
--
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
[PATCHv7 06/18] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 2769f67..3670088 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1124,6 +1124,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1144,6 +1145,7 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.7.4.1 -- 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
[PATCHv7 04/18] I2C: OMAP: I2C register restore only if context is lost
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c |3 ++
drivers/i2c/busses/i2c-omap.c | 52 ++--
include/linux/i2c-omap.h |1 +
3 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a882558..45389db 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -157,9 +158,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
#define SYSC_SIDLEMODE_MASK(0x3 3)
@@ -184,6 +182,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -206,6 +205,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -1025,6 +1025,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1151,12 +1152,32 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ 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_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+}
static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
@@ -1179,24 +1200,19 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ int loss_cnt;
- 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,
[PATCHv7 03/18] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e402ebb..a882558 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,16 +147,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK(1 0)
@@ -319,6 +318,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
dev-westate);
}
}
+ return 0;
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -471,6 +471,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, (OMAP_I2C_SYSTEST_ST_EN
+ | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -597,6 +622,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.4.1
--
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
[PATCHv7 02/18] I2C: OMAP: Remove reset at init
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
omap_i2c_reset is added in those places to effect the reset.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4f4188d..e402ebb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,15 +269,9 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-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, buf = 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,
@@ -325,6 +319,16 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-westate);
}
}
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
@@ -548,6 +552,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return r;
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
+ omap_i2c_reset(dev);
omap_i2c_init(dev);
return -ETIMEDOUT;
}
@@ -558,6 +563,7 @@ 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_reset(dev);
omap_i2c_init(dev);
return -EIO;
}
--
1.7.4.1
--
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
[PATCHv7 18/18] I2C: OMAP: Rename the 1p153 to the erratum id i462
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2bf8120..667d344 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -170,7 +170,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
-#define I2C_OMAP3_1P153(1 1)
+#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
struct device *dev;
@@ -753,11 +753,11 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
#endif
/*
- * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * OMAP3430 Errata i462: When an XRDY/XDR is hit, wait for XUDF before writing
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
unsigned long timeout = 1;
@@ -920,8 +920,8 @@ complete:
break;
}
- if ((dev-errata I2C_OMAP3_1P153)
- errata_omap3_1p153(dev, stat, err))
+ if ((dev-errata I2C_OMAP_ERRATA_I462)
+ errata_omap3_i462(dev, stat, err))
goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
@@ -1061,7 +1061,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-errata |= I2C_OMAP_ERRATA_I207;
if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
- dev-errata |= I2C_OMAP3_1P153;
+ dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
1.7.4.1
--
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
[PATCHv7 05/18] I2C: OMAP: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are
clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 45389db..2769f67 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1179,10 +1179,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev-dev_lost_count = _dev-get_context_loss_count(dev);
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.7.4.1
--
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
[PATCHv7 17/18] I2C: OMAP: Do not set the XUDF if the underflow is not reached
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7489eb6..2bf8120 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -765,7 +765,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- *err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
@@ -778,6 +777,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
return 0;
}
+ *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
--
1.7.4.1
--
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
[PATCHv7 13/18] I2C: OMAP: Handle error check for pm runtime
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8258597..f371d4f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -616,7 +616,11 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
int i;
int r;
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, r);
+ return r;
+ }
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1044,7 +1048,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed:%d\n, r);
+ return r;
+ }
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1129,12 +1137,17 @@ err_unuse_clocks:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
+ int ret;
platform_set_drvdata(pdev, NULL);
free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
- pm_runtime_get_sync(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, r);
+ return ret;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.4.1
--
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
[PATCHv7 15/18] I2C: OMAP: make the read ready processing a separate function
No functional change. Makes the read ready processing a separate
function. This is to avoid extremely long level of indentation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 86 +---
1 files changed, 45 insertions(+), 41 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c396cb7..666a365 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -786,6 +786,49 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev,
u16 *stat, int *err)
return 0;
}
+static int process_read_rdy(struct omap_i2c_dev *dev)
+{
+ u8 num_bytes = 1;
+ u16 stat, w;
+
+ if (dev-errata I2C_OMAP_ERRATA_I207)
+ i2c_omap_errata_i207(dev, stat);
+
+ if (dev-fifo_size) {
+ if (stat OMAP_I2C_STAT_RRDY)
+ num_bytes = dev-fifo_size;
+ else/* read RXSTAT on RDR interrupt */
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) 8) 0x3F;
+ }
+ while (num_bytes) {
+ num_bytes--;
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ if (dev-buf_len) {
+ *dev-buf++ = w;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and omap4 is 8 bit wide
+*/
+ if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
+ } else {
+ if (stat OMAP_I2C_STAT_RRDY)
+ dev_err(dev-dev,
+ RRDY IRQ while no data requested\n);
+ if (stat OMAP_I2C_STAT_RDR)
+ dev_err(dev-dev,
+ RDR IRQ while no data requested\n);
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
@@ -836,48 +879,9 @@ complete:
return IRQ_HANDLED;
}
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
- u8 num_bytes = 1;
-
- if (dev-errata I2C_OMAP_ERRATA_I207)
- i2c_omap_errata_i207(dev, stat);
+ if (process_read_rdy(dev) == -EIO)
+ break;
- if (dev-fifo_size) {
- if (stat OMAP_I2C_STAT_RRDY)
- num_bytes = dev-fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
-8) 0x3F;
- }
- while (num_bytes) {
- num_bytes--;
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev-buf_len) {
- *dev-buf++ = w;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- } else {
- if (stat OMAP_I2C_STAT_RRDY)
- dev_err(dev-dev,
- RRDY IRQ while no data
-requested\n);
- if (stat OMAP_I2C_STAT_RDR)
- dev_err(dev-dev,
- RDR IRQ while no data
-requested\n);
- break;
- }
- }
[PATCHv7 00/18] I2C updates
The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. - Adds a patch to use devm_* functions - Also checks the return type of the get_sync and in case of errors prevents register access, also print the cause of failure in case of errors. - In case of i2c remove register access was done without any get_sync fix the same. - Adds a pdata function pointer to do context save restore - Split the omap_i2c_isr to increase readability - Make the i2c use SET_RUNTIME_PM_OPS - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. - As discussed in [2] Paul has queued the flag for context restore patch, removing it from the series. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html [2] http://www.spinics.net/lists/linux-i2c/msg07685.html Tested on omap4sdp and omap3sdp. The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-next Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (15): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Remove reset at init I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Optimise the remove code I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: use devm_* functions I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: make the read ready processing a separate function I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 348 +++-- include/linux/i2c-omap.h |1 + 3 files changed, 198 insertions(+), 154 deletions(-) -- 1.7.4.1 -- 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
[PATCHv7 08/18] I2C: OMAP: Fix the error handling
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto err_free_irq;
}
...
return 0;
err_free_irq:
free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
This may access the i2c registers without the clocks.
Attempting to fix the same by moving the pm_rintime_put after the error check.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2096726..a461097 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1095,8 +1095,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id,
dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed);
- pm_runtime_put(dev-dev);
-
adap = dev-adapter;
i2c_set_adapdata(adap, dev);
adap-owner = THIS_MODULE;
@@ -1116,6 +1114,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
+ pm_runtime_put(dev-dev);
+
return 0;
err_free_irq:
--
1.7.4.1
--
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
[PATCHv7 11/18] I2C: OMAP: use devm_* functions
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_mem_region and
devm_ioremap for data that is allocated in the probe function of a platform
device and is only freed in the remove function.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 121c52e..86be475 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -995,17 +995,17 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
+ ioarea = devm_request_mem_region(pdev-dev, mem-start,
+ resource_size(mem), pdev-name);
if (!ioarea) {
dev_err(pdev-dev, I2C region already claimed\n);
return -EBUSY;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -1029,11 +1029,10 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
+ dev-base = devm_ioremap(pdev-dev, mem-start, resource_size(mem));
+ if (!dev-base)
+ return -ENOMEM;
+
platform_set_drvdata(pdev, dev);
@@ -1121,13 +1120,8 @@ err_free_irq:
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
-err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1135,7 +1129,6 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
platform_set_drvdata(pdev, NULL);
@@ -1143,10 +1136,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
i2c_del_adapter(dev-adapter);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.4.1
--
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
[PATCHv7 12/18] I2C: OMAP: Fix the crash in i2c remove
In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Cc: sta...@vger.kernel.org Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 86be475..8258597 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1134,7 +1134,9 @@ static int __devexit omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); return 0; } -- 1.7.4.1 -- 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: [PATCHv7 00/18] I2C updates
Please ignore this series sent the wrong patches by mistake. Will resend. On Wednesday 11 April 2012 04:22 PM, Shubhrajyoti D wrote: The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. - Adds a patch to use devm_* functions - Also checks the return type of the get_sync and in case of errors prevents register access, also print the cause of failure in case of errors. - In case of i2c remove register access was done without any get_sync fix the same. - Adds a pdata function pointer to do context save restore - Split the omap_i2c_isr to increase readability - Make the i2c use SET_RUNTIME_PM_OPS - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. - As discussed in [2] Paul has queued the flag for context restore patch, removing it from the series. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html [2] http://www.spinics.net/lists/linux-i2c/msg07685.html Tested on omap4sdp and omap3sdp. The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-next Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (15): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Remove reset at init I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Optimise the remove code I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: use devm_* functions I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: make the read ready processing a separate function I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 348 +++-- include/linux/i2c-omap.h |1 + 3 files changed, 198 insertions(+), 154 deletions(-) -- 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: hwmod: Make omap_hwmod_softreset wait for reset status
Hi Paul, On Wednesday 11 April 2012 05:41 AM, Paul Walmsley wrote: Just noticed that this change results in I2C softreset failed messages on OMAP2/3/4 on v3.4-rc2. For example, on 2420: [0.200378] omap_hwmod: i2c1: softreset failed (waited 1 usec) [0.222076] omap_hwmod: i2c2: softreset failed (waited 1 usec) Looking more closely at the code, I think the intention of the original code was basically correct. HDQ and I2C both need to execute some custom reset code after the SOFTRESET bit is set, but before the RESETDONE bit is tested. After this patch, the internal hwmod code tries to wait for RESETDONE to change, before the custom code runs -- and that is going to fail. Just out of curiosity, was the change in this patch prompted by some code that needed the change? Or was this a theoretical problem, driven by a code review? The changes were done to fix up random L3 interconnect errors that Anand G was seeing(during i2c reset operation) on some customer platforms. I seem to have completely overlooked the I2C_EN programming part done in omap_i2c_reset() function when I did the patch. While the patch did fix the issue for Anand, I guess it was because of the additional delay post reset, waiting on the RESETDONE bit and timing out, before accessing the i2c_con register. So looks like this patch should certainly be reverted but atleast some platforms/modules (the issue was seen on OMAP4/i2c) will need some delay between the omap_hwmod_softreset() call and any subsequent module register accesses. The patch from Fernando [1] can be quite useful if we can use the 'srst_udelay' field to populate the appropriate delay needed which can then be used up in omap_hwmod_softreset() function. I am out sick today, but I can try some on these lines tomorrow once I am in office, if the approach seems fine to you. Btw, is [1] queued already by you/Benoit to go upstream or are there issues with it? regards, Rajendra [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086713.html -- 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
[PATCHv7 01/18] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..4f4188d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ 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_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
1.7.4.1
--
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
[PATCHv7 03/18] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e402ebb..a882558 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,16 +147,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK(1 0)
@@ -319,6 +318,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
dev-westate);
}
}
+ return 0;
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -471,6 +471,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, (OMAP_I2C_SYSTEST_ST_EN
+ | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -597,6 +622,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.4.1
--
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
[PATCHv7 09/18] I2C: OMAP: Correct I2C revision for OMAP3
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a461097..959e97c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_4430 0x40
+#define OMAP_I2C_REV_ON_3430_3530 0x3C
+#define OMAP_I2C_REV_ON_3630_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } 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
@@ -1051,7 +1051,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP3_1P153;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1069,7 +1069,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
1.7.4.1
--
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
[PATCHv7 13/18] I2C: OMAP: Handle error check for pm runtime
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8258597..dd65416 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -616,7 +616,11 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
int i;
int r;
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, r);
+ return r;
+ }
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1044,7 +1048,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed:%d\n, r);
+ return r;
+ }
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1129,12 +1137,17 @@ err_unuse_clocks:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
+ int ret;
platform_set_drvdata(pdev, NULL);
free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
- pm_runtime_get_sync(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, ret);
+ return ret;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.4.1
--
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
[PATCHv7 16/18] I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
From: Tasslehoff Kjappfot tasskj...@gmail.com i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index dd78ba1..f28bd5d 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -431,11 +431,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1060,6 +1055,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430_3530) dev-errata |= I2C_OMAP3_1P153; -- 1.7.4.1 -- 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
[PATCHv7 00/18] I2C updates
The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. - Adds a patch to use devm_* functions - Also checks the return type of the get_sync and in case of errors prevents register access, also print the cause of failure in case of errors. - In case of i2c remove register access was done without any get_sync fix the same. - Adds a pdata function pointer to do context save restore - Split the omap_i2c_isr to increase readability - Make the i2c use SET_RUNTIME_PM_OPS - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. - As discussed in [2] Paul has queued the flag for context restore patch, removing it from the series. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html [2] http://www.spinics.net/lists/linux-i2c/msg07685.html Tested on omap4sdp and omap3sdp. The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-next Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (15): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Remove reset at init I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Optimise the remove code I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: use devm_* functions I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: make the read ready processing a separate function I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 348 +++-- include/linux/i2c-omap.h |1 + 3 files changed, 198 insertions(+), 154 deletions(-) -- 1.7.4.1 -- 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
[PATCHv7 15/18] I2C: OMAP: make the read ready processing a separate function
No functional change. Makes the read ready processing a separate
function. This is to avoid extremely long level of indentation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 86 +---
1 files changed, 45 insertions(+), 41 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 28de1d2..dd78ba1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -786,6 +786,49 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev,
u16 *stat, int *err)
return 0;
}
+static int process_read_rdy(struct omap_i2c_dev *dev)
+{
+ u8 num_bytes = 1;
+ u16 stat, w;
+
+ if (dev-errata I2C_OMAP_ERRATA_I207)
+ i2c_omap_errata_i207(dev, stat);
+
+ if (dev-fifo_size) {
+ if (stat OMAP_I2C_STAT_RRDY)
+ num_bytes = dev-fifo_size;
+ else/* read RXSTAT on RDR interrupt */
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) 8) 0x3F;
+ }
+ while (num_bytes) {
+ num_bytes--;
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ if (dev-buf_len) {
+ *dev-buf++ = w;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and omap4 is 8 bit wide
+*/
+ if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
+ } else {
+ if (stat OMAP_I2C_STAT_RRDY)
+ dev_err(dev-dev,
+ RRDY IRQ while no data requested\n);
+ if (stat OMAP_I2C_STAT_RDR)
+ dev_err(dev-dev,
+ RDR IRQ while no data requested\n);
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
@@ -836,48 +879,9 @@ complete:
return IRQ_HANDLED;
}
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
- u8 num_bytes = 1;
-
- if (dev-errata I2C_OMAP_ERRATA_I207)
- i2c_omap_errata_i207(dev, stat);
+ if (process_read_rdy(dev) == -EIO)
+ break;
- if (dev-fifo_size) {
- if (stat OMAP_I2C_STAT_RRDY)
- num_bytes = dev-fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
-8) 0x3F;
- }
- while (num_bytes) {
- num_bytes--;
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev-buf_len) {
- *dev-buf++ = w;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- } else {
- if (stat OMAP_I2C_STAT_RRDY)
- dev_err(dev-dev,
- RRDY IRQ while no data
-requested\n);
- if (stat OMAP_I2C_STAT_RDR)
- dev_err(dev-dev,
- RDR IRQ while no data
-requested\n);
- break;
- }
- }
[PATCHv7 07/18] I2C: OMAP: Optimise the remove code
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3670088..2096726 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1134,8 +1134,7 @@ err_release_region:
return r;
}
-static int
-omap_i2c_remove(struct platform_device *pdev)
+static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
@@ -1228,7 +1227,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
- .remove = omap_i2c_remove,
+ .remove = __devexit_p(omap_i2c_remove),
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
--
1.7.4.1
--
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
[PATCHv7 05/18] I2C: OMAP: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are
clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 45389db..2769f67 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1179,10 +1179,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev-dev_lost_count = _dev-get_context_loss_count(dev);
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.7.4.1
--
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
[PATCHv7 02/18] I2C: OMAP: Remove reset at init
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
omap_i2c_reset is added in those places to effect the reset.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4f4188d..e402ebb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,15 +269,9 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-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, buf = 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,
@@ -325,6 +319,16 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-westate);
}
}
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
@@ -548,6 +552,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return r;
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
+ omap_i2c_reset(dev);
omap_i2c_init(dev);
return -ETIMEDOUT;
}
@@ -558,6 +563,7 @@ 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_reset(dev);
omap_i2c_init(dev);
return -EIO;
}
--
1.7.4.1
--
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
[PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
@@ -1233,7 +1230,7 @@ static struct platform_driver omap_i2c_driver = {
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
- .pm = OMAP_I2C_PM_OPS,
+ .pm = omap_i2c_pm_ops,
.of_match_table = of_match_ptr(omap_i2c_of_match),
},
};
--
1.7.4.1
--
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
[PATCHv7 18/18] I2C: OMAP: Rename the 1p153 to the erratum id i462
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2b7182b..705a0f7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -170,7 +170,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
-#define I2C_OMAP3_1P153(1 1)
+#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
struct device *dev;
@@ -753,11 +753,11 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
#endif
/*
- * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * OMAP3430 Errata i462: When an XRDY/XDR is hit, wait for XUDF before writing
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
unsigned long timeout = 1;
@@ -920,8 +920,8 @@ complete:
break;
}
- if ((dev-errata I2C_OMAP3_1P153)
- errata_omap3_1p153(dev, stat, err))
+ if ((dev-errata I2C_OMAP_ERRATA_I462)
+ errata_omap3_i462(dev, stat, err))
goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
@@ -1061,7 +1061,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-errata |= I2C_OMAP_ERRATA_I207;
if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
- dev-errata |= I2C_OMAP3_1P153;
+ dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
1.7.4.1
--
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
[PATCHv7 17/18] I2C: OMAP: Do not set the XUDF if the underflow is not reached
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f28bd5d..2b7182b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -765,7 +765,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- *err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
@@ -778,6 +777,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
return 0;
}
+ *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
--
1.7.4.1
--
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
[PATCHv7 11/18] I2C: OMAP: use devm_* functions
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_mem_region and
devm_ioremap for data that is allocated in the probe function of a platform
device and is only freed in the remove function.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 121c52e..86be475 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -995,17 +995,17 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
+ ioarea = devm_request_mem_region(pdev-dev, mem-start,
+ resource_size(mem), pdev-name);
if (!ioarea) {
dev_err(pdev-dev, I2C region already claimed\n);
return -EBUSY;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -1029,11 +1029,10 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
+ dev-base = devm_ioremap(pdev-dev, mem-start, resource_size(mem));
+ if (!dev-base)
+ return -ENOMEM;
+
platform_set_drvdata(pdev, dev);
@@ -1121,13 +1120,8 @@ err_free_irq:
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
-err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1135,7 +1129,6 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
platform_set_drvdata(pdev, NULL);
@@ -1143,10 +1136,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
i2c_del_adapter(dev-adapter);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.4.1
--
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
[PATCHv7 04/18] I2C: OMAP: I2C register restore only if context is lost
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c |3 ++
drivers/i2c/busses/i2c-omap.c | 52 ++--
include/linux/i2c-omap.h |1 +
3 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a882558..45389db 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -157,9 +158,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
#define SYSC_SIDLEMODE_MASK(0x3 3)
@@ -184,6 +182,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -206,6 +205,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -1025,6 +1025,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1151,12 +1152,32 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ 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_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+}
static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
@@ -1179,24 +1200,19 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ int loss_cnt;
- 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,
[PATCHv7 06/18] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 2769f67..3670088 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1124,6 +1124,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1144,6 +1145,7 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.7.4.1 -- 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
[PATCHv7 10/18] I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the wait_for_completion_timeout returns long.
Original patch is
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7bbc736e60c4188a11aaa74bc6e6
Cc : Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 959e97c..121c52e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -502,7 +502,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg, int stop)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
- int r;
+ unsigned long timeout;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -570,12 +570,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ timeout = wait_for_completion_timeout(dev-cmd_complete,
+ OMAP_I2C_TIMEOUT);
dev-buf_len = 0;
- if (r 0)
- return r;
- if (r == 0) {
+ if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_reset(dev);
omap_i2c_init(dev);
--
1.7.4.1
--
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
[PATCHv7 12/18] I2C: OMAP: Fix the crash in i2c remove
In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Cc: sta...@vger.kernel.org Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 86be475..8258597 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1134,7 +1134,9 @@ static int __devexit omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); return 0; } -- 1.7.4.1 -- 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
[PATCHv7 08/18] I2C: OMAP: Fix the error handling
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto err_free_irq;
}
...
return 0;
err_free_irq:
free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
This may access the i2c registers without the clocks.
Attempting to fix the same by moving the pm_rintime_put after the error check.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2096726..a461097 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1095,8 +1095,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id,
dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed);
- pm_runtime_put(dev-dev);
-
adap = dev-adapter;
i2c_set_adapdata(adap, dev);
adap-owner = THIS_MODULE;
@@ -1116,6 +1114,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
+ pm_runtime_put(dev-dev);
+
return 0;
err_free_irq:
--
1.7.4.1
--
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: [PATCHv7 01/18] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
On Wed, Apr 11, 2012 at 04:42:39PM +0530, Shubhrajyoti D wrote: The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME. This patch removes the omap_i2c_unidle/idle functions and folds them into the runtime callbacks. This fixes the below warn when CONFIG_PM_RUNTIME is not defined CC arch/arm/mach-omap2/board-ti8168evm.o drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not used drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used CC net/ipv4/ip_forward.o Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com how about just moving them into the #ifdef ? /me thinks it's easier to read with the function. Matter of taste though, it's not that much code. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 02/15] ARM: mark const init data with __initconst instead of __initdata
Hi Uwe, On 3/31/2012 1:34 AM, Uwe Kleine-König wrote: As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de For the DaVinci parts, Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- 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: [PATCHv7 11/18] I2C: OMAP: use devm_* functions
On Wed, Apr 11, 2012 at 04:42:49PM +0530, Shubhrajyoti D wrote: The various devm_ functions allocate memory that is released when a driver detaches. This patch uses devm_kzalloc, devm_request_mem_region and devm_ioremap for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 29 + 1 files changed, 9 insertions(+), 20 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 121c52e..86be475 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -995,17 +995,17 @@ omap_i2c_probe(struct platform_device *pdev) return -ENODEV; } - ioarea = request_mem_region(mem-start, resource_size(mem), - pdev-name); + ioarea = devm_request_mem_region(pdev-dev, mem-start, + resource_size(mem), pdev-name); you could use devm_request_and_ioremap() -- balbi signature.asc Description: Digital signature
Re: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. Hi sameo Since I am not seeing this patch in linux-next labled 3.4.rc2 on 10th april 2012; please let me know your plan to queue this patch for the main line. Thanks and Regards Keshava -- 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 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Tue, Apr 10, 2012 at 9:41 PM, Tony Lindgren t...@atomide.com wrote:
* Govindraj.R govindraj.r...@ti.com [120410 06:44]:
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,11 +120,63 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+static struct omap_device_pad default_omap_uart_pads[2] __initdata;
Won't the default_omap_uart_pads get overwritten for each port?
We need that information in the driver too for each port? Why don't you
just allocate bdata.pads in omap_serial_board_init as we now assume it's
needed for each port?
Yes can be part of omap_uart_state structure.
+static void __init omap_serial_fill_default_pads(struct omap_board_data
*bdata)
{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+
+ if (bdata-id != 2) {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx.uart%d_rx, bdata-id + 1, bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx.uart%d_tx, bdata-id + 1, bdata-id + 1);
+ } else {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx_irrx.uart%d_rx_irrx, bdata-id + 1,
+ bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx_irtx.uart%d_tx_irtx, bdata-id + 1,
+ bdata-id + 1);
+ }
This would be simpler with something like this (untested):
char *rx_fmt, *tx_fmt;
int uart_nr = bdata-id + 1;
if (bdata-id == 2) {
rx_fmt = uart%d_rx.uart%d_rx;
tx_fmt = uart%d_tx.uart%d_tx;
} else {
rx_fmt = uart%d_rx_irrx.uart%d_rx_irrx;
tx_fmt = uart%d_tx_irtx.uart%d_tx_irtx;
}
snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
uart_nr, uart_nr);
snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
uart_nr, uart_nr);
okay fine.
+ if (omap_mux_get_by_name(rx_pad_name, rx_partition, rx_mux) = 0
+ omap_mux_get_by_name
+ (tx_pad_name, tx_partition, tx_mux) = 0) {
+ u16 tx_mode, rx_mode;
+
+ tx_mode = omap_mux_read(tx_partition, tx_mux-reg_offset);
+ rx_mode = omap_mux_read(rx_partition, rx_mux-reg_offset);
+
+ /*
+ * Check if uart is used in default tx/rx mode i.e. in mux
mode0
+ * if yes then configure rx pin for wake up capability
+ */
+ if (!(rx_mode 0x07) !(tx_mode 0x07)) {
+ default_omap_uart_pads[0].name = rx_pad_name;
+ default_omap_uart_pads[0].flags =
+ OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP;
+ default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+ default_omap_uart_pads[0].idle = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+
+ default_omap_uart_pads[1].name = tx_pad_name;
+ default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
+ OMAP_MUX_MODE0;
+ bdata-pads = default_omap_uart_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_omap_uart_pads);
+ }
+ }
}
Then looking at omap_serial_board_init, it still looks wrong:
void __init omap_serial_board_init(struct omap_uart_port_info *info)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
bdata.pads = NULL;
bdata.pads_cnt = 0;
if (cpu_is_omap44xx() || cpu_is_omap34xx())
omap_serial_fill_default_pads(bdata);
Why don't you fill the pads for omap2? It has the same pads, although
it does not have the serial wake-up events working.
And why don't you exit if omap_serial_fill_default_pads fails for the
no info case?
Shouldn't it be something like:
if (!info) {
res = omap_serial_fill_default_pads(bdata);
if (!res)
return;
Re: [PATCHv7 11/18] I2C: OMAP: use devm_* functions
On Wednesday 11 April 2012 05:04 PM, Felipe Balbi wrote: On Wed, Apr 11, 2012 at 04:42:49PM +0530, Shubhrajyoti D wrote: The various devm_ functions allocate memory that is released when a driver detaches. This patch uses devm_kzalloc, devm_request_mem_region and devm_ioremap for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 29 + 1 files changed, 9 insertions(+), 20 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 121c52e..86be475 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -995,17 +995,17 @@ omap_i2c_probe(struct platform_device *pdev) return -ENODEV; } -ioarea = request_mem_region(mem-start, resource_size(mem), -pdev-name); +ioarea = devm_request_mem_region(pdev-dev, mem-start, +resource_size(mem), pdev-name); you could use devm_request_and_ioremap() 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: [PATCHv7 01/18] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
Hi Felipe, On Wed, Apr 11, 2012 at 5:02 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Apr 11, 2012 at 04:42:39PM +0530, Shubhrajyoti D wrote: The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME. This patch removes the omap_i2c_unidle/idle functions and folds them into the runtime callbacks. This fixes the below warn when CONFIG_PM_RUNTIME is not defined CC arch/arm/mach-omap2/board-ti8168evm.o drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not used drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used CC net/ipv4/ip_forward.o Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com how about just moving them into the #ifdef ? /me thinks it's easier to read with the function. Matter of taste though, it's not that much code. Kevin preferred folding into the runtime functions. http://www.spinics.net/lists/linux-omap/msg62764.html Don't feel strongly though. -- 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
Re: [PATCHv7 01/18] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
On Wed, Apr 11, 2012 at 05:29:07PM +0530, Shubhrajyoti Datta wrote: Hi Felipe, On Wed, Apr 11, 2012 at 5:02 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Apr 11, 2012 at 04:42:39PM +0530, Shubhrajyoti D wrote: The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME. This patch removes the omap_i2c_unidle/idle functions and folds them into the runtime callbacks. This fixes the below warn when CONFIG_PM_RUNTIME is not defined CC arch/arm/mach-omap2/board-ti8168evm.o drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not used drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used CC net/ipv4/ip_forward.o Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com how about just moving them into the #ifdef ? /me thinks it's easier to read with the function. Matter of taste though, it's not that much code. Kevin preferred folding into the runtime functions. http://www.spinics.net/lists/linux-omap/msg62764.html Don't feel strongly though. ok, I stand corrected ;-) No need to change your patch again ;-) -- balbi signature.asc Description: Digital signature
RE: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Bablpi,
On Wed, Apr 11, 2012 at 17:05:38, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device
*dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
No. using SET_RUNTIME_PM_OPS will make it NULL when !CONFIG_PM_RUNTIME
Kindly correct me if I am wrong.
--
balbi
Regards,
Gururaja
--
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] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On 04/11/2012 05:03 AM, Rajendra Nayak wrote:
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Ack
Rob
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
--
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: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
On Wed, Apr 11, 2012 at 12:09:22PM +, Hebbar, Gururaja wrote:
Bablpi,
On Wed, Apr 11, 2012 at 17:05:38, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device
*dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
No. using SET_RUNTIME_PM_OPS will make it NULL when !CONFIG_PM_RUNTIME
Kindly correct me if I am wrong.
you will have a defined structure with NULL members, but the structure
itself is still valid.
--
balbi
signature.asc
Description: Digital signature
RE: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
On Wed, Apr 11, 2012 at 17:40:58, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 12:09:22PM +, Hebbar, Gururaja wrote:
Bablpi,
On Wed, Apr 11, 2012 at 17:05:38, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct
device *dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
No. using SET_RUNTIME_PM_OPS will make it NULL when !CONFIG_PM_RUNTIME
Kindly correct me if I am wrong.
you will have a defined structure with NULL members, but the structure
itself is still valid.
Oops. You are correct. I stand corrected.
--
balbi
Regards,
Gururaja
--
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: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Hi Felipe,
On Wed, Apr 11, 2012 at 5:05 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device
*dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
Will correct it .
Thanks,
--
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
Re: Suspend broken on 3.3?
On Tue, Apr 10, 2012 at 11:33 PM, Kevin Hilman khil...@ti.com wrote:
Raja, Govindraj govindraj.r...@ti.com writes:
Hi Kevin,
On Mon, Apr 9, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote:
Paul Walmsley p...@pwsan.com writes:
[...]
Just to summarize on how the behavior should be IIUC if user disables uart
wakeup from sysfs and does system wide suspend it should _not_ wakeup
from uart.
Correct.
And if the system is woken up from suspend due to keypad press and
uart resumes we have keep module level wakeup enabled from here.
Keypad press, or any other wakeup source, yes.
Basically, UART wakeups (module and IO) should be enabled all the time,
*except* when suspending and wakeups were disabled by sysfs control.
Here is the patch [1] to do the same.
Tested on beagle-XM with retention and off mode in suspend path and
idle path by disabling/enabling the uart wakeups from sysfs for the console.
--
Thanks,
Govindraj.R
[1]:
From 4e2502015e8b69d3a5047ae9f92820e4833e6d74 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 27 Mar 2012 18:55:00 +0530
Subject: [PATCH] OMAP2+: UART: Correct the module level wakeup enable/disable
mechanism
The commit (62f3ec5 ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts)
removed module level wakeup enable/disable mechanism and retained only
the pad wakeup handling.
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs. The module level wakeups are enabled by
default from bootloader, however the wakeups can be enabled/disabled
using sysfs entry
echo disabled /sys/devices/platform/omap/omap_uart.X/power/wakeup
[X=0,1,2,3]
Since module level wakeups were left enabled from bootup and when
wakeups were disabled from sysfs uart module level wakeups were
still happening as they were not getting disabled.
The wakeup can be left enabled by default and should be disabled only
when disabled from sysfs and thus prevent system from uart wakeup in suspend
path. However in idle path the wakeup can be enabled and thus uart can wakeup
after gating of uart functional clocks.
Thanks to Kevin Hilman khil...@ti.com for suggesting this.
Discussion References:
http://www.spinics.net/lists/linux-omap/msg67764.html
http://www.spinics.net/lists/linux-omap/msg67838.html
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 88 +-
drivers/tty/serial/omap-serial.c | 30 +
2 files changed, 97 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..9312d6b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -41,6 +41,7 @@
#include prm-regbits-34xx.h
#include control.h
#include mux.h
+#include iomap.h
/*
* NOTE: By default the serial auto_suspend timeout is disabled as it causes
@@ -55,6 +56,10 @@
struct omap_uart_state {
int num;
+ void __iomem *wk_st;
+ void __iomem *wk_en;
+ u32 wk_mask;
+
struct list_head node;
struct omap_hwmod *oh;
};
@@ -80,17 +85,46 @@ static struct omap_uart_port_info
omap_serial_default_info[] __initdata = {
};
#ifdef CONFIG_PM
+
+static void omap_uart_disable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
+static void omap_uart_enable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
struct omap_device *od = to_omap_device(pdev);
+ struct omap_uart_state *uart;
if (!od)
return;
- if (enable)
+ list_for_each_entry(uart, uart_list, node)
+ if (pdev-id == uart-num)
+ break;
+
+ if (enable) {
+ omap_uart_enable_module_wakeup(uart);
omap_hwmod_enable_wakeup(od-hwmods[0]);
- else
+ } else {
+ omap_uart_disable_module_wakeup(uart);
omap_hwmod_disable_wakeup(od-hwmods[0]);
+ }
}
/*
@@ -112,7 +146,56 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev)
omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_SMART);
}
+static void omap_uart_idle_init(struct omap_uart_state *uart)
+{
+ if (cpu_is_omap34xx() !cpu_is_ti816x()) {
+ u32 mod = (uart-num == 2) ? OMAP3430_PER_MOD : CORE_MOD;
+
+ uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
+ uart-wk_st = OMAP34XX_PRM_REGADDR(mod, PM_WKST1);
+
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 3:33 PM, Rajendra Nayak rna...@ti.com wrote:
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Looks good to me
Reviewed-by: Balaji T K balaj...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
--
1.7.1
--
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] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
Hi,
On Wed, Apr 11 2012, Rajendra Nayak wrote:
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
Thanks, pushed to mmc-next for 3.4.
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
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: PM related performance degradation on OMAP3
On 2012-04-06 16:50, Grazvydas Ignotas wrote: Hello, I'm DMA seeing performance loss related to CONFIG_PM on OMAP3. # CONFIG_PM is set: echo 3 /proc/sys/vm/drop_caches # file copy from NAND (using NAND driver in DMA mode) dd if=/mnt/tmp/a of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 9.088714 seconds, 3.5MB/s # file read from SD (hsmmc uses DMA) dd if=/dev/mmcblk0 of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 2.065460 seconds, 15.5MB/s # CONFIG_PM not set: # NAND dd if=/mnt/tmp/a of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 5.653534 seconds, 5.7MB/s # SD dd if=/dev/mmcblk0 of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 1.919007 seconds, 16.7MB/s While SD card performance loss is not that bad (~7%), NAND one is worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also cpuidle states over sysfs, it did not have any significant effect. Is there something else to try? I'm guessing this is caused by CPU wakeup latency to service DMA interrupts? I've noticed that if I keep CPU busy, the loss is reduced almost completely. Talking about cpuidle, what's the difference between C1 and C2 states? They look mostly the same. Then there is omap3_do_wfi, it seems to be unconditionally putting SDRC on self-refresh, would it make sense to just do wfi in higher power states, like OMAP4 seems to be doing? I fear I'm seeing similar problems with 3.3. I have my board (similar to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network performance on 3.3. For example, if I use TFTP to download a large file (~35MB), I get this: 3.0: 42.5 sec 3.3: 625.0 sec That's a factor of 15 worse! I'd like to try building without CONFIG_PM, but when I disabled this, my kernel fails to come up. Can someone point me to the magic to build without CONFIG_PM, or possibly send me a working config file? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 1/9] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 04/11/2012 12:11 AM, Mohammed, Afzal wrote:
Hi Jon,
On Wed, Apr 11, 2012 at 00:53:14, Hunter, Jon wrote:
I agree with your argument but I was thinking today only OMAP uses the
GPMC so we could not worry about this. Ok, leave as-is, but can we
modify the code as follows as the else if is not really needed...
if (gpmc-num_irq GPMC_NR_IRQ) {
dev_warn(gpmc-dev, Insufficient interrupts for device\n);
return -EINVAL;
}
gpmc-num_irq = GPMC_NR_IRQ;
Yes, it is better
Furthermore, GPMC_NR_IRQ is defined as 6 which is correct for OMAP2/3
but not for OMAP4/5, it is 5. Therefore, we need to detect whether we
are using an OMAP2/3 or OMAP4+ and set num_irqs based upon this. This
could be done in the probe and we can avoid passing this.
Is it dependent on OMAPX or GPMC IP version? if it is IP version, then
driver
can be enhanced to handle it, if not, platform has to pass this information.
Here are the GPMC IP revisions ...
OMAP5430 = 0x0060
OMAP4430 = 0x0060
OMAP3630 = 0x0050
OMAP3430 = 0x0050
So this should work for OMAP. We should check OMAP2 as well. What about
the AMxxx devices?
I badly needed this information, thanks.
AM3359 = 0x0060, it has only 2 waitpin interrupts
Great so this is consistent!
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res == NULL)
+ dev_warn(gpmc-dev, Failed to get resource: irq\n);
+ else
+ gpmc-master_irq = res-start;
Why not return an error if the IRQ is not found? We don't know if anyone
will be trying to use them.
Why do you want to do that ?
Because this indicates a BUG :-)
I disagree, this need not be considered a bug always,
for eg. If gpmc irq is not connected to intc
Ok, so for devices existing today this indicates a bug ;-)
I do not want to consider that case to be bug enough for probe
to fail, there are other drivers which does similar enhancing
its use cases,
eg. 1e351a9 mfd: Make TPS65910 usable without interrupts
Ok, fine.
At a minimum you need to improve the error handing here. If the
platform_get_resource fails you are still calling gpmc_setup_irq()
which appears to be pointless. It would be better if the gpmc irq chip
is not initialised in this case so that drivers attempting to request
these irqs failed.
Please see gpmc_setup_irq, if irq is not present, it returns in the
beginning, and gpmc_irq_chip is not initialized in that case.
Yes you are right.
+ for (gdq = gp-device_pdata, gd = gpmc-device; *gdq; gdq++,
i++) {
+ ret = gpmc_setup_device(*gdq, gd, gpmc);
+ if (IS_ERR_VALUE(ret))
+ dev_err(gpmc-dev, gpmc setup on %s failed\n,
+
(*gdq)-name);
+ else
+ gd++;
+ }
Would a while loop be simpler?
My preference is to go with for
Ok, just wondering if this could be cleaned up a little.
For travelling through array of pointers, for looks natural to me, if you
have a better way, please send it, it can be folded in next version.
Could you have num_devices to indicate how many platform devices there
are and then a simple for-loop of 0 to num_devices?
This will cause coding to be done by platform to be less simple, and my
preference is not to use another variable
Hehe, I wondered if that would make life a little more difficult. Ok
lets leave it for now.
Jon
--
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: pass minimal SoC/board data for UART from dt
On Wed, Apr 11, 2012 at 3:39 AM, Cousson, Benoit b-cous...@ti.com wrote: Yes, it is a known issue and the fix was unfortunately was not merged during -rc phases but is fixed in 3.4 and should be fixed in 3.3 stable branch as well. I received the notification from Greg KH 2 weeks ago about the stable: Patch tty: serial: OMAP: Fix oops due to NULL pdata in DT boot has been added to the 3.3-stable tree You should just switch to 3.4-rc2 or get the patch if you are stuck to 3.3. Thanks, switching to 3.4-rc kernels fixed the problem (for cramfs), and right now this works for me. Regards, Omar -- 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: PM related performance degradation on OMAP3
On Wed, Apr 11, 2012 at 5:59 PM, Gary Thomas g...@mlbassoc.com wrote: I'd like to try building without CONFIG_PM, but when I disabled this, my kernel fails to come up. Can someone point me to the magic to build without CONFIG_PM, or possibly send me a working config file? You probably need this patch: http://marc.info/?l=linux-omapm=133374930011086w=2 If it still won't boot, you'll need to enable earlyprintk both in .config and as kernel argument to see where it dies. -- Gražvydas -- 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 v4 01/12] ARM: OMAP2+: declare file-local functions as static
On Wed, 11 Apr 2012, Arnd Bergmann wrote: On Wednesday 11 April 2012, Paul Walmsley wrote: Several function declarations used only in the files in which they're declared should include the static keyboard, but don't: ^^^ ??? Heh, should have read keyword. The patch looks good otherwise, Acked-by: Arnd Bergmann a...@arndb.de Thanks for the comment, ack added. - 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: [PATCH v4 04/12] ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
On Wed, 11 Apr 2012, Roland Stigge wrote: On 04/11/2012 02:35 AM, Paul Walmsley wrote: Also interesting is that drivers/usb/host/ohci-nxp.c contains a stub for ocpi_enable() - perhaps the NXP chips use a similar OCPI IP block? I'd rather suspect a copy-paste error here since ocpi_enable() is unused in ohci-nxp.c and the extern declaration looks like an incomplete but intended removal. Will probably just remove this reference in my DT patchset. Thanks, will drop the comment from the patch description. - 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: PM related performance degradation on OMAP3
On 2012-04-11 11:23, Grazvydas Ignotas wrote: On Wed, Apr 11, 2012 at 5:59 PM, Gary Thomasg...@mlbassoc.com wrote: I'd like to try building without CONFIG_PM, but when I disabled this, my kernel fails to come up. Can someone point me to the magic to build without CONFIG_PM, or possibly send me a working config file? You probably need this patch: http://marc.info/?l=linux-omapm=133374930011086w=2 If it still won't boot, you'll need to enable earlyprintk both in .config and as kernel argument to see where it dies. That does help, but there are lots of tracebacks like these: [0.588500] [ cut here ] [0.588531] WARNING: at drivers/video/omap2/dss/dispc.c:404 dss_driver_probe+0x44/0xd8() [0.588562] Modules linked in: [0.588592] [c0012204] (unwind_backtrace+0x0/0xf8) from [c002b81c] (warn_slowpath_common+0x4c/0x64) [0.588623] [c002b81c] (warn_slowpath_common+0x4c/0x64) from [c002b850] (warn_slowpath_null+0x1c/0x24) [0.588623] [c002b850] (warn_slowpath_null+0x1c/0x24) from [c022609c] (dss_driver_probe+0x44/0xd8) [0.588653] [c022609c] (dss_driver_probe+0x44/0xd8) from [c0273e10] (driver_probe_device+0x70/0x1e4) [0.588684] [c0273e10] (driver_probe_device+0x70/0x1e4) from [c0274018] (__driver_attach+0x94/0x98) [0.588714] [c0274018] (__driver_attach+0x94/0x98) from [c027270c] (bus_for_each_dev+0x50/0x7c) [0.588745] [c027270c] (bus_for_each_dev+0x50/0x7c) from [c0273664] (bus_add_driver+0x184/0x244) [0.588775] [c0273664] (bus_add_driver+0x184/0x244) from [c02742bc] (driver_register+0x78/0x12c) [0.588775] [c02742bc] (driver_register+0x78/0x12c) from [c00085a0] (do_one_initcall+0x34/0x178) [0.588806] [c00085a0] (do_one_initcall+0x34/0x178) from [c061d7dc] (kernel_init+0x78/0x114) [0.588836] [c061d7dc] (kernel_init+0x78/0x114) from [c000e0d0] (kernel_thread_exit+0x0/0x8) [0.588867] ---[ end trace 1b75b31a2719ed24 ]--- I also had to disable the watchdog to get it up. That said, with CONFIG_PM disabled, my network performance is back to what it was in 3.0 :-) Note: I also had CONFIG_PM disabled in that kernel build, so I don't know for sure what the performance might be with that version if it were enabled. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 v4 04/12] ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
Hi,
+Alan Stern
On Tue, Apr 10, 2012 at 06:35:38PM -0600, Paul Walmsley wrote:
The OMAP1 OHCI driver needs to enable the OCPI IP block before it can
work. Previously, the driver was simply calling a symbol defined in
the OMAP platform code, but this is incorrect: drivers should be fully
decoupled from platform and architecture code.
So instead, modify the driver to call through a platform_data function
pointer instead. We skip any DT aspect, since OMAP1 is not scheduled
to be converted to DT in the near future.
This resolves the following sparse warning:
It also gets rid of a cpu_is_omap16xx() call in a driver.
In the long term, it probably makes sense to move the OCPI bus code to
somewhere under drivers/. This should avoid the whole platform_data/DT
issue with this function.
Also interesting is that drivers/usb/host/ohci-nxp.c contains a stub
for ocpi_enable() - perhaps the NXP chips use a similar OCPI IP block?
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Roland Stigge sti...@antcom.de
Cc: Felipe Balbi ba...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
FWIW:
Acked-by: Felipe Balbi ba...@ti.com
ideally ocpi.c would be a platform_driver
---
arch/arm/mach-omap1/usb.c |3 +++
arch/arm/plat-omap/include/plat/board.h |2 ++
drivers/usb/host/ohci-omap.c|5 +++--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 19de03b..e61afd9 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -29,6 +29,8 @@
#include plat/mux.h
#include plat/usb.h
+#include common.h
+
/* These routines should handle the standard chip-specific modes
* for usb0/1/2 ports, covering basic mux and transceiver setup.
*
@@ -138,6 +140,7 @@ static inline void ohci_device_init(struct
omap_usb_config *pdata)
if (cpu_is_omap7xx())
ohci_resources[1].start = INT_7XX_USB_HHC_1;
pdata-ohci_device = ohci_device;
+ pdata-ocpi_enable = ocpi_enable;
}
#else
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index d5eb4c8..4814c5b 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -91,6 +91,8 @@ struct omap_usb_config {
u32 (*usb0_init)(unsigned nwires, unsigned is_device);
u32 (*usb1_init)(unsigned nwires);
u32 (*usb2_init)(unsigned nwires, unsigned alt_pingroup);
+
+ int (*ocpi_enable)(void);
};
struct omap_lcd_config {
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 96451e4..71229cb 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -205,8 +205,9 @@ static int ohci_omap_init(struct usb_hcd *hcd)
need_transceiver = need_transceiver
|| machine_is_omap_h2() || machine_is_omap_h3();
- if (cpu_is_omap16xx())
- ocpi_enable();
+ /* XXX OMAP16xx only */
+ if (config-ocpi_enable)
+ config-ocpi_enable();
#ifdef CONFIG_USB_OTG
if (need_transceiver) {
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 10/12] ARM: OMAP1: board files: deduplicate and clean some NAND-related code
On Wed, 11 Apr 2012, Arnd Bergmann wrote:
On Wednesday 11 April 2012, Paul Walmsley wrote:
+void omap1_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+
+ mask |= (unsigned long)this-IO_ADDR_W;
+
+ writeb(cmd, (void __iomem *)mask);
+}
IO_ADDR_W is always a page aligned pointer AFAICT, so you can actually
remove both casts and make it more readable at the same time by writing
the last two lines as
writeb(cmd, this-IO_ADDR_W + mask);
Thanks, patch updated.
- 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: [PATCH v2 2/2] ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
Hi Rajendra, On Wed, 11 Apr 2012, Rajendra Nayak wrote: The changes were done to fix up random L3 interconnect errors that Anand G was seeing(during i2c reset operation) on some customer platforms. Okay. I seem to have completely overlooked the I2C_EN programming part done in omap_i2c_reset() function when I did the patch. No worries. While the patch did fix the issue for Anand, I guess it was because of the additional delay post reset, waiting on the RESETDONE bit and timing out, before accessing the i2c_con register. So looks like this patch should certainly be reverted but atleast some platforms/modules (the issue was seen on OMAP4/i2c) will need some delay between the omap_hwmod_softreset() call and any subsequent module register accesses. The patch from Fernando [1] can be quite useful if we can use the 'srst_udelay' field to populate the appropriate delay needed which can then be used up in omap_hwmod_softreset() function. I am out sick today, but I can try some on these lines tomorrow once I am in office, if the approach seems fine to you. Sorry to hear that - I hope you feel better soon. That approach sounds fine to me, but I don't think Fernando's patch will help with I2C.. Since it uses a custom reset function omap_i2c_reset(), the delay will actually need to go there. Another option though is that it might be possible to generalize the _ocp_softreset() function to handle the I2C/HDQ cases, so they wouldn't need custom reset functions. I'd guess that's probably 3.5 material, though. Btw, is [1] queued already by you/Benoit to go upstream or are there issues with it? [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086713.html Tony pulled it: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=b8a633451951d149494076393698880453bf6bfe Not sure when he plans to send it upstream, but I now think it should go up sooner as part of v3.4-rc fixes, to avoid any potential OCP bus errors. - 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: [PATCH v4 04/12] ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
Hi Felipe, On Wed, 11 Apr 2012, Felipe Balbi wrote: Acked-by: Felipe Balbi ba...@ti.com Thanks, ack added. ideally ocpi.c would be a platform_driver Agreed. - 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: PM related performance degradation on OMAP3
Gary Thomas g...@mlbassoc.com writes: [...] I fear I'm seeing similar problems with 3.3. I have my board (similar to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network performance on 3.3. For example, if I use TFTP to download a large file (~35MB), I get this: 3.0: 42.5 sec 3.3: 625.0 sec That's a factor of 15 worse! This might not be the same problem. What is the NIC being used, and does it have GPIO interrupts? If it's using GPIO interrupts, then you likely need this patch from mainline (v3.4-rc1) If that doesn't work, or you're not using GPIO interrupts, could you confirm if the patch below[2] (based on idea from Grasvydas) increases performance for you when CONFIG_PM=y. Kevin [1] Author: Kevin Hilman khil...@ti.com 2012-03-05 15:10:04 Committer: Grant Likely grant.lik...@secretlab.ca 2012-03-12 09:16:11 Parent: 25db711df3258d125dc1209800317e5c0ef3c870 (gpio/omap: Fix IRQ handling for SPARSE_IRQ) Child: 8805f410e4fb88a56552c1af42d61b38837a38fd (gpio/omap: Fix section warning for omap_mpuio_alloc_gc()) Branches: many (66) Follows: v3.3-rc7 Precedes: v3.4-rc1 gpio/omap: fix wakeups on level-triggered GPIOs While both level- and edge-triggered GPIOs are capable of generating interrupts, only edge-triggered GPIOs are capable of generating a module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.) In order to ensure that devices using level-triggered GPIOs as interrupts can also cause wakeups (e.g. from idle), this patch enables edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO bank is runtime-suspended (which also happens during idle.) This fixes a problem found in GPMC-connected network cards with GPIO interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting with NFSroot was very slow since the GPIO IRQs used by the NIC were not generating PRCM wakeups, and thus not waking the system from idle. NOTE: until v3.3, this boot-time problem was somewhat masked because the UART init prevented WFI during boot until the full serial driver was available. Preventing WFI allowed regular GPIO interrupts to fire and this problem was not seen. After the UART runtime PM cleanups, we no longer avoid WFI during boot, so GPIO IRQs that were not causing wakeups resulted in very slow IRQ response times. Tested on platforms using level-triggered GPIOs for network IRQs using the SMSC911x NIC: 3530/Overo and 3630/Zoom3. Reported-by: Tony Lindgren t...@atomide.com Tested-by: Tarun Kanti DebBarma tarun.ka...@ti.com Tested-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Grant Likely grant.lik...@secretlab.ca [2] diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 413aac4..ace4bf6 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -120,7 +120,10 @@ static int __omap3_enter_idle(struct cpuidle_device *dev, cpu_pm_enter(); /* Execute ARM wfi */ - omap_sram_idle(); + if (index == 0) + cpu_do_idle(); + else + omap_sram_idle(); /* * Call idle CPU PM enter notifier chain to restore -- 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: Suspend broken on 3.3?
Hi
a few brief comments based on a quick scan:
On Wed, 11 Apr 2012, Raja, Govindraj wrote:
Here is the patch [1] to do the same.
- I don't see where it affects I/O wakeups for the UART. If I/O wakeups
are still set on the UART pads, won't that still wake the chip up from
suspend, even if module-level wakeups are disabled?
- The UART driver and integration code should not be reading from or
writing to registers outside the UART IP block. PRM register reads and
writes belong in the PRM code, which should then export a higher-level
interface to the calling code. This is because, aside from making the
code easier to read and debug, we're trying to move the PRM and CM code to
drivers/.
- The code to change the PM_WKEN* and test the PM_WKST* bits should
probably be called from omap_hwmod_{enable,disable}_wakeup(), not the UART
code directly. The UART code shouldn't need to care about the hardware
details; it should just ask the integration layer to enable or disable
module-level wakeups.
As you work on these changes, please split them up into several different
topic series - one for the PRM changes, one for hwmod code/data changes,
and one for the UART driver/integration changes. Just note the
dependencies in the series description E-mails. That way, we can avoid
merge conflicts.
- 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
arm: omap3: am35x: Powerdomain, EMIF4, etc. fixups
The am35x family of SoCs has several differences from standard OMAP3 SoCs that haven't been accounted for in Linux ARM code. These differences include: - There is no IVA. - The device doesn't not support RETENTION OFF power states. - The SDRC *module* has an EMIF4 submodule instead of an SDRC submodule. This series of patches tries to account for those changes. They do the following: - Prevent the cpu_idle thread and cpu_idle driver from sleeping because there are no I/O wake-ups to wake things back up again. - Add a new cpu feature that indicates whether the device supports RETENTION OFF power states. Add code to support devices that only have INACTIVE ON states. - Add a parallel set of clockdomain dependencies that don't include the IVA. - Add a new cpu feature that indicates whether the device has an EMIF4 or SDRC submodule of the SDRC module (the SDRC term/acronym is overloaded). Add a minimal amount of code to support the EMIF4 submodule. - Some miscellaneous patches to fix issues found while developing testing the changes outlined above. With these patches, the am3517 EVM boots and suspend-to-RAM functions. Unfortunately, though, after all of this, I still can't manage to get the CORE power domain to enter the INACTIVE state (at least according to /sys/kernel/debug/pm_debug/count with debugfs mounted under /sys/kernel/debug). The EMIF4 support is fairly minimal because there is an EMIF driver working its way to mainline. If more changes are necessary, they can be made once the final version of that driver is in mainline. Please note that the SDRC submodule mapping is used by the EMIF4 code. They are at the same physical addresses and are the same size so it works okay. The reason I left the mapping alone is because when those mappings are made, its too early to use cpu_is_xxx() or omap3_has_sdrc_emif4() and I didn't want to bloat the kernel with something that's not strictly necessary. I already have the code for the separate mappings, so adding it in is easy, if that's preferred. I tried to make the mapping reuse clear with the commit log and by adding a comment in am35xx_init_early(). These patches are based on the latest mainline kernel as of this writing, commit 258f742635360175564e9470eb060ff4d4b984e7, (modpost: Fix modpost license checking of vmlinux.o). That kernel with these patches was tested on an am35x EVM, am37x EVM, and a Beagleboard-xM. Testing included suspend-to-RAM (i.e., echo mem /sys/power/state) with a rootfs mounted from mmc and nfs (except for the Beagleboard-xM). Mark -- -- 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/12] arm: omap3: Only access IVA if one exists
From: Mark A. Greer mgr...@animalcreek.com
prcm_setup_regs() blindly accesses IVA bits
in the PRM and calls omap3_iva_idle() which
does more IVA related register accesses.
Only do this if the IVA hardware actually
exists.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/pm34xx.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..ec92676 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -583,10 +583,13 @@ static void __init prcm_setup_regs(void)
OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
/* Don't attach IVA interrupts */
- omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
- omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
- omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
- omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL);
+ if (omap3_has_iva()) {
+ omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
+ omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
+ omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
+ omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD,
+ OMAP3430_PM_IVAGRPSEL);
+ }
/* Clear any pending 'reset' flags */
omap2_prm_write_mod_reg(0x, MPU_MOD, OMAP2_RM_RSTST);
@@ -600,7 +603,9 @@ static void __init prcm_setup_regs(void)
/* Clear any pending PRCM interrupts */
omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- omap3_iva_idle();
+ if (omap3_has_iva())
+ omap3_iva_idle();
+
omap3_d2d_idle();
}
--
1.7.9.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 05/12] arm: omap3: am35x: Add PWROFF feature
From: Mark A. Greer mgr...@animalcreek.com Typical OMAP3 SoCs have four power domain states: ON, INACTIVE, RETENTION, and OFF. The am35x family of SoCs has only two states: ON and INACTIVE. To distinguish which set of states the current device has, add the 'OMAP3_HAS_PWROFF' feature. When that feature/bit is set, the device supports the RETENTION and OFF states; otherwise, it doesn't. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/id.c |7 +-- arch/arm/plat-omap/include/plat/cpu.h |8 +--- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 9736049..b6508e5 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -245,7 +245,7 @@ void __init omap3xxx_check_features(void) omap_rev() == OMAP3430_REV_ES3_1_2) omap_features |= OMAP3_HAS_IO_CHAIN_CTRL; - omap_features |= OMAP3_HAS_SDRC; + omap_features |= OMAP3_HAS_SDRC | OMAP3_HAS_PWROFF; /* * am35x fixups: @@ -254,9 +254,12 @@ void __init omap3xxx_check_features(void) * OMAP3_CHECK_FEATURE() will interpret some of those zeroes to * mean that a feature is present even though it isn't so clear * the incorrectly set feature bits. +* - Indicate that am35x SoCs don't support the PWRDM_POWER_RET +* and PWRDM_POWER_OFF states by clearing OMAP3_HAS_PWROFF. */ if (cpu_is_omap3505() || cpu_is_omap3517()) - omap_features = ~(OMAP3_HAS_IVA | OMAP3_HAS_ISP); + omap_features = ~(OMAP3_HAS_IVA | OMAP3_HAS_ISP | + OMAP3_HAS_PWROFF); /* * TODO: Get additional info (where applicable) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index dc6a86b..c3f1a42 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -477,9 +477,10 @@ 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 OMAP3_HAS_PWROFF BIT(9) +#define OMAP4_HAS_MPU_1GHZ BIT(10) +#define OMAP4_HAS_MPU_1_2GHZ BIT(11) +#define OMAP4_HAS_MPU_1_5GHZ BIT(12) #define OMAP3_HAS_FEATURE(feat,flag) \ @@ -497,6 +498,7 @@ OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) OMAP3_HAS_FEATURE(sdrc, SDRC) OMAP3_HAS_FEATURE(io_chain_ctrl, IO_CHAIN_CTRL) +OMAP3_HAS_FEATURE(pwroff, PWROFF) /* * Runtime detection of OMAP4 features -- 1.7.9.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 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/cpuidle34xx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 5358664..12cf81d 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -100,7 +100,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev, pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); - if (omap_irq_pending() || need_resched()) + if (omap_irq_pending() || need_resched() || !omap3_has_io_wakeup()) goto return_sleep_time; /* Deny idle for C1 */ -- 1.7.9.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 04/12] arm: omap3: am35x: Don't mark missing features as present
From: Mark A. Greer mgr...@animalcreek.com The Chip Identification register on the am35x family of SoCs has bits 12, 7:5, and 3:2 marked as reserved and are read as zeroes. Unfortunately, on other omap SoCs, a 0 bit means a feature is Full Use so the OMAP3_CHECK_FEATURE() macro called by omap3_check_features() will incorrectly interpret those zeroes to mean that a feature is present even though it isn't. To fix that, the feature bits that are incorrectly set (namely, OMAP3_HAS_IVA and OMAP3_HAS_ISP) need to be cleared after all of the calls to OMAP3_CHECK_FEATURE() in omap3_check_features() are made. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/id.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 0e79b7b..9736049 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -248,6 +248,17 @@ void __init omap3xxx_check_features(void) omap_features |= OMAP3_HAS_SDRC; /* +* am35x fixups: +* - The am35x Chip ID register has bits 12, 7:5, and 3:2 marked as +* reserved and therefore return 0 when read. Unfortunately, +* OMAP3_CHECK_FEATURE() will interpret some of those zeroes to +* mean that a feature is present even though it isn't so clear +* the incorrectly set feature bits. +*/ + if (cpu_is_omap3505() || cpu_is_omap3517()) + omap_features = ~(OMAP3_HAS_IVA | OMAP3_HAS_ISP); + + /* * TODO: Get additional info (where applicable) * e.g. Size of L2 cache. */ -- 1.7.9.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 02/12] arm: omap3: Only sleep during cpu_idle if I/O wake-ups work
From: Mark A. Greer mgr...@animalcreek.com
Currently in the OMAP3 code, cpu_idle() calls pm_idle(),
which is a function pointer set to omap3_pm_idle()).
omap3_pm_idle() calls omap_sram_idle() which eventually
causes a 'wfi' instruction to be executed effectively
putting the system to sleep. It is assumed that an
I/O wake-up event will occur to wake the system up again.
This doesn't work on systems that don't support I/O wake-ups
(indicated by omap3_has_io_wakeup() returning false).
Leaving pm_idle() pointing to default_idle() won't work
either because the cpu_processor_do_idle() routine which
is eventually called may also execute a 'wfi' instruction
(e.g., cpu_v7_do_idle()).
To handle this, leave pm_idle() pointing to omap3_pm_idle()
but add a check in omap3_pm_idle() so it avoids calling
omap_sram_idle() when I/O wake-ups aren't supported.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/pm34xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ec92676..b7bbcee 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -397,7 +397,7 @@ static void omap3_pm_idle(void)
{
local_fiq_disable();
- if (omap_irq_pending())
+ if (omap_irq_pending() || !omap3_has_io_wakeup())
goto out;
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
--
1.7.9.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 12/12] arm: omap3: am35x: Register davinci_mdio before davinci_emac
From: Mark A. Greer mgr...@animalcreek.com
Problem:
When resuming from a Suspend-to-RAM event, the eth0 device
(davinci emac/mdio) on am35xx boards wouldn't work and the
following error message appeared on the console:
net eth0: could not connect to phy davinci_mdio-0:00
Cause:
--
When davinci_emac_resume() calls emac_dev_open() which
ultimately calls davinci_mdio_read(), the 'data-suspended'
flag in davinci_mdio.c is still set to 'true'. This causes
davinci_mdio_read() to fail which ripples back up the call
chain causing davinci_emac_resume() to fail. The reason
'data-suspended' is still set to 'true' is that
davinci_mdio_resume() hasn't been called yet as it should
have been. davinci_mdio_resume() must be called before
davinci_emac_resume().
Solution:
-
Register the davinci_mdio platform device before registering
the davinci_emac platform device so davinci_mdio_resume()
is called before davinci_emac_resume() and eth0 can resume.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 1f97e74..d23bd6c 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -97,11 +97,6 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8
rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
am35xx_emac_mdio_pdata.bus_freq = mdio_bus_freq;
- err = platform_device_register(am35xx_emac_device);
- if (err) {
- pr_err(AM35x: failed registering EMAC device: %d\n, err);
- return;
- }
err = platform_device_register(am35xx_emac_mdio_device);
if (err) {
@@ -110,6 +105,12 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
return;
}
+ err = platform_device_register(am35xx_emac_device);
+ if (err) {
+ pr_err(AM35x: failed registering EMAC device: %d\n, err);
+ return;
+ }
+
regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
regval = regval (~(AM35XX_CPGMACSS_SW_RST));
omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
--
1.7.9.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 11/12] arm: omap3: am35x: Add do_wfi routine for EMIF4 submodules
From: Mark A. Greer mgr...@animalcreek.com
The typical SDRAM Controller Subsystem module (SDRC)
on TI OMAP3 devices has two submodules: the SDRAM Memory
Scheduler (SMS) submodule, and the SDRC submodule--the
'SDRC' acronym/term is overloaded. The am35x family of
devices is different in that it has an EMIF4 submodule
instead of an SDRC submodule. The SMS submodules are
similar, though.
The difference in SDRC/EMIF4 submodules is important because
omap34xx_cpu_suspend() will ultimately access the submodule's
registers and the register sets are different. To support
the EMIF4 submodule, add the omap3_emif4_do_wfi() routine which
roughly does for the EMIF4 submodule what omap3_do_wfi() does
for the SDRC submodule. This requires omap34xx_cpu_suspend()
to use a pointer set up in omap_push_sram_idle() so that it
jumps to the correct omap3*_do_wfi() routine in either SDRAM
or SRAM.
Credits: arch/arm/mach-omap2/sleep3517.S in TI's am35x SDK
(05.03.02.00) which appears to be authored by Ranjith Lohithakshan
ranji...@ti.com was used as a reference.
CC: Ranjith Lohithakshan ranji...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/control.c |5 +-
arch/arm/mach-omap2/emif4.h| 24 ++
arch/arm/mach-omap2/pm.h |7 ++-
arch/arm/mach-omap2/pm34xx.c | 11 -
arch/arm/mach-omap2/sleep34xx.S| 69 ++--
arch/arm/plat-omap/include/plat/omap34xx.h |1 +
6 files changed, 107 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/mach-omap2/emif4.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 08e674b..c659217 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -283,8 +283,9 @@ void omap3_save_scratchpad_contents(void)
if (cpu_is_omap3630())
scratchpad_contents.public_restore_ptr =
virt_to_phys(omap3_restore_3630);
- else if (omap_rev() != OMAP3430_REV_ES3_0
- omap_rev() != OMAP3430_REV_ES3_1)
+ else if (omap3_has_sdrc_emif4() ||
+ (omap_rev() != OMAP3430_REV_ES3_0
+omap_rev() != OMAP3430_REV_ES3_1))
scratchpad_contents.public_restore_ptr =
virt_to_phys(omap3_restore);
else
diff --git a/arch/arm/mach-omap2/emif4.h b/arch/arm/mach-omap2/emif4.h
new file mode 100644
index 000..0126af3
--- /dev/null
+++ b/arch/arm/mach-omap2/emif4.h
@@ -0,0 +1,24 @@
+/*
+ * SDRC Module, EMIF4 Submodule Definitions
+ *
+ * Author: Mark A. Greer mgr...@animalcreek.com
+ *
+ * Copyright (c) 2012 by Animal Creek Technologies, Inc.
+ *
+ * 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.
+ */
+#ifndef ASM_ARCH_EMIF4_H
+#define ASM_ARCH_EMIF4_H
+
+#ifdef __ASSEMBLER__
+
+#define OMAP34XX_EMIF4_REGADDR(reg) \
+ OMAP2_L3_IO_ADDRESS(OMAP343X_EMIF4_BASE + (reg))
+
+#endif
+
+#define EMIF4_PWR_MGMT_CTRL0x38
+
+#endif
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..ab1262b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -85,10 +85,13 @@ extern unsigned int omap24xx_cpu_suspend_sz;
/* 3xxx */
extern void omap34xx_cpu_suspend(int save_state);
-/* omap3_do_wfi function pointer and size, for copy to SRAM */
+/* omap3*_do_wfi function pointers and sizes, for copy to SRAM */
extern void omap3_do_wfi(void);
extern unsigned int omap3_do_wfi_sz;
-/* ... and its pointer from SRAM after copy */
+extern void omap3_emif4_do_wfi(void);
+extern unsigned int omap3_emif4_do_wfi_sz;
+/* ... and pointers when in SDRAM and in SRAM after copy */
+extern void (*omap3_do_wfi_sdram)(void);
extern void (*omap3_do_wfi_sram)(void);
/* save_secure_ram_context function pointer and size, for copy to SRAM */
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 00c4abe..c1dee25 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -66,6 +66,7 @@ struct power_state {
static LIST_HEAD(pwrst_list);
static int (*_omap_save_secure_sram)(u32 *addr);
+void (*omap3_do_wfi_sdram)(void);
void (*omap3_do_wfi_sram)(void);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -694,7 +695,15 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
*/
void omap_push_sram_idle(void)
{
- omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz);
+ if (omap3_has_sdrc_emif4()) {
+ omap3_do_wfi_sdram = omap3_emif4_do_wfi;
+ omap3_do_wfi_sram = omap_sram_push(omap3_emif4_do_wfi,
+ omap3_emif4_do_wfi_sz);
+ } else {
+ omap3_do_wfi_sdram = omap3_do_wfi;
+
[PATCH 06/12] arm: omap3: am35x: Add full PWRDM_POWER_INACTIVE support
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support PWRDM_POWER_ON
and PWRDM_POWER_INACTIVE power states. This causes
an issue in some areas of the OMAP3 power-related
code because of assumptions that PWRDM_POWER_RET
and/or PWRDM_POWER_OFF are always valid states.
To get am35x SoCs to work properly, add missing support
for PWRDM_POWER_INACTIVE and remove assumptions that
PWRDM_POWER_RET and PWRDM_POWER_OFF are always valid states.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 29 +++--
arch/arm/mach-omap2/pm-debug.c|8 +--
arch/arm/mach-omap2/pm34xx.c | 43 +++--
3 files changed, 60 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 12cf81d..187872a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -175,12 +175,23 @@ static int next_valid_state(struct cpuidle_device *dev,
struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct cpuidle_state *curr = drv-states[index];
struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
- u32 mpu_deepest_state = PWRDM_POWER_RET;
- u32 core_deepest_state = PWRDM_POWER_RET;
+ u32 mpu_deepest_state;
+ u32 core_deepest_state;
int next_index = -1;
+ if (omap3_has_pwroff()) {
+ mpu_deepest_state = PWRDM_POWER_RET;
+ core_deepest_state = PWRDM_POWER_RET;
+ } else {
+ mpu_deepest_state = PWRDM_POWER_INACTIVE;
+ core_deepest_state = PWRDM_POWER_INACTIVE;
+ }
+
if (enable_off_mode) {
+ WARN_ON(!omap3_has_pwroff());
+
mpu_deepest_state = PWRDM_POWER_OFF;
+
/*
* Erratum i583: valable for ES rev Es1.2 on 3630.
* CORE OFF mode is not supported in a stable form, restrict
@@ -311,6 +322,9 @@ void omap3_pm_init_cpuidle(struct cpuidle_params
*cpuidle_board_params)
cpuidle_board_params[i].exit_latency;
cpuidle_params_table[i].target_residency =
cpuidle_board_params[i].target_residency;
+
+ WARN_ON(!omap3_has_pwroff() (i = 2)
+ cpuidle_params_table[i].valid);
}
return;
}
@@ -349,6 +363,16 @@ static inline struct omap3_idle_statedata
*_fill_cstate_usage(
return cx;
}
+/* Only C1 C2 C states valid when RET OFF states aren't supported */
+static void omap3_cstate_valid_fixup(void)
+{
+ int idx;
+
+ if (!omap3_has_pwroff())
+ for (idx = 2; idx OMAP3_NUM_STATES; idx++)
+ cpuidle_params_table[idx].valid = 0;
+}
+
/**
* omap3_idle_init - Init routine for OMAP3 idle
*
@@ -366,6 +390,7 @@ int __init omap3_idle_init(void)
per_pd = pwrdm_lookup(per_pwrdm);
cam_pd = pwrdm_lookup(cam_pwrdm);
+ omap3_cstate_valid_fixup();
drv-safe_state_index = -1;
dev = per_cpu(omap3_idle_dev, smp_processor_id());
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..339ed42 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -239,19 +239,23 @@ static int option_get(void *data, u64 *val)
static int option_set(void *data, u64 val)
{
u32 *option = data;
+ int ret = -EINVAL;
*option = val;
- if (option == enable_off_mode) {
+ if (omap3_has_pwroff() (option == enable_off_mode)) {
if (val)
omap_pm_enable_off_mode();
else
omap_pm_disable_off_mode();
+
if (cpu_is_omap34xx())
omap3_pm_off_mode_enable(val);
+
+ ret = 0;
}
- return 0;
+ return ret;
}
DEFINE_SIMPLE_ATTRIBUTE(pm_dbg_option_fops, option_get, option_set, %llu\n);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b7bbcee..00c4abe 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -279,6 +279,7 @@ void omap_sram_idle(void)
mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
switch (mpu_next_state) {
case PWRDM_POWER_ON:
+ case PWRDM_POWER_INACTIVE:
case PWRDM_POWER_RET:
/* No need to save context */
save_state = 0;
@@ -614,6 +615,8 @@ void omap3_pm_off_mode_enable(int enable)
struct power_state *pwrst;
u32 state;
+ WARN_ON(!omap3_has_pwroff());
+
if (enable)
state = PWRDM_POWER_OFF;
else
@@ -668,7 +671,12 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
- pwrst-next_state =
[PATCH 10/12] arm: omap3: am35x: Add minimal EMIF4 support
From: Mark A. Greer mgr...@animalcreek.com
The typical SDRAM Controller Subsystem module (SDRC)
on TI OMAP3 devices has two submodules: the SDRAM Memory
Scheduler (SMS) submodule, and the SDRC submodule--the
'SDRC' acronym/term is overloaded. The am35x family of
devices is different in that it has an EMIF4 submodule
instead of an SDRC submodule. The SMS submodules are
similar, though.
Currently, the code assumes that if its an OMAP3 device,
then it has an SDRC module and if it has an SDRC module,
it has an SDRC submodule. Since the SDRC module can now
have an EMIF4 submodule, the code needs to be reworked.
This rework can be minimal since there is an EMIF driver being
developed which should take care of most of the EMIF4 details.
In the meantime:
- enable smart-idle and VTP power save mode in the EMIF4
- have omap3_core_dpll_m2_set_rate() return an error when
there's an EMIF4 module because it assumes there's an
SDRC submodule
- don't bother pushing map3_sram_configure_core_dpll()
to sram since its not used when there's an EMIF4
submodule.
NOTE: There is still a bit of ugliness in that the SDRC
submodule's mapping (in omap34xx_io_desc[]) is used.
That works okay since the address and size of the EMIF4
submodule is the same as the SDRC submodule's. To fix that,
a special early_cpu_is_xxx() or early_omap3_has_sdrc_emif4()
routine needs to be created because its too early to use the
regular cpu_is_xxx() or omap3_has_sdrc_emif4() calls.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c |6 +++-
arch/arm/mach-omap2/io.c |9 ++
arch/arm/mach-omap2/sdrc.c | 52 ++--
arch/arm/mach-omap2/sdrc.h | 13
arch/arm/plat-omap/sram.c |8 +++--
5 files changed, 68 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index d6e34dd..3864528 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -21,6 +21,7 @@
#include linux/clk.h
#include linux/io.h
+#include plat/cpu.h
#include plat/clock.h
#include plat/sram.h
#include plat/sdrc.h
@@ -45,7 +46,7 @@
* @rate: rounded target rate
*
* Program the DPLL M2 divider with the rounded target rate. Returns
- * -EINVAL upon error, or 0 upon success.
+ * -EINVAL upon error or if there's an EMIF4 submodule, or 0 upon success.
*/
int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)
{
@@ -60,6 +61,9 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
if (!clk || !rate)
return -EINVAL;
+ if (omap3_has_sdrc_emif4())
+ return -EINVAL;
+
validrate = omap2_clksel_round_rate_div(clk, rate, new_div);
if (validrate != rate)
return -EINVAL;
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 065bd76..1accc90 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -450,6 +450,15 @@ void __init omap3630_init_early(void)
void __init am35xx_init_early(void)
{
+ /*
+* The am35x has an EMIF4 submodule in the SDRC module instead
+* of an SDRC submodule like other OMAP3 SoCs. Fortunately,
+* the EMIF4 and SDRC submodules are at the same physical address
+* so we can use the SDRC mapping to access the EMIF4 submodule.
+* The reason for not making a separate mapping for the EMIF4 is
+* to avoid creating an early_cpu_is_xxx()-like call because its
+* too early to use cpu_is_3505/3517() or omap3_has_sdrc_emif4().
+*/
omap3_init_early();
}
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index e3d345f..d804065 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -24,11 +24,13 @@
#include linux/io.h
#include common.h
+#include control.h
#include plat/clock.h
#include plat/sram.h
#include plat/sdrc.h
#include sdrc.h
+#include emif4.h
static struct omap_sdrc_params *sdrc_init_params_cs0, *sdrc_init_params_cs1;
@@ -136,28 +138,46 @@ void __init omap2_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
u32 l;
+ void __iomem *ctrl_base;
l = sms_read_reg(SMS_SYSCONFIG);
l = ~(0x3 3);
l |= (0x2 3);
sms_write_reg(l, SMS_SYSCONFIG);
- l = sdrc_read_reg(SDRC_SYSCONFIG);
- l = ~(0x3 3);
- l |= (0x2 3);
- sdrc_write_reg(l, SDRC_SYSCONFIG);
-
- sdrc_init_params_cs0 = sdrc_cs0;
- sdrc_init_params_cs1 = sdrc_cs1;
-
- /* XXX Enable SRFRONIDLEREQ here also? */
- /*
-* PWDENA should not be set due to 34xx erratum 1.150 - PWDENA
-* can cause random memory corruption
-*/
- l = (1 SDRC_POWER_EXTCLKDIS_SHIFT) |
- (1
[PATCH 07/12] arm: omap3: am35x: Set proper powerdomain states
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support PWRSTS_ON
and PWRSTS_INACTIVE states so create a new set
of powerdomain structures that ensure that only
the ON and INACTIVE states are entered.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/powerdomain.h |1 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 134 ---
2 files changed, 123 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..561cb27 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -43,6 +43,7 @@
#define PWRSTS_OFF_ON (PWRSTS_OFF | PWRSTS_ON)
#define PWRSTS_OFF_RET (PWRSTS_OFF | PWRSTS_RET)
#define PWRSTS_RET_ON (PWRSTS_RET | PWRSTS_ON)
+#define PWRSTS_INACTIVE_ON (PWRSTS_INACTIVE | PWRSTS_ON)
#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index b7ea468..fae6dea 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -71,6 +71,22 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.voltdm = { .name = mpu_iva },
};
+static struct powerdomain mpu_am35x_pwrdm = {
+ .name = mpu_pwrdm,
+ .prcm_offs= MPU_MOD,
+ .pwrsts = PWRSTS_INACTIVE_ON,
+ .pwrsts_logic_ret = PWRSTS_INACTIVE,
+ .flags= PWRDM_HAS_MPU_QUIRK,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_INACTIVE,
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_INACTIVE_ON,
+ },
+ .voltdm = { .name = mpu_iva },
+};
+
/*
* The USBTLL Save-and-Restore mechanism is broken on
* 3430s up to ES3.0 and 3630ES1.0. Hence this feature
@@ -120,6 +136,23 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain core_am35x_pwrdm = {
+ .name = core_pwrdm,
+ .prcm_offs= CORE_MOD,
+ .pwrsts = PWRSTS_INACTIVE_ON,
+ .pwrsts_logic_ret = PWRSTS_INACTIVE,
+ .banks= 2,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_INACTIVE, /* MEM1RETSTATE */
+ [1] = PWRSTS_INACTIVE, /* MEM2RETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_INACTIVE_ON, /* MEM1ONSTATE */
+ [1] = PWRSTS_INACTIVE_ON, /* MEM2ONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain dss_pwrdm = {
.name = dss_pwrdm,
.prcm_offs= OMAP3430_DSS_MOD,
@@ -135,6 +168,21 @@ static struct powerdomain dss_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain dss_am35x_pwrdm = {
+ .name = dss_pwrdm,
+ .prcm_offs= OMAP3430_DSS_MOD,
+ .pwrsts = PWRSTS_INACTIVE_ON,
+ .pwrsts_logic_ret = PWRSTS_INACTIVE,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_INACTIVE, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
/*
* Although the 34XX TRM Rev K Table 4-371 notes that retention is a
* possible SGX powerstate, the SGX device itself does not support
@@ -156,6 +204,21 @@ static struct powerdomain sgx_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain sgx_am35x_pwrdm = {
+ .name = sgx_pwrdm,
+ .prcm_offs= OMAP3430ES2_SGX_MOD,
+ .pwrsts = PWRSTS_INACTIVE_ON,
+ .pwrsts_logic_ret = PWRSTS_INACTIVE,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_INACTIVE, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain cam_pwrdm = {
.name = cam_pwrdm,
.prcm_offs= OMAP3430_CAM_MOD,
@@ -186,6 +249,21 @@ static struct powerdomain per_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain per_am35x_pwrdm = {
+ .name = per_pwrdm,
+ .prcm_offs= OMAP3430_PER_MOD,
+ .pwrsts = PWRSTS_INACTIVE_ON,
+ .pwrsts_logic_ret = PWRSTS_INACTIVE,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_INACTIVE, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain emu_pwrdm = {
.name
[PATCH 09/12] arm: omap3: am35x: Add SDRC EMIF4 feature
From: Mark A. Greer mgr...@animalcreek.com
The typical SDRAM Controller Subsystem module (SDRC)
on TI OMAP3 devices has two submodules: the SDRAM Memory
Scheduler (SMS) submodule, and the SDRC submodule--the
'SDRC' acronym/term is overloaded. The am35x family of
devices is different in that it has an EMIF4 submodule
instead of an SDRC submodule. The SMS submodules are
similar, though.
To allow code to determine whether the current device has an
SDRC submodule or and EMIF4 submodule, add the 'OMAP3_HAS_SDRC_EMIF4'
feature and set it when running on an am35x SoC.
So when:
- omap3_has_sdrc() returns true: the system has an SDRC module
consisting of an SMS submodule and either an SDRC submodule
or an EMIF4 submodule.
- omap3_has_sdrc_emif4() returns true: the system has an EMIF4
submodule. It is assumed that this feature will only be
checked when there is an SDRC module present (i.e., when
omap3_has_sdrc() would return true).
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/id.c |5 -
arch/arm/plat-omap/include/plat/cpu.h | 12 +++-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index b6508e5..abb5e51 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -256,10 +256,13 @@ void __init omap3xxx_check_features(void)
* the incorrectly set feature bits.
* - Indicate that am35x SoCs don't support the PWRDM_POWER_RET
* and PWRDM_POWER_OFF states by clearing OMAP3_HAS_PWROFF.
+* - Indicate that am35x SoCs have an EMIF4 SDRC submodule.
*/
- if (cpu_is_omap3505() || cpu_is_omap3517())
+ if (cpu_is_omap3505() || cpu_is_omap3517()) {
omap_features = ~(OMAP3_HAS_IVA | OMAP3_HAS_ISP |
OMAP3_HAS_PWROFF);
+ omap_features |= OMAP3_HAS_SDRC_EMIF4;
+ }
/*
* TODO: Get additional info (where applicable)
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index c3f1a42..207f21b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -476,11 +476,12 @@ extern u32 omap_features;
#define OMAP3_HAS_192MHZ_CLK BIT(5)
#define OMAP3_HAS_IO_WAKEUPBIT(6)
#define OMAP3_HAS_SDRC BIT(7)
-#define OMAP3_HAS_IO_CHAIN_CTRLBIT(8)
-#define OMAP3_HAS_PWROFF BIT(9)
-#define OMAP4_HAS_MPU_1GHZ BIT(10)
-#define OMAP4_HAS_MPU_1_2GHZ BIT(11)
-#define OMAP4_HAS_MPU_1_5GHZ BIT(12)
+#define OMAP3_HAS_SDRC_EMIF4 BIT(8)
+#define OMAP3_HAS_IO_CHAIN_CTRLBIT(9)
+#define OMAP3_HAS_PWROFF BIT(10)
+#define OMAP4_HAS_MPU_1GHZ BIT(11)
+#define OMAP4_HAS_MPU_1_2GHZ BIT(12)
+#define OMAP4_HAS_MPU_1_5GHZ BIT(13)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -497,6 +498,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(sdrc_emif4, SDRC_EMIF4)
OMAP3_HAS_FEATURE(io_chain_ctrl, IO_CHAIN_CTRL)
OMAP3_HAS_FEATURE(pwroff, PWROFF)
--
1.7.9.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
