On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang wrote:
> Seems the unmap function don't take phys as parameter, does this mean
> domain->ops->unmap will walk through the page table to find out the
> actual page size?
The short answer is yes, and furthermore, we also consider to remove
the size param f
Hi,
On Wednesday 09 November 2011 11:56 PM, Ilya Yanok wrote:
Hi Archit,
09.11.2011 14:10, Archit Taneja wrote:
AM35xx don't have VDDS_DSI regulator.
AM35xx do have vdds_dsi regulator. Are you saying that your particular
board doesn't have vdds_dsi connected to a regulator?
Yes, you are ri
>
> -int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int
> gfp_order)
> +size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t
> size)
> {
> - size_t size, unmapped;
> + size_t unmapped_page, unmapped = 0;
> + unsigned int min_pagesz;
>
>
Hi,
On 10.11.2011, at 2.04, Tony Lindgren wrote:
* Aaro Koskinen [09 15:25]:
On 10.11.2011, at 1.39, Russell King - ARM Linux wrote:
On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote:
Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use
generic
map_io, init_early
* Aaro Koskinen [09 15:25]:
> Hi,
>
> On 10.11.2011, at 1.39, Russell King - ARM Linux wrote:
> >On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote:
> >>Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use
> >>generic
> >>map_io, init_early and init_irq) changed omap1 t
Hi,
On 10.11.2011, at 1.39, Russell King - ARM Linux wrote:
On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote:
Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use
generic
map_io, init_early and init_irq) changed omap1 to use generic map_io.
Looks like I missed one bo
On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote:
> Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use generic
> map_io, init_early and init_irq) changed omap1 to use generic map_io.
>
> Looks like I missed one board though. Fix this by adding a custom
> map_io for Amstr
Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use generic
map_io, init_early and init_irq) changed omap1 to use generic map_io.
Looks like I missed one board though. Fix this by adding a custom
map_io for Amstrad E3.
Reported-by: Aaro Koskinen
Signed-off-by: Tony Lindgren
---
Un
* Aaro Koskinen [09 14:19]:
> Hi,
>
> Has anyone managed to boot 3.2-rc1 on OMAP1?
>
> On Amstrad E3 it seems to hang at very early on the boot (below
> output is
> with earlyprintk enabled):
>
> Uncompressing Linux... done, booting the kernel.
> [0.00] Initializing cgroup subsys cp
Hi,
Has anyone managed to boot 3.2-rc1 on OMAP1?
On Amstrad E3 it seems to hang at very early on the boot (below
output is
with earlyprintk enabled):
Uncompressing Linux... done, booting the kernel.
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-rc1-e3 (aaro
* Tony Lindgren [07 16:11]:
> * Russell King - ARM Linux [06 05:18]:
> > Here's a list of my peaves about current platform code - which are
> > causing me great issue when trying to clean up the arch_reset() stuff:
> >
> > 1. Lack of trailing ',' on structure initializers
> >This mak
Hi Archit,
09.11.2011 14:10, Archit Taneja wrote:
AM35xx don't have VDDS_DSI regulator.
AM35xx do have vdds_dsi regulator. Are you saying that your particular
board doesn't have vdds_dsi connected to a regulator?
Yes, you are right. But looking at the manual (and name) I think it's
needed o
Fix the following compilation failure with v3.2-rc1 by including module.h:
CC drivers/input/serio/ams_delta_serio.o
drivers/input/serio/ams_delta_serio.c:33:15: error: expected declaration
specifiers or '...' before string constant
drivers/input/serio/ams_delta_serio.c:34:20: error: expect
On Wed, Nov 09, 2011 at 08:06:45PM +0200, Aaro Koskinen wrote:
> Fix the following compilation failure with v3.2-rc1 by including module.h:
>
> CC drivers/input/serio/ams_delta_serio.o
> drivers/input/serio/ams_delta_serio.c:33:15: error: expected declaration
> specifiers or '...' before s
Hi Deepthi,
>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
> From: Deepthi Dharwar [mailto:deep...@linux.vnet.ibm.com]
> Sent: Wednesday, November 09, 2011 12:13 PM
> To: Hilman, Kevin
>
From: Hugo Dupras
By calling poll() on the /sys/class/gpio/gpioN/value sysfs file, usermode
application can take benefit of gpio interrupts.
However, depending on the power state reached, this interrupt may not wake-up
the CPU.
This patch creates a new sysfs file /sys/class/gpio/gpioN/irq_wake to
On Tue, Nov 8, 2011 at 8:55 PM, Cousson, Benoit wrote:
> On 11/8/2011 12:59 PM, Govindraj wrote:
>>
>> On Tue, Nov 8, 2011 at 4:24 PM, Santosh Shilimkar
>> wrote:
>
> [...]
>
>>> Opps. I missed that one while acking the patch.
>>> Indeed the semi-colon one was agreed to be the left over
>>> in t
Fix below compilation failure on mainline kernel 3.2-rc1
when omap_l3_noc.c is built as module.
arch/arm/mach-omap2/omap_l3_noc.c:240: error: expected ',' or ';' before
'MODULE_DEVICE_TABLE'
Signed-off-by: Govindraj.R
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_l3_noc.c |2 +-
Hi,
On Tue, Nov 8, 2011 at 11:42 PM, Paul Walmsley wrote:
>
> Hi
>
> I just read
>
> http://comments.gmane.org/gmane.comp.embedded.pandaboard/168
>
> Looks to me that the L3_EMU interconnect and the emulation IP blocks need
You mean the "emu" hwmod in the patch should be kept and a new "l3_emu"
On Saturday 05 November 2011 03:16 AM, Kevin Hilman wrote:
> ping v2
>
> Kevin Hilman writes:
>
>> From: Nicole Chalhoub
>>
>> While there is CPU load, program a C-state specific one-shot timer in
>> order to give CPUidle another opportunity to pick a deeper C-state
>> instead of spending poten
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
> Sent: Wednesday, November 09, 2011 5:45 AM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
> Subject:
Hi,
On Wednesday 09 November 2011 05:42 AM, Ilya Yanok wrote:
AM35xx don't have VDDS_DSI regulator.
AM35xx do have vdds_dsi regulator. Are you saying that your particular
board doesn't have vdds_dsi connected to a regulator?
I assumed that vdds_dsi regulator was required for DPI to function
Hello,
Is there any way to perform Cortex-A8 operations that require "secure
privileged mode" on DM3730, for example inspecting L2 tag RAM?
--
Antti P Miettinen
http://www.iki.fi/~ananaza/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to major
Hi,
Thanks for your comments.
On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley wrote:
>> +static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
>> + { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
>> + { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
>> + { .irq = -1
Hi Kevin,
On Mon, Oct 17, 2011 at 1:41 PM, Ohad Ben-Cohen wrote:
> Expose omap_device_{alloc, delete, register} so we can use them outside
> of omap_device.c.
Can you please take this one ?
Please tell me if you want a refreshed version against 3.2-rc1.
Thanks!
Ohad.
>
> This approach allows
On Wed, Nov 9, 2011 at 11:17 AM, Laurent Pinchart
wrote:
> Hi Ohad,
>
> On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
>> Bind OMAP3's isp device to the isp's dedicated iommu, by setting
>> the device's archdata iommu member.
>>
>> This way omap3isp will be able to use the generic IOMM
Hi Ohad,
On Wednesday 09 November 2011 09:50:30 Ohad Ben-Cohen wrote:
> On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart wrote:
> > On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
> >> Eliminate the public omap_find_iommu_device() method, and don't
> >> expect clients to provide the om
Hi Ohad,
On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
> Bind OMAP3's isp device to the isp's dedicated iommu, by setting
> the device's archdata iommu member.
>
> This way omap3isp will be able to use the generic IOMMU API without
> having to call any omap-specific binding method.
>
Hi Laurent,
On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart
wrote:
> On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
>> Eliminate the public omap_find_iommu_device() method, and don't
>> expect clients to provide the omap_iommu handle anymore.
>>
>> Instead, OMAP's iommu driver shoul
29 matches
Mail list logo
