NULL and safety checks
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/pmgr/dev.c | 35 +--
drivers/dsp/bridge/pmgr/msg.c |4 +-
drivers/dsp/bridge/rmgr/node.c | 33 +--
drivers/dsp/bridge/rmgr/proc.c | 10 ++-
drivers/dsp/bridge
Replace the physical contiguos allocation for DMM tables as the
required space might not available after some time, use virtual memory
allocation instead.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/mem.h | 17 +
drivers/dsp/bridge/pmgr
avoid issues of two modules managing mmu data/irqs/resets;
this until tidspbridge can be safely migrated to iommu framework.
Omar Ramirez Luna (4):
OMAP3: hwmod data: add mmu data for iva and isp
OMAP4: hwmod data: add mmu hwmod for ipu and dsp
OMAP3/4: iommu: migrate to hwmod framework
Add mmu hwmod data for iva and isp.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 131
arch/arm/plat-omap/include/plat/iommu.h| 13 +++
2 files changed, 144 insertions(+), 0 deletions(-)
diff --git
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 154 +--
1 files changed, 142 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm
device and resource data, handling
of sysconfig register for softreset purposes; and add device
latency in preparation for runtime PM.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 163
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations, reset and sysconfig
handling.
Tidspbridge uses a macro removed with this patch, for now the value
is hardcoded to avoid breaking compilation.
Signed-off-by: Omar Ramirez Luna omar.rami
Hi Tarun,
On Tue, Sep 20, 2011 at 6:30 AM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Clock is enabled only when timer is started and disabled when the the timer
is stopped. Therefore before accessing registers in functions clock is enabled
and then disabled back at the end of access.
On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
...
My use case is as follows:
DSP sends a mailbox message to ARM, this triggers a tasklet in mailbox
for processing the message, when it reaches tidspbridge it turns out
that the DSP wants to enable a gpt
On Thu, Nov 17, 2011 at 3:42 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
...
Is the intention to restrict enabling the dmtimer clocks from hard|soft
irqs?
The aim is to prevent client drivers perform clock enable/disable
independently.
Instead just use the request/start/stop APIs.
Given that dm timer framework doesn't support request of clocks
by soft | hard irqs because some recent changes, tidspbridge needs
to request its clocks on init and enable/disable them on demand.
This was first seen on 3.2-rc1.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers
* on softirq or hardirq, because code handling source
parent clocks is still using clk_get, since there is only one user of those
APIs that acquires a lock in a softirq context (tidspbridge) for now it
can be changed.
Omar Ramirez Luna (2):
ARM: OMAP: dmtimer: fix sleeping function called from invalid
-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 69 +
1 files changed, 42 insertions(+), 27 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index af3b92b..2acd4de 100644
--- a/arch/arm
.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 83 -
arch/arm/plat-omap/include/plat/dmtimer.h |6 ++-
2 files changed, 26 insertions(+), 63 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat
Hi Paul,
On 27 June 2012 20:27, Omar Ramirez Luna omar.l...@linaro.org wrote:
On 19 June 2012 12:48, Cousson, Benoit b-cous...@ti.com wrote:
On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
Hi Benoit,
On 19 June 2012 07:36, Cousson, Benoit b-cous...@ti.com wrote:
On 6/16/2012 3:56 AM, Omar
On 11 July 2012 12:07, Kevin Hilman khil...@ti.com wrote:
...
[2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
[2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine
channel 62
[2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
[2.331512]
On 12 June 2012 07:01, Rajendra Nayak rna...@ti.com wrote:
On Friday 08 June 2012 06:46 PM, Rajendra Nayak wrote:
On Friday 08 June 2012 06:35 PM, Tero Kristo wrote:
On Fri, 2012-06-08 at 17:55 +0530, Rajendra Nayak wrote:
On Friday 08 June 2012 04:26 PM, Tony Lindgren wrote:
* Rajendra
Hi Kevin,
On 11 July 2012 16:42, Kevin Hilman khil...@ti.com wrote:
Omar Ramirez Luna omar.l...@linaro.org writes:
On 12 June 2012 07:01, Rajendra Nayak rna...@ti.com wrote:
[...]
..anyone knows of any more fixes going around?
I'm seeing the same thing, it gets stuck trying to enable
On 12 July 2012 00:27, Rajendra Nayak rna...@ti.com wrote:
On Thursday 12 July 2012 05:28 AM, Omar Ramirez Luna wrote:
I suspect this might be specific to 4460 as Rajendra reported it was
working for him on 4430 but not on 4460, I haven't tried 4430 but let
me see if I can find one.
Yes
by hwmod code.
While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 files changed, 22 insertions(+), 15
-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 091c199..f6f8d99 100644
--- a/arch
This APIs are meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data
to control their reset lines, they are expected to know the name
of the reset line they are trying to control.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
On 17 July 2012 05:51, Ohad Ben-Cohen o...@wizery.com wrote:
+ Paul
On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel joerg.roe...@amd.com wrote:
On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
Omar Ramirez Luna (6):
ARM: OMAP: iommu: fix including iommu.h without IOMMU_API
to control.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
This one has been queued for 3.7 with a few changes. Some more detail was
added to the function documentationrovement. Also the multiple
assignments were removed per Documentation/CodingStyle chapter 1:
Don't put multiple
Hi.
On 2 August 2012 02:52, Paul Walmsley p...@pwsan.com wrote:
On Mon, 16 Jul 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
On 3 August 2012 00:24, Vaibhav Hiremath hvaib...@ti.com wrote:
On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote:
So in _enable:
_enable_clocks(oh);
if (soc_ops.enable_module)
soc_ops.enable_module(oh);
The enable_module part seems redundant to me, since
Hi Benoit,
On 20 August 2012 09:49, Benoit Cousson b-cous...@ti.com wrote:
On 07/16/2012 09:21 PM, 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
Hi Benoit,
On 20 August 2012 05:21, Benoit Cousson b-cous...@ti.com wrote:
Hi Omar,
On 08/03/2012 05:52 PM, Omar Ramirez Luna wrote:
On 3 August 2012 00:24, Vaibhav Hiremath hvaib...@ti.com wrote:
On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote:
So in _enable:
_enable_clocks(oh
On 20 August 2012 09:49, Benoit Cousson b-cous...@ti.com wrote:
On 07/16/2012 09:21 PM, 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
From: Omar Ramirez Luna omar.rami...@ti.com
The patch to expose hwmod assert/deassert functions through omap_device
has been accepted and queued for 3.7[1], however these two patches are
needed to make the API functional. Hence a revised version is being sent
according to previous comments
-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eaedc33..b65e021 100644
--- a/arch/arm/mach
callbacks.
c. Do its usecase.
d. Disable hwmod through runtime PM.
e. Assert the reset line.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch
On 22 August 2012 00:42, Omar Ramirez Luna omar.l...@linaro.org wrote:
From: Omar Ramirez Luna omar.rami...@ti.com
The patch to expose hwmod assert/deassert functions through omap_device
has been accepted and queued for 3.7[1], however these two patches are
needed to make the API functional
Hi Benoit,
On 6 September 2012 10:12, Benoit Cousson b-cous...@ti.com wrote:
The sequence is good, I'm just a little bit concern about the
duplication of code compared to _enable sequence.
That being said, this is the consequence of removing the hardreset
sequence outside of the main
-archive.com/linux-omap@vger.kernel.org/msg60133.html
Omar Ramirez Luna (9):
ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
ARM: OMAP3: hwmod data: add mmu data for iva and isp
ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
ARM: OMAP3/4: iommu: migrate to hwmod
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
.../devicetree/bindings/arm/omap/iommu.txt | 10 +++
arch/arm/mach-omap2/omap-iommu.c |4 ++
drivers/iommu/omap-iommu.c | 65
Add nodes for iommu DT, to interface with hwmods.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 12 +++-
arch/arm/boot/dts
to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l
device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c
includes iommu.h to get the
structure for attributes. Also needed for tidspbridge
incremental migration to use iommu code.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/include/plat/iommu.h |2 ++
1 file changed, 2 insertions
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c
Add mmu hwmod data for ipu and dsp.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++-
1 file changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2
be migrated
to iommu framework.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 121
arch/arm/plat-omap/include/plat/iommu.h| 13 +++
2 files changed, 134 insertions
should be a single patch, to avoid compilation
issues.
I'll appreciate any comments or suggestions.
Omar Ramirez Luna (7):
OMAP2+: hwmod_data: define number of mailboxes
OMAP2+: devices: get the number of supported mailboxes
OMAP: mailbox: use OMAP's naming convention for devices
OMAP
Define number of mailboxes available to a specific chip.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++
arch/arm
Use hwmod data attributes to get the defined number of mailboxes on
our current chip, and pass it through platform data.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/devices.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm
Use omap_XXX as the OMAP device naming convention.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/mailbox.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Move API functions to common framework like save/restore_ctx,
enable/disable_irq instead of being under a header file. While
at it dropping their static inline declarations.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 35
of the mailbox id needed, also a
request_byname is provided to cover the cases where there are multiple irqs
tied to a single mailbox block (i.e. OMAP2420).
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 19 ++-
arch/arm/plat-omap/mailbox.c
Remove mailbox static declarations, while at it, simplify the macros
to be reused in a cleaner way.
New approach configures available mailboxes per request.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap1/mailbox.c | 92 -
1
Remove mailbox static declarations which limit the driver to
either work with 1 or 2 predefined mailboxes, even if there are
more mailboxes in hardware.
New approach configures available mailboxes per request.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2
: mailbox: add device tree support, there wasn't an
opposition other than to cleanup the driver too, however I got
quite some patches to send before continuing the cleanup.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html
Omar Ramirez Luna (2):
OMAP: mailbox: add device tree
: mailbox: add device tree support, there wasn't an
opposition other than to cleanup the driver too, however I got
quite some patches to send before continuing the cleanup.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html
Omar Ramirez Luna (2):
OMAP: mailbox: add device tree
Add nodes for mailbox DT, to interface with hwmods.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
3 files changed
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
.../devicetree/bindings/arm/omap/mailbox.txt |9 +
arch/arm/mach-omap2/devices.c |3 +++
arch/arm/mach-omap2/mailbox.c | 12
Hi Tony,
On 18 September 2012 13:04, Tony Lindgren t...@atomide.com wrote:
* Omar Ramirez Luna omar.l...@linaro.org [120912 12:47]:
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -27,6 +27,13 @@ struct iotlb_entry {
};
};
+/* context
Hi,
On Mon, Sep 24, 2012 at 11:37 AM, Selso LIBERADO s...@cioinfoindus.fr wrote:
...
CC [M] drivers/staging/tidspbridge/core/tiomap3430.o
drivers/staging/tidspbridge/core/tiomap3430.c: In function
'bridge_brd_start':
drivers/staging/tidspbridge/core/tiomap3430.c:421:25: error:
Hi,
On Tue, Sep 25, 2012 at 12:39 PM, Selso LIBERADO s...@cioinfoindus.fr wrote:
Hi !
Here what's happening when applying the patch :
sli@SLI-V420:~/developpement/INTERNE/BEAGLEBOARD/logiciel/linux-omap$ git
apply
--check
Hi Benoit,
On 12 September 2012 19:08, Omar Ramirez Luna omar.l...@linaro.org wrote:
To allow mailbox driver to function with device tree.
Tested in OMAP4 and OMAP3. OMAP2 untested.
Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit
however it seems it wasn't picked up, so
Hi Matt,
On 2 October 2012 16:25, Matt Porter mpor...@ti.com wrote:
...
I can see why you went this path with the iommu driver as it already had
some integration code present here. I have some concerns going forward
about how this should be long-term. Take any platform booting only with
DT
is idled first, the other one will cause L3
aborts given that the module is already disabled. So, if ipu is idled
and disabled first, then all tear down operations on iommu will cause
L3 aborts.
I created the following:
From: Omar Ramirez Luna omar.l...@linaro.org
Subject: [PATCH] ARM: OMAP: hwmod: allow
://www.mail-archive.com/linux-omap@vger.kernel.org/msg75701.html
[v1]
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70447.html
[old iteration without reset, save/restore and device tree]
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60133.html
Omar Ramirez Luna (6):
ARM
device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c
device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c
to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
.../devicetree/bindings/arm/omap/iommu.txt | 10 +++
arch/arm/mach-omap2/omap-iommu.c |4 ++
drivers/iommu/omap-iommu.c | 65
to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach
Add nodes for iommu DT, to interface with hwmods.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 12 +++-
arch/arm/boot/dts
On 12 October 2012 02:48, Felipe Contreras felipe.contre...@gmail.com wrote:
I already made most of these comments, but here they go again.
I replied to all, but here it goes again:
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
-
Hi Felipe,
On 12 October 2012 16:25, Felipe Contreras felipe.contre...@gmail.com wrote:
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err =
On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote:
On probe this patch does pm_runtime_enable, however this doesn't mean
the device is turned ON or resumed or kept ON all the time.
In fact it's the other way around; pm_runtime_enable turns off the
power (if it's ON).
On 16 October 2012 12:22, Tony Lindgren t...@atomide.com wrote:
* Omar Ramirez Luna omar.l...@linaro.org [121011 18:07]:
These patches are needed for remoteproc to work on OMAP4.
Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
Tony,
On 18 October 2012 18:52, Tony Lindgren t...@atomide.com wrote:
Thanks, the related patches are now posted in thread
[PATCH v3 0/6] omap iommu changes to remove plat includes.
Ok.
Also, can you please take a look at the Updated status of the removal
of plat headers thread?
I've
Hi,
On 16 October 2012 18:00, Tony Lindgren t...@atomide.com wrote:
Hi all,
Here's a quick status update on the removal of remaining
#include plat/*.h files. Most files are now fixed up, and
we only have the following remaining:
cpu.h wrapper only left, will be removed as soon as
Hi,
On Wed, Oct 24, 2012 at 10:34 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi,
Selso, hopefully you don't mind, but I'll forward this to the
linux-omap mailing list, as this seems to be an interesting kernel
problem in tidspbridge.
Omar, any ideas?
I don't see tidspbridge
Actually moving it from plat-omap code as this is supposed to be
under drivers/ folder. This framework should work with the current
OMAP processors that have mailbox and can be used as a method of
interprocessor communication.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: de...@driverdev.osuosl.org
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/mailbox.c |2 +-
arch/arm/plat-omap/include/plat/mailbox.h | 105
arch/arm/plat
From: Omar Ramirez Luna omar.rami...@copitl.com
Move Mailbox's headers and driver out of platform code as
per current plat-omap cleanup activities.
While at it move mailbox code out of platform and to drivers/
folder, given that this is an OMAP specific framework, some people
might frown upon
Hi,
On 26 October 2012 13:00, Tony Lindgren t...@atomide.com wrote:
...
I would also like to move the tidspbridge to the DMA API, but I think we'll
need to move step by step there, and using the OMAP IOMMU and IOVMM APIs
as an
intermediate step would allow splitting patches in reviewable
Tony,
On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote:
--- /dev/null
+++ b/include/linux/platform_data/omap_mailbox.h
@@ -0,0 +1,105 @@
This file should only contain pure platform data needed
by the core omap code to pass to the mailbox driver.
Ok, looking at it closely,
Hi Greg,
On 30 October 2012 16:02, Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
OK.
Greg, do these patches look OK to you to move to live under
drivers/mailbox?
Um, I don't know, I wasn't paying attention here, sorry.
As part of plat-omap code cleanup, I was planning to move
/mailbox and split
internal structures from common API for others to use.
Based on 3.7-rc4.
1. https://lkml.org/lkml/2012/10/31/123
Omar Ramirez Luna (2):
mailbox: OMAP: introduce mailbox framework
mailbox: split internal header from API header
arch/arm/configs/omap1_defconfig |3
Now internal structures can remain hidden to the user and just API
related functions and defines are made available.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/mailbox/mailbox.c | 34
drivers/mailbox/mailbox.h | 48
://www.mail-archive.com/devel@linuxdriverproject.org/msg18762.html
Omar Ramirez Luna (3):
OMAP2+: control: new APIs to configure boot address and mode
OMAP: dsp: interface to control module functions
staging: tidspbridge: use scm functions to set boot address and mode
arch/arm/mach-omap2
BOOTADDR to start running the code at that
location. BOOTMOD register specifies a different set of
modes for the processor to execute when booting (from direct,
idle, self-loop, user and default).
Since there was no offset associated with OMAP4, this patch
defines it.
Signed-off-by: Omar Ramirez
Provide an interface for a driver to call SCM functions to
set a boot address and boot mode.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/dsp.c |4
arch/arm/plat-omap/include/plat/dsp.h |3 +++
2 files changed, 7 insertions(+), 0
Instead of ioremapping SCM registers, use the correspondent layer
to write into them.
This allows us to get rid of a layer violation, since the registers
are no longer touched by driver code.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/staging/tidspbridge/core/tiomap3430.c
Hi Vaibhav,
Somehow I missed this mail.
On 2 May 2012 00:42, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Omar,
On Tue, May 01, 2012 at 23:17:38, Omar Ramirez Luna wrote:
To allow mailbox driver to function with device tree.
Tested in OMAP4 and OMAP3. OMAP2 untested.
I think
On 2 May 2012 21:11, Omar Ramirez Luna omar.l...@linaro.org wrote:
Recently a patch went in for tidspbridge code, to ioremap
SCM registers and solve a build break[1]. However it has
been pointed out before that this is a layer violation
given that control module should handle its own registers
Hi Tony, Benoit,
On 1 May 2012 12:47, Omar Ramirez Luna omar.l...@linaro.org wrote:
To allow mailbox driver to function with device tree.
Tested in OMAP4 and OMAP3. OMAP2 untested.
Omar Ramirez Luna (2):
OMAP: mailbox: add device tree support
arm/dts: OMAP2+: Add mailbox nodes
Hi,
On 24 May 2012 10:44, Cousson, Benoit b-cous...@ti.com wrote:
On 5/2/2012 7:42 AM, Bedia, Vaibhav wrote:
Hi Omar,
On Tue, May 01, 2012 at 23:17:38, Omar Ramirez Luna wrote:
To allow mailbox driver to function with device tree.
Tested in OMAP4 and OMAP3. OMAP2 untested.
I think
sequence.
These APIs are intended to be used by iommu for now, but were
tested with IPU and remoteproc on Pandaboard.
Omar Ramirez Luna (3):
ARM: OMAP: hwmod: partially un-reset hwmods might not be properly
enabled
ARM: OMAP: hwmod: revise deassert sequence
ARM: OMAP: omap_device
by hwmod code.
While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 files changed, 22 insertions(+), 15
-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5f0811a..8a7e5bc 100644
--- a/arch
This APIs are meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data
to control their reset lines, they are expected to know the name
of the reset line they are trying to control.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
501 - 600 of 688 matches
Mail list logo
