Which toolchain are we using?
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 trying to investigate further, wanted to know if someone else has seen the problem. If no, which toolchain is being used. ~sanjeev -- 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
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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 },
+ { .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
Are you sure these are part of the emulation IP? We already have those
I am not sure, I just figure out one way to make omap4 pmu work. Since there
are few descriptions in TRM about it, it is a hacking based on [1], :-)
IRQs in the MPU hwmod, see omap44xx_mpu_irqs[] in the same file.
I just see it, but looks like the mpu hwmod isn't populated as omap_device,
so the CTI irqs aren't requested now.
Okay. Maybe you can probably add some code in mach-omap2/devices.c to
build an omap_device for this for right now? I am not 100% sure whether
those cti0/1 interrupts should be associated with the MPU or with the
DEBUGSS but Benoît might be able to answer this.
Also, current arm perf code don't handle three IRQs(one pl310 irq and
two CTI irq) inside one device correctly.
To fix this, that ARM perf code should either be using
platform_get_irq_byname(), or the hwmod hardware data will need to be
rearranged to meet the arbitrary ordering requirement. I'd suggest
pinging Will on this issue to see what he wants to do.
So any suggestion about CTI IRQs connecting to which hwmod, so that they can
be found by pmu driver?
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+ .name = emu,
+ .class = omap44xx_emu_hwmod_class,
+ .clkdm_name = emu_sys_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
This doesn't look right either: EMU is a clockdomain, not an IP block.
I defined the 'emu' hwmod to control the clock state transition of the EMU
clock domain by writing to CLKTRCTRL.CM_EMU_CLKSTCTRL with standard
hwmod interface(_enable / _idle). Is there any other neat way to do it?
So the clockdomain is already defined in
mach-omap2/clockdomains44xx_data.c and there's code to control it - see
for example clkdm_enable_idle(). But this code should not be called
directly by any device driver code or driver integration code. The thing
to do here is to ask Benoît to release the hwmod data for the DEBUGSS
hwmod, then someone will need to write an MFD driver for that which
exposes the PMU address space to the PMU platform driver.
But also proper dependency support in hwmod enable/idle operations will be
needed to enable the instrumentation and emulation interconnects when the
DEBUGSS is enabled. This has been on my plate for a few months, it's good
to have another reason to prioritize it.
- Paul
[PATCH v4-rebased 0/7] iommu: split mapping to page sizes as supported by the hardware
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) - unroll iommu_unmap completely in case it fails (KyongHo) - use size_t for size parameters (KyongHo) - add a patch to remove the bytes-order-bytes conversion we had - rabased to master branch of the iommu tree (Joerg) (and now rebased to 3.2-rc1) v2-v3: - s/KB/KiB/ (David W) v1-v2: - split to patches (by keeping the old code around until all drivers are converted) (Joerg) Tested with OMAP4 (with rpmsg/remoteproc) and compile tested for X86-64. Ohad Ben-Cohen (7): iommu/core: stop converting bytes to page order back and forth iommu/core: split mapping to page sizes as supported by the hardware iommu/omap: announce supported page sizes iommu/msm: announce supported page sizes iommu/amd: announce supported page sizes iommu/intel: announce supported page sizes iommu/core: remove the temporary pgsize settings drivers/iommu/amd_iommu.c | 32 +--- drivers/iommu/intel-iommu.c | 30 --- drivers/iommu/iommu.c | 119 ++ drivers/iommu/msm_iommu.c | 25 - drivers/iommu/omap-iommu.c | 18 +++--- drivers/iommu/omap-iovmm.c | 17 ++ include/linux/iommu.h | 26 +++-- virt/kvm/iommu.c|8 ++-- 8 files changed, 205 insertions(+), 70 deletions(-) -- 1.7.5.4 -- 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
[PATCH v4-rebased 3/7] iommu/omap: announce supported page sizes
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
---
drivers/iommu/omap-iommu.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index ad80b1d..08cf7ec 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -33,6 +33,9 @@
(__i (n)) (cr = __iotlb_read_cr((obj), __i), true); \
__i++)
+/* bitmap of the page sizes currently supported */
+#define OMAP_IOMMU_PGSIZES (SZ_4K | SZ_64K | SZ_1M | SZ_16M)
+
/**
* struct omap_iommu_domain - omap iommu domain
* @pgtable: the page table
@@ -1207,6 +1210,7 @@ static struct iommu_ops omap_iommu_ops = {
.unmap = omap_iommu_unmap,
.iova_to_phys = omap_iommu_iova_to_phys,
.domain_has_cap = omap_iommu_domain_has_cap,
+ .pgsize_bitmap = OMAP_IOMMU_PGSIZES,
};
static int __init omap_iommu_init(void)
--
1.7.5.4
--
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
[PATCH v4-rebased 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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 duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel joerg.roe...@amd.com for significant review!
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: David Woodhouse dw...@infradead.org
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: KyongHo Cho pullip@samsung.com
Cc: Hiroshi DOYU hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: k...@vger.kernel.org
---
drivers/iommu/iommu.c | 131 +++-
drivers/iommu/omap-iovmm.c | 17 ++
include/linux/iommu.h | 20 ++-
virt/kvm/iommu.c |8 +-
4 files changed, 144 insertions(+), 32 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 7a2953d..b278458 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -16,6 +16,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#define pr_fmt(fmt)%s: fmt, __func__
+
#include linux/device.h
#include linux/kernel.h
#include linux/bug.h
@@ -47,6 +49,16 @@ int bus_set_iommu(struct bus_type *bus, struct iommu_ops
*ops)
if (bus-iommu_ops != NULL)
return -EBUSY;
+ /*
+* Set the default pgsize values, which retain the existing
+* IOMMU API behavior: drivers will be called to map
+* regions that are sized/aligned to order of 4KiB pages.
+*
+* This will be removed once all drivers are migrated.
+*/
+ if (!ops-pgsize_bitmap)
+ ops-pgsize_bitmap = ~0xFFFUL;
+
bus-iommu_ops = ops;
/* Do IOMMU specific setup for this bus-type */
@@ -157,34 +169,125 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
int iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, int gfp_order, int prot)
+ phys_addr_t paddr, size_t size, int prot)
{
- size_t size;
+ unsigned long orig_iova = iova;
+ unsigned int min_pagesz;
+ size_t orig_size = size;
+ int ret = 0;
if (unlikely(domain-ops-map == NULL))
return -ENODEV;
- size = PAGE_SIZE gfp_order;
+ /* find out the minimum page size supported */
+ min_pagesz = 1 __ffs(domain-ops-pgsize_bitmap);
+
+ /*
+* both the virtual address and the physical one, as well as
+* the size of the mapping, must be aligned (at least) to the
+* size of the smallest page supported by the hardware
+*/
+ if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
+ pr_err(unaligned: iova 0x%lx pa 0x%lx size 0x%lx min_pagesz
+ 0x%x\n, iova, (unsigned long)paddr,
+ (unsigned long)size, min_pagesz);
+ return -EINVAL;
+ }
+
+ pr_debug(map: iova 0x%lx pa 0x%lx size 0x%lx\n, iova,
+ (unsigned long)paddr, (unsigned long)size);
+
+ while (size) {
+ unsigned long pgsize, addr_merge = iova | paddr;
+ unsigned int pgsize_idx;
+
+ /* Max page size that still fits into 'size' */
+ pgsize_idx = __fls(size);
+
+ /* need to consider alignment requirements ? */
+ if (likely(addr_merge)) {
+ /* Max page size allowed by both iova and paddr */
+ unsigned int align_pgsize_idx = __ffs(addr_merge);
+
+ pgsize_idx = min(pgsize_idx, align_pgsize_idx);
+ }
+
+ /* build a mask of acceptable page sizes */
+ pgsize = (1UL (pgsize_idx + 1)) - 1;
[PATCH v4-rebased 5/7] iommu/amd: announce supported page sizes
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 o...@wizery.com
Cc: Joerg Roedel joerg.roe...@amd.com
---
drivers/iommu/amd_iommu.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a3b7072..3415738 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -41,6 +41,24 @@
#define LOOP_TIMEOUT 10
+/*
+ * This bitmap is used to advertise the page sizes our hardware support
+ * to the IOMMU core, which will then use this information to split
+ * physically contiguous memory regions it is mapping into page sizes
+ * that we support.
+ *
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KiB page and that the
+ * mapping has natural alignment.
+ *
+ * To retain this behavior, we currently advertise that we support
+ * all page sizes that are an order of 4KiB.
+ *
+ * If at some point we'd like to utilize the IOMMU core's new behavior,
+ * we could change this to advertise the real page sizes we support.
+ */
+#define AMD_IOMMU_PGSIZES (~0xFFFUL)
+
static DEFINE_RWLOCK(amd_iommu_devtable_lock);
/* A list of preallocated protection domains */
@@ -2779,6 +2797,7 @@ static struct iommu_ops amd_iommu_ops = {
.unmap = amd_iommu_unmap,
.iova_to_phys = amd_iommu_iova_to_phys,
.domain_has_cap = amd_iommu_domain_has_cap,
+ .pgsize_bitmap = AMD_IOMMU_PGSIZES,
};
/*
--
1.7.5.4
--
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
[PATCH v4-rebased 7/7] iommu/core: remove the temporary pgsize settings
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 a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index b278458..84cdd8a 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -49,16 +49,6 @@ int bus_set_iommu(struct bus_type *bus, struct iommu_ops *ops) if (bus-iommu_ops != NULL) return -EBUSY; - /* -* Set the default pgsize values, which retain the existing -* IOMMU API behavior: drivers will be called to map -* regions that are sized/aligned to order of 4KiB pages. -* -* This will be removed once all drivers are migrated. -*/ - if (!ops-pgsize_bitmap) - ops-pgsize_bitmap = ~0xFFFUL; - bus-iommu_ops = ops; /* Do IOMMU specific setup for this bus-type */ -- 1.7.5.4 -- 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
[PATCH v4-rebased 6/7] iommu/intel: announce supported page sizes
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 support arbitrary page sizes,
but the driver does (it splits arbitrary-sized mappings into
the pages supported by the hardware).
To make everything simpler for now, though, this patch effectively tells
the IOMMU core to keep giving this driver the same memory regions it did
before, so nothing is changed as far as it's concerned.
At this point, the page sizes announced remain static within the IOMMU
core. To correctly utilize the pgsize-splitting of the IOMMU core by
this driver, it seems that some core changes should still be done,
because Intel's IOMMU page size capabilities seem to have the potential
to be different between different DMA remapping devices.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Woodhouse dw...@infradead.org
---
drivers/iommu/intel-iommu.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 2a16501..4c780ef 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -78,6 +78,24 @@
#define LEVEL_STRIDE (9)
#define LEVEL_MASK (((u64)1 LEVEL_STRIDE) - 1)
+/*
+ * This bitmap is used to advertise the page sizes our hardware support
+ * to the IOMMU core, which will then use this information to split
+ * physically contiguous memory regions it is mapping into page sizes
+ * that we support.
+ *
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KiB page and that the
+ * mapping has natural alignment.
+ *
+ * To retain this behavior, we currently advertise that we support
+ * all page sizes that are an order of 4KiB.
+ *
+ * If at some point we'd like to utilize the IOMMU core's new behavior,
+ * we could change this to advertise the real page sizes we support.
+ */
+#define INTEL_IOMMU_PGSIZES(~0xFFFUL)
+
static inline int agaw_to_level(int agaw)
{
return agaw + 2;
@@ -4066,6 +4084,7 @@ static struct iommu_ops intel_iommu_ops = {
.unmap = intel_iommu_unmap,
.iova_to_phys = intel_iommu_iova_to_phys,
.domain_has_cap = intel_iommu_domain_has_cap,
+ .pgsize_bitmap = INTEL_IOMMU_PGSIZES,
};
static void __devinit quirk_iommu_rwbf(struct pci_dev *dev)
--
1.7.5.4
--
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
[PATCH v4-rebased 4/7] iommu/msm: announce supported page sizes
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 Moskovchenko step...@codeaurora.org
---
drivers/iommu/msm_iommu.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 13718d9..08a90b8 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -42,6 +42,9 @@ __asm__ __volatile__ (
\
#define RCP15_PRRR(reg)MRC(reg, p15, 0, c10, c2, 0)
#define RCP15_NMRR(reg)MRC(reg, p15, 0, c10, c2, 1)
+/* bitmap of the page sizes currently supported */
+#define MSM_IOMMU_PGSIZES (SZ_4K | SZ_64K | SZ_1M | SZ_16M)
+
static int msm_iommu_tex_class[4];
DEFINE_SPINLOCK(msm_iommu_lock);
@@ -679,7 +682,8 @@ static struct iommu_ops msm_iommu_ops = {
.map = msm_iommu_map,
.unmap = msm_iommu_unmap,
.iova_to_phys = msm_iommu_iova_to_phys,
- .domain_has_cap = msm_iommu_domain_has_cap
+ .domain_has_cap = msm_iommu_domain_has_cap,
+ .pgsize_bitmap = MSM_IOMMU_PGSIZES,
};
static int __init get_tex_class(int icp, int ocp, int mt, int nos)
--
1.7.5.4
--
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
[PATCH v4-rebased 1/7] iommu/core: stop converting bytes to page order back and forth
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: David Woodhouse dw...@infradead.org
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: KyongHo Cho pullip@samsung.com
Cc: Hiroshi DOYU hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/amd_iommu.c | 13 +
drivers/iommu/intel-iommu.c | 11 ---
drivers/iommu/iommu.c |8 +---
drivers/iommu/msm_iommu.c | 19 +++
drivers/iommu/omap-iommu.c | 14 +-
include/linux/iommu.h |6 +++---
6 files changed, 29 insertions(+), 42 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 4ee277a..a3b7072 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2702,9 +2702,8 @@ static int amd_iommu_attach_device(struct iommu_domain
*dom,
}
static int amd_iommu_map(struct iommu_domain *dom, unsigned long iova,
-phys_addr_t paddr, int gfp_order, int iommu_prot)
+phys_addr_t paddr, size_t page_size, int iommu_prot)
{
- unsigned long page_size = 0x1000UL gfp_order;
struct protection_domain *domain = dom-priv;
int prot = 0;
int ret;
@@ -2721,13 +2720,11 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
return ret;
}
-static int amd_iommu_unmap(struct iommu_domain *dom, unsigned long iova,
- int gfp_order)
+static size_t amd_iommu_unmap(struct iommu_domain *dom, unsigned long iova,
+ size_t page_size)
{
struct protection_domain *domain = dom-priv;
- unsigned long page_size, unmap_size;
-
- page_size = 0x1000UL gfp_order;
+ size_t unmap_size;
mutex_lock(domain-api_lock);
unmap_size = iommu_unmap_page(domain, iova, page_size);
@@ -2735,7 +2732,7 @@ static int amd_iommu_unmap(struct iommu_domain *dom,
unsigned long iova,
domain_flush_tlb_pde(domain);
- return get_order(unmap_size);
+ return unmap_size;
}
static phys_addr_t amd_iommu_iova_to_phys(struct iommu_domain *dom,
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c0c7820..2a16501 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3979,12 +3979,11 @@ static void intel_iommu_detach_device(struct
iommu_domain *domain,
static int intel_iommu_map(struct iommu_domain *domain,
unsigned long iova, phys_addr_t hpa,
- int gfp_order, int iommu_prot)
+ size_t size, int iommu_prot)
{
struct dmar_domain *dmar_domain = domain-priv;
u64 max_addr;
int prot = 0;
- size_t size;
int ret;
if (iommu_prot IOMMU_READ)
@@ -3994,7 +3993,6 @@ static int intel_iommu_map(struct iommu_domain *domain,
if ((iommu_prot IOMMU_CACHE) dmar_domain-iommu_snooping)
prot |= DMA_PTE_SNP;
- size = PAGE_SIZE gfp_order;
max_addr = iova + size;
if (dmar_domain-max_addr max_addr) {
u64 end;
@@ -4017,11 +4015,10 @@ static int intel_iommu_map(struct iommu_domain *domain,
return ret;
}
-static int intel_iommu_unmap(struct iommu_domain *domain,
-unsigned long iova, int gfp_order)
+static size_t intel_iommu_unmap(struct iommu_domain *domain,
+unsigned long iova, size_t size)
{
struct dmar_domain *dmar_domain = domain-priv;
- size_t size = PAGE_SIZE gfp_order;
int order;
order = dma_pte_clear_range(dmar_domain, iova VTD_PAGE_SHIFT,
@@ -4030,7 +4027,7 @@ static int intel_iommu_unmap(struct iommu_domain *domain,
if (dmar_domain-max_addr == iova + size)
dmar_domain-max_addr = iova;
- return order;
+ return PAGE_SIZE order;
}
static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain *domain,
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2fb2963..7a2953d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -168,13 +168,13 @@ int iommu_map(struct iommu_domain *domain, unsigned long
iova,
BUG_ON(!IS_ALIGNED(iova | paddr, size));
- return domain-ops-map(domain, iova, paddr, gfp_order, prot);
+ return domain-ops-map(domain, iova, paddr, size, prot);
}
EXPORT_SYMBOL_GPL(iommu_map);
int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int gfp_order)
{
- size_t size;
+ size_t size, unmapped;
if (unlikely(domain-ops-unmap == NULL))
return -ENODEV;
@@ -183,6 +183,8 @@ int
Re: [PATCH v7 17/21] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
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 actually needed for CORE UARTs, so it's a bit wasteful to go through all the constraint setting for no reason. I had a short chat with Govind on this and was trying to understand this better. Are you referring to the 'autodeps' for omap3 here, because they would prevent any clock domain from idling as long as MPU or IVA are active, No, I was thinking of HW sleepdeps. However, I looked back at the OMAP3430 TRM and see that MPU does not have a HW sleepdep on CORE like I thought. but not the other way round. Which means MPU can still idle, while CORE does not. My guess was, its probably the CORE domain idling itself thats causing the UART sluggishness, (and not MPU idling), due to higher latency, which is prevented with an active UART module in CORE, but not in PER. OK, that indeed makes sense. Thanks for correcting me. So Govind did a small experiment to prevent just CORE idling and let MPU idle alone and that did not show any sluggishness. OK, good. Now, putting a pm-qos constraint for a UART in CORE still looks redundant because the latency requirement that UART has is in some way *indirectly* met (because the active UART in CORE prevents CORE transitions in idle). But don't you think the UART driver should express its latency constraints regardless, without thinking of any indirect ways in which the same requirements would have already been met? Yes, you're right. The driver should not need to know which powerdomain a given UART is in. It's probably best (and most portable) to have UART always express its requirements all the time. Thanks for digging into this, I have fixed this and other uart_v7 comments and have re-based the patch series on top of 3.2-rc1 along with Tero's v9 irq chaining patches and tested the same. Available here [1]. Can this patches series be added to a test branch for upstreaming or do you think there are still some outstanding comments that needs to be discussed? -- Thanks, Govindraj.R [1]: git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc1_uart_runtime -- 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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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 answer is yes, and furthermore, we also consider to remove the size param from domain-ops-unmap entirely at some point. We had a long discussion about it, please see: https://lkml.org/lkml/2011/10/10/234 Yes I've seen your discussion, I followed this thread from beginning:) How about the IOTLB flush? As I said I think we need to consider that IOMMU (even does not exist now) may have some limitation on IOTLB flush, and hiding page size from IOTLB flush code may hurt performance, or even worse, trigger undefined behaviors. -cody -- 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
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
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 +++
arch/arm/boot/dts/om3xxx.dtsi | 28
arch/arm/boot/dts/omap3-beagle.dts |2 +-
arch/arm/boot/dts/omap3.dtsi |9 -
4 files changed, 44 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/boot/dts/am35xx.dtsi
create mode 100644 arch/arm/boot/dts/om3xxx.dtsi
om3xxx name is confusing - I haven't seen this name
in any documentation/code before...
Am I missing something?
What do you think of omap3-iva.dtsi or omap3-dsp.dtsi?
diff --git a/arch/arm/boot/dts/am35xx.dtsi b/arch/arm/boot/dts/am35xx.dtsi
new file mode 100644
index 000..0dbc69d
--- /dev/null
+++ b/arch/arm/boot/dts/am35xx.dtsi
@@ -0,0 +1,15 @@
+/*
+ * Device Tree Source for TI AM35xx SoCs
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap3.dtsi
+
+/ {
+ compatible = ti,am35xx, ti,omap3;
+};
diff --git a/arch/arm/boot/dts/om3xxx.dtsi b/arch/arm/boot/dts/om3xxx.dtsi
new file mode 100644
index 000..e8a17dd
--- /dev/null
+++ b/arch/arm/boot/dts/om3xxx.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for TI OM3xxx SoCs
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap3.dtsi
+
+/ {
+ /*
+ * The soc node represents the soc top level view. It is uses for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ iva {
+ compatible = ti,iva2.2;
+ ti,hwmods = iva;
+
+ dsp {
+ compatible = ti,omap3-c64;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..63e4be1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ om3xxx.dtsi
/ {
model = TI OMAP3 BeagleBoard;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..2b12b0e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -29,15 +29,6 @@
compatible = ti,omap3-mpu;
ti,hwmods = mpu;
};
-
- iva {
- compatible = ti,iva2.2;
- ti,hwmods = iva;
-
- dsp {
- compatible = ti,omap3-c64;
- };
- };
};
/*
--
Regards,
Igor.
--
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
Re: [PATCH v2 1/2] OMAP2+: DMA: Workaround for invalid source position
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 transfer on the channel has
been started already.
When CDAC == 0 we can not trust the CSAC value since it has
not been updated, and can contain random number.
Return the start address in case the DMA has not jet started.
Note: The CDAC register has been initialized to 0 at dma_start
time.
Signed-off-by: Peter Ujfalusipeter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..a9983b6 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1034,6 +1034,18 @@ dma_addr_t omap_get_dma_src_pos(int lch)
if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0)
offset = p-dma_read(CSAC, lch);
+ if (!cpu_is_omap15xx()) {
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed source start address in this case.
+*/
+ if (likely(p-dma_read(CDAC, lch)))
+ offset = p-dma_read(CSAC, lch);
+ else
+ offset = p-dma_read(CSSA, lch);
+ }
+
I think this is enough:
if (unlikely(p-dma_read(CDAC, lch) == 0))
offset = p-dma_read(CSSA, lch);
I suppose offset is ok for normal case as it is already read (twise) above.
--
Jarkko
--
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
Re: [PATCH v2 1/2] OMAP2+: DMA: Workaround for invalid source position
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
register:
CDAC != 0 indicates that the DMA transfer on the channel has
been started already.
When CDAC == 0 we can not trust the CSAC value since it has
not been updated, and can contain random number.
Return the start address in case the DMA has not jet started.
Note: The CDAC register has been initialized to 0 at dma_start
time.
Signed-off-by: Peter Ujfalusipeter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..a9983b6 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1034,6 +1034,18 @@ dma_addr_t omap_get_dma_src_pos(int lch)
if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0)
offset = p-dma_read(CSAC, lch);
+ if (!cpu_is_omap15xx()) {
+ /*
+ * CDAC == 0 indicates that the DMA transfer on the channel has
+ * not been started (no data has been transferred so far).
+ * Return the programmed source start address in this case.
+ */
+ if (likely(p-dma_read(CDAC, lch)))
+ offset = p-dma_read(CSAC, lch);
+ else
+ offset = p-dma_read(CSSA, lch);
+ }
+
I think this is enough:
if (unlikely(p-dma_read(CDAC, lch) == 0))
offset = p-dma_read(CSSA, lch);
I suppose offset is ok for normal case as it is already read (twise) above.
Or actually my proposal could have a race if CDAC changes between CSAC
read and CDAC read. In that case it's better to re-read CSAC as your
patch does after CDAC test and give to both:
Reviewed-by: Jarkko Nikula jarkko.nik...@bitmer.com
--
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
Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
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 ++
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/board-mcx.c | 618
++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
5 files changed, 656 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/mcx.dts
create mode 100644 arch/arm/mach-omap2/board-mcx.c
diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..c87df59
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ am35xx.dtsi
+
+/ {
+ model = HTKW mcx;
+ compatible = htkw,mcx;
+
+ /*
+ * Since the initial device tree board file does not create any
+ * devices (MMC, network...), the only way to boot is to provide a
+ * ramdisk.
+ */
+ chosen {
+ bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug
earlyprintk;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c3d530b..3be9cc0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -230,6 +230,11 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
+config MACH_MCX
+ bool htkw mcx board
I have no problem with that, but is this really how you want
the config option to be displayed?
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+
config MACH_NOKIA_N800
bool
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..913aa43 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -232,6 +232,9 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=
board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o \
+omap_phy_internal.o \
This one is always compiled in, so you don't need to specify it
(see a couple of lines below in the file)
+hsmmc.o
This one is compiled in when CONFIG_MMC_OMAP_HS symbol
enabled, so you don't need to specify this one either.
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 000..311e1fb
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,618 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/input.h
+#include linux/gpio_keys.h
+#include linux/opp.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mmc/host.h
+
+#include linux/regulator/machine.h
+#include linux/davinci_emac.h
+#include linux/i2c/edt_ts.h
+
+#include mach/hardware.h
+#include mach/am35xx.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/flash.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/omap_hwmod.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/usb.h
+#include plat/omap_device.h
+
+#include mux.h
+#include control.h
+#include hsmmc.h
+#include common-board-devices.h
I bet, you don't use and don't need all the includes above...
Can it be reduced to the really needed ones?
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mdio_platform_data mcx_mdio_pdata = {
+ .bus_freq = MCX_MDIO_FREQUENCY,
+};
+
+static struct resource am3517_mdio_resources[] = {
+ {
+
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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 to find out the actual page size? The short answer is yes, and furthermore, we also consider to remove the size param from domain-ops-unmap entirely at some point. We had a long discussion about it, please see: https://lkml.org/lkml/2011/10/10/234 Yes I've seen your discussion, I followed this thread from beginning:) How about the IOTLB flush? As I said I think we need to consider that IOMMU (even does not exist now) may have some limitation on IOTLB flush, and hiding page size from IOTLB flush code may hurt performance, or even worse, trigger undefined behaviors. We can only care about IOMMUs that exist today or ones that will exist and we already know of. In general for the hardware I know of a page-size is not required for implementing unmap operations. Requiring this would imply that any user of the IOMMU-API needs to keeps track of the page-sizes used to map a given area. This would be a huge burden which is not really necessary because the IOMMU driver already has this information and can return it to the user. So if you want to change that you need a very good reason for it. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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, 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 from domain-ops-unmap entirely at some point. We had a long discussion about it, please see: https://lkml.org/lkml/2011/10/10/234 Yes I've seen your discussion, I followed this thread from beginning:) How about the IOTLB flush? As I said I think we need to consider that IOMMU (even does not exist now) may have some limitation on IOTLB flush, and hiding page size from IOTLB flush code may hurt performance, or even worse, trigger undefined behaviors. We can only care about IOMMUs that exist today or ones that will exist and we already know of. In general for the hardware I know of a page-size is not required for implementing unmap operations. Requiring this would imply that any user of the IOMMU-API needs to keeps track of the page-sizes used to map a given area. This would be a huge burden which is not really necessary because the IOMMU driver already has this information and can return it to the user. So if you want to change that you need a very good reason for it. 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 similar logic in IOTLB flush code (such as in Intel IOMMU dirver) to grantee that when issuing IOTLB flush command for large page, we will still meet the hardware limitation of flushing large page. Seems for Intel IOMMU the only limitation is the mask value (indicating number of 4k-pages) cannot be smaller than the value to cover large page, and seems current Intel IOMMU driver code has covered this case well. I am not familiar with how AMD IOMMU issues IOTLB flush command, it should be able to handle this large page case too. So at this moment, this patch should not have any issues :) -cody Joerg -- 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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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 similar logic in IOTLB flush code (such as in Intel IOMMU dirver) to grantee that when issuing IOTLB flush command for large page, we will still meet the hardware limitation of flushing large page. Seems for Intel IOMMU the only limitation is the mask value (indicating number of 4k-pages) cannot be smaller than the value to cover large page, and seems current Intel IOMMU driver code has covered this case well. I am not familiar with how AMD IOMMU issues IOTLB flush command, it should be able to handle this large page case too. So at this moment, this patch should not have any issues :) The map-operation actually takes a size, as it should. The idea is to change this function to a map_page interface which takes a page-size parameter, but thats another story. The IOTLB flushing is not exposed by the IOMMU-API anyway. To whatever is necessary to do that, it is the business of the IOMMU driver. So in the unmap-path the driver finds out the page-size to unmap and can immediatly flush the IOTLB for that page. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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
[PATCH] OMAP4: ID: Chip detection for OMAP4470
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 Iziumtsev x0153...@ti.com
---
arch/arm/mach-omap2/id.c | 10 +-
arch/arm/plat-omap/include/plat/cpu.h |8
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 7f47092..c8667c0 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -367,7 +367,7 @@ static void __init omap4_check_revision(void)
* Few initial 4430 ES2.0 samples IDCODE is same as ES1.0
* Use ARM register to detect the correct ES version
*/
- if (!rev (hawkeye != 0xb94e)) {
+ if (!rev (hawkeye != 0xb94e) (hawkeye != 0xb975)) {
idcode = read_cpuid(CPUID_ID);
rev = (idcode 0xf) - 1;
}
@@ -401,6 +401,14 @@ static void __init omap4_check_revision(void)
break;
}
break;
+ case 0xb975:
+ switch (rev) {
+ case 0:
+ default:
+ omap_revision = OMAP4470_REV_ES1_0;
+ break;
+ }
+ break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP4430_REV_ES2_2;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index aa52d1e..d99b3be 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -69,6 +69,7 @@ unsigned int omap_rev(void);
* cpu_is_omap343x(): True for OMAP3430
* cpu_is_omap443x(): True for OMAP4430
* cpu_is_omap446x(): True for OMAP4460
+ * cpu_is_omap447x(): True for OMAP4470
*/
#define GET_OMAP_CLASS (omap_rev() 0xff)
@@ -120,6 +121,7 @@ IS_OMAP_SUBCLASS(343x, 0x343)
IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
IS_OMAP_SUBCLASS(446x, 0x446)
+IS_OMAP_SUBCLASS(447x, 0x447)
IS_TI_SUBCLASS(816x, 0x816)
IS_AM_SUBCLASS(335x, 0x335)
@@ -138,6 +140,7 @@ IS_AM_SUBCLASS(335x, 0x335)
#define cpu_is_omap44xx() 0
#define cpu_is_omap443x() 0
#define cpu_is_omap446x() 0
+#define cpu_is_omap447x() 0
#if defined(MULTI_OMAP1)
# if defined(CONFIG_ARCH_OMAP730)
@@ -368,9 +371,11 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap44xx
# undef cpu_is_omap443x
# undef cpu_is_omap446x
+# undef cpu_is_omap447x
# define cpu_is_omap44xx() is_omap44xx()
# define cpu_is_omap443x() is_omap443x()
# define cpu_is_omap446x() is_omap446x()
+# define cpu_is_omap447x() is_omap447x()
# endif
/* Macros to detect if we have OMAP1 or OMAP2 */
@@ -420,6 +425,9 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP446X_CLASS 0x44600044
#define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8))
+#define OMAP447X_CLASS 0x44700044
+#define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 8))
+
void omap2_check_revision(void);
/*
--
1.7.1
--
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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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 it does not say we need to exactly match the page size as it is mapped. I guess it's not necessary for Intel IOMMU, but other vendor's IOMMU may have such limitation (or some other limitations). In my understanding current implementation does not provide page size information for particular DVMA ranges that has been mapped, and it's not flexible to implement IOTLB flush code (ex, we may need to walk through page table to find out actual page size). Maybe we can also add iommu_ops-flush_iotlb ? Which brings me to another question I have been pondering... do we even have a consensus on exactly *when* the IOTLB should be flushed? Even just for the Intel IOMMU, we have three different behaviours: - For DMA API users by default, we do 'batched unmap', so a mapping may be active for a period of time after the driver has requested that it be unmapped. - ... unless booted with 'intel_iommu=strict', in which case we do the unmap and IOTLB flush immediately before returning to the driver. - But the IOMMU API for virtualisation is different. In fact that doesn't seem to flush the IOTLB at all. Which is probably a bug. What is acceptable, though? That batched unmap is quite important for performance, because it means that we don't have to bash on the hardware and wait for a flush to complete in the fast path of network driver RX, for example. If we move to a model where we have a separate -flush_iotlb() call, we need to be careful that we still allow necessary optimisations to happen. Since I have the right people on Cc and the iommu list is still down, and it's vaguely tangentially related... I'm looking at fixing performance issues in the Intel IOMMU code, with its virtual address space allocation (the rbtree-based one in iova.c that nobody else uses, which has a single spinlock that *all* CPUs bash on when they need to allocate). The plan is, vaguely, to allocate large chunks of space to each CPU, and then for each CPU to allocate from its own region first, thus ensuring that the common case doesn't bounce locks between CPUs. It'll be rare for one CPU to have to touch a subregion 'belonging' to another CPU, so lock contention should be drastically reduced. Should I be planning to drop the DMA API support from intel-iommu.c completely, and have the new allocator just call into the IOMMU API functions instead? Other people have been looking at that, haven't they? Is there any code? Or special platform-specific requirements for such a generic wrapper that I might not have thought of? Details about when to flush the IOTLB are one such thing which might need special handling for certain hardware... -- dwmw2 -- 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
Re: Which toolchain are we using?
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 consistently all the time. Before trying to investigate further, wanted to know if someone else has seen the problem. If no, which toolchain is being used. Sanjeev: I've seen this behavior with kernels as far back as 2.6.32. The solutions explored in discussions on the Web seem to be around soft- vs. hardware alignment exception handling. Mentor is aware of the issue but has no specific recommendations at this time. Best, Grant -- 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
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
+ 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 Yanokya...@emcraft.com --- arch/arm/boot/dts/am35xx.dtsi | 15 +++ arch/arm/boot/dts/om3xxx.dtsi | 28 arch/arm/boot/dts/omap3-beagle.dts |2 +- arch/arm/boot/dts/omap3.dtsi |9 - 4 files changed, 44 insertions(+), 10 deletions(-) create mode 100644 arch/arm/boot/dts/am35xx.dtsi create mode 100644 arch/arm/boot/dts/om3xxx.dtsi om3xxx name is confusing - I haven't seen this name in any documentation/code before... Am I missing something? What do you think of omap3-iva.dtsi or omap3-dsp.dtsi? Cannot we avoid at all hacking the original file and use instead the status = disabled field for any variant that will not have the functionality? It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file. Regards, Benoit -- 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
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
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 AM35xx. Signed-off-by: Ilya Yanokya...@emcraft.com --- arch/arm/boot/dts/am35xx.dtsi | 15 +++ arch/arm/boot/dts/om3xxx.dtsi | 28 arch/arm/boot/dts/omap3-beagle.dts |2 +- arch/arm/boot/dts/omap3.dtsi |9 - 4 files changed, 44 insertions(+), 10 deletions(-) create mode 100644 arch/arm/boot/dts/am35xx.dtsi create mode 100644 arch/arm/boot/dts/om3xxx.dtsi om3xxx name is confusing - I haven't seen this name in any documentation/code before... Am I missing something? What do you think of omap3-iva.dtsi or omap3-dsp.dtsi? Cannot we avoid at all hacking the original file and use instead the status = disabled field for any variant that will not have the functionality? This might be an option. What I thought of is splitting the original file into atomic (none splittable) parts and each OMAP variant will include the ones it has. This way you have all the features available and can make any mixture of them (which, probably will reflect the hardware best ;-)) It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file. it will be a nightmare anyway ;-) I don't really know what can make it a less scary nightmare. -- Regards, Igor. -- 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
Re: [PATCH] ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
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 you want a refreshed version against 3.2-rc1.
Current version is fine.
Kevin
--
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
[PATCH-V4 1/3] arm:omap:am33xx: Update common OMAP machine specific sources
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 related comment (from KevinH) has been handled by removing the
check for cpu_is_am33xx, as mentioned in thread, for am33xx dpll5 doesn't
come into execution path.
And Soon I will be submitting clock/power/voltage/hwmod related patches for
review.
arch/arm/mach-omap2/clock3xxx_data.c |3 +++
arch/arm/mach-omap2/common.c | 21 +
arch/arm/mach-omap2/id.c |6 ++
arch/arm/mach-omap2/io.c | 24
arch/arm/mach-omap2/serial.c |4 ++--
arch/arm/plat-omap/include/plat/am33xx.h | 25 +
arch/arm/plat-omap/include/plat/common.h |2 ++
arch/arm/plat-omap/include/plat/hardware.h |1 +
arch/arm/plat-omap/include/plat/io.h | 20
arch/arm/plat-omap/include/plat/omap34xx.h |2 ++
arch/arm/plat-omap/io.c|5 +
11 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 5d0064a..c1ab6bc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3517,6 +3517,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_ti816x()) {
cpu_mask = RATE_IN_TI816X;
cpu_clkflg = CK_TI816X;
+ } else if (cpu_is_am33xx()) {
+ cpu_mask = RATE_IN_AM33XX;
+ cpu_clkflg = CK_AM33XX;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 110e5b9..16bac26 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -128,6 +128,27 @@ void __init omap2_set_globals_ti816x(void)
{
__omap2_set_globals(ti816x_globals);
}
+
+#define AM33XX_TAP_BASE(AM33XX_CTRL_BASE + \
+ TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals am33xx_globals = {
+ .class = AM335X_CLASS,
+ .tap= AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE),
+ .ctrl = AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+ .prm= AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+ .cm = AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+};
+
+void __init omap2_set_globals_am33xx(void)
+{
+ __omap2_set_globals(am33xx_globals);
+}
+
+void __init am33xx_map_io(void)
+{
+ omapam33xx_map_common_io();
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f1784ee..37fe42f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -340,6 +340,10 @@ static void __init omap3_check_revision(const char
**cpu_rev)
break;
}
break;
+ case 0xb944:
+ omap_revision = AM335X_REV_ES1_0;
+ *cpu_rev = 1.0;
+ break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
@@ -432,6 +436,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
cpu_name = (omap3_has_sgx()) ? AM3517 : AM3505;
} else if (cpu_is_ti816x()) {
cpu_name = TI816X;
+ } else if (cpu_is_am335x()) {
+ cpu_name = AM335X;
} else if (omap3_has_iva() omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
cpu_name = OMAP3430/3530;
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index da9bc4a..74e84c6 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -183,7 +183,24 @@ static struct map_desc omapti816x_io_desc[] __initdata = {
.pfn= __phys_to_pfn(L4_34XX_PHYS),
.length = L4_34XX_SIZE,
.type = MT_DEVICE
+ }
+};
+#endif
+
+#ifdef CONFIG_SOC_OMAPAM33XX
+static struct map_desc omapam33xx_io_desc[] __initdata = {
+ {
+ .virtual= L4_34XX_VIRT,
+ .pfn= __phys_to_pfn(L4_34XX_PHYS),
+ .length = L4_34XX_SIZE,
+ .type = MT_DEVICE
},
+ {
+ .virtual= L4_WK_AM33XX_VIRT,
+ .pfn= __phys_to_pfn(L4_WK_AM33XX_PHYS),
+ .length = L4_WK_AM33XX_SIZE,
+ .type = MT_DEVICE
+ }
};
#endif
@@ -270,6 +287,13 @@ void
[PATCH-V4 0/3] Introducing TI's New SoC/board AM335XEVM
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 added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks return success for AM335X. Also, I have validated OMAP3 boot test with this patch-series on OMAP3EVM. Changes from V3: - Common platform patch has already been accepted and available under linux-omap/soc and linux-omap/master branch. - Clean-up where cpu_is_ instances are being used and patches has been submitted to the list. - These patches have been created on top of cleanup patches - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58276.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58277.html - Based on Tony's request, rebased patches against linux-omap/fixes (+ common platform patch). Changes from V2(RFC): - Rebased against Paul's OMAP_CHIP* cleanup patches git://git.pwsan.com/linux-2.6_omap_chip_remove_cleanup_3.2 Changes from V1(RFC): - Created separate cpu/SoC class for AM33XX family of devices, due to all known facts. This is been mentioned in main-chain https://patchwork.kernel.org/patch/1056312/ - BUG Fix in debug-macro.S, which was leading to build failure. https://patchwork.kernel.org/patch/1056302/ Afzal Mohammed (3): arm:omap:am33xx: Update common OMAP machine specific sources arm:omap:am33xx: Add AM335XEVM machine support arm:omap:am33xx: Add low level debugging support arch/arm/mach-omap2/Kconfig|5 arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-am3517evm.c | 21 arch/arm/mach-omap2/clock3xxx_data.c |3 ++ arch/arm/mach-omap2/common.c | 21 arch/arm/mach-omap2/id.c |6 arch/arm/mach-omap2/include/mach/debug-macro.S | 17 - arch/arm/mach-omap2/io.c | 31 arch/arm/mach-omap2/serial.c |4 +- arch/arm/mach-omap2/timer.c|2 + arch/arm/plat-omap/include/plat/am33xx.h | 25 +++ arch/arm/plat-omap/include/plat/common.h |4 +++ arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/io.h | 20 +++ arch/arm/plat-omap/include/plat/omap34xx.h |2 + arch/arm/plat-omap/include/plat/serial.h |4 +++ arch/arm/plat-omap/include/plat/uncompress.h |6 arch/arm/plat-omap/io.c|5 18 files changed, 175 insertions(+), 3 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h -- 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
[PATCH-V4 2/3] arm:omap:am33xx: Add AM335XEVM machine support
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: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-am3517evm.c| 21 +
arch/arm/mach-omap2/io.c |7 +++
arch/arm/mach-omap2/timer.c |2 ++
arch/arm/plat-omap/include/plat/common.h |2 ++
6 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c3d530b..2ef39c2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -326,6 +326,11 @@ config MACH_TI8168EVM
depends on SOC_OMAPTI816X
default y
+config MACH_AM335XEVM
+ bool AM335X Evaluation Module
+ depends on SOC_OMAPAM33XX
+ default y
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 14cd2fd..b33a85f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -233,6 +233,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=
board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM) += board-am3517evm.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index f7df8d3..090457f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -516,3 +516,24 @@ MACHINE_START(OMAP3517EVM, OMAP3517/AM3517 EVM)
.init_machine = am3517_evm_init,
.timer = omap3_timer,
MACHINE_END
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+ omap_serial_init();
+ omap_sdrc_init(NULL, NULL);
+ omap_board_config = am335x_evm_config;
+ omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+MACHINE_START(AM335XEVM, am335xevm)
+ /* Maintainer: Texas Instruments */
+ .atag_offset= 0x100,
+ .map_io = am33xx_map_io,
+ .init_early = am33xx_init_early,
+ .init_irq = ti816x_init_irq,
+ .timer = omap3_am33xx_timer,
+ .init_machine = am335x_evm_init,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 74e84c6..6f03cc1 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -477,6 +477,13 @@ void __init omap4430_init_early(void)
}
#endif
+void __init am33xx_init_early(void)
+{
+ omap2_set_globals_am33xx();
+ omap_common_init_early();
+ omap3xxx_clk_init();
+}
+
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 037b0d7..7b29197 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -333,6 +333,8 @@ OMAP_SYS_TIMER(3)
OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
2, OMAP3_MPU_SOURCE)
OMAP_SYS_TIMER(3_secure)
+OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(3_am33xx)
#endif
#ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index b83818d..87bd3e2 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -38,6 +38,7 @@ extern struct sys_timer omap1_timer;
extern struct sys_timer omap2_timer;
extern struct sys_timer omap3_timer;
extern struct sys_timer omap3_secure_timer;
+extern struct sys_timer omap3_am33xx_timer;
extern struct sys_timer omap4_timer;
extern bool omap_32k_timer_init(void);
extern int __init omap_init_clocksource_32k(void);
@@ -54,6 +55,7 @@ void omap3_init_early(void); /* Do not use this one */
void am35xx_init_early(void);
void ti816x_init_early(void);
void omap4430_init_early(void);
+void am33xx_init_early(void);
void omap_sram_init(void);
--
1.7.0.4
--
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
[PATCH-V4 3/3] arm:omap:am33xx: Add low level debugging support
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
---
arch/arm/mach-omap2/include/mach/debug-macro.S | 17 -
arch/arm/plat-omap/include/plat/serial.h |4
arch/arm/plat-omap/include/plat/uncompress.h |6 ++
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 13f98e5..ce543ae 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -72,6 +72,8 @@ omap_uart_lsr:.word 0
beq 82f @ configure UART2
cmp \rp, #TI816XUART3 @ ti816x UART offsets different
beq 83f @ configure UART3
+ cmp \rp, #AM33XXUART1 @ AM33XX UART offsets different
+ beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART
@@ -100,7 +102,9 @@ omap_uart_lsr: .word 0
b 98f
83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
b 98f
-
+84:ldr \rp, =AM33XX_UART1_BASE
+ and \rp, \rp, #0x00ff
+ b 97f
95:ldr \rp, =ZOOM_UART_BASE
str \rp, [\tmp, #0] @ omap_uart_phys
ldr \rp, =ZOOM_UART_VIRT
@@ -110,6 +114,17 @@ omap_uart_lsr: .word 0
b 10b
/* Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400 @ phys base
+ str \rp, [\tmp, #0] @ omap_uart_phys
+ sub \rp, \rp, #0x4400 @ phys base
+ add \rp, \rp, #0xf900 @ virt base
+ str \rp, [\tmp, #4] @ omap_uart_virt
+ mov \rp, #(UART_LSR OMAP_PORT_SHIFT)
+ str \rp, [\tmp, #8] @ omap_uart_lsr
+
+ b 10b
+
+ /* Store both phys and virt address for the uart */
98:add \rp, \rp, #0x4800 @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
sub \rp, \rp, #0x4800 @ phys base
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index 1ab9fd6..e988c92 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
/* AM3505/3517 UART4 */
#define AM35XX_UART4_BASE 0x4809E000 /* Only on AM3505/3517 */
+/* AM33XX serial port */
+#define AM33XX_UART1_BASE 0x44E09000
+
/* External port on Zoom2/3 */
#define ZOOM_UART_BASE 0x1000
#define ZOOM_UART_VIRT 0xfa40
@@ -92,6 +95,7 @@
#define TI816XUART181
#define TI816XUART282
#define TI816XUART383
+#define AM33XXUART184
#define ZOOM_UART 95 /* Only on zoom2/3 */
/* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
b/arch/arm/plat-omap/include/plat/uncompress.h
index 2d45ea3..ff59570 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -103,6 +103,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT, \
TI816XUART##p)
+#define DEBUG_LL_AM33XX(p, mach) \
+ _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT, \
+ AM33XXUART##p)
+
static inline void __arch_decomp_setup(unsigned long arch_id)
{
int port = 0;
@@ -181,6 +185,8 @@ static inline void __arch_decomp_setup(unsigned long
arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI816X(3, ti8168evm);
+ /* AM33XX base boards using UART1 */
+ DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
}
--
1.7.0.4
--
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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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 IOMMU-API. Even just for the Intel IOMMU, we have three different behaviours: - For DMA API users by default, we do 'batched unmap', so a mapping may be active for a period of time after the driver has requested that it be unmapped. 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' on the Intel IOMMU driver side. The AMD IOMMU driver uses a round-robin bitmap allocator for the IO addresses which makes it very easy to flush certain IOTLB ranges only before they are reused. - ... unless booted with 'intel_iommu=strict', in which case we do the unmap and IOTLB flush immediately before returning to the driver. There is something similar on the AMD IOMMU side. There it is called unmap_flush. - But the IOMMU API for virtualisation is different. In fact that doesn't seem to flush the IOTLB at all. Which is probably a bug. Well, *current* requirement is, that the IOTLB is in sync with the page-table at every time. This is true for the iommu_map and especially for the iommu_unmap function. It means basically that the unmapped area needs to be flushed out of the IOTLBs before iommu_unmap returns. Some time ago I proposed the iommu_commit() interface which changes these requirements. With this interface the requirement is that after a couple of map/unmap operations the IOMMU-API user has to call iommu_commit() to make these changes visible to the hardware (so mostly sync the IOTLBs). As discussed at that time this would make sense for the Intel and AMD IOMMU drivers. What is acceptable, though? That batched unmap is quite important for performance, because it means that we don't have to bash on the hardware and wait for a flush to complete in the fast path of network driver RX, for example. Have you considered a round-robin bitmap-allocator? It allows quite nice flushing behavior. If we move to a model where we have a separate -flush_iotlb() call, we need to be careful that we still allow necessary optimisations to happen. With iommu_commit() this should be possible, still. I'm looking at fixing performance issues in the Intel IOMMU code, with its virtual address space allocation (the rbtree-based one in iova.c that nobody else uses, which has a single spinlock that *all* CPUs bash on when they need to allocate). The plan is, vaguely, to allocate large chunks of space to each CPU, and then for each CPU to allocate from its own region first, thus ensuring that the common case doesn't bounce locks between CPUs. It'll be rare for one CPU to have to touch a subregion 'belonging' to another CPU, so lock contention should be drastically reduced. Thats an interesting issue. It exists on the AMD IOMMU side too, the bitmap-allocator runs in a per-domain spinlock which can get high contention. I am not sure how per-cpu chunks of the address space scale to large numbers of cpus, though, given that some devices only have a small address range that they can address. I have been thinking about some lockless algorithms for the bitmap-allocator. But the ideas are not finalized yet, so I still don't know if they will work out at all :) The basic idea builds around the fact, that most allocations using the DMA-API fit into one page. So probably we can split the address-space into a region for one-page allocations which can be accessed without locks and another region for larger allocations which still need locks. Should I be planning to drop the DMA API support from intel-iommu.c completely, and have the new allocator just call into the IOMMU API functions instead? Other people have been looking at that, haven't they? Yes, Marek Szyprowski from the ARM side is looking into this already, but his patches are very ARM specific and not suitable for x86 yet. Is there any code? Or special platform-specific requirements for such a generic wrapper that I might not have thought of? Details about when to flush the IOTLB are one such thing which might need special handling for certain hardware... 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 discuss if you want. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
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 now the only difference is missing IVA node on AM35xx. Signed-off-by: Ilya Yanokya...@emcraft.com --- arch/arm/boot/dts/am35xx.dtsi | 15 +++ arch/arm/boot/dts/om3xxx.dtsi | 28 arch/arm/boot/dts/omap3-beagle.dts |2 +- arch/arm/boot/dts/omap3.dtsi |9 - 4 files changed, 44 insertions(+), 10 deletions(-) create mode 100644 arch/arm/boot/dts/am35xx.dtsi create mode 100644 arch/arm/boot/dts/om3xxx.dtsi om3xxx name is confusing - I haven't seen this name in any documentation/code before... Am I missing something? What do you think of omap3-iva.dtsi or omap3-dsp.dtsi? Cannot we avoid at all hacking the original file and use instead the status = disabled field for any variant that will not have the functionality? This might be an option. What I thought of is splitting the original file into atomic (none splittable) parts and each OMAP variant will include the ones it has. This way you have all the features available and can make any mixture of them (which, probably will reflect the hardware best ;-)) Yeah, but it will be less readable for my point of view. You will add another level of include hierarchy. The point is that each time some new variants will come with less and less feature, we will keep de-populating the original file. My other concern is that all these variants are handled by different people for different products. So by having dedicated file for each variant, each owner can handle its own stuff without messing up the original file. Considering that this omap3.dtsi file is under construction, we can expect a bunch a dirty merge conflicts if different people from different organization start adding / removing nodes at the same time. We already faced that kind of nightmare for our existing clock / hwmod static data files. So if we can avoid it with DT files, it will be cool. It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file. it will be a nightmare anyway ;-) Indeed, the best is to avoid any variant :-) I don't really know what can make it a less scary nightmare. For my point of view, since I will have to keep hacking on that omap3.dtsi, having some separate variant files that does not have to touch this file will be much better. If all these variants were already there and well defined, we might have then decided to re-organized that by starting from a common subset. But since everything is moving at the same time and with an unknown target, we should minimize hacking any common file under construction. Regards, Benoit -- 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
Re: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present
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 [...] I have been out-of-loop from PM for some time. So my query may be redundant: 1) What happens when different PMIC (not TWL series) is registered for AM35x? e.g. TPS65023 http://www.spinics.net/lists/linux-omap/msg48630.html 2) Wouldn't we still fall back into omap3_twl_init()? I'm not sure I follow the question. If you're not using a TWL PMIC (or similar derivative) then omap*_twl_init() should not be called. If you are using a TWL PMIC, then no, the omap*_twl_init functions should not be called. Kevin -- 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
Re: [PATCH] omap-serial: add RS485 mode support
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] http://marc.info/?l=linux-omapm=131914563820506w=2 -- 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
Re: [RFC][PATCH] gpiolib: add irq_wake (power-management) sysfs file
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 patch creates a new sysfs file /sys/class/gpio/gpioN/irq_wake to enable usermode application to set the wake properties of a gpio IRQ. This option can be set or not for each gpio to preserve power consumption (e.g embedded systems). Signed-off-by: Hugo Dupras h-dup...@ti.com Signed-off-by: Patrick Combes p-com...@ti.com Hello, This is a change to the GPIO core but you only have the OMAP-specific list here. Please send this to the GPIO maintainer[1] and the lists. Also, please copy linux-arm-ker...@lists.infradead.org where there are lots of GPIOlib users who might be interested in this, and also copy LKML (linux-ker...@vger.kernel.org) Thanks, Kevin P.S. David Brownell passed away earlier this year, so I removed his email from the to list: http://lkml.org/lkml/2011/6/6/32 [1] excerpt from MAINTAINERS file GPIO SUBSYSTEM M: Grant Likely grant.lik...@secretlab.ca S: Maintained T: git git://git.secretlab.ca/git/linux-2.6.git F: Documentation/gpio.txt F: drivers/gpio/ F: include/linux/gpio* -- 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
Re: [PATCH v7 17/21] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
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 between MPU and CORE, this constraint isn't actually needed for CORE UARTs, so it's a bit wasteful to go through all the constraint setting for no reason. I had a short chat with Govind on this and was trying to understand this better. Are you referring to the 'autodeps' for omap3 here, because they would prevent any clock domain from idling as long as MPU or IVA are active, No, I was thinking of HW sleepdeps. However, I looked back at the OMAP3430 TRM and see that MPU does not have a HW sleepdep on CORE like I thought. but not the other way round. Which means MPU can still idle, while CORE does not. My guess was, its probably the CORE domain idling itself thats causing the UART sluggishness, (and not MPU idling), due to higher latency, which is prevented with an active UART module in CORE, but not in PER. OK, that indeed makes sense. Thanks for correcting me. So Govind did a small experiment to prevent just CORE idling and let MPU idle alone and that did not show any sluggishness. OK, good. Now, putting a pm-qos constraint for a UART in CORE still looks redundant because the latency requirement that UART has is in some way *indirectly* met (because the active UART in CORE prevents CORE transitions in idle). But don't you think the UART driver should express its latency constraints regardless, without thinking of any indirect ways in which the same requirements would have already been met? Yes, you're right. The driver should not need to know which powerdomain a given UART is in. It's probably best (and most portable) to have UART always express its requirements all the time. Thanks for digging into this, I have fixed this and other uart_v7 comments and have re-based the patch series on top of 3.2-rc1 along with Tero's v9 irq chaining patches and tested the same. Available here [1]. Please repost your updated series. Can this patches series be added to a test branch for upstreaming or do you think there are still some outstanding comments that needs to be discussed? The PRCM IRQ chaining series is not yet finalized. Kevin -- 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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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' on the Intel IOMMU driver side. The AMD IOMMU driver uses a round-robin bitmap allocator for the IO addresses which makes it very easy to flush certain IOTLB ranges only before they are reused. ... which implies that a mapping, once made, might *never* actually get torn down until we loop and start reusing address space? That has interesting security implications. Is it true even for devices which have been assigned to a VM and then unassigned? - ... unless booted with 'intel_iommu=strict', in which case we do the unmap and IOTLB flush immediately before returning to the driver. There is something similar on the AMD IOMMU side. There it is called unmap_flush. OK, so that definitely wants consolidating into a generic option. - But the IOMMU API for virtualisation is different. In fact that doesn't seem to flush the IOTLB at all. Which is probably a bug. Well, *current* requirement is, that the IOTLB is in sync with the page-table at every time. This is true for the iommu_map and especially for the iommu_unmap function. It means basically that the unmapped area needs to be flushed out of the IOTLBs before iommu_unmap returns. Some time ago I proposed the iommu_commit() interface which changes these requirements. With this interface the requirement is that after a couple of map/unmap operations the IOMMU-API user has to call iommu_commit() to make these changes visible to the hardware (so mostly sync the IOTLBs). As discussed at that time this would make sense for the Intel and AMD IOMMU drivers. I would *really* want to keep those off the fast path (thinking mostly about DMA API here, since that's the performance issue). But as long as we can achieve that, that's fine. What is acceptable, though? That batched unmap is quite important for performance, because it means that we don't have to bash on the hardware and wait for a flush to complete in the fast path of network driver RX, for example. Have you considered a round-robin bitmap-allocator? It allows quite nice flushing behavior. Yeah, I was just looking through the AMD code with a view to doing something similar. I was thinking of using that technique *within* each larger range allocated from the whole address space. If we move to a model where we have a separate -flush_iotlb() call, we need to be careful that we still allow necessary optimisations to happen. With iommu_commit() this should be possible, still. I'm looking at fixing performance issues in the Intel IOMMU code, with its virtual address space allocation (the rbtree-based one in iova.c that nobody else uses, which has a single spinlock that *all* CPUs bash on when they need to allocate). The plan is, vaguely, to allocate large chunks of space to each CPU, and then for each CPU to allocate from its own region first, thus ensuring that the common case doesn't bounce locks between CPUs. It'll be rare for one CPU to have to touch a subregion 'belonging' to another CPU, so lock contention should be drastically reduced. Thats an interesting issue. It exists on the AMD IOMMU side too, the bitmap-allocator runs in a per-domain spinlock which can get high contention. I am not sure how per-cpu chunks of the address space scale to large numbers of cpus, though, given that some devices only have a small address range that they can address. I don't care about performance of broken hardware. If we have a single *global* subrange for the 4GiB range of address space, that's absolutely fine by me. But also, it's not *so* much of an issue to divide the space up even when it's limited. The idea was not to have it *strictly* per-CPU, but just for a CPU to try allocating from its own subrange first, and then fall back to allocating a new subrange, and *then* fall back to allocating from subranges belonging to other CPUs. It's not that the allocation from a subrange would be lockless — it's that the lock would almost never leave the l1 cache of the CPU that *normally* uses that subrange. With batched unmaps, the CPU doing the unmap may end up taking the lock occasionally, and bounce cache lines then. But it's infrequent enough that it shouldn't be a performance problem. I have been thinking about some lockless algorithms for the bitmap-allocator. But the ideas are not finalized yet, so I still don't know if they will work out at all :) As explained above, I wasn't going for lockless. I was going for lock-contention-less. Or at least mostly :) Do you think that approach sounds reasonable? 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
[PATCH] ARM: OMAP: Fix dpll_data compile error when omap2 only is selected
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 a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 197ca03..eb73ab4 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -165,8 +165,8 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
- u8 flags;
# endif
+ u8 flags;
};
#endif
--
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
[PATCH] ARM: OMAP: Introduce local common.h files
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 t...@atomide.com diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index 51bae31..1b37400 100644 --- Here's a patch that fixes the locality issues for MACHINE_START/END functions at least. --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -35,7 +35,7 @@ #include plat/mux.h #include plat/usb.h #include plat/board.h -#include plat/common.h +#include common.h #include mach/camera.h #include mach/ams-delta-fiq.h diff --git a/arch/arm/mach-omap1/board-fsample.c b/arch/arm/mach-omap1/board-fsample.c index 2317827..b9c4c0f 100644 --- a/arch/arm/mach-omap1/board-fsample.c +++ b/arch/arm/mach-omap1/board-fsample.c @@ -32,7 +32,7 @@ #include plat/flash.h #include plat/fpga.h #include plat/keypad.h -#include plat/common.h +#include common.h #include plat/board.h /* fsample is pretty close to p2-sample */ diff --git a/arch/arm/mach-omap1/board-generic.c b/arch/arm/mach-omap1/board-generic.c index dc5b75d..7f41d7a 100644 --- a/arch/arm/mach-omap1/board-generic.c +++ b/arch/arm/mach-omap1/board-generic.c @@ -25,7 +25,7 @@ #include plat/mux.h #include plat/usb.h #include plat/board.h -#include plat/common.h +#include common.h /* assume no Mini-AB port */ diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c index b334b14..7933b97 100644 --- a/arch/arm/mach-omap1/board-h2.c +++ b/arch/arm/mach-omap1/board-h2.c @@ -43,7 +43,7 @@ #include plat/irda.h #include plat/usb.h #include plat/keypad.h -#include plat/common.h +#include common.h #include plat/flash.h #include board-h2.h diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c index 74ebe72..04be2f8 100644 --- a/arch/arm/mach-omap1/board-h3.c +++ b/arch/arm/mach-omap1/board-h3.c @@ -45,7 +45,7 @@ #include plat/usb.h #include plat/keypad.h #include plat/dma.h -#include plat/common.h +#include common.h #include plat/flash.h #include board-h3.h diff --git a/arch/arm/mach-omap1/board-htcherald.c b/arch/arm/mach-omap1/board-htcherald.c index 3e91baa..46fcfeb 100644 --- a/arch/arm/mach-omap1/board-htcherald.c +++ b/arch/arm/mach-omap1/board-htcherald.c @@ -41,7 +41,7 @@ #include asm/mach/arch.h #include plat/omap7xx.h -#include plat/common.h +#include common.h #include plat/board.h #include plat/keypad.h #include plat/usb.h diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c index 273153d..f99d11d 100644 --- a/arch/arm/mach-omap1/board-innovator.c +++ b/arch/arm/mach-omap1/board-innovator.c @@ -37,7 +37,7 @@ #include plat/tc.h #include plat/usb.h #include plat/keypad.h -#include plat/common.h +#include common.h #include plat/mmc.h /* At OMAP1610 Innovator the Ethernet is directly connected to CS1 */ diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index 6798b84..c643423 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -30,7 +30,7 @@ #include plat/usb.h #include plat/board.h #include plat/keypad.h -#include plat/common.h +#include common.h #include plat/hwa742.h #include plat/lcd_mipid.h #include plat/mmc.h diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c index c385927..a409dfc 100644 --- a/arch/arm/mach-omap1/board-osk.c +++ b/arch/arm/mach-omap1/board-osk.c @@ -51,7 +51,7 @@ #include plat/usb.h #include plat/mux.h #include plat/tc.h -#include plat/common.h +#include common.h /* At OMAP5912 OSK the Ethernet is directly connected to CS1 */ #define OMAP_OSK_ETHR_START0x04800300 diff --git a/arch/arm/mach-omap1/board-palmte.c b/arch/arm/mach-omap1/board-palmte.c index f9c44cb..105292d 100644 --- a/arch/arm/mach-omap1/board-palmte.c +++ b/arch/arm/mach-omap1/board-palmte.c @@ -41,7 +41,7 @@ #include plat/board.h #include plat/irda.h #include plat/keypad.h -#include plat/common.h +#include common.h #define PALMTE_USBDETECT_GPIO 0 #define PALMTE_USB_OR_DC_GPIO 1 diff --git a/arch/arm/mach-omap1/board-palmtt.c b/arch/arm/mach-omap1/board-palmtt.c index 11a9853..387a900 100644 --- a/arch/arm/mach-omap1/board-palmtt.c +++ b/arch/arm/mach-omap1/board-palmtt.c @@ -39,7 +39,7 @@ #include plat/board.h #include plat/irda.h #include plat/keypad.h -#include plat/common.h +#include common.h #include linux/spi/spi.h #include linux/spi/ads7846.h diff --git a/arch/arm/mach-omap1/board-palmz71.c b/arch/arm/mach-omap1/board-palmz71.c index 4206157..df6d15e 100644 --- a/arch/arm/mach-omap1/board-palmz71.c +++ b/arch/arm/mach-omap1/board-palmz71.c @@ -41,7 +41,7 @@ #include plat/board.h #include plat/irda.h #include plat/keypad.h
Re: [PATCH] ARM: OMAP: Introduce local common.h files
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 plat/common.h and mach/omap4-common.h. Signed-off-by: Tony Lindgren t...@atomide.com Great, looks fine, thanks. I suspect the chance of conflicts on this are about the same as the chance of conflicts with the rest of the restart series (in that, new platforms will need to be fixed for both these changes.) So, I suggest that I add it to my series so I can fix the OMAP changes there so stuff still builds - and then I can see about publishing a more stable branch in a couple of weeks for new platforms to base on. If you agree, could you put it in the patch system please? 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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
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 discuss if you want. I have been experimenting with an iommu_map_range call, which maps a given scatterlist of discontiguous physical pages into a contiguous virtual region at a given IOVA. This has some performance advantages over just calling iommu_map iteratively. First, it reduces the amount of table walking / calculation needed for mapping each page, given how you know that all the pages will be mapped into a single virtually-contiguous region (so in most cases, the first-level table calculation can be reused). Second, it allows one to defer the TLB (and sometimes cache) maintenance operations until the entire scatterlist has been mapped, rather than doing a TLB invalidate after mapping each page, as would have been the case if iommu_map were just being called from within a loop. Granted, just using iommu_map many times may be acceptable on the slow path, but I have seen significant performance gains when using this approach on the fast path. Steve -- 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
Re: [PATCH] ARM: OMAP: Introduce local common.h files
* 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 mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: Tony Lindgren t...@atomide.com Great, looks fine, thanks. I suspect the chance of conflicts on this are about the same as the chance of conflicts with the rest of the restart series (in that, new platforms will need to be fixed for both these changes.) So, I suggest that I add it to my series so I can fix the OMAP changes there so stuff still builds - and then I can see about publishing a more stable branch in a couple of weeks for new platforms to base on. OK, a stable branch is needed badly for this.. If possible please publish some minimal stable base branch as soon as you can as pretty much all omap patches need to be updated for this one. If you agree, could you put it in the patch system please? Thanks. Sounds good to me, it there now as patch 7159/1. Regards, Tony -- 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
Re: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
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 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 aaro.koski...@iki.fi Signed-off-by: Tony Lindgren t...@atomide.com --- Untested, does this help? --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -302,8 +302,6 @@ static void __init ams_delta_init(void) omap_cfg_reg(J19_1610_CAM_D6); omap_cfg_reg(J18_1610_CAM_D7); - iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); - This is definitely wrong. Using iotable_init() after map_io has returned has (and remains) a serious bug - doing so may _appear_ to work but as it doesn't obtain its memory from the standard kernel memory allocators, it will lead to duplicate usage of that memory. Also, the patch did not help. It still hangs like before. Hmm that patch is needed for sure but sounds like there's also something else wrong.. Can you try to git bisect it? I found it impossible to bisect, but there are two issues I found: 1) earlyconsole turns into garbage in omap1_clk_init() unless I do the following: diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c index 92400b9..b9ce2ad 100644 --- 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 - /* -* Resets some clocks that may be left on from bootloader, -* but leaves serial clocks on. -*/ - omap_writel(0x3 29, MOD_CONF_CTRL_0); -#endif - /* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ reg = omap_readw(SOFT_REQ_REG) (1 4); omap_writew(reg, SOFT_REQ_REG); 2) By using the above hack, I could see the actual crash: Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-rc1-e3 (aaro@dell) (gcc version 4.6.1 (GCC) ) #9 PREEMPT Thu Nov 10 23:48:23 EET 2011 [0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Amstrad E3 (Delta) [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writethrough [0.00] OMAP1510 [0.00] revision 2 handled as 15xx id: bc058c9b93111a16 [0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2cb3 ARM_CKCTL: 0x250e [0.00] [ cut here ] [0.00] kernel BUG at arch/arm/plat-omap/sram.c:226! [0.00] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.2.0-rc1-e3 #9) [0.00] PC is at omap_sram_reprogram_clock+0x28/0x30 [0.00] LR is at omap1_select_table_rate+0x88/0xb4 [0.00] pc : [c001b0c4]lr : [c0019f54]psr: 60d3 [0.00] sp : c035bf10 ip : c035bf20 fp : c035bf1c [0.00] r10: c035bfd4 r9 : 54029252 r8 : c03f8120 [0.00] r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40 [0.00] r3 : r2 : c0362b40 r1 : 010a r0 : 2cb0 [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 317f Table: 10004000 DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc035a270) [0.00] Stack: (0xc035bf10 to 0xc035c000) [0.00] bf00: c035bf3c c035bf20 c0019f54 c001b0ac [0.00] bf20: 1000 2cb3 0004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc [0.00] bf40: c02f526c 0002 0015 bc058c9b 93111a16 c035335c 0200 c035ed4c [0.00] bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88 [0.00] bf80: c033bc24 c00194a0 c035bf90 c035bf98 [0.00] bfa0: 0001 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8 [0.00] bfc0: c0338574 c033b598 c035467c 317d c035c03c [0.00] bfe0: c0354678 c035ece4 c035bff8 10008040 c0338508 [0.00] Backtrace: [0.00] [c001b09c] (omap_sram_reprogram_clock+0x0/0x30) from [c0019f54] (omap1_select_table_rate+0x88/0xb4) [0.00] [c0019ecc] (omap1_select_table_rate+0x0/0xb4) from [c033ea24] (omap1_clk_init+0x148/0x334) [0.00] r7:c035ed4c r6:0004 r5:2cb3 r4:1000 [0.00] [c033e8dc]
Re: [PATCH] ARM: OMAP: Introduce local common.h files
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 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 t...@atomide.com Great, looks fine, thanks. I suspect the chance of conflicts on this are about the same as the chance of conflicts with the rest of the restart series (in that, new platforms will need to be fixed for both these changes.) So, I suggest that I add it to my series so I can fix the OMAP changes there so stuff still builds - and then I can see about publishing a more stable branch in a couple of weeks for new platforms to base on. OK, a stable branch is needed badly for this.. If possible please publish some minimal stable base branch as soon as you can as pretty much all omap patches need to be updated for this one. I want to give it something between a week and two before closing the window for acked-bys etc (amongst other reasons). If you agree, could you put it in the patch system please? Thanks. Sounds good to me, it there now as patch 7159/1. Thanks, merged that into the series. The updated OMAP patch updated is below, which has been moved to part 2. Lastly, the final patch of part 2 has been updated to delete the empty arch_reset(), so OMAP is now entirely free of arch_reset() references. This leaves a total of 12 references left to nobble. 8--- From: Russell King - ARM Linux li...@arm.linux.org.uk Subject: [PATCH] ARM: restart: omap: use new restart hook Hook these platforms restart code into the new restart hook rather than using arch_reset(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-omap1/board-ams-delta.c |1 + arch/arm/mach-omap1/board-fsample.c|1 + arch/arm/mach-omap1/board-generic.c|1 + arch/arm/mach-omap1/board-h2.c |1 + arch/arm/mach-omap1/board-h3.c |1 + arch/arm/mach-omap1/board-htcherald.c |1 + arch/arm/mach-omap1/board-innovator.c |1 + arch/arm/mach-omap1/board-nokia770.c |1 + arch/arm/mach-omap1/board-osk.c|1 + arch/arm/mach-omap1/board-palmte.c |1 + arch/arm/mach-omap1/board-palmtt.c |1 + arch/arm/mach-omap1/board-palmz71.c|1 + arch/arm/mach-omap1/board-perseus2.c |1 + arch/arm/mach-omap1/board-sx1.c|1 + arch/arm/mach-omap1/board-voiceblue.c |5 ++--- arch/arm/mach-omap1/common.h |1 + arch/arm/mach-omap1/reset.c|4 +--- arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|1 + arch/arm/mach-omap2/board-am3517crane.c|1 + arch/arm/mach-omap2/board-am3517evm.c |1 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-cm-t3517.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-generic.c|4 arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |3 +++ arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |1 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |1 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rm680.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-ti8168evm.c |1 + arch/arm/mach-omap2/board-zoom.c |2 ++ arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/prcm.c |4 +--- arch/arm/plat-omap/include/plat/system.h |4 +++- 47 files changed, 59 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index 1b37400..2120369 100644 --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -382,6 +382,7 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (Delta)) .init_irq = omap1_init_irq, .init_machine = ams_delta_init, .timer = omap1_timer, + .restart= omap1_restart,
Re: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
* 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 - /* - * Resets some clocks that may be left on from bootloader, - * but leaves serial clocks on. - */ - omap_writel(0x3 29, MOD_CONF_CTRL_0); -#endif - /* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ reg = omap_readw(SOFT_REQ_REG) (1 4); omap_writew(reg, SOFT_REQ_REG); Hmm that should keep the serial clocks on. What other bit(s) need to be on in MOD_CONF_CTRL_0 for you in addition to the serial bits? 2) By using the above hack, I could see the actual crash: Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-rc1-e3 (aaro@dell) (gcc version 4.6.1 (GCC) ) #9 PREEMPT Thu Nov 10 23:48:23 EET 2011 [0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Amstrad E3 (Delta) [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writethrough [0.00] OMAP1510 [0.00] revision 2 handled as 15xx id: bc058c9b93111a16 [0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2cb3 ARM_CKCTL: 0x250e [0.00] [ cut here ] [0.00] kernel BUG at arch/arm/plat-omap/sram.c:226! [0.00] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.2.0-rc1-e3 #9) [0.00] PC is at omap_sram_reprogram_clock+0x28/0x30 [0.00] LR is at omap1_select_table_rate+0x88/0xb4 [0.00] pc : [c001b0c4]lr : [c0019f54]psr: 60d3 [0.00] sp : c035bf10 ip : c035bf20 fp : c035bf1c [0.00] r10: c035bfd4 r9 : 54029252 r8 : c03f8120 [0.00] r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40 [0.00] r3 : r2 : c0362b40 r1 : 010a r0 : 2cb0 [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 317f Table: 10004000 DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc035a270) [0.00] Stack: (0xc035bf10 to 0xc035c000) [0.00] bf00: c035bf3c c035bf20 c0019f54 c001b0ac [0.00] bf20: 1000 2cb3 0004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc [0.00] bf40: c02f526c 0002 0015 bc058c9b 93111a16 c035335c 0200 c035ed4c [0.00] bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88 [0.00] bf80: c033bc24 c00194a0 c035bf90 c035bf98 [0.00] bfa0: 0001 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8 [0.00] bfc0: c0338574 c033b598 c035467c 317d c035c03c [0.00] bfe0: c0354678 c035ece4 c035bff8 10008040 c0338508 [0.00] Backtrace: [0.00] [c001b09c] (omap_sram_reprogram_clock+0x0/0x30) from [c0019f54] (omap1_select_table_rate+0x88/0xb4) [0.00] [c0019ecc] (omap1_select_table_rate+0x0/0xb4) from [c033ea24] (omap1_clk_init+0x148/0x334) [0.00] r7:c035ed4c r6:0004 r5:2cb3 r4:1000 [0.00] [c033e8dc] (omap1_clk_init+0x0/0x334) from [c00194c4] (omap1_init_early+0x34/0x48) [0.00] r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:0200 r4:c035335c [0.00] [c0019490] (omap1_init_early+0x0/0x48) from [c033bc24] (setup_arch+0x69c/0x79c) [0.00] [c033b588] (setup_arch+0x0/0x79c) from [c0338574] (start_kernel+0x7c/0x2f4) [0.00] [c03384f8] (start_kernel+0x0/0x2f4) from [10008040] (0x10008040) [0.00] r7:c035ece4 r6:c0354678 r5:c035c03c r4:317d [0.00] Code: 0a02 e1a0e00f e12fff13 e89da800 (e7f001f2) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- The BUG_ON() in omap_sram_reprogram_clock() triggers, because it's called before omap_sram_init(). If I comment out the code in omap_sram_reprogram_clock(), the board boots up. Ouch. I guess I have not seen that as omap1_defconfig has by default CONFIG_OMAP_CLOCKS_SET_BY_BOOTLOADER=y. To fix the issue you're seeing we should move some of omap1_clk_init into an arch_initcall that calls omap1_select_table_rate later on, and then does propagate_rate(ck_ref). This way sram is configured when omap_sram_reprogram_clock gets called. Regards, Tony -- 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
Re: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
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: 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 aaro.koski...@iki.fi Signed-off-by: Tony Lindgren t...@atomide.com --- Untested, does this help? --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -302,8 +302,6 @@ static void __init ams_delta_init(void) omap_cfg_reg(J19_1610_CAM_D6); omap_cfg_reg(J18_1610_CAM_D7); -iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); - This is definitely wrong. Using iotable_init() after map_io has returned has (and remains) a serious bug - doing so may _appear_ to work but as it doesn't obtain its memory from the standard kernel memory allocators, it will lead to duplicate usage of that memory. Also, the patch did not help. It still hangs like before. Hmm that patch is needed for sure but sounds like there's also something else wrong.. Can you try to git bisect it? Ok, I'll try bisecting tomorrow. Hi Aaro, Please let me know if you think I could help, or I'll wait for your findings, to avoid duplicating efforts. Thanks, Janusz -- 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
Re: [PATCH] ARM: OMAP: Introduce local common.h files
* 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 base branch as soon as you can as pretty much all omap patches need to be updated for this one. I want to give it something between a week and two before closing the window for acked-bys etc (amongst other reasons). OK If you agree, could you put it in the patch system please? Thanks. Sounds good to me, it there now as patch 7159/1. Thanks, merged that into the series. The updated OMAP patch updated is below, which has been moved to part 2. Lastly, the final patch of part 2 has been updated to delete the empty arch_reset(), so OMAP is now entirely free of arch_reset() references. This leaves a total of 12 references left to nobble. Great, good to hear. 8--- From: Russell King - ARM Linux li...@arm.linux.org.uk Subject: [PATCH] ARM: restart: omap: use new restart hook Hook these platforms restart code into the new restart hook rather than using arch_reset(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tony Lindgren t...@atomide.com -- 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
Re: [PATCH v7 11/21] OMAP2+: UART: Move errata handling from serial.c to omap-serial
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 from on errata will be handled in driver file itself. Corrected errata id from chapter reference 2.15 to errata id i291. Removed errata and dma_enabled feilds from omap_uart_state struct as they are no more needed with errata handling done within omap-serial. Acked-by: Alan Coxa...@linux.intel.com Signed-off-by: Govindraj.Rgovindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 97 +++-- arch/arm/plat-omap/include/plat/omap-serial.h |6 ++ drivers/tty/serial/omap-serial.c | 66 - 3 files changed, 95 insertions(+), 74 deletions(-) [snip] + /* Enable the MDR1 errata for OMAP3 */ + if (cpu_is_omap34xx() !cpu_is_ti816x()) + omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS; This errata (i202) is applicable to all devices from OMAP2430 to OMAP4460 (apparently this one is not getting fixed). So could you make sure this is enabled for 2430, 3430, 3630, 4430 and 4460? [snip] +/* + * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6) We should update the comment to be Work Around for Errata i202 (2430, 3430, 3630, 4430 and 4460). The 1.12 and 1.6 are just the section references in the errata docs, but I think that you can drop these as you can just search for the errata ID which is i202. Cheers Jon -- 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
Re: [PATCH] ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
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
Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
* 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 ++ arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-mcx.c | 618 ++ This looks OK but let's concentrate on getting things working with board-generic.c and DT only in mainline kernel. I can apply this into testing-board, but let's not cause more churn in mainline with the board files that will be disappearing. Can you please split it into something minimal for mainline that allows booting with DT, and then another patch for testing-board branch? Thanks, Tony -- 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
Re: Pet Peaves about Platform code, and arch_reset
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 up the arch_reset() stuff:
1. Lack of trailing ',' on structure initializers
This makes it much harder to add additional initializers at the end
of existing initializers, and increases the risks of conflicts being
caused due to more lines having to be modified.
(This won't work directly because the tabs have been converted to space.
The empty-looking [] contain a space plus a tab.)
$ grep '[ ][ ]*\.[[:alnum:]_][[:alnum:]_]*[ ]*=[
]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm -r|wc -l
768
$ grep '[ ][ ]*\.[[:alnum:]_][[:alnum:]_]*[ ]*=[
]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm/*omap* -r|wc -l
325
Note that this is _far_ too big a problem - and trivial - to fix in
a set of silly churn generating patches - it's a problem to be fixed
as a part of _other_ changes to the files.
But most importantly _stop_ introducing versions of this problem.
Sounds like we need a spatch for this issue?
I guess spatch would need some patching to deal with this.. I tried
with something like:
@r@
identifier I, s, fld;
position p0,p;
expression E;
@@
struct I s =@p0 {
...
- .fld@p = E,
+ .fld = E,
...
};
That catches them, but adds an extra comma in the beginning :)
--- a/ams-delta-fiq.c 2011-11-08 18:03:20.110707512 -0800
+++ b/ams-delta-fiq.c 2011-11-08 18:04:36.094948038 -0800
@@ -25,7 +25,7 @@
#include mach/ams-delta-fiq.h
static struct fiq_handler fh = {
- .name = ams-delta-fiq
+ ,.name = ams-delta-fiq,
};
/*
And it also messes up the formatting for other structs..
Anyways, I think I got most of these fixed for all ARM subarchitectures
in a pile of 72 patches, the stats are:
486 files changed, 2296 insertions(+), 2296 deletions(-)
This is something people can then use as a base to start chipping away at
the problem. I'm thinking it may be possible to use this as a base for
search and replacement type work and then hopefully git mergetool will
pick the relevant changes when rebasing a working branch to the mainline.
I can also post the patches here if people want, but sounds like we're
not going to merge them as they are, but instead will slowly fix the
issue in other related patches?
I've pushed the patches into a git branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap formatting:
Web interface at:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=shortlog;h=refs/heads/formatting
For record, we may not want to do this for cases below, since we should
never add entry after sentinel.
static const struct of_device_id imx53_iomuxc_of_match[] __initconst = {
@@ -75,7 +75,7 @@ static const struct of_device_id imx53_iomuxc_of_match[]
__initconst = {
{ .compatible = fsl,imx53-iomuxc-evk, .data = imx53_evk_common_init,
},
{ .compatible = fsl,imx53-iomuxc-qsb, .data = imx53_qsb_common_init,
},
{ .compatible = fsl,imx53-iomuxc-smd, .data = imx53_smd_common_init,
},
- { /* sentinel */ }
+ { /* sentinel */ },
};
static void __init imx53_dt_init(void)
@@ -112,7 +112,7 @@ static const char *imx53_dt_board_compat[] __initdata = {
fsl,imx53-evk,
fsl,imx53-qsb,
fsl,imx53-smd,
- NULL
+ NULL,
};
--
Regards,
Shawn
--
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
Re: [PATCH v7 11/21] OMAP2+: UART: Move errata handling from serial.c to omap-serial
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 errata macro from serial.c file to driver header file as from on errata will be handled in driver file itself. Corrected errata id from chapter reference 2.15 to errata id i291. Removed errata and dma_enabled feilds from omap_uart_state struct Nitpick. The field spelling could be corrected. as they are no more needed with errata handling done within omap-serial. Acked-by: Alan Coxa...@linux.intel.com Signed-off-by: Govindraj.Rgovindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 97 +++-- arch/arm/plat-omap/include/plat/omap-serial.h |6 ++ drivers/tty/serial/omap-serial.c | 66 - 3 files changed, 95 insertions(+), 74 deletions(-) [snip] +/* Enable the MDR1 errata for OMAP3 */ +if (cpu_is_omap34xx() !cpu_is_ti816x()) +omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS; This errata (i202) is applicable to all devices from OMAP2430 to OMAP4460 (apparently this one is not getting fixed). So could you make sure this is enabled for 2430, 3430, 3630, 4430 and 4460? Yes good point. [snip] +/* + * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6) We should update the comment to be Work Around for Errata i202 (2430, 3430, 3630, 4430 and 4460). The 1.12 and 1.6 are just the section references in the errata docs, but I think that you can drop these as you can just search for the errata ID which is i202. Cheers Jon -- 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 -- 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
[PATCH] OMAP2+: Fix compilation break when cpuidle pm is selected
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 --- arch/arm/mach-omap2/cpuidle34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 6b4ed89..8ca1ddb 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -24,6 +24,7 @@ #include linux/sched.h #include linux/cpuidle.h +#include linux/module.h #include plat/prcm.h #include plat/irqs.h -- 1.7.4.1 -- 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
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
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, OM3xxx specific part and AM35xx specific part. For now the only difference is missing IVA node on AM35xx. Signed-off-by: Ilya Yanokya...@emcraft.com --- arch/arm/boot/dts/am35xx.dtsi | 15 +++ arch/arm/boot/dts/om3xxx.dtsi | 28 arch/arm/boot/dts/omap3-beagle.dts |2 +- arch/arm/boot/dts/omap3.dtsi |9 - 4 files changed, 44 insertions(+), 10 deletions(-) create mode 100644 arch/arm/boot/dts/am35xx.dtsi create mode 100644 arch/arm/boot/dts/om3xxx.dtsi om3xxx name is confusing - I haven't seen this name in any documentation/code before... Am I missing something? What do you think of omap3-iva.dtsi or omap3-dsp.dtsi? Cannot we avoid at all hacking the original file and use instead the status = disabled field for any variant that will not have the functionality? This might be an option. What I thought of is splitting the original file into atomic (none splittable) parts and each OMAP variant will include the ones it has. This way you have all the features available and can make any mixture of them (which, probably will reflect the hardware best ;-)) Yeah, but it will be less readable for my point of view. Agreed, it will be less readable, because it will be spread among several files. You will add another level of include hierarchy. Why is adding another level of include hierarchy is a problem? The point is that each time some new variants will come with less and less feature, we will keep de-populating the original file. Here you assume that it will be always *less* features and never *more*? Also, that is the reason, why I think splitting it right now to smaller pieces will do a good job for the future. My other concern is that all these variants are handled by different people for different products. So by having dedicated file for each variant, each owner can handle its own stuff without messing up the original file. I'm not saying that we should not have a dedicated file for each variant. What I'm saying is that the dedicated file for each variant can include the pieces the hardware has, instead of duplicating them or disabling what it does not have. Considering that this omap3.dtsi file is under construction, we can expect a bunch a dirty merge conflicts if different people from different organization start adding / removing nodes at the same time. IMO, that problem can also be avoided by splitting it to smaller pieces. Don't you think so? We already faced that kind of nightmare for our existing clock / hwmod static data files. So if we can avoid it with DT files, it will be cool. I don't think it falls in the same problem category, but may be I'm missing something... It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file. it will be a nightmare anyway ;-) Indeed, the best is to avoid any variant :-) I don't really know what can make it a less scary nightmare. For my point of view, since I will have to keep hacking on that omap3.dtsi, having some separate variant files that does not have to touch this file will be much better. Or split it to pieces right now, so no one will have to hack on it... If all these variants were already there and well defined, we might have then decided to re-organized that by starting from a common subset. Yeah, it would be perfect, but it is never been this way and will never be... But since everything is moving at the same time and with an unknown target, we should minimize hacking any common file under construction. I think the design of having a common file with data does not scale. Again, having multiple files, each with data per subsystem or per an ip block, does scale and IMO will do a better job, now and in the future. This will mean that common file will only do the includes to assemble all the *right* data together. -- Regards, Igor. -- 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
