Hi Tony,
On 09/20/2012 12:05 AM, Tony Lindgren wrote:
This can be local to mach-omap2 after we rip out the messed up
extmute stuff from board-zoom-peripherals.c that's all over
the place and probably does not even work because of all the
hardcoded GPIO numbers.
I also suggest ASoC gusy
-Ursprüngliche Nachricht-
Von: Paul Walmsley [mailto:p...@pwsan.com]
Gesendet: Mittwoch, 19. September 2012 18:07
An: Maximilian Schwerin
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Betreff: Re: AW: USB problem on beagleboard clone
On Wed, 19 Sep 2012, Maximilian
Hi,
On Wed, 19 Sep 2012, Paul E. McKenney wrote:
On Thu, Sep 13, 2012 at 06:52:10PM +, Paul Walmsley wrote:
On Wed, 12 Sep 2012, Paul E. McKenney wrote:
Subodh Nijsure (also CCed) reported something that might be similar on
ARM, and also reported that setting the following got
On Wed, 2012-09-19 at 15:53 -0400, Raphaël Assénat wrote:
Hello Tomi,
On 21/08/12 06:39 AM, Tomi Valkeinen wrote:
Hi,
On Wed, 2012-08-15 at 15:16 -0400, Raphael Assenat wrote:
On our AM3505 based board, dpi.c complains that there is no VDSS_DSI
regulator
and the framebuffer
Rename the smartreflex fck names:
- for consistency and better readability,
- for use by the SmartReflex driver, through the hwmod .main_clk
field.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
On Wed, Sep 19, 2012 at 02:46:58PM +0100, Dave Martin wrote:
On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote:
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For
On Wed, Sep 19, 2012 at 02:51:56PM +0100, Dave Martin wrote:
On Tue, Sep 18, 2012 at 05:35:32PM +0100, Lorenzo Pieralisi wrote:
This patch renames jump labels in v7_flush_dcache_all in order to define
a specific flush cache levels entry point.
TODO: factor out the level flushing loop if
On Wed, Sep 19, 2012 at 11:08:13PM +0300, Aaro Koskinen wrote:
On Fri, Sep 14, 2012 at 12:08:06PM +0200, Wolfram Sang wrote:
On Mon, Sep 03, 2012 at 11:23:22PM +0300, Aaro Koskinen wrote:
Add i2c driver to enable access to devices behind CBUS on Nokia Internet
Tablets.
The patch
On Thu, Sep 20, 2012 at 11:32:12AM +0100, Lorenzo Pieralisi wrote:
On Wed, Sep 19, 2012 at 02:51:56PM +0100, Dave Martin wrote:
On Tue, Sep 18, 2012 at 05:35:32PM +0100, Lorenzo Pieralisi wrote:
This patch renames jump labels in v7_flush_dcache_all in order to define
a specific flush
On Thu, Sep 20, 2012 at 11:25:14AM +0100, Lorenzo Pieralisi wrote:
On Wed, Sep 19, 2012 at 02:46:58PM +0100, Dave Martin wrote:
On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote:
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache
[adding CCs: Kukjin Kim, Shawn Guo, Magnus Damm, Rob Herring]
Pushed out a branch containing the set @
git://linux-arm.org/linux-2.6-lp.git cache-louis
for testing purposes.
Thanks a lot,
Lorenzo
On Tue, Sep 18, 2012 at 05:35:30PM +0100, Lorenzo Pieralisi wrote:
This patch series provides an
On Wed, 19 Sep 2012 14:05:43 Tony Lindgren wrote:
This is only used by omap1.
And to fix things properly, this should not be included
from the drivers at all.
Akced-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
I'll take care of updating the drivers when I have some spare time.
Thanks,
From: Jean Pihet j-pi...@ti.com
Select POWER_SUPPLY from POWER_AVS_OMAP entry in Kconfig.
This avoids the following build problems using a randconfig
that has CONFIG_POWER_SUPPLY not set:
LD init/built-in.o
arch/arm/mach-omap2/built-in.o: In function `sr_class3_configure':
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data.
Calls runtime PM API only in the DT case in order to unidle the
associated hwmods on AM335x.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 252
For platforms with DT populated, use dma_request_slave_channel()
to acquire the DMA channel. For !DT platforms, we fall back to
explicitly passing the omap_dma_filter_fn() to dma_request_channel().
Once all platforms boot from DT, the dma_request_channel() path can
be dropped.
Signed-off-by: Matt
AM33xx requires special handling in hsmmc initialization
platform glue.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index
For platforms with DT populated, use dma_request_slave_channel()
to acquire the DMA channel. For !DT platforms, we fall back to
explicitly passing the omap_dma_filter_fn() to dma_request_channel().
Once all platforms boot from DT, the dma_request_channel() path can
be dropped.
Signed-off-by: Matt
The davinci-pcm driver is the last in-kernel user of the private
EDMA API. Once it has been converted to DMA Engine API the
private EDMA API functionality can be folded into the EDMA DMA
Engine driver and removed.
Signed-off-by: Matt Porter mpor...@ti.com
---
Adds support for the defined EDMA, generic DMA controller, and
DMA request bindings for mmc and spi.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 46 +
1 file changed, 46 insertions(+)
diff --git
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. Since the EDMA
DMA Engine driver sets the maximum segments to 16, we do the
same.
Note: this can be removed once the DMA Engine API supports an
API to query the DMAC's segment
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 insertions(+)
create mode 100644
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 37 -
1 file changed, 37
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
There are a mind-boggling number of dependencies for this series:
Enable config option on OMAP and adjust the
private EDMA API header to match the move
of the private EDMA API out of mach-davinci/
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/dma/Kconfig |2 +-
drivers/dma/edma.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
Remove the device dependent settings (cpu_is_xxx(), IP fck etc.)
from the driver code and pass them instead via the platform
data.
This allows a clean separation of the driver code and the platform
code, as required by the recent re-org of the platform data header
files.
The patch also includes a
Remove the device dependent settings (cpu_is_xxx(), IP fck etc.)
from the driver code and pass them instead via the platform
data.
This allows a clean separation of the driver code and the platform
code.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/sr_device.c | 14
Fix the error handling path in omap_sr_probe to correctly
de-allocate resources in case of problems.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/power/avs/smartreflex.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c
I'll give it a try on my panda later today.
B
Sent from my iPhone
On Sep 20, 2012, at 2:56 AM, Paul Walmsley p...@pwsan.com wrote:
Hi,
On Wed, 19 Sep 2012, Paul E. McKenney wrote:
On Thu, Sep 13, 2012 at 06:52:10PM +, Paul Walmsley wrote:
On Wed, 12 Sep 2012, Paul E. McKenney
From: Arnout Vandecappelle (Essensium/Mind) arn...@mind.be
The buffers given to the read_buf and write_buf methods are not
necessarily u32-aligned, while the DMA engine is configured with
32-bit accesses. As a consequence, the DMA engine gives an error
which appears in the log as follows:
DMA
On Thu, Sep 20, 2012 at 10:43:46AM -0400, Matt Porter wrote:
Documentation/feature-removal-schedule.txt | 10 ++
1 file changed, 10 insertions(+)
We decided at kernel summit that we'd stop bothering with this, it's
mostly just bitrot and rarely read. I guess the ASoC driver update
On Thu, Sep 20, 2012 at 04:58:58PM +0100, Mark Brown wrote:
On Thu, Sep 20, 2012 at 10:43:46AM -0400, Matt Porter wrote:
Documentation/feature-removal-schedule.txt | 10 ++
1 file changed, 10 insertions(+)
We decided at kernel summit that we'd stop bothering with this, it's
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power state of the MPU subsystem.
The
Arnd, Olof,
Not sure if this has been reported yet, but arm-soc/for-next now has a
build error on omap due to the recent merge of the platform_data move
series.
The arm-soc/next/soc branch contains the arm-soc/omap/am33xx branch
which adds an include of plat/mscpi.h which has now moved.
Below
Hi
On Mon, 10 Sep 2012, Jon Hunter wrote:
From: Ming Lei ming@canonical.com
For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to
work
on OMAP4430.
The idea is from Woodruff Richard
Hi
On Mon, 10 Sep 2012, Jon Hunter wrote:
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we
can create a PMU device based upon the DEBUGSS HWMOD and use the CTI
interrupts
for routing
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120920 06:48]:
On Wed, 19 Sep 2012 14:05:43 Tony Lindgren wrote:
This is only used by omap1.
And to fix things properly, this should not be included
from the drivers at all.
Akced-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
I'll take
* Mark Brown broo...@opensource.wolfsonmicro.com [120919 19:05]:
On Wed, Sep 19, 2012 at 02:05:43PM -0700, Tony Lindgren wrote:
This is only used by omap1.
And to fix things properly, this should not be included
from the drivers at all.
Acked-by: Mark Brown
On Wed, 19 Sep 2012, Paul Walmsley wrote:
On Mon, 10 Sep 2012, Jon Hunter wrote:
To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding
HWMOD
data for the debug sub-system for OMAP3, we can
Hi
On Mon, 10 Sep 2012, Jon Hunter wrote:
From: Ming Lei ming@canonical.com
For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
(CTI) because there are no dedicated interrupts. In order to route the PMU
events via the CTI IRQs, the following modules must be
Hi
On Mon, 10 Sep 2012, Jon Hunter wrote:
When CPU-idle is enabled, the MPU sub-system will transition to low power
states during idle periods. If the PMU is active and the MPU sub-system
transitions to a low power state, such as retention, then the PMU context
will be lost and PMU events
* Peter Ujfalusi peter.ujfal...@ti.com [120920 00:29]:
Hi Tony,
On 09/20/2012 12:05 AM, Tony Lindgren wrote:
This can be local to mach-omap2 after we rip out the messed up
extmute stuff from board-zoom-peripherals.c that's all over
the place and probably does not even work because of
Hi Jon, Will, Ming, et al.,
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material) and the PM
runtime suspend/resume patch (which looks to me like 3.7-rc material) --
assuming this series makes it in for 3.7 ...
Paul,
On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley p...@pwsan.com wrote:
Hi Jon, Will, Ming, et al.,
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material) and the PM
runtime suspend/resume patch (which looks to me
Hi
On Thu, 20 Sep 2012, Shilimkar, Santosh wrote:
On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley p...@pwsan.com wrote:
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material) and the PM
runtime suspend/resume patch
On Thu, Sep 20, 2012 at 11:13 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Thu, 20 Sep 2012, Shilimkar, Santosh wrote:
On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley p...@pwsan.com wrote:
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which
* Tony Lindgren t...@atomide.com [120919 14:07]:
This is only used by omap1.
Turns out this one is already taken care of by Arnd's
platform data patches, so I'll drop this one.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
* Tony Lindgren t...@atomide.com [120919 14:07]:
This is only used by omap1.
This too is handled by Arnd's series already, dropping this one.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
* Kevin Hilman khil...@deeprootsystems.com [120920 09:39]:
Arnd, Olof,
Not sure if this has been reported yet, but arm-soc/for-next now has a
build error on omap due to the recent merge of the platform_data move
series.
The arm-soc/next/soc branch contains the arm-soc/omap/am33xx branch
Hi,
On Thursday, September 20, 2012, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When runtime PM is disabled, what we want is for callbacks not to be
called from then on. However, currently, when runtime PM is disabled,
operations such as 'get' will also fail even if the device
On Wed, Sep 19, 2012 at 02:05:39PM -0700, Tony Lindgren wrote:
We are moving omap2+ to use the device tree based pinctrl-single.c
and will be removing the old mux framework. This will remove the
omap1 specific parts from plat-omap.
Cc: Felipe Balbi ba...@ti.com
Cc: Grant Likely
Hi,
On Thu, Sep 20, 2012 at 11:34:42AM -0700, Tony Lindgren wrote:
Hi Keshava Felipe,
Looks like we have something broken in linux next:
make[2]: *** No rule to make target `drivers/mfd/omap-usb-tll.o', needed by
`drivers/mfd/built-in.o'. Stop.
This is at least with my n8x0 config,
On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
Hi Jon, Will, Ming, et al.,
Hi Paul,
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material) and the PM
runtime suspend/resume patch (which looks to me
From: Kevin Hilman khil...@ti.com
When runtime PM is disabled, what we want is for callbacks not to be
called from then on. However, currently, when runtime PM is disabled,
operations such as 'get' will also fail even if the device is
currently active.
Since calling 'get' on a device that is
On Sep 20, 2012, at 2:56 AM, Paul Walmsley wrote:
Hi,
On Wed, 19 Sep 2012, Paul E. McKenney wrote:
On Thu, Sep 13, 2012 at 06:52:10PM +, Paul Walmsley wrote:
On Wed, 12 Sep 2012, Paul E. McKenney wrote:
Subodh Nijsure (also CCed) reported something that might be similar on
ARM,
On Thursday, September 20, 2012, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When runtime PM is disabled, what we want is for callbacks not to be
called from then on. However, currently, when runtime PM is disabled,
operations such as 'get' will also fail even if the device is
On Thu, Sep 20, 2012 at 09:49:13PM +, Bruce, Becky wrote:
On Sep 20, 2012, at 2:56 AM, Paul Walmsley wrote:
Hi,
On Wed, 19 Sep 2012, Paul E. McKenney wrote:
On Thu, Sep 13, 2012 at 06:52:10PM +, Paul Walmsley wrote:
On Wed, 12 Sep 2012, Paul E. McKenney wrote:
* Matt Porter mpor...@ti.com [120920 07:43]:
For platforms with DT populated, use dma_request_slave_channel()
to acquire the DMA channel. For !DT platforms, we fall back to
explicitly passing the omap_dma_filter_fn() to dma_request_channel().
Once all platforms boot from DT, the
Hi,
* Jean Pihet jean.pi...@newoldbits.com [120920 07:48]:
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -131,14 +131,11 @@ static void sr_set_clk_length(struct omap_sr *sr)
struct clk *sys_ck;
u32 sys_clk_speed;
- if (cpu_is_omap34xx())
* Matt Porter mpor...@ti.com [120920 07:43]:
For platforms with DT populated, use dma_request_slave_channel()
to acquire the DMA channel. For !DT platforms, we fall back to
explicitly passing the omap_dma_filter_fn() to dma_request_channel().
Once all platforms boot from DT, the
On Mon, Sep 17, 2012 at 08:06:36PM -0700, Tony Lindgren wrote:
The following changes since commit 68cb700c59fae6cd539c9dc1e9f2584f671935a0:
ARM: OMAP1: Move SoC specific headers from plat to mach for omap1
(2012-09-12 18:06:31 -0700)
are available in the git repository at:
On Thu, 20 Sep 2012, Paul E. McKenney wrote:
On Thu, Sep 20, 2012 at 09:49:13PM +, Bruce, Becky wrote:
OK, people, you can stop heckling me about sent from my iPhone - I'm in
the wilds of rural Louisiana with really bad internet service and was
trying to work on my phone (but, alas,
Hi Felipe,
I just noticed today that one of my boards (3530/Overo) was not making
it to the console when using an Debian rootfs (nfsroot) but works fine
with my basic busybox initramfs. Basically, it hangs somewhere between
finishing the userspace init and launching the login shell.
git bisect
Kevin Hilman khil...@deeprootsystems.com writes:
Hi Felipe,
I just noticed today that one of my boards (3530/Overo) was not making
it to the console when using an Debian rootfs (nfsroot) but works fine
with my basic busybox initramfs. Basically, it hangs somewhere between
finishing the
Hi Arnd Olof,
Here's one more branch to take us a bit closer to getting the
single zImage working on omaps. It would be nice to get merged
into arm-soc/next/cleanup before the merge window if still
possible.
I've based it on top of Arnd's 2203747c (ARM: omap: move
platform_data definitions) to
On Thu, Sep 20, 2012 at 10:47:25PM +, Paul Walmsley wrote:
On Thu, 20 Sep 2012, Paul E. McKenney wrote:
On Thu, Sep 20, 2012 at 09:49:13PM +, Bruce, Becky wrote:
OK, people, you can stop heckling me about sent from my iPhone - I'm in
the wilds of rural Louisiana with really
On Wed, Sep 19, 2012 at 10:56 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Thu, Sep 20, 2012 at 12:27 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 17 September 2012, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120914 02:21]:
OMAP interconnect drivers
Hi all,
With the recent pull request I sent for v3.7, we now have pretty
much all the mach includes fixed up for omap2+ for single zImage
support.
We still have quite a few plat headers that we need to sort
out manually.
Please take a look at the following list, and reply to this
thread if you
* Benoit Cousson b-cous...@ti.com [120919 19:24]:
Hi Tony,
I was about to take the DTS patch, but was wondering if you will pull
the driver changes for 3.7.
I suggest that you do a separate branch on top of Paul's hwmod series
when he posts those if that works for you?
Regards,
Tony
--
To
* Olof Johansson o...@lixom.net [120920 16:23]:
On Wed, Sep 19, 2012 at 10:56 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Thu, Sep 20, 2012 at 12:27 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 17 September 2012, Tony Lindgren wrote:
* Santosh Shilimkar
* Pantelis Antoniou pa...@antoniou-consulting.com [120918 12:11]:
As long as we get the regulator to work early in the game no problem.
I don't know if deferring the probe will work in this case.
I could give it a shot and see if it works at all.
Did you have any luck with deferred probe
Hi
On Wed, 12 Sep 2012, Omar Ramirez Luna wrote:
Add mmu hwmod data for iva and isp.
Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
Hi
On Wed, 12 Sep 2012, Paul Walmsley wrote:
On Thu, 19 Jul 2012, Tero Kristo wrote:
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level
Hi Omar
On Wed, 22 Aug 2012, Omar Ramirez Luna wrote:
Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.
E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- As of now cpu1 is not
Hi
On Wed, 22 Aug 2012, Omar Ramirez Luna wrote:
For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony
The following changes since commit c4dbc7c086ce96d17f18b7a4a965b01d54d45f46:
Merge tag 'cleanup-fixes-for-v3.7' into test_merge_v3.6-rc6_cleanup-fixes
(2012-09-19 13:54:08 -0600)
are available in the git repository at:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony
The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:
Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
On Thu, Sep 20, 2012 at 04:09:36PM -0700, Tony Lindgren wrote:
Hi Arnd Olof,
Here's one more branch to take us a bit closer to getting the
single zImage working on omaps. It would be nice to get merged
into arm-soc/next/cleanup before the merge window if still
possible.
I've based it on
* Afzal Mohammed af...@ti.com [120919 06:22]:
Hi,
This version - v7 as compared to previous version, takes care of
rounding issues due to the usage of nanoseconds in generic timing
routine. All calculations are now in picoseconds. Once all timings
are calculated it is converted to
Hi Tony,
On Fri, Sep 21, 2012 at 10:21:04, Tony Lindgren wrote:
I gave this series a quick test on my n800 after applying the
two serial patches needed to get the uart to work, and it seems
to be working just fine.
Was there still some discussion on the format of the generic
timings
Hi Kevin,
On Thu, Sep 20, 2012 at 3:13 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Poddar, Sourav sourav.pod...@ti.com writes:
Hi Felipe,
On Tue, Sep 18, 2012 at 5:04 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Sep 18, 2012 at 05:05:54PM +0530, Sourav Poddar wrote:
Drop the check
Commit c49f34bc (ARM: OMAP2+ Move SoC specific headers to be local to
mach-omap2) moved omap34xx.h to mach-omap2. This broke omap3isp, as it
includes omap34xx.h.
Instead of moving omap34xx to platform_data, simply add the two
definitions the driver needs and remove the include altogether.
Since iommu is not currently supported on OMAP1, merge plat/iommu2.h into
iommu.h so only one file would have to move to platform_data/ as part of the
single zImage effort.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h | 88 +++--
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/iommu2.c| 2 +-
* Mohammed, Afzal af...@ti.com [120920 22:02]:
Hi Tony,
On Fri, Sep 21, 2012 at 10:21:04, Tony Lindgren wrote:
I gave this series a quick test on my n800 after applying the
two serial patches needed to get the uart to work, and it seems
to be working just fine.
Was there still
86 matches
Mail list logo
