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
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 p...@pwsan.com wrote:
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+ { .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ {
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)
-
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 o...@wizery.com
Cc: Hiroshi DOYU hd...@nvidia.com
---
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
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
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 o...@wizery.com
---
drivers/iommu/iommu.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git
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
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 o...@wizery.com
Acked-by: David Brown dav...@codeaurora.org
Cc: Stepan
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 o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc:
Hi Kevin,
On Wed, Nov 9, 2011 at 12:50 AM, Kevin Hilman khil...@ti.com wrote:
Rajendra Nayak rna...@ti.com 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
On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
On Thu, Nov 10, 2011 at 8:17 AM, Kai Huangmail.kai.hu...@gmail.com 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
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 ya...@emcraft.com
---
arch/arm/boot/dts/am35xx.dtsi | 15
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
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
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 ya...@emcraft.com
---
arch/arm/boot/dts/mcx.dts| 29 ++
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 Huangmail.kai.hu...@gmail.com wrote:
Seems the unmap function don't take phys as parameter, does this mean
domain-ops-unmap will walk through the page table
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 Huangmail.kai.hu...@gmail.com wrote:
Seems the unmap function don't take phys as parameter,
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
From: Leonid Iziumtsev x0153...@ti.com
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=6123navigationId=12869contentId=123362
Signed-off-by: Leonid
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, but
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-203 boot
+ 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
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 IVA node on
Ohad Ben-Cohen o...@wizery.com writes:
Hi Kevin,
On Mon, Oct 17, 2011 at 1:41 PM, Ohad Ben-Cohen o...@wizery.com 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
From: Afzal Mohammed af...@ti.com
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 af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
DPLL5
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
From: Afzal Mohammed af...@ti.com
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 af...@ti.com
Signed-off-by:
From: Afzal Mohammed af...@ti.com
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 af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
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
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.
Premi, Sanjeev pr...@ti.com 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 khil...@ti.com
Ilya Yanok ya...@emcraft.com 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]
Patrick Combes p-com...@ti.com writes:
From: Hugo Dupras h-dup...@ti.com
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
Govindraj govindraj...@gmail.com writes:
Hi Kevin,
On Wed, Nov 9, 2011 at 12:50 AM, Kevin Hilman khil...@ti.com wrote:
Rajendra Nayak rna...@ti.com writes:
Hi Kevin,
On Saturday 05 November 2011 04:12 AM, Kevin Hilman wrote:
However, as mentioned previously[1], due to a HW sleepdep
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 unmap'
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 t...@atomide.com
diff --git
As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
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
On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
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
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
* Russell King - ARM Linux li...@arm.linux.org.uk [10 11:49]:
On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
there's no need to keep local prototypes in non-local headers.
Add mach-omap1/common.h and
Hi,
On Wed, 9 Nov 2011, Tony Lindgren wrote:
* Aaro Koskinen aaro.koski...@iki.fi [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
On Thu, Nov 10, 2011 at 01:50:09PM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [10 11:49]:
On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
there's no need to keep local
* Aaro Koskinen aaro.koski...@iki.fi [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 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 aaro.koski...@iki.fi [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:
* Russell King - ARM Linux li...@arm.linux.org.uk [10 13:54]:
On Thu, Nov 10, 2011 at 01:50:09PM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [10 11:49]:
OK, a stable branch is needed badly for this.. If possible please
publish some minimal stable
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
On Thu, Nov 10, 2011 at 7:37 PM, Kevin Hilman khil...@ti.com 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
* Ilya Yanok ya...@emcraft.com [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 ya...@emcraft.com
---
arch/arm/boot/dts/mcx.dts| 29 ++
On Wed, Nov 09, 2011 at 01:46:52PM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [07 16:11]:
* Russell King - ARM Linux li...@arm.linux.org.uk [06 05:18]:
Here's a list of my peaves about current platform code - which are
causing me great issue when trying to clean
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
Moving the
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 govindraj.r...@ti.com
---
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.dtsi file into common part,
53 matches
Mail list logo
