On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 17:26]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory
On Wednesday 05 October 2011 06:15 AM, Tony Lindgren wrote:
This way we don't need to initialize SoC detection early
and can start using generic map_io.
Signed-off-by: Tony Lindgren t...@atomide.com
---
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
Add new error value so that drivers can request deferred probe
from drivercore.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Reported-by: Grant Likely grant.lik...@secretlab.ca
---
Cc:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
From: Grant Likely grant.lik...@secretlab.ca
Allow drivers to report at probe time that they cannot get all the
resources required by the device, and should be retried at a
later time.
This should completely solve
On Fri, Oct 07, 2011 at 10:33:05AM +0500, G, Manjunath Kondaiah wrote:
Why did you send this series of patches out twice? Were they different?
confused,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
On Thursday 06 October 2011 03:43 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 17:34]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
This allows us to remove omap hacks for map_io.
Signed-off-by: Tony Lindgren t...@atomide.com
Nice cleanup.
Acked-by: Nicolas Pitre
On Thursday 06 October 2011 07:06 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 18:17]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Signed-off-by: Tony
On Thursday 06 October 2011 07:12 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111004 23:29]:
Will look at this series in next couple of days and do some testing.
Thanks, turns out there were a few issues with early ioremap
that I fixed. Care to check the
On Thu, 29 Sep 2011, Mike Turquette wrote:
Not all DPLLs are identical; some require special consideration such as
OMAP4's ABE DPLL, which can have an additional 4x multiplier added to
it's clock rate based on programming the REGM4XEN bit in it's CLKMODE
register.
Unfortunately the clock
Hi Florian,
Please pull OMAP DSS patches for v3.2 merge window.
Note that there are some conflicts with other trees. The board file
conflicts are trivial, changes in code which just happen to be next to
each other. The LCD driver conflicts are even simpler, there were
changes to them from some
Hi Greg,
On Thu, Oct 06, 2011 at 11:50:42PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:05AM +0500, G, Manjunath Kondaiah wrote:
Why did you send this series of patches out twice? Were they different?
confused,
Looks like this patch series has reached only individual recepients
On Thu, Oct 6, 2011 at 10:05 PM, Paul Walmsley p...@pwsan.com wrote:
Hi Keshava,
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci,
Hi Tony,
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37
-0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 omap_clock_fixes_3.2
Jon Hunter (3):
ARM:
On Fri, 7 Oct 2011, Paul Walmsley wrote:
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26
17:50:37 -0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6
Hi
some comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
From: Rajendra Nayak rna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
Hi
a few comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for enabling IO
Daisy
chain is The I/O wake-up scheme is enabled by triggering the I/O daisy chain
control (Wu clock) by programming a dedicated register
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and
Convert a printk(KERN_ERR) message in the driver to pr_err().
v2:
* Replaced dump_stack() with WARN()
v3:
* Rebased against omap/master
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
arch/arm/plat-omap/dmtimer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
Hi,
On Mon, Sep 26, 2011 at 03:21:07PM +0530, Gupta, Ajay Kumar wrote:
To: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org; Balbi, Felipe; t...@atomide.com; B, Ravi;
Cousson, Benoit; Gupta, Ajay Kumar
Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
Felipe,
I
On Fri, Sep 09, 2011 at 07:17:46PM +0530, Ajay Kumar Gupta wrote:
From: Ravi Babu ravib...@ti.com
Added musb support for ti81xx platform which has two instances of musb
interface and uses CPPI4.1 DMA. The current patch set adds support for
single instance and in PIO mode only.
On Fri, Sep 09, 2011 at 07:17:47PM +0530, Ajay Kumar Gupta wrote:
Adding ti81xx_musb_phy_power() which will be used by musb driver through
its function pointer in board_data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
this should go through
Hi,
On Fri, Sep 09, 2011 at 07:17:48PM +0530, Ajay Kumar Gupta wrote:
From: Ravi Babu ravib...@ti.com
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
this looks ok, but should go through OMAP tree:
On Fri, Sep 09, 2011 at 07:17:49PM +0530, Ajay Kumar Gupta wrote:
From: Ravi Babu ravib...@ti.com
Adding musb support in ti814 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
similarly:
Acked-by: Felipe Balbi ba...@ti.com
--
Hi,
On Fri, Sep 09, 2011 at 07:17:50PM +0530, Ajay Kumar Gupta wrote:
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
new file mode 100644
index 000..fb59e34
--- /dev/null
+++ b/drivers/usb/musb/musb_dsps.c
@@ -0,0 +1,693 @@
+/*
+ * Texas Instruments DSPS
Hi
On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
Thanks paul;
Now I am seeing that without OCPIF_SWSUP_IDLE the system is going to
low power mode but after
adding HWMOD_INIT_NO_RESET flag ; After adding this flag; I dint
check the system without this flag;
so, PRCM automatically idle
Hi
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with
Hi,
On Fri, 30 Sep 2011, Abhilash K V wrote:
From: Abhilash K V abhilash...@ti.com
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.
Signed-off-by: Abhilash K V abhilash...@ti.com
I've dropped the mailbox
Hi Tony,
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37
-0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 prcm_scm_misc_fixes_3.2
Abhilash K V (1):
On Fri, Oct 7, 2011 at 2:36 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional
On Fri, Oct 07, 2011 at 10:50:16AM +0200, Víctor Manuel Jáquez Leal wrote:
Convert a printk(KERN_ERR) message in the driver to pr_err().
...
@@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
while (!(__raw_readl(timer-sys_stat) 1)) {
On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
Thanks Paul;
yes, I can your changes in the patches.
so, you don't need v14 from me right? please confirm.
I am preparing/validating next version patches with OCPIF_SWSUP_IDLE removed.
Thanks for guiding me and helping on the finalizing the
Hi,
On Mon, Sep 26, 2011 at 03:33:11PM +0530, Ajay Kumar Gupta wrote:
Adding musb support in am335x EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
should go through OMAP tree:
Acked-by: Felipe Balbi ba...@ti.com
--
balbi
signature.asc
Description: Digital signature
Hi,
On Mon, Sep 26, 2011 at 03:33:12PM +0530, Ajay Kumar Gupta wrote:
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
should go through OMAP tree:
Acked-by: Felipe Balbi ba...@ti.com
--
balbi
signature.asc
Description: Digital signature
Hi,
On Mon, Sep 26, 2011 at 02:47:11PM +0400, Sergei Shtylyov wrote:
Hello.
On 26-09-2011 14:03, Ajay Kumar Gupta wrote:
Enabled the flag so that musb_dsps glue file can be used for am335x
Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com
---
drivers/usb/musb/Kconfig |6 +++---
On Thu, Oct 06, 2011 at 11:43:49PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
+#define EPROBE_DEFER 517 /* restart probe again after some time
*/
Can we really do this? Isn't this some user/kernel api here?
What's wrong with
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, October 07, 2011 1:44 PM
To: Vishwanath BS
Cc: linux-omap@vger.kernel.org; khil...@ti.com; linux-arm-
ker...@lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH 2/4] ARM: OMAP4 PM: Add IO Daisychain
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, October 07, 2011 1:50 PM
To: Vishwanath BS
Cc: linux-omap@vger.kernel.org; khil...@ti.com; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
Hi
a
On Fri, 07 Oct 2011 10:33:09 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready.
Why not use the perfectly good existing error codes we have for this ?
We have EAGAIN and EUNATCH both of which look
On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
Thanks Paul;
yes, I can your changes in the patches.
so, you don't need v14 from me right? please confirm.
I am preparing/validating next version patches with OCPIF_SWSUP_IDLE
On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
Thanks Paul;
yes, I can your changes in the patches.
so, you don't need v14 from me right? please confirm.
I am preparing/validating next version patches with OCPIF_SWSUP_IDLE
On Fri, Oct 07, 2011 at 10:22:43AM +0100, Russell King - ARM Linux wrote:
On Fri, Oct 07, 2011 at 10:50:16AM +0200, Víctor Manuel Jáquez Leal wrote:
Convert a printk(KERN_ERR) message in the driver to pr_err().
...
@@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
Dnia wtorek, 23 sierpnia 2011 o 19:11:47 Kevin Hilman napisał(a):
Janusz Krzysztofik jkrzy...@tis.icnet.pl writes:
With commit f64ad1a0e21a, gpio/omap: cleanup _set_gpio_wakeup(), remove
ifdefs, access to build time conditionally omitted 'suspend_wakeup'
member of the 'gpio_bank'
Hi Paul,
linux-arm-kernel-boun...@lists.infradead.org wrote on :
macros and detection support
Hi Paul,
Paul Walmsley wrote on Friday, September 30, 2011 2:17 AM:
Hello Hemant,
a few comments:
On Thu, 29 Sep 2011, Hemant Pedanekar wrote:
[...]
Note that following update to
On Fri, Oct 7, 2011 at 4:13 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
Thanks Paul;
yes, I can your changes in the patches.
so, you don't need v14 from me right? please
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:06]:
On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 17:26]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:25]:
On Thursday 06 October 2011 07:12 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111004 23:29]:
Will look at this series in next couple of days and do some testing.
Thanks, turns out there were a few
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:22]:
The changes looks fine to me. Though the ugly hard-coding
is back with it, it's a step towards generic_io, so hopefully
it won't have to stay for long time.
Nico please correct me if I'm wrong, but I think that with
generic map_io we
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:18]:
Are you considering this change for 3.2?
I think we should as this is blocking development for
generic map_io and genalloc changes for SRAM code.
OMAP4 errata WA would have a conflict with the
change is sram code and hence the
On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:06]:
On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 17:26]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
+void __iomem *
* Santosh Shilimkar santosh.shilim...@ti.com [111007 07:29]:
On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
..so I think we should just have a separate static mapping for
the omap4 errata fix SO page, and just limit the memory available
for SRAM code to ioremap.
How does
Hi Jean
On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote:
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are
On Thursday 06 October 2011, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com [111001 13:21]:
On 09/30/2011 05:29 PM, Kevin Hilman wrote:
Hi Arnd,
Kevin Hilman khil...@ti.com writes:
The upcoming OMAP4 PM series from Santosh[1] that we're planning to
queue for v3.2
On Friday 07 October 2011 08:41 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111007 07:29]:
On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
..so I think we should just have a separate static mapping for
the omap4 errata fix SO page, and just limit the memory
On Fri, 2011-10-07 at 10:22 +0100, Russell King - ARM Linux wrote:
On Fri, Oct 07, 2011 at 10:50:16AM +0200, Víctor Manuel Jáquez Leal wrote:
Convert a printk(KERN_ERR) message in the driver to pr_err().
...
@@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer
Arnd Bergmann a...@arndb.de writes:
On Thursday 06 October 2011, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com [111001 13:21]:
On 09/30/2011 05:29 PM, Kevin Hilman wrote:
Hi Arnd,
Kevin Hilman khil...@ti.com writes:
The upcoming OMAP4 PM series from Santosh[1] that
Enable IO Wake up for OMAP3 as part of PM Init.
Currently this has been managed in cpuidle path which is not the right place.
Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy
chain is handled as part of hwmod mux.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
The folowing patch series provides IO Daisychain feature via omap hwmod mux
framework.
The patch series has been generated against 3.1 rc9 and tested on OMAP3 Platform
(ZOOM3 and OMAP3430 SDP) for Retentiona and OFF mode in suspend/cpuidle path.
Tested on OMAP4 using [1] as OMAP4 Core PM is not
IO Daisychain has to be enabled only if the corresponding omap has
io wake up capability.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
From: Mohan V moh...@ti.com
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain according to the Sec 3.5.7.2.2
I/O Wake-Up Mechanism in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 15
From: Rajendra Nayak rna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 33 +
Since IO Daisychain modifies only PRM registers, it makes sense to move it to
PRM File.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 33 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 35 +++
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a window
where device
is idled and corresponding powerdomain can be ON/INACTIVE state.
* Santosh Shilimkar santosh.shilim...@ti.com [111007 10:05]:
I initially tried some thing similar but the issue was GP and
HS devices. SRAM_PA isn't same on GP and EMU device and hence
did that dynamically. One way is I can make GP and HS
device SRAM_PA same for OMAP4 (Will loose 16 KB of
On Friday 07 October 2011 11:46 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111007 10:05]:
I initially tried some thing similar but the issue was GP and
HS devices. SRAM_PA isn't same on GP and EMU device and hence
did that dynamically. One way is I can make GP and
* Santosh Shilimkar santosh.shilim...@ti.com [111007 10:46]:
On Friday 07 October 2011 11:46 PM, Tony Lindgren wrote:
I assume now you can add the mapping to io.c instead? If so,
then it's easier to apply the patches whatever way makes more
sense.
io.c change I took as you suggested.
On Friday 07 October 2011, Kevin Hilman wrote:
I've pulled in rmk/devel-stable as a dependency now, thanks for
reminding me of that.
Thomas, where should I get the irq-core branch (or whichever
I should wait for) to pull in as another dependency. Is that
branch one that never gets
On Fri, 7 Oct 2011, Arnd Bergmann wrote:
On Friday 07 October 2011, Kevin Hilman wrote:
I've pulled in rmk/devel-stable as a dependency now, thanks for
reminding me of that.
Thomas, where should I get the irq-core branch (or whichever
I should wait for) to pull in as another
On Monday 03 October 2011, Tony Lindgren wrote:
Please pull omap fixes from:
git://github.com/tmlind/linux.git fixes
Out of these the first three commits would be nice to get
into the -rc series with the first two causing boot issues
and the musb fixing an ugly warning.
Note however
On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote:
At some point in the next couple of years, I want
to convert all of, or as many as possible of, the
remaining printk uses to pr_level.
If the idea is also to get rid of printk() too (which IMHO would be a
good thing as it kills off
* Arnd Bergmann a...@arndb.de [111007 11:37]:
On Monday 03 October 2011, Tony Lindgren wrote:
Please pull omap fixes from:
git://github.com/tmlind/linux.git fixes
Out of these the first three commits would be nice to get
into the -rc series with the first two causing boot issues
On Fri, Oct 7, 2011 at 12:07 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 29 Sep 2011, Mike Turquette wrote:
Not all DPLLs are identical; some require special consideration such as
OMAP4's ABE DPLL, which can have an additional 4x multiplier added to
it's clock rate based on programming
Hi all,
Here's a repost of the original patches with minimal changes
to fix some compile warnings and with the acks added.
There's also one new patch to warn about trying to use the
omap_ioremap too early that's good to have for some sanity
checks.
These patches are against the dt branch in
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Signed-off-by:
This allows removing omap hacks for map_io allowing generic
map_io.
Note that in the future we can't do cpu_is_omap detection
until in init_early. This means that board-innovator.c now
assumes 15xx only, and board-generic.c assumes 16xx only.
This is best fixed later on by passing the SoC
This allows us to remove omap hacks for map_io.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/devices.c
Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony
This way we don't need to initialize SoC detection early
and can start using generic map_io.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3beagle.c |
We don't have cpu_is_omap SoC detection initialized until
SoC detection is initialized from init_early.
Note that with the common map_io we should no longer need
cpu_is_omap for ioremap.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/io.c |1 +
This assumes fixed mappings which will not work once we move
to use ioremap_exec(). It seems that these are currently
not in use, or in use for some out of tree corner cases.
If SRAM support for framebuffer is wanted, it should be done
with ioremap in the driver.
Note that further removal of the
On Fri, 2011-10-07 at 20:18 +0100, Russell King - ARM Linux wrote:
On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote:
At some point in the next couple of years, I want
to convert all of, or as many as possible of, the
remaining printk uses to pr_level.
If the idea is also to get
On Fri, Oct 07, 2011 at 12:48:21PM -0700, Joe Perches wrote:
On Fri, 2011-10-07 at 20:18 +0100, Russell King - ARM Linux wrote:
On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote:
At some point in the next couple of years, I want
to convert all of, or as many as possible of, the
* Tony Lindgren t...@atomide.com [111007 12:11]:
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
On Fri, 2011-10-07 at 20:57 +0100, Russell King - ARM Linux wrote:
On Fri, Oct 07, 2011 at 12:48:21PM -0700, Joe Perches wrote:
I think it needs to be done subsystem by subsystem,
arch by arch, as maintainers accept.
Agreed - but doing one instance here, maybe another instance somewhere
* Tony Lindgren t...@atomide.com [111006 16:38]:
Fix Enable 32kHz OS timer in order to allow sleep states in idle
warning. We are now compiling in bothe MPU timer and 32 KiHz timer,
so this warning is only valid when CONFIG_OMAP_32K_TIMER is not set.
-#ifdef CONFIG_OMAP_MPU_TIMER
+#if
On Friday 07 October 2011, Tony Lindgren wrote:
Then merge all the -rc fixes for various ARM platforms with:
$ git checkout fixes-for-rc
$ git reset --hard v3.1-rc9
$ git merge omap/fixes-for-rc soc foo/fixes-for-rc bar/fixes-for-rc
And then no rebasing is needed. Of course I could also
On Friday 07 October 2011, Thomas Gleixner wrote:
For your internal dependecies, yes. But for irq/core you don't have to
wait. You just need to tell Linus in the pull request that you pulled
my branch with my ack as it contains modifications which are
prerequisite for arm/whatever.
When I
On Thu, 6 Oct 2011, Tony Lindgren wrote:
* S, Venkatraman svenk...@ti.com [110825 07:23]:
On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Venkat,
On 8/24/2011 9:46 PM, S, Venkatraman wrote:
As part of an effort to get single ARM kernel binary [1],
On Fri, 7 Oct 2011, Santosh Shilimkar wrote:
I have reviewed and tested this series. No problems seen.
As asked on other thread, if you are targeting this one for
3.2, then sram changes would have a small conflict with
OMAP4 errata patch. If it is for 3.3, we should be able to
sort out that
On Fri, 7 Oct 2011, Tony Lindgren wrote:
We don't have cpu_is_omap SoC detection initialized until
SoC detection is initialized from init_early.
Note that with the common map_io we should no longer need
cpu_is_omap for ioremap.
Signed-off-by: Tony Lindgren t...@atomide.com
Paul Walmsley p...@pwsan.com writes:
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.
Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517. The TI81xx family of SoCs are at present
considered to
* Nicolas Pitre n...@fluxnic.net [111007 12:41]:
On Thu, 6 Oct 2011, Tony Lindgren wrote:
* S, Venkatraman svenk...@ti.com [110825 07:23]:
On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Venkat,
On 8/24/2011 9:46 PM, S, Venkatraman wrote:
As
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
+config PROBE_DEFER
+ bool Deferred Driver Probe
+ default y
+ help
+ This option provides deferring driver probe if it has dependency on
+
Tony,
Please pull the (hopefully) last few PM fixes/cleanups for v3.2.
Kevin
The following changes since commit 976d167615b64e14bc1491ca51d424e2ba9a5e84:
Linux 3.1-rc9 (2011-10-04 18:11:50 -0700)
are available in the git repository at:
git://github.com/khilman/linux-omap-pm.git
On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
+config PROBE_DEFER
+ bool Deferred Driver Probe
+ default y
+ help
+ This option
On Fri, Oct 7, 2011 at 12:49 AM, Greg KH g...@kroah.com wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
+config PROBE_DEFER
+ bool Deferred Driver Probe
+ default y
+ help
+ This option provides deferring driver probe if it has dependency on
+
On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Fri, 07 Oct 2011 10:33:09 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready.
Why not use the perfectly good existing error
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH g...@kroah.com wrote:
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
Add new error value so that drivers can request deferred probe
from drivercore.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Reported-by: Grant Likely
Hi Paul,
On 10/6/2011 20:40, Paul Walmsley wrote:
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check
On Fri, 7 Oct 2011, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111007 12:41]:
On Thu, 6 Oct 2011, Tony Lindgren wrote:
* S, Venkatraman svenk...@ti.com [110825 07:23]:
On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com
wrote:
Hi Venkat,
1 - 100 of 113 matches
Mail list logo
