Hi,
On 24 May 2012 10:44, Cousson, Benoit 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.
>
Hi Tony, Benoit,
On 1 May 2012 12:47, Omar Ramirez Luna 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 node
On 2 May 2012 21:11, Omar Ramirez Luna 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, t
Hi Vaibhav,
Somehow I missed this mail.
On 2 May 2012 00:42, 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.
>
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
---
arch/arm/mach-omap2/dsp.c |4
arch/arm/plat-omap/include/plat/dsp.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a
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 | 32
://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
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
.../devicetree/bindings/arm/omap/mailbox.txt |9 +
arch/arm/boot/dts/omap2
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
---
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(+), 0 deletions(-)
diff --git a/arch/arm/boot
Hi Joerg,
On 12 April 2012 05:25, Joerg Roedel wrote:
> Doesn't apply against 3.4-rc2. Please rebase and send a new version.
I rebased the patch and sent v2.
Thanks,
Omar
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.or
o track devices using the iommu, current
use cases only have one user of iommu per instance. When required
this can evolve to a list with the devices using the iommu_dev.
Reported-by: Joerg Roedel
Reviewed-by: Ohad Ben-Cohen
Signed-off-by: Omar Ramirez Luna
---
v2: rebased onto v3.4-rc2
dri
On 10 April 2012 19:29, Deepak Saxena wrote:
>> Last week we tried v3.3 mainline and it dies in some problem about UART.
>
> Have you tried 3.4-rc kernels?
I tried 3.4-rc1 and failed with nfs and mmc, it does work with cramfs
which I didn't try until now, according to Benoit Cousson there is a
fi
On 10 April 2012 19:01, Andy Green wrote:
> Omar, you should look here
>
> http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=summary
>
> use tilt-tracking and omap_5430evm_defconfig
>
> That's workable on 4430, 4460 (and Omap5) with DT boot. We have a race
> bug about mmc probe
o track devices using the iommu, current
use cases only have one user of iommu per instance. When required
this can evolve to a list with the devices using the iommu_dev.
Reported-by: Joerg Roedel
Reviewed-by: Ohad Ben-Cohen
Signed-off-by: Omar Ramirez Luna
---
drivers/iommu/omap
o track devices using the iommu, current
use cases only have one user of iommu per instance. When required
this can evolve to a list with the devices using the iommu_dev.
Reported-by: Joerg Roedel
Reviewed-by: Ohad Ben-Cohen
Signed-off-by: Omar Ramirez Luna
---
drivers/iommu/omap
17 matches
Mail list logo
