On Sun, Jan 20, 2013 at 5:51 PM, Greg Kroah-Hartman
wrote:
> That looks good, care to update the TODO file for the driver in the
> kernel to reflect this?
I'll update it.
Cheers,
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@
Hi Tony,
On Thu, Jan 17, 2013 at 8:01 PM, Tony Lindgren wrote:
> * Greg Kroah-Hartman [130117 16:51]:
>> On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote:
>> > Patches for staging-next, fixing comments and suggestions provided
>> > by Chen Gang.
>&
Hi Greg,
On Thu, Jan 17, 2013 at 6:47 PM, Greg Kroah-Hartman
wrote:
> On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote:
>> Patches for staging-next, fixing comments and suggestions provided
>> by Chen Gang.
>>
>> There is an additional scm patch, tha
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
There is no way to specify the value of iva_img and since this code
is not being used, remove it.
This analysis resulted from a report by
Chen Gang , mentioning that the existing code
was wrongly specifying the size to be copied.
Signed-off-by: Omar Ramirez Luna
---
.../staging/tidspbridge
On both counts, sym_name could be printed uninitialized, this
is solved by moving the pr_* statement to be triggered if the
value is assigned.
Reported-by: Chen Gang
Signed-off-by: Omar Ramirez Luna
---
drivers/staging/tidspbridge/rmgr/nldr.c |6 --
drivers/staging/tidspbridge/rmgr
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
---
drivers/staging/tidspbridge/core/tiomap3430.c | 34
The value allocated doesn't match the one that is meant to be
stored, resulting in corruption of memory for longer strings
that can't be held in such space.
Fix by allocating the correct byte value for the string meant to
be stored.
Signed-off-by: Omar Ramirez Luna
---
drive
on this cases, because the driver expects the NULL
ending to be among the 255 char limit.
Reported-by: Chen Gang
Signed-off-by: Omar Ramirez Luna
---
drivers/staging/tidspbridge/rmgr/proc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tidspbridge/r
Patches for staging-next, fixing comments and suggestions provided
by Chen Gang.
There is an additional scm patch, that removes hardcoded defines
related to direct register handling for SCM, it was dependent on
changes that already made it to mainline.
Omar Ramirez Luna (5):
staging
On Mon, Jan 7, 2013 at 5:03 PM, Greg Kroah-Hartman
wrote:
> On Mon, Dec 24, 2012 at 08:10:24AM -0600, Omar Ramirez Luna wrote:
>> 3.8-rc1 introduced changes in the clock management header files,
>> this resulted in compilation breakages for this driver.
>>
>> Define
50:13: error:
'OMAP3430_CM_AUTOIDLE_PLL' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap_io.c:416:13: error:
'OMAP3430_CM_CLKEN_PLL' undeclared (first use in this function)
Reported-by: Chen Gang
Signed-off-by: Omar Ramirez Luna
---
drivers
correct
order while handling clocks.
Code path to enable/disable dsp clocks can still be reached from an
atomic context, hence we can't use clk_prepare_enable and
clk_disable_unprepare yet.
Signed-off-by: Omar Ramirez Luna
---
drivers/staging/tidspbridge/core/dsp-clock.c |
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
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(-)
/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
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
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
? It does not appear that this
> file needs to include dmtimer.h.
Indeed, we don't use it here.
> Is it ok for this to go through Tony's tree? If so, care to ACK?
Looks fine to me, but I believe you will want to let Greg know if this
patch will bypass staging tree.
Acked-by: Omar R
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
>>
Hi,
On 14 November 2012 09:44, Paul Walmsley wrote:
> Hi
>
> On Tue, 13 Nov 2012, Omar Ramirez Luna wrote:
>
>> This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
>> from enabling modulemode inside CLKCTRL using its clk->enable_reg
>> field. Instea
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
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
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
/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
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
Hi,
On 26 October 2012 13:00, Tony Lindgren 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 chun
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
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
Hi,
On Wed, Oct 24, 2012 at 10:34 AM, Felipe Contreras
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 trace paths (but I don
Hi,
On 16 October 2012 18:00, Tony Lindgren wrote:
> Hi all,
>
> Here's a quick status update on the removal of remaining
> #include 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 drivers are
> fi
Tony,
On 18 October 2012 18:52, Tony Lindgren 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 tagged you
On 16 October 2012 12:22, Tony Lindgren wrote:
> * Omar Ramirez Luna [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
On 15 October 2012 22:23, Felipe Contreras 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).
pm_runtime_enable
Hi Felipe,
On 12 October 2012 16:25, Felipe Contreras wrote:
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj->clk);
+ pm_runtime_get_sync(obj->dev);
err = arch_iommu->ena
On 12 October 2012 02:48, Felipe Contreras 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)
>> }
>> }
>>
>> - clk_enable(obj->cl
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
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
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
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
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 |
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 |
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
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
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
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
://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
is consistent.
I think that on _omap4_disable_module() we want to check if the module
is deasserted rather than if it is asserted.
E.g.: If you have 2 hwmods for the same module (ipu with reset "cpu0"
and mmu_ipu with reset "mmu") controlled by different drivers,
depending on
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 Tue, Sep 25, 2012 at 12:39 PM, Selso LIBERADO wrote:
> Hi !
>
> Here what's happening when applying the patch :
>
> sli@SLI-V420:~/developpement/INTERNE/BEAGLEBOARD/logiciel/linux-omap$ git
> apply
> --check
> ../../archive/10-17-staging-tidspbridge-Prepare-for-irqs.h-removal.patch
> err
Hi,
On Mon, Sep 24, 2012 at 11:37 AM, Selso LIBERADO 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:
>> 'OMAP343X_CTRL_BASE'
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
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
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
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 |
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
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
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
-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
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:
On 17 July 2012 05:51, Ohad Ben-Cohen wrote:
> + Paul
>
> On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel 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 wit
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
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/
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 --
On 12 July 2012 00:27, Rajendra Nayak 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
Hi Kevin,
On 11 July 2012 16:42, Kevin Hilman wrote:
> Omar Ramirez Luna writes:
>
>> On 12 June 2012 07:01, Rajendra Nayak wrote:
>
> [...]
>
>>> ..anyone knows of any more fixes going around?
>>
>> I'm seeing the same thing, it gets stuck trying
On 12 June 2012 07:01, Rajendra Nayak 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:
>
>>>
On 11 July 2012 12:07, Kevin Hilman 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] omap
Hi Paul,
On 27 June 2012 20:27, Omar Ramirez Luna wrote:
> On 19 June 2012 12:48, Cousson, Benoit wrote:
>> On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
>>>
>>> Hi Benoit,
>>>
>>> On 19 June 2012 07:36, Cousson, Benoit wrote:
>>&g
+ Paul
On 19 June 2012 12:48, Cousson, Benoit wrote:
> On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
>>
>> Hi Benoit,
>>
>> On 19 June 2012 07:36, Cousson, Benoit wrote:
>>>
>>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
>>
>> ...
&
Hi Paul,
On 15 June 2012 20:54, Omar Ramirez Luna wrote:
> Recent changes in omap_hwmod framework have reworked the behaviour
> towards hardreset handling, commit 747834a (ARM: OMAP2+: hwmod:
> revise hardreset behavior) recommends for drivers to implement
> their own reset sequence
1 - 100 of 730 matches
Mail list logo
