Hi,
On Thu, Feb 28, 2013 at 11:51 AM, Pali Rohár wrote:
> Fix includes and use clk_prepare_enable/clk_disable_unprepare
>
> Signed-off-by: Pali Rohár
> Signed-off-by: Joni Lapilainen
> ---
> drivers/staging/tidspbridge/core/dsp-clock.c | 16
> drivers/staging/tidspbridge/co
On Wed, Jan 9, 2013 at 6:29 AM, Loic PALLARDY wrote:
> Hi Vaibhav,
>
> On 01/09/2013 01:11 PM, Bedia, Vaibhav wrote:
>> Hi Loic,
>>
>> On Fri, Dec 21, 2012 at 16:23:24, Loic PALLARDY wrote:
>>>
>>>
>>> On 12/21/2012 11:49 AM, Bedia, Vaibhav wrote:
On Fri, Dec 21, 2012 at 14:24:26, Loic PALLAR
On Thu, Jan 10, 2013 at 4:07 AM, Omar Ramirez Luna
wrote:
> Hi,
>
> On Mon, Dec 31, 2012 at 4:03 AM, Peter Ujfalusi wrote:
>> On 12/24/2012 03:19 PM, Chuansheng Liu wrote:
>>> This patch fix the below build error:
>>> drivers/built-in.o: In function `twl_probe&
Hi,
On Mon, Dec 31, 2012 at 4:03 AM, Peter Ujfalusi wrote:
> On 12/24/2012 03:19 PM, Chuansheng Liu wrote:
>> This patch fix the below build error:
>> drivers/built-in.o: In function `twl_probe':
>> drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c'
>> make: *** [vmlinux]
Hi,
On Thu, Dec 13, 2012 at 9:50 PM, Chen Gang wrote:
> in drivers/staging/tidspbridge/rmgr/proc.c:
>
> if strlen(drv_datap->base_img) == size, will pass checking (line 397)
> the size is the full length of exec_file (line 382, line 468..469)
> strcpy causes issue: src len is strlen
Hi,
On Sun, Dec 30, 2012 at 9:28 PM, Chen Gang wrote:
> is it suitable to send a patch for it, by me ?
Thanks for your suggestions, I have created the patches and will
submit them soon, but feel free to submit patches for any other
suggestions in future.
Cheers,
Omar
--
To unsubscribe from t
On Tue, Dec 25, 2012 at 7:56 PM, Chen Gang wrote:
> 于 2012年12月24日 22:26, Omar Ramirez Luna 写道:
>>> b: version merging issue:
>>> > in drivers/staging/tidspbridge/core/_tiomap.h
>>> > need use "#include " instead
Hi Gchen,
On Mon, Dec 17, 2012 at 8:40 PM, Chen Gang wrote:
> Hello Omar Ramirez Luna:
>
> excuse me to bother you (maybe you are busy in these days).
> please help checking this suggestion when you have free time.
Yes, I'm checking your suggestions, I was a little busy l
Hi,
On Thu, Dec 13, 2012 at 7:30 PM, Chen Gang wrote:
> also another suggestions:
> I built ti otmap with ti dsp bridge by arm cross-compiler under i386
> platform.
> the version tag is next-20121213
> I met 2 compiling issues.
>
> a: module dependency:
> Multifunctio
; [-Werror=implicit-function-declaration]
Reported-by: Chen Gang
Signed-off-by: Omar Ramirez Luna
---
drivers/mfd/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1c0abd4..47ad4e2 100644
--- a/drivers/mfd/Kconfig
++
Hi Loic/Ohad,
On Fri, Dec 21, 2012 at 2:52 AM, Loic PALLARDY wrote:
>
>
> On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote:
>> On Thu, Dec 20, 2012 at 9:19 PM, Olof Johansson wrote:
>>> While we can make the branch stable, would it make sense to make
>>> remoteproc for omap depend on !multiplatform
Hi Chen,
Thanks for your report.
On Wed, Dec 12, 2012 at 4:12 AM, Chen Gang wrote:
> excuse me, I have to forward this mail to you.
> I have sent it to Omar Ramirez Luna , but failed.
>(get mail delivery failed )
Please contact me with my new address (this one).
I'll
Hi Paul,
On Thu, Dec 6, 2012 at 6:59 PM, Paul Walmsley wrote:
> Hi Omar,
>
> On Thu, 6 Dec 2012, Omar Ramirez Luna wrote:
>
>> I have checked next-20121206, it's OK to delete that file as the patch
>> from Paul is doing that for common clock framework migration; now
Hi All,
On Tue, Dec 4, 2012 at 5:10 AM, Ohad Ben-Cohen wrote:
> On Tue, Dec 4, 2012 at 1:06 PM, Joerg Roedel wrote:
>> On Tue, Dec 04, 2012 at 03:42:03PM +1100, Stephen Rothwell wrote:
>>> Today's linux-next merge of the arm-soc tree got a conflict in
>>> arch/arm/mach-omap2/clock44xx_data.c bet
/mach-omap2.
Omar Ramirez Luna (5):
iommu/omap: remove redundant clock handling on ISR
iommu/omap: keep mmu enabled when requested
iommu/omap: migrate to hwmod framework
iommu/omap: adapt to runtime pm
ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of
leaf clocks
doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.
Signed-off-by: Omar Ramirez Luna
---
drivers/iommu/omap-iommu.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/omap-iomm
through debugfs, some of
them doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap-iommu.c |1 -
drivers/iommu/omap-iommu.c |
is
to get rid of leaf clocks in future. So remove these two while at it.
[1] http://lkml.org/lkml/2012/8/20/226
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/clock44xx_data.c | 22 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
2 files changed
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
---
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/omap-iommu.c | 168
context the handling of
clocks inside the ISR doesn't seem to be needed nor helping.
Next patch should also correct the dependency on clients to handle
iommu clocks.
Signed-off-by: Omar Ramirez Luna
---
drivers/iommu/omap-iommu.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
On 15 November 2012 11:39, Ohad Ben-Cohen wrote:
>> I do agree description is missing, again I thought I had done this
>> somewhere but looks like I didn't, will update these. If you think
>> these should be different patches please let me know, otherwise I
>> would like to keep a single *document
Hi Ohad,
On 14 November 2012 03:54, Ohad Ben-Cohen wrote:
> Hi Omar,
>
> On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna
> wrote:
>> Use runtime PM functionality interfaced with hwmod enable/idle
>> functions, to replace direct clock operations and sysconfig
>>
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
---
arch/arm
/gmane.linux.kernel/1387788
Minor rebasing might be needed if these are included on top of
linux-omap, since they are affected by changes on headers being
moved to include/linux/platform_data and arch/arm/mach-omap2.
Omar Ramirez Luna (2):
ARM: OMAP3/4: iommu: migrate to hwmod framework
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
---
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/omap-iommu.c | 168
Hi,
On 11 November 2012 03:39, Ohad Ben-Cohen wrote:
> On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren wrote:
>> We need to move the iommu code to live under drivers
>> for arm common zImage support.
>
> For the iommu changes in the entire series:
>
> Acked-by: Ohad Ben-Cohen
>
> Joerg, it might
Hi Loic,
On 6 November 2012 06:53, Loic PALLARDY wrote:
>
>
> On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
>> Now internal structures can remain hidden to the user and just API
>> related functions and defines are made available.
>>
>> Signed-off-by: Omar
Hi Greg,
On 6 November 2012 02:59, Greg Kroah-Hartman wrote:
> On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote:
>> On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren wrote:
>>
>> > Is this a public interface to the driver? If so, shouldn't the header be
>> > in include/linux somewhere?
Hi Stephen,
On 5 November 2012 21:40, Stephen Warren wrote:
> On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote:
>> Actually moving it from plat-omap, as this framework/driver code is
>> supposed to be under drivers/ folder. The framework should work with
>> the current supp
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
---
drivers/mailbox/mailbox.c | 34
drivers/mailbox/mailbox.h | 48
ivers/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 |
Hi Greg,
On 30 October 2012 16:02, Greg Kroah-Hartman 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 omap-mailbox
framework
Tony,
On 29 October 2012 12:52, Tony Lindgren 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, this header
CC: Greg Kroah-Hartman
CC: de...@driverdev.osuosl.org
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/mailbox.c |2 +-
arch/arm/plat-omap/include/plat/mailbox.h | 105
arch/arm/plat-omap/mailbox.c |2
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
---
arch/arm/plat-omap/Kconfig
From: Omar Ramirez Luna
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 this, however it s
Hi,
On Wed, Oct 24, 2012 at 5:28 PM, Greg Kroah-Hartman
wrote:
> On Wed, Oct 24, 2012 at 05:09:14PM -0500, Omar Ramirez Luna wrote:
>> With 3.7-rc1 changes:
>>
>> - New irq numbering in OMAP3 broke the driver request for a mmu irq,
>> until this is migrated to the co
el' makes pointer from integer
without a cast
../io.h:88: note: expected 'volatile void *' but argument is of type 'u32'
Signed-off-by: Omar Ramirez Luna
---
Intended for 3.7 due to code changes during rc1.
drivers/staging/tidspbridge/core/tiomap3430.c | 37
es pointer from integer
without a cast
../io.h:88: note: expected 'volatile void *' but argument is of type 'u32'
Signed-off-by: Omar Ramirez Luna
---
Intended for 3.7 due to code changes during rc1.
.../tidspbridge/include/dspbridge/cfgdefs.h|4 ++--
drivers/
avoid writeback addressing modes for
__raw_ accessors", so the build system was filled with warnings from
the old parameter usage.
Omar Ramirez Luna (6):
staging: tidspbridge: request the right irq for mmu
staging: tidspbridge: drop const from custom mmu implementation
staging: tidspbrid
Due to data type change, readl can no longer receive a u32.
Signed-off-by: Omar Ramirez Luna
---
Intended for 3.7 due to code changes during rc1.
drivers/staging/tidspbridge/rmgr/node.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers
volatile void *' but argument is of type 'const
void *'
Signed-off-by: Omar Ramirez Luna
---
Intended for 3.7 due to code changes during rc1.
drivers/staging/tidspbridge/hw/hw_mmu.c | 40 +++
drivers/staging/tidspbridge/hw/hw_mmu.h | 28 +++
From: Omar Ramirez Luna
This should get rid of warnings of the type:
warning: passing argument 1 of '' discards qualifiers from pointer target type
note: expected 'void *' but argument is of type 'const void *'
Signed-off-by: Omar Ramirez Luna
---
Intended for
Ramirez Luna
---
Intended for 3.7 due to code changes during rc1.
.../tidspbridge/include/dspbridge/host_os.h|4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
b/drivers/staging/tidspbridge/include/dspbridge
Hi Matt,
On 2 October 2012 16:25, Matt Porter 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 populated, we
Hi Benoit,
On 12 September 2012 19:08, Omar Ramirez Luna 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
Hi,
On Mon, Sep 24, 2012 at 1:54 PM, selso wrote:
> From: sli
>
>
> Signed-off-by: sli
> ---
> drivers/staging/tidspbridge/core/dsp-clock.c |3 ++
> drivers/staging/tidspbridge/core/tiomap3430.c |4 ++
> drivers/staging/tidspbridge/core/wdt.c |2 +-
> .../tid
Hi Tony,
On 18 September 2012 13:04, Tony Lindgren wrote:
> * Omar Ramirez Luna [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 {
>> };
>>
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna
---
.../devicetree/bindings/arm/omap/mailbox.txt |9 +
arch/arm/mach-omap2/devices.c |3 +++
arch/arm/mach-omap2/mailbox.c | 12
3 files changed
OMAP: 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 d
Add nodes for mailbox DT, to interface with hwmods.
Signed-off-by: Omar Ramirez Luna
Acked-by: Benoit Cousson
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
3 files changed, 15 insertions(+)
diff --git a
OMAP: 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 d
be migrated
to iommu framework.
Cc: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 121
arch/arm/plat-omap/include/plat/iommu.h| 13 +++
2 files changed, 134 insertions(+)
diff --git a/arch/arm/mach-omap2
Add mmu hwmod data for ipu and dsp.
Cc: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++-
1 file changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm
-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
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
---
drivers/iommu/omap-iommu.c |
ds 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
---
arch/arm/mach-omap
Add nodes for iommu DT, to interface with hwmods.
Cc: Grant Likely
Cc: Rob Herring
Cc: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
---
arch/arm/boot/dts/omap3.dtsi | 12 +++-
arch/arm/boot/dts/omap4.dtsi | 17 -
2 files changed, 27 insertions(+), 2 deletions
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna
---
.../devicetree/bindings/arm/omap/iommu.txt | 10 +++
arch/arm/mach-omap2/omap-iommu.c |4 ++
drivers/iommu/omap-iommu.c | 65 +++-
3 files changed
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
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c| 19
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
---
arch/arm
This will be seen when hwmod includes iommu.h to get the
structure for attributes. Also needed for tidspbridge
incremental migration to use iommu code.
Cc: Tony Lindgren
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/plat/iommu.h |2 ++
1 file changed, 2 insertions(+)
d
Hi Benoit,
On 6 September 2012 10:12, Benoit Cousson 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 _enable/_shutdown s
On 22 August 2012 00:42, Omar Ramirez Luna wrote:
> From: Omar Ramirez Luna
>
> 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 v
fault callbacks.
c. Do its usecase.
d. Disable hwmod through runtime PM.
e. Assert the reset line.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-
m.
Signed-off-by: Omar Ramirez Luna
---
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-omap2/omap_hwm
From: Omar Ramirez Luna
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:
- ARM: OMAP: hwmod
On 20 August 2012 09:49, Benoit Cousson 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.
>>
&
Hi Benoit,
On 20 August 2012 05:21, Benoit Cousson wrote:
> Hi Omar,
>
> On 08/03/2012 05:52 PM, Omar Ramirez Luna wrote:
>> On 3 August 2012 00:24, Vaibhav Hiremath wrote:
>>> On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote:
>>>> So in _enable:
Hi Benoit,
On 20 August 2012 09:49, Benoit Cousson 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
On 3 August 2012 00:24, Vaibhav Hiremath 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
Hi.
On 2 August 2012 02:52, Paul Walmsley 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 fail
ey are trying to control.
>>
>> Signed-off-by: Omar Ramirez Luna
>
> 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:
m.
Signed-off-by: Omar Ramirez Luna
---
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/arm/
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
---
arch/arm/plat-omap
ed 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
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 files changed, 22 insertions(+), 15 deletions(-)
diff --
76 matches
Mail list logo
