On 11/10/11 20:07, Cousson, Benoit wrote:
> Hi Igor,
>
> On 11/10/2011 6:26 PM, Igor Grinberg wrote:
>> On 11/10/11 19:09, Cousson, Benoit wrote:
>>> + devicetree ml
>>>
>>> On 11/10/2011 1:18 PM, Igor Grinberg wrote:
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
> Split omap3.d
When cpuidle pm is selected the following compilation break is seen
fix the same.
arch/arm/mach-omap2/cpuidle34xx.c:312: error: 'THIS_MODULE' undeclared here
(not in a function)
make[1]: *** [arch/arm/mach-omap2/cpuidle34xx.o] Error 1
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/cpuidle3
On Friday 11 November 2011 05:14 AM, Jon Hunter wrote:
> Hi Govindraj,
>
> On 10/18/2011 10:26, Govindraj.R wrote:
>> Move the errata handling mechanism from serial.c to omap-serial file
>> and utilise the same func in driver file.
>>
>> Errata i202, i291 are moved to be handled with omap-serial
>>
On Wed, Nov 09, 2011 at 01:46:52PM -0800, Tony Lindgren wrote:
> * 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:
> >
* Ilya Yanok [08 15:38]:
> Support for the HTKW mcx board (TI AM3517 based) including serial,
> Ethernet, I2C, USB host, HSMMC, DSS and RTC.
>
> Signed-off-by: Ilya Yanok
> ---
> arch/arm/boot/dts/mcx.dts| 29 ++
> arch/arm/mach-omap2/Kconfig |5 +
On Thu, Nov 10, 2011 at 7:37 PM, Kevin Hilman wrote:
> Yes, will queue for v3.3.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Govindraj,
On 10/18/2011 10:26, Govindraj.R wrote:
Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.
Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as fro
* Russell King - ARM Linux [10 13:54]:
> On Thu, Nov 10, 2011 at 01:50:09PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [10 11:49]:
> >
> > OK, a stable branch is needed badly for this.. If possible please
> > publish some minimal stable base branch as soon as you can as p
On Thursday 10 of November 2011 at 01:28:58, Aaro Koskinen wrote:
> 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:
> Com
* Aaro Koskinen [10 13:31]:
> --- a/arch/arm/mach-omap1/clock_data.c
> +++ b/arch/arm/mach-omap1/clock_data.c
> @@ -774,14 +774,6 @@ int __init omap1_clk_init(void)
> int crystal_type = 0; /* Default 12 MHz */
> u32 reg, cpu_mask;
>
> -#ifdef CONFIG_DEBUG_LL
> - /*
> - *
On Thu, Nov 10, 2011 at 01:50:09PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [10 11:49]:
> > On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
> > > As suggested by Russell King - ARM Linux ,
> > > there's no need to keep local prototypes in non-local headers.
> > >
Hi,
On Wed, 9 Nov 2011, 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 and
* Russell King - ARM Linux [10 11:49]:
> On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
> > As suggested by Russell King - ARM Linux ,
> > there's no need to keep local prototypes in non-local headers.
> >
> > Add mach-omap1/common.h and mach-omap2/common.h and move the
> > lo
On 11/10/2011 9:09 AM, Joerg Roedel wrote:
The plan is to have a single DMA-API implementation for all IOMMU
drivers (X86 and ARM) which just uses the IOMMU-API. But to make this
performing reasonalbly well a few changes to the IOMMU-API are
required. I already have some ideas which we can disc
On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
> As suggested by Russell King - ARM Linux ,
> there's no need to keep local prototypes in non-local headers.
>
> Add mach-omap1/common.h and mach-omap2/common.h and move the
> local prototypes there from plat/common.h and mach/omap4-c
As suggested by Russell King - ARM Linux ,
there's no need to keep local prototypes in non-local headers.
Add mach-omap1/common.h and mach-omap2/common.h and move the
local prototypes there from plat/common.h and mach/omap4-common.h.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1
Without this patch we get the following error:
arch/arm/mach-omap2/clkt_dpll.c: In function '_dpll_test_fint':
arch/arm/mach-omap2/clkt_dpll.c:98: error: 'struct dpll_data' has no member
named 'flags'
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm
On Thu, 2011-11-10 at 18:09 +0100, Joerg Roedel wrote:
> The requirement for the DMA-API is, that the IOTLB must be consistent
> with existing mappings, and only with the parts that are really mapped.
> The unmapped parts are not important.
>
> This allows nice optimizations like your 'batched unm
Govindraj writes:
> Hi Kevin,
>
> On Wed, Nov 9, 2011 at 12:50 AM, Kevin Hilman wrote:
>> Rajendra Nayak writes:
>>
>>> Hi Kevin,
>>>
>>> On Saturday 05 November 2011 04:12 AM, Kevin Hilman wrote:
However, as mentioned previously[1], due to a HW sleepdep between MPU
and CORE, this con
Patrick Combes writes:
> 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
Ilya Yanok writes:
> Hi guys,
>
> any comments on this? Is anybody interested?
There's a major cleanup of the OMAP UART driver in progress[1]. I
suggest you rebase on top of that, or hold onto this until the cleanup
is merged.
Kevin
[1] http://marc.info/?l=linux-omap&m=131914563820506&w=2
--
"Premi, Sanjeev" writes:
>> Current code registers voltage layer details for TWL PMIC even when a
>> TWL has not been registered. Fix this to only register the TWL with
>> voltage layer when the TWL PMIC is initialized by board-level code.
>>
>> Signed-off-by: Kevin Hilman
[...]
> I have bee
Hi Igor,
On 11/10/2011 6:26 PM, Igor Grinberg wrote:
On 11/10/11 19:09, Cousson, Benoit wrote:
+ devicetree ml
On 11/10/2011 1:18 PM, Igor Grinberg wrote:
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
Split omap3.dtsi file into common part, OM3xxx specific part and
AM35xx specific part. For
On Thu, Nov 10, 2011 at 03:28:50PM +, David Woodhouse wrote:
> Which brings me to another question I have been pondering... do we even
> have a consensus on exactly *when* the IOTLB should be flushed?
Well, sort of, there is still the outstanding idea of the
iommu_commit() interface for the I
From: Afzal Mohammed
Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.
Signed-off-by: Afzal Mohammed
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/include/mach/debug-macro.S | 17 +
From: Afzal Mohammed
This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.
Signed-off-by: Afzal Mohammed
Signed-off-by: Vaibhav Hiremath
---
arch/
This patch set adds support for AM335x device having
Cortex-A8 MPU.
Official website - http://www.ti.com/product/am3359
AM335X is treated as another OMAP3 variant, where,
along with existing cpu class OMAP34XX, new cpu class AM33XX is created
and the respective type is AM335X, which is newly adde
From: Afzal Mohammed
This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Signed-off-by: Afzal Mohammed
Signed-off-by: Vaibhav Hiremath
---
DPLL5 related comment (from KevinH) has been handle
Ohad Ben-Cohen writes:
> 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 ?
Yes, will queue for v3.3.
> Please tell me if you want a refreshed ve
On 11/10/11 19:09, Cousson, Benoit wrote:
> + devicetree ml
>
> On 11/10/2011 1:18 PM, Igor Grinberg wrote:
>> Hi Ilya,
>>
>> On 11/09/11 02:12, Ilya Yanok wrote:
>>> Split omap3.dtsi file into common part, OM3xxx specific part and
>>> AM35xx specific part. For now the only difference is missing I
+ devicetree ml
On 11/10/2011 1:18 PM, Igor Grinberg wrote:
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
Split omap3.dtsi file into common part, OM3xxx specific part and
AM35xx specific part. For now the only difference is missing IVA node on
AM35xx.
Signed-off-by: Ilya Yanok
---
arch/arm/
On 11/10/11 12:47 AM, Premi, Sanjeev wrote:
> I have been running latest linux-omap/master on OMAP3EVM (boot from MMC).
> When building with CodeSourcery 2011.03-41, I see frequent "hangs" just
> after "Uncompressing Linux... done, booting the kernel"
>
> However, builds with CodeSourcery 2009q1-2
On Thu, 2011-11-10 at 14:17 +0800, Kai Huang wrote:
> And another question: have we considered the IOTLB flush operation? I
> think we need to implement similar logic when flush the DVMA range.
> Intel VT-d's manual says software needs to specify the appropriate
> mask value to flush large pages, b
From: Leonid Iziumtsev
Add support for detection of the next chip in the OMAP4 family: OMAP4470 ES1.0
For more details on OMAP4470, visit:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12869&contentId=123362
Signed-off-by: Leonid Iziumtsev
---
arch/
On Thu, Nov 10, 2011 at 10:35:34PM +0800, cody wrote:
> Yes I totally agree page-size is not required for unmap operations
> and should not be added as parameter to map/unmap operations. I am
> not saying the unmap operation, but the IOTLB flush operation. My
> point is we also may also need to add
On 11/10/2011 09:08 PM, Joerg Roedel wrote:
On Thu, Nov 10, 2011 at 08:16:16PM +0800, cody wrote:
On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
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->op
On Thu, Nov 10, 2011 at 08:16:16PM +0800, cody wrote:
> On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
> >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 t
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
> Support for the HTKW mcx board (TI AM3517 based) including serial,
> Ethernet, I2C, USB host, HSMMC, DSS and RTC.
>
> Signed-off-by: Ilya Yanok
> ---
> arch/arm/boot/dts/mcx.dts| 29 ++
> arch/arm/mach-omap2/Kconfig
On 11/10/2011 02:46 PM, Jarkko Nikula wrote:
On 11/07/2011 11:33 AM, Peter Ujfalusi wrote:
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
regi
On 11/07/2011 11:33 AM, Peter Ujfalusi wrote:
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
register:
CDAC != 0 indicates that the DMA transfe
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
> Split omap3.dtsi file into common part, OM3xxx specific part and
> AM35xx specific part. For now the only difference is missing IVA node on
> AM35xx.
>
> Signed-off-by: Ilya Yanok
> ---
> arch/arm/boot/dts/am35xx.dtsi | 15 +++
>
On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
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 fur
Hi Kevin,
On Wed, Nov 9, 2011 at 12:50 AM, Kevin Hilman wrote:
> Rajendra Nayak writes:
>
>> Hi Kevin,
>>
>> On Saturday 05 November 2011 04:12 AM, Kevin Hilman wrote:
>>> However, as mentioned previously[1], due to a HW sleepdep between MPU
>>> and CORE, this constraint isn't actually needed fo
Express sizes in bytes rather than in page order, to eliminate the
size->order->size conversions we have whenever the IOMMU API is calling
the low level drivers' map/unmap methods.
Adopt all existing drivers.
Signed-off-by: Ohad Ben-Cohen
Cc: David Brown
Cc: David Woodhouse
Cc: Joerg Roedel
C
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen
Acked-by: David Brown
Cc: Stepan Moskovchenko
---
drivers/iommu/msm_io
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KiB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KiB
- they are naturally aligned
Note: Intel IOMMU hardware doesn't
Now that all IOMMU drivers are exporting their supported pgsizes,
we can remove the default pgsize settings in register_iommu().
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/iommu.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/iommu.c b/driv
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KiB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KiB
- they are naturally aligned
Signed-off-by: Ohad Ben-Cohen
Cc:
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to d
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen
Cc: Hiroshi DOYU
---
drivers/iommu/omap-iommu.c |4
1 files ch
v3->v4:
- simplify splitter logic (Joerg)
- declare supported page-sizes in the iommu_ops, without extending
iommu_register (Joerg)
- iommu_unmap should now return bytes too (Joerg)
- don't cache min_pgsize anymore (Joerg)
- handle cases when ->unmap() actually unmaps more than requested (Joerg)
-
Hello Ming Lei,
just a few quick comments for now -
On Wed, 9 Nov 2011, Ming Lei wrote:
> 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
Hi all,
I have been running latest linux-omap/master on OMAP3EVM (boot from MMC).
When building with CodeSourcery 2011.03-41, I see frequent "hangs" just
after "Uncompressing Linux... done, booting the kernel"
However, builds with CodeSourcery 2009q1-203 boot consistently all the
time.
Before tr
53 matches
Mail list logo
