On Tue, Oct 4, 2011 at 4:29 AM, Tony Lindgren t...@atomide.com wrote:
* Nicolas Pitre n...@fluxnic.net [111003 15:05]:
On Mon, 3 Oct 2011, Nicolas Pitre wrote:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 11:26]:
Furthermore... there is also a
On Tue, Oct 4, 2011 at 9:21 AM, Paul Walmsley p...@pwsan.com wrote:
+ Rajendra, Santosh, Benoît
Hi
On Mon, 3 Oct 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110929 17:40]:
On Thu, 22 Sep 2011, Keerthy wrote:
From: Vishwanath BS vishwanath...@ti.com
OMAP4460
Nicolas,
On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 14:36]:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 11:26]:
OK, so let's modify omap4_panda_map_io() just to test this one board and
reverse
On Monday 03 October 2011, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [111003 02:20]:
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
In the long run, I'd hope we can just get rid of these for
subarchitectures
that support device tree probing and make the
Hi,
On my BeagleBoard xM, configuring the MUSB controller in Linux to
peripheral mode (i.e. not OTG mode) and using a built-in gadget driver,
the gadget device sometimes does not appear after a software reboot.
I've seen this with both 2.6.32 and 2.6.39 (Angstrom 2008.1 and 2010.x
distros,
Hi Paul,
On Mon, 2011-10-03 at 14:48 -0600, Paul Walmsley wrote:
Hello Sricharan,
It looks like Archit is out of the office. Would it be possible for you
to test the updated DSS reset patch, below?
thanks
- Paul
-- Forwarded message --
Date: Mon, 3 Oct 2011
On 10/03/11 18:45, Pedanekar, Hemant wrote:
Hi Igor,
Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM:
Hi Hemant,
On 09/29/11 04:09, Hemant Pedanekar wrote:
This patch adds minimal support and build configuration for TI8148 EVM.
Also adds support for low level debugging on UART1
On 10/04/11 10:06, Tomi Valkeinen wrote:
Hi Paul,
On Mon, 2011-10-03 at 14:48 -0600, Paul Walmsley wrote:
Hello Sricharan,
It looks like Archit is out of the office. Would it be possible for you
to test the updated DSS reset patch, below?
thanks
- Paul
-- Forwarded
Hi,
On Tue, 23 Aug 2011, Hemant Pedanekar wrote:
This patch set is the v2 of TI816X clock and hwmods patches sent earlier.
The clock data is currently added only for TI816X, while minimal hwmod data
common for TI816X and TI814X is added.
This patch set depends on following patches:
From: Hemant Pedanekar hema...@ti.com
Add clockdomain data for the TI816x and TI814x SoCs.
This patch is a collaboration between Hemant Pedanekar hema...@ti.com
and Paul Walmsley p...@pwsan.com.
---
arch/arm/mach-omap2/Makefile|3
arch/arm/mach-omap2/clockdomain.h
Add clockdomain control code for the TI816x and TI814x SoCs.
This patch is a collaboration between Hemant Pedanekar hema...@ti.com
and Paul Walmsley p...@pwsan.com.
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/clockdomain.h |1
TI81xx uses a novel PRCM register layout. It most closely resembles
the OMAP4 PRCM, but with a few changes. These devices also have
limited power management functionality.
Add powerdomain PRCM implementation code for the TI81xx chips.
This patch is a collaboration between Hemant Pedanekar
From: Hemant Pedanekar hema...@ti.com
Add powerdomain data for the TI81xx family of SoCs.
This patch is a collaboration between Hemant Pedanekar hema...@ti.com
and Paul Walmsley p...@pwsan.com.
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/io.c |
From: Hemant Pedanekar hema...@ti.com
This patch adds some of the PRCM register offsets for the TI814X and
TI816X devices as required for the clockdomain, powerdomain, clock, and
hwmod data.
This patch is a collaboration between Hemant Pedanekar hema...@ti.com
and Paul Walmsley p...@pwsan.com.
Igor Grinberg wrote on Tuesday, October 04, 2011 2:31 PM:
On 10/03/11 18:45, Pedanekar, Hemant wrote:
Hi Igor,
Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM:
Hi Hemant,
On 09/29/11 04:09, Hemant Pedanekar wrote:
This patch adds minimal support and build configuration for
Hi Todd,
On Mon, Sep 26, 2011 at 04:44:23PM -0700, Todd Poynor wrote:
LOCKDEP explicitly sets all irq_desc locks as a single lock-class,
causing possible recursive locking detected when the TWL RTC
driver calls through enable_irq_wake to twl6030_irq_set_wake,
which recursively calls
Hi Todd,
On Mon, Sep 26, 2011 at 04:44:24PM -0700, Todd Poynor wrote:
Module IRQs may still be disabled by DPM at the time the TWL6030
ISR runs, causing handle_simple_irq() to silently do nothing.
This may result in missing TWL RTC alarm wakeups, for example,
since the RTC child module ISR is
Hi Tony,
(git.)kernel.org is back online recently, but there is no tmlind/* project(s)
on it?
What are your intentions on this?
Should we just wait for while, or will it stay on the github?
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of
On Tue, Oct 04, 2011 at 10:58:40AM +0530, Rajendra Nayak wrote:
The problem is I don't know if the property in the regulator dt
node is called vin-supply or vxyz-supply and hence I
can parse the property based on a substring alone, which is
-supply because all I know is the property name is
Hi Tony,
On Wed, Sep 28, 2011 at 11:32:31AM -0700, Tony Lindgren wrote:
* Samuel Ortiz sa...@linux.intel.com [110822 06:20]:
Hi Kyle,
On Thu, Aug 11, 2011 at 10:33:11PM -0500, Kyle Manna wrote:
These patches add basic functionality to the twl4030-madc driver to make
it work on the
Hi Arnd,
On Sun, Oct 02, 2011 at 04:45:52PM +0200, Arnd Bergmann wrote:
We can only have one pwm driver built into the kernel,
I seem to remember that Bill Gatliff was working on a PWM subsystem that would
get rid of the current pwm.h ugliness. Do we have any updates on this one ?
The patch
Hi Arnd,
On Sun, Oct 02, 2011 at 04:45:48PM +0200, Arnd Bergmann wrote:
The ehci-omap and ohci-omap3 drivers both depend on the
omap-usb-host MFD support driver. By default, this is
automatically turned on, but it is possible to disable
the driver, which results in a link error.
I don't see
On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
On Tue, Oct 04, 2011 at 10:58:40AM +0530, Rajendra Nayak wrote:
The problem is I don't know if the property in the regulator dt
node is called vin-supply or vxyz-supply and hence I
can parse the property based on a substring alone, which
On Tue, Oct 04, 2011 at 05:10:00PM +0530, Rajendra Nayak wrote:
On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
This seems fairly straightforward though it will require some changes
within Linux, all we have to do is have the regulators name their
supplies.
through dt? thats what the
On Sat, Oct 1, 2011 at 12:31 AM, Paul Walmsley p...@pwsan.com wrote:
Hi Keshava,
by the way, when you repost these, can you split this into two series --
one for the arch/arm/*omap* changes, and the other for changes that should
go in through the MFD tree? Then just note in the second
On Fri, Sep 30, 2011 at 11:46 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 30 Sep 2011, Munegowda, Keshava wrote:
On Fri, Sep 30, 2011 at 2:02 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 28 Sep 2011, Munegowda, Keshava wrote:
Thanks paul,
But In USB Host case, there is a
On Fri, Sep 30, 2011 at 10:47 PM, Kevin Hilman khil...@ti.com wrote:
Munegowda, Keshava keshava_mgo...@ti.com writes:
[...]
+
+static struct omap_hwmod_ocp_if omap34xx_f_cfg__usb_tll_hs = {
+ .clk = usbtll_ick,
+ .user = OCP_USER_MPU,
+ .flags =
On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
On Tue, Oct 04, 2011 at 05:10:00PM +0530, Rajendra Nayak wrote:
On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
This seems fairly straightforward though it will require some changes
within Linux, all we have to do is have the
On Tue, Oct 04, 2011 at 05:32:47PM +0530, Rajendra Nayak wrote:
On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
I wouldn't expect it done through DT (except for things like the fixed
voltage regulator) - the driver should just know.
something like a
int regulator_set_supply(struct
On Tue, Oct 4, 2011 at 5:41 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Tue, Oct 04, 2011 at 05:32:47PM +0530, Rajendra Nayak wrote:
On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
I wouldn't expect it done through DT (except for things like the fixed
voltage
On Tuesday 04 October 2011, Samuel Ortiz wrote:
On Sun, Oct 02, 2011 at 04:45:52PM +0200, Arnd Bergmann wrote:
We can only have one pwm driver built into the kernel,
I seem to remember that Bill Gatliff was working on a PWM subsystem that would
get rid of the current pwm.h ugliness. Do we
Hi Grant,
On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
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 the problem of getting devices
initialized in the
* Igor Grinberg grinb...@compulab.co.il [111004 02:20]:
Hi Tony,
(git.)kernel.org is back online recently, but there is no tmlind/* project(s)
on it?
What are your intentions on this?
Should we just wait for while, or will it stay on the github?
OK thanks for the update, I'll switch back
* Arnd Bergmann a...@arndb.de [111004 00:10]:
On Monday 03 October 2011, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [111003 02:20]:
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
In the long run, I'd hope we can just get rid of these for
subarchitectures
On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah manj...@ti.com wrote:
On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
Hi Manjunath,
Here's the current state of the patch. The major think that needs to
be done is to convert it to use a separate workqueue as described in
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
suspend (S2R), CPU hotplug and CPUidle.
No need to repost, but can you update the versions in your branch to
have an ARM: prefix in the subject per Arnd's
* Shilimkar, Santosh santosh.shilim...@ti.com [111003 22:45]:
On Tue, Oct 4, 2011 at 4:29 AM, Tony Lindgren t...@atomide.com wrote:
* Nicolas Pitre n...@fluxnic.net [111003 15:05]:
On Mon, 3 Oct 2011, Nicolas Pitre wrote:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
* Nicolas Pitre
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
(PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software must wait for
the I/O
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
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration.
The patch also removes IO Daisychain control from OMAP3 CPUIdle path since
it is not required anymore as it has handled via hwmod mux.
omap3_enable_io_chain is renamed as omap3_trigger_wuclk_ctrl
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/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 36
The folowing patch series provides IO Daisychain feature via omap hwmod mux
framework.
The patch series has been generated against 3.1 rc4 and tested on OMAP3 Platform
(ZOOM3) for Retention and OFF mode in suspend/cpuidle path.
Also tested against latest UART Runtime with Chain Handler patches
On Fri, Sep 30, 2011 at 03:04:45PM +0530, Rajendra Nayak wrote:
On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
On 9/27/2011 8:59 PM, Mark Brown wrote:
I'm not sure how this should work in a device tree world, I'd
Ohad Ben-Cohen o...@wizery.com writes:
Hi Kevin,
On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman khil...@ti.com wrote:
Benoit did just this in preparation for DT.
http://marc.info/?l=linux-omapm=131672480111927w=2
Will that meet your needs?
It's almost there, but not entirely.
On Mon, Oct 03, 2011 at 11:34:34AM -0600, Paul Walmsley wrote:
+ devicetree-discuss, lkml
On Mon, 3 Oct 2011, Cousson, Benoit wrote:
But at that time, device tree was not there...
Now, the whole dev_attr stuff will be replaced because device tree is able
to
provide the driver any
On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah manj...@ti.com wrote:
On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
Hi Manjunath,
Here's the current state of the patch. The major think that needs to
be
* Vishwanath BS vishwanath...@ti.com [111004 10:25]:
@@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD,
On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [111004 00:10]:
On Monday 03 October 2011, Tony Lindgren wrote:
Yes please leave out the list so we don't need to constantly update it.
Let's just always build in MACH_OMAP_GENERIC.
That's what I
On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman khil...@ti.com wrote:
The approach is OK with me, but I'm a bit torn about whether or not to
merge this since the need for this should go away when converting to DT.
I guess it will still take some time until our boards are fully
functional with DT,
On Monday, October 03, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Update the documentation for the recently updated pm_qos API, kernel
and user space.
Add the documentation for the per-device PM QoS (dev_pm_qos) framework
API.
Signed-off-by: Jean Pihet
On 09/22/2011 08:59 AM, Yong Zhang wrote:
Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn
Ohad Ben-Cohen o...@wizery.com writes:
On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman khil...@ti.com wrote:
The approach is OK with me, but I'm a bit torn about whether or not to
merge this since the need for this should go away when converting to DT.
I guess it will still take some time until
Hi Vishwa,
Vishwanath BS vishwanath...@ti.com writes:
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
(PRCM.PM_WKEN_WKUP[16]
Hi Rajendra,
Rajendra Nayak rna...@ti.com writes:
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup
On Mon, Sep 26, 2011 at 03:30:50PM -0700, Kevin Hilman wrote:
ping
On 09/06/2011 03:31 PM, Kevin Hilman wrote:
Hi Ben,
On 08/23/2011 05:10 PM, Kevin Hilman wrote:
Ben,
Here's one more I2C cleanup series for v3.2.
It applies on top of my for_3.2/i2c-fixes branch just submitted.
On Mon, 3 Oct 2011, Russell King - ARM Linux wrote:
On Mon, Oct 03, 2011 at 06:09:57PM -0400, Nicolas Pitre wrote:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
Having the SRAM base address move around with different sizes also
requires the SoC detection.. Otherwise we can end up mapping
The commit 318c3e15cd55c73a26ae22a65a8183655b3003f9
added some fck clock alias to timer devices that are
not needed anymore since hwmod framework will create
them automatically.
A warning was added to highlight and thus fix the redundancy.
[0.616424] omap_timer.1: alias fck already exists
[
On Tue, 4 Oct 2011, Santosh Shilimkar wrote:
On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 14:36]:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
Having the SRAM base address move around with different sizes also
requires the SoC
Hi Tony,
Here is the series to fix the warning and remove the redundant
latency structure that be removed since the timer runtime PM
adaptation was just pulled.
I was just able to test that on OMAP4.
Patches are based on Kevin's for_3.2/omap_device-2 branch
and are available here:
Remove the structure since a default one is now available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/timer.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c
Hi Tarun,
On 10/4/2011 11:20 PM, Cousson, Benoit wrote:
Hi Tony,
Here is the series to fix the warning and remove the redundant
latency structure that be removed since the timer runtime PM
adaptation was just pulled.
I was just able to test that on OMAP4.
It will be nice if you can test
On 10/4/2011 9:54 PM, Ohad Ben-Cohen wrote:
On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilmankhil...@ti.com wrote:
The approach is OK with me, but I'm a bit torn about whether or not to
merge this since the need for this should go away when converting to DT.
I guess it will still take some time
Govindraj.R govindraj.r...@ti.com writes:
We had been using traditional 8250 driver as uart console driver
prior to omap-serial driver. Since we have omap-serial driver
in mainline kernel for some time now it has been used as default
uart console driver on omap2+ platforms. Remove 8250
On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
Which makes me think... with all those architectures intercepting
ioremap calls in order to provide an equivalent static mapping address,
they already get an unexpected domain given that static mappings are
mostly DOMAIN_IO and
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+GFP_KERNEL);
+ if (!init_data)
+
On Tue, 4 Oct 2011, Russell King - ARM Linux wrote:
On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
Which makes me think... with all those architectures intercepting
ioremap calls in order to provide an equivalent static mapping address,
they already get an unexpected
On Wed, Oct 05, 2011 at 12:05:16AM +0530, G, Manjunath Kondaiah wrote:
On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah manj...@ti.com
wrote:
On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
Hi Manjunath,
On Wed, Oct 05, 2011 at 12:01:27AM +0100, Russell King - ARM Linux wrote:
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+
* Nicolas Pitre n...@fluxnic.net [111004 15:47]:
On Tue, 4 Oct 2011, Russell King - ARM Linux wrote:
On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
Which makes me think... with all those architectures intercepting
ioremap calls in order to provide an equivalent static
Hi all,
Related to the omap static mapping, here's a first take on moving the
SRAM init to happen later so we can do generic map_io.
Still working on a similar patch for omap1, will send it a bit later.
Regards,
Tony
---
Tony Lindgren (4):
ARM: Add __arm_ioremap_exec for mapping
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.
Signed-off-by: Tony Lindgren t...@atomide.com
---
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
---
arch/arm/mach-omap2/board-omap3beagle.c |7 --
arch/arm/mach-omap2/io.c | 91 --
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
This allows us to remove omap hacks for map_io.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/io.c | 19 +---
arch/arm/plat-omap/sram.c | 69 +
2 files changed, 22 insertions(+), 66 deletions(-)
diff --git
On Tue, 4 Oct 2011, Tony Lindgren wrote:
In any case, I suggest we add the following __arm_ioremap_exec patch
and then sort out issues with it as they show up.
This allows further work on the common SRAM genalloc patches and generic
map_io patches.
Nico, I already have a series
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 source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Signed-off-by:
* Arnd Bergmann a...@arndb.de [111004 11:55]:
On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [111004 00:10]:
On Monday 03 October 2011, Tony Lindgren wrote:
Yes please leave out the list so we don't need to constantly update it.
Let's just
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 nicolas.pi...@linaro.org
---
arch/arm/mach-omap2/io.c | 19 +---
arch/arm/plat-omap/sram.c | 69
* Nicolas Pitre n...@fluxnic.net [111004 17:23]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
In any case, I suggest we add the following __arm_ioremap_exec patch
and then sort out issues with it as they show up.
This allows further work on the common SRAM genalloc patches and generic
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 Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index e26c79c..e6ee884 100644
---
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 Lindgren t...@atomide.com
That's great.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
diff --git
Hi Paul,
Paul Walmsley wrote on Tuesday, October 04, 2011 2:54 PM:
Hi,
On Tue, 23 Aug 2011, Hemant Pedanekar wrote:
This patch set is the v2 of TI816X clock and hwmods patches sent earlier.
The clock data is currently added only for TI816X, while minimal hwmod data
common for TI816X
On 10/04/2011 04:21 PM, Nicolas Pitre wrote:
On Tue, 4 Oct 2011, Santosh Shilimkar wrote:
On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 14:36]:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
Having the SRAM base address move around with
On Tue, 4 Oct 2011, Rob Herring wrote:
On 10/04/2011 04:21 PM, Nicolas Pitre wrote:
On Tue, 4 Oct 2011, Santosh Shilimkar wrote:
On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 14:36]:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Wednesday, October 05, 2011 2:18 AM
To: Vishwanath BS
Cc: linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; moh...@ti.com
Subject: Re: [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
Hi
85 matches
Mail list logo
