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
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
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
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
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.
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
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
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 ==
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
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
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
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
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
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.
*/
-
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
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)
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
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
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
---
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
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
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
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
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
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
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
---
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
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.
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
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
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
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
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(+),
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
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);
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
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
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
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:
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
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
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
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
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
---
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
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(+),
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
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
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.
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
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
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
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
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
---
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
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
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
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);
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
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
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
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
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
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
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
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
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
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 ---
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
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
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
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
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
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()
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
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)
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
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
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
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
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()
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
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
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)
+
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
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
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:
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
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
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
---
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
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
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
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
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:
--
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
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
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
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
---
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
1 - 100 of 155 matches
Mail list logo
