Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod which activates the restore for OMAP4.
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
On Wednesday 06 July 2011 12:01 AM, Kevin Hilman wrote:
Shubhrajyotishubhrajy...@ti.com writes:
On Monday 20 June 2011 09:05 PM, Kevin Hilman wrote:
shubhrajy...@ti.com writes:
From: Shubhrajyoti Dshubhrajy...@ti.com
Currently the OMAP4 doesnot hit device off still the
driver may have
* Paul Walmsley p...@pwsan.com [110705 18:37]:
cc'ing Aaro
On Mon, 4 Jul 2011, Tony Lindgren wrote:
Also related is the gptimer12 on secure omaps as reported by Aaro.
This problem is actually worse. In this case it's not just preventing
reset; we must prevent the kernel from using
* Paul Walmsley p...@pwsan.com [110705 18:55]:
On Tue, 5 Jul 2011, Paul Walmsley wrote:
For this case, we probably need some board file function to tell the
hwmod code to disregard a device completely, to tell the kernel to
pretend that the device does not exist.
... and the other
* Paul Walmsley p...@pwsan.com [110705 14:42]:
On Tue, 5 Jul 2011, Tony Lindgren wrote:
Can't we always reset the registered hwmods automatically one at a time when
omap_device_build is called?
The experimental series that I wrote, but haven't posted yet, resets each
IP block during
* Raphaël Assénat r...@8d.com [110705 07:30]:
On 05/07/11 07:19 AM, Tony Lindgren wrote:
* Raphaël Assénat r...@8d.com [110704 12:51]:
The am3505 is apparently so similar to the 3430 that it was treated as
such
(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a
On Fri, 1 Jul 2011, Benoit Cousson wrote:
From: Jon Hunter jon-hun...@ti.com
McASP2, 3 and MMC6 modules are not present in the OMAP4 family.
Remove the fclk and the clksel related to these nodes.
Rename the references that were potentially re-used in order nodes.
Remove related macros in
On Fri, 1 Jul 2011, Benoit Cousson wrote:
From: Jon Hunter jon-hun...@ti.com
UNIPRO was removed from OMAP4 devices from ES2.0 onwards.
Since this IP was anyway non-functional and not supported,
it is best to remove it completely.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Hi,
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Here are a bunch of cleanups on almost every PRCM related data files.
Some of them are purely code moves, and will look like a lot of
noise for nothing, but this is needed if we want to keep the files
aligned with generator tool and thus ease the
Hi Tony, Benoît,
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Here are the latest bug fixes done on the hwmod framework.
There are mainly around wakeup capability added in OMAP4.
The series is based on for_3.1/2_prcm_files_cleanup and tested
on OMAP4430 ES2.1 + SDP.
The patches are
On Wed, 6 Jul 2011, Paul Walmsley wrote:
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Here are the latest bug fixes done on the hwmod framework.
There are mainly around wakeup capability added in OMAP4.
The series is based on for_3.1/2_prcm_files_cleanup and tested
on OMAP4430 ES2.1 +
Hi,
I'm currently working on a beagleboard clone that has two NAND chips on
OMAP3 CS0 and CS1. The flash on CS0 works as expected. What would be the
correct way to get both chips to work?
Thanks, Maximilian
pgpan8UVNquWu.pgp
Description: PGP signature
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Wednesday, July 06, 2011 12:26 PM
To: Raphaël Assénat; Paul Walmsley
Cc: linux-omap@vger.kernel.org
Subject: Re: AM3505/3517 support
* Raphaël
On 06/07/11 04:54 AM, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Wednesday, July 06, 2011 12:26 PM
To: Raphaël Assénat; Paul Walmsley
Cc: linux-omap@vger.kernel.org
On 05/07/11 05:59 AM, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raphaël Assénat
Sent: Tuesday, July 05, 2011 12:59 AM
To: linux-omap@vger.kernel.org
Subject: AM3505/3517 support
Hello,
Menon, Nishanth n...@ti.com writes:
On Tue, Jul 5, 2011 at 17:01, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on
This patch adds support for the AM35xx ZCN package specific muxmodes.
Signed-off-by: Raphael Assenat r...@8d.com
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4ae6257..5c880de 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -103,6
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raphaël Assénat
Sent: Wednesday, July 06, 2011 8:59 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH] AM3505/3517 ZCN package support
This patch adds support for the
-Original Message-
From: Raphaël Assénat [mailto:r...@8d.com]
Sent: Wednesday, July 06, 2011 7:29 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: AM3505/3517 support
On 05/07/11 05:59 AM, Premi, Sanjeev wrote:
-Original Message-
From:
Fixes according to Sanjeev's comments in previous thread.
---
This patch adds support for the AM35xx ZCN package specific muxmodes.
Signed-off-by: Raphael Assenat r...@8d.com
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4ae6257..bf452eb 100644
---
On 06/07/11 12:11 PM, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raphaël Assénat
Sent: Wednesday, July 06, 2011 8:59 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH] AM3505/3517 ZCN package
With the addition of support for the ZCN package, there
are even more placeholders in the superset, such as:
_OMAP3_MUXENTRY(GPMC_A11, 0,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL),
which takes a lot of space. This patch introduces and uses
Make the debug message useful by printing the name of the device
that no associated driver could be found for.
Signed-off-by: Andy Doan andy.d...@linaro.org
---
drivers/video/omap2/omapfb/omapfb-main.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
On Tuesday 05 July 2011, Tony Lindgren wrote:
Please pull some fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
devel-fixes
These are intented for the merge window, there's no rush for
these to go in during the -rc cycle this late. I have one fix
Hi,
On Tue, Jul 05, 2011 at 10:37:40AM -0700, Kevin Hilman wrote:
While I did design the OMAP PM core to be runtime PM centric, and we
implemented several drivers based on runtime PM alone, after some long
discussions on linux-pm[1] with Alan and Rafael (PM maintainer) over the
last couple
On Thu, Jun 30, 2011 at 07:27:02AM -0700, Tony Lindgren wrote:
Hi,
Few comments on the .dts data layout below.
* G, Manjunath Kondaiah manj...@ti.com [110630 02:44]:
--- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
+++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
@@ -2,11 +2,6 @@
On Thu, Jun 30, 2011 at 03:07:23PM +0500, G, Manjunath Kondaiah wrote:
Add I2C and it's child device nodes for beagle board.
The I2C1 controller child devices are not populated and it
should be handled along with OMAP clock changes.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
On Thu, Jun 30, 2011 at 03:07:24PM +0500, G, Manjunath Kondaiah wrote:
Add I2C and it's child device nodes for beagle board.
The I2C1 controller child devices are not populated and it
should be handled along with OMAP clock changes.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
On Thu, Jun 30, 2011 at 03:07:25PM +0500, G, Manjunath Kondaiah wrote:
The beagle board file is updated to use i2c nodes from device
tree data structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 24
1
On Thu, Jun 30, 2011 at 03:07:26PM +0500, G, Manjunath Kondaiah wrote:
The OMAP4 panda board file is updated to use i2c nodes from device
tree data structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 22 ++
1
On Thu, Jun 30, 2011 at 03:07:27PM +0500, G, Manjunath Kondaiah wrote:
The OMAP I2C driver is modified to use platform_device data from
device tree data structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Mostly looks good, but a few things that need to be fixed. You can
Felipe Balbi ba...@ti.com writes:
Hi,
On Tue, Jul 05, 2011 at 10:37:40AM -0700, Kevin Hilman wrote:
While I did design the OMAP PM core to be runtime PM centric, and we
implemented several drivers based on runtime PM alone, after some long
discussions on linux-pm[1] with Alan and Rafael (PM
The omap_device layer currently has two ways of getting an omap_device
pointer from a platform_device pointer.
Replace current usage of _find_by_pdev() with to_omap_device() since
to_omap_device() is more familiar to the existing to_platform_device()
used when getting a platform_device pointer
On 7/6/2011 12:19 AM, Paul Walmsley wrote:
Hi,
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Here are a bunch of cleanups on almost every PRCM related data files.
Some of them are purely code moves, and will look like a lot of
noise for nothing, but this is needed if we want to keep the files
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Wakeup register offsets are initialized according to OMAP versions
during device registration. These explicit checks are no longer needed.
mpuio_init() function is defined under #ifdefs. It is required only in
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
With register offsets now defined for respective OMAP versions we can get rid
of cpu_class_* checks. This function now has common initialization code for
all OMAP versions. Initialization specific to OMAP16xx has been moved within
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
There is no need to operate on all the banks every time the function is
called.
Just operate on the current bank passed by the framework.
That's a good change.
There is also no need to runtime suspend/resume the bank if
bank-suspend_wakeup ==
Hi Tony
On Tue, 5 Jul 2011, Tony Lindgren wrote:
So basically we want to tell the following from the board file or board
specific .dts file:
- Device is being used on the board and can be reset and configured.
This is the usual case.
By 'used', you mean, have a Linux driver associated
On Tue, 5 Jul 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110705 18:55]:
On Tue, 5 Jul 2011, Paul Walmsley wrote:
For this case, we probably need some board file function to tell the
hwmod code to disregard a device completely, to tell the kernel to
pretend that
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
Please also Cc the linux-arm-kernel mailing list for OMAP patches
targetted for upstream.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap
Hi
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Here are the latest bug fixes done on the hwmod framework.
There are mainly around wakeup capability added in OMAP4.
The series is based on for_3.1/2_prcm_files_cleanup and tested
on OMAP4430 ES2.1 + SDP.
The patches are available here:
Hi,
On Wed, Jul 06, 2011 at 12:20:40PM -0700, Kevin Hilman wrote:
+ if ((od-flags OMAP_DEVICE_SUSPENDED)
+ (od-_state == OMAP_DEVICE_STATE_IDLE))
+ omap_device_enable(pdev);
+
+ return pm_generic_resume(dev);
+}
+
static struct dev_power_domain
On Wed, Jul 06, 2011 at 12:26:17PM -0700, Kevin Hilman wrote:
The omap_device layer currently has two ways of getting an omap_device
pointer from a platform_device pointer.
Replace current usage of _find_by_pdev() with to_omap_device() since
to_omap_device() is more familiar to the existing
On Wed, 6 Jul 2011, Paul Walmsley wrote:
Patches 13-15 have been queued for 3.1 at
git://git.pwsan.com/linux-2.6 in the 'hwmod_cleanup_a_3.1' branch.
This branch has been renamed to 'omap4_hwmod_data_cleanup_a_3.1' to better
express its content.
- Paul
--
To unsubscribe from this list: send
On Fri, 1 Jul 2011, Benoit Cousson wrote:
The interconnect modules were using a slightly different layout than
the regular modules.
Align the layout for better consitency.
Thanks, this patch has been queued for 3.1 at
git://git.pwsan.com/linux-2.6 in the 'omap4_hwmod_data_cleanup_a_3.1'
On Tue, Jul 05, 2011 at 10:29:17AM -0700, Stephen Boyd wrote:
If an ARM system has multiple cpus in the same socket and the
kernel is booted with maxcpus=1, secondary cpus are possible but
not present due to how platform_smp_prepare_cpus() is called.
Since most typical ARM processors don't
Grant Likely wrote at Wednesday, July 06, 2011 12:56 PM:
On Thu, Jun 30, 2011 at 03:07:23PM +0500, G, Manjunath Kondaiah wrote:
Add I2C and it's child device nodes for beagle board.
The I2C1 controller child devices are not populated and it
should be handled along with OMAP clock changes.
Hi,
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Since the clkdm is now part of the omap_hwmod structure, there is no need
to retrieve it from the main_clock or interface clock.
The code can be simplified a little bit with a direct access.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc:
On Wed, Jul 6, 2011 at 5:26 PM, Stephen Warren swar...@nvidia.com wrote:
Grant Likely wrote at Wednesday, July 06, 2011 12:56 PM:
On Thu, Jun 30, 2011 at 03:07:23PM +0500, G, Manjunath Kondaiah wrote:
Add I2C and it's child device nodes for beagle board.
The I2C1 controller child devices are
-Original Message-
From: Hilman, Kevin
Sent: Thursday, July 07, 2011 2:37 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; t...@atomide.com
Subject: Re: [PATCH v3 00/20] GPIO: OMAP: driver cleanup and fixes
Tarun Kanti DebBarma tarun.ka...@ti.com
[...]
With register offsets now defined for respective OMAP versions we can
get rid
of cpu_class_* checks. This function now has common initialization code
for
all OMAP versions. Initialization specific to OMAP16xx has been moved
within
omap16xx_gpio_init().
This patch also adds the
-Original Message-
From: Hilman, Kevin
Sent: Thursday, July 07, 2011 2:25 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; t...@atomide.com
Subject: Re: [PATCH v3 19/20] GPIO: OMAP: optimize suspend and resume
functions
Tarun Kanti DebBarma
[...]
By adding level and edge detection register offsets and then
initializing them
correctly according to OMAP versions during device registrations we can
now remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Thursday, July 07, 2011 3:48 AM
To: Kevin Hilman
Cc: ba...@ti.com; Alan Stern; Partha Basak; Keshava Munegowda; linux-
u...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; Anand Gadiyar;
[...]
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Wakeup register offsets are initialized according to OMAP versions
during device registration. These explicit checks are no longer needed.
mpuio_init() function is defined under #ifdefs. It is
* Paul Walmsley p...@pwsan.com [110706 23:52]:
Hi Tony
On Tue, 5 Jul 2011, Tony Lindgren wrote:
So basically we want to tell the following from the board file or board
specific .dts file:
- Device is being used on the board and can be reset and configured.
This is the usual
57 matches
Mail list logo
