Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Andi Kleen wrote: The VCMM provides a more abstract, global view with finer-grained control of each mapping a user wants to create. For instance, the semantics of iommu_map preclude its use in setting up just the IOMMU side of a mapping. With a one-sided map, two IOMMU devices can be Hmm? dma_map_* does not change any CPU mappings. It only sets up DMA mapping(s). Sure, but I was saying that iommu_map() doesn't just set up the IOMMU mappings, its sets up both the iommu and kernel buffer mappings. Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs unless the user explicitly That assumes that all the IOMMUs on the system support the same page table format, right? Actually no. Since the VCMM abstracts a page-table as a Virtual Contiguous Region (VCM) a VCM can be associated with any device, regardless of their individual page table format. As I understand your approach would help if you have different IOMMus with an different low level interface, which just happen to have the same pte format. Is that very likely? I would assume if you have lots of copies of the same IOMMU in the system then you could just use a single driver with multiple instances that share some state for all of them. That model would fit in the current interfaces. There's no reason multiple instances couldn't share the same allocation data structure. And if you have lots of truly different IOMMUs then they likely won't be able to share PTEs at the hardware level anyways, because the formats are too different. See VCM's above. The VCMM takes the long view. Its designed for a future in which the number of IOMMUs will go up and the ways in which these IOMMUs are composed will vary from system to system, and may vary at runtime. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). The standard Linux approach to such a problem is to write a library that drivers can use for common functionality, not put a middle layer in between. Libraries are much more flexible than layers. That's true up to the, is this middle layer so useful that its worth it point. The VM is a middle layer, you could make the same argument about it, the mapping code isn't too hard, just map in the memory that you need and be done with it. But the VM middle layer provides a clean separation between page frames and pages which turns out to be infinitely useful. The VCMM is built in the same spirit, It says things like, mapping is a global problem, I'm going to abstract entire virtual spaces and allow people arbitrary chuck size allocation, I'm not going to care that my device is physically mapping this buffer and this other device is a virtual, virtual device. That said I'm not sure there's all that much duplicated code anyways. A lot of the code is always IOMMU specific. The only piece which might be shareable is the mapping allocation, but I don't think that's very much of a typical driver In my old pci-gart driver the allocation was all only a few lines of code, although given it was somewhat dumb in this regard because it only managed a small remapping window. I agree that its not a lot of code, and that this layer may be a bit heavy, but I'd like to focus on is a global mapping view useful and if so is something like the graph management that the VCMM provides generally useful. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 5/9] dspbridge: add mmufault support
Hi Fernando,
From: ext Fernando Guzman Lugo x0095...@ti.com
Subject: [PATCH 5/9] dspbridge: add mmufault support
Date: Thu, 1 Jul 2010 02:20:56 +0200
With changes for iommu migration mmu fault report and dsp track
dump is broken, this patch fixes that.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/core/mmu_fault.c | 93 ++---
drivers/dsp/bridge/core/mmu_fault.h |5 +-
drivers/dsp/bridge/core/tiomap3430.c |2 +
drivers/dsp/bridge/core/ue_deh.c | 31 +---
4 files changed, 34 insertions(+), 97 deletions(-)
diff --git a/drivers/dsp/bridge/core/mmu_fault.c
b/drivers/dsp/bridge/core/mmu_fault.c
index 5c0124f..d991c6a 100644
--- a/drivers/dsp/bridge/core/mmu_fault.c
+++ b/drivers/dsp/bridge/core/mmu_fault.c
@@ -23,9 +23,12 @@
/* --- Trace Debug */
#include dspbridge/host_os.h
#include dspbridge/dbc.h
+#include plat/iommu.h
/* --- OS Adaptation Layer */
#include dspbridge/drv.h
+#include dspbridge/dev.h
+
/* --- Link Driver */
#include dspbridge/dspdeh.h
@@ -40,11 +43,6 @@
#include _tiomap.h
#include mmu_fault.h
-static u32 dmmu_event_mask;
-u32 fault_addr;
-
-static bool mmu_check_if_fault(struct bridge_dev_context *dev_context);
-
/*
* mmu_fault_dpc
* Deferred procedure call to handle DSP MMU fault.
@@ -62,78 +60,21 @@ void mmu_fault_dpc(IN unsigned long pRefData)
* mmu_fault_isr
* ISR to be triggered by a DSP MMU fault interrupt.
*/
-irqreturn_t mmu_fault_isr(int irq, IN void *pRefData)
-{
- struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)pRefData;
- struct bridge_dev_context *dev_context;
- struct cfg_hostres *resources;
-
- DBC_REQUIRE(irq == INT_DSP_MMU_IRQ);
- DBC_REQUIRE(deh_mgr_obj);
-
- if (deh_mgr_obj) {
-
- dev_context =
- (struct bridge_dev_context *)deh_mgr_obj-hbridge_context;
-
- resources = dev_context-resources;
-
- if (!resources) {
- dev_dbg(bridge, %s: Failed to get Host Resources\n,
- __func__);
- return IRQ_HANDLED;
- }
- if (mmu_check_if_fault(dev_context)) {
- printk(KERN_INFO * DSPMMU FAULT * IRQStatus
-0x%x\n, dmmu_event_mask);
- printk(KERN_INFO * DSPMMU FAULT * fault_addr
-0x%x\n, fault_addr);
- /*
- * Schedule a DPC directly. In the future, it may be
- * necessary to check if DSP MMU fault is intended for
- * Bridge.
- */
- tasklet_schedule(deh_mgr_obj-dpc_tasklet);
-
- /* Reset err_info structure before use. */
- deh_mgr_obj-err_info.dw_err_mask = DSP_MMUFAULT;
- deh_mgr_obj-err_info.dw_val1 = fault_addr 16;
- deh_mgr_obj-err_info.dw_val2 = fault_addr 0x;
- deh_mgr_obj-err_info.dw_val3 = 0L;
- /* Disable the MMU events, else once we clear it will
- * start to raise INTs again */
- hw_mmu_event_disable(resources-dw_dmmu_base,
- HW_MMU_TRANSLATION_FAULT);
- } else {
- hw_mmu_event_disable(resources-dw_dmmu_base,
- HW_MMU_ALL_INTERRUPTS);
- }
- }
- return IRQ_HANDLED;
-}
+int mmu_fault_isr(struct iommu *mmu)
-/*
- * mmu_check_if_fault
- * Check to see if MMU Fault is valid TLB miss from DSP
- * Note: This function is called from an ISR
- */
-static bool mmu_check_if_fault(struct bridge_dev_context *dev_context)
{
+ struct deh_mgr *dm;
+ u32 da;
+
+ dev_get_deh_mgr(dev_get_first(), dm);
+
+ if (!dm)
+ return -EPERM;
+
+ da = iommu_read_reg(mmu, MMU_FAULT_AD);
+ iommu_write_reg(mmu, 0, MMU_IRQENABLE);
+ dm-err_info.dw_val1 = da;
+ tasklet_schedule(dm-dpc_tasklet);
I think that the following iommu_disable() does disabling MMU.
Modified arch/arm/plat-omap/iommu.c
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index a202a2c..17407f1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -800,7 +800,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!stat)
return IRQ_HANDLED;
- iommu_disable(obj);
+ iommu_disable(obj); - HERE!
iopgd = iopgd_offset(obj, da);
You can find the latest omap iommu code from:
Re: [PATCH 1/9] dspbridge: replace iommu custom for opensource implementation
Hi Fernando,
From: ext Fernando Guzman Lugo x0095...@ti.com
Subject: [PATCH 1/9] dspbridge: replace iommu custom for opensource
implementation
Date: Thu, 1 Jul 2010 02:20:52 +0200
This patch replace the call to custom dsp mmu implemenation
for the once on iommu module.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/core/_tiomap.h| 16 +
drivers/dsp/bridge/core/io_sm.c | 114 ++--
drivers/dsp/bridge/core/tiomap3430.c | 501
+-
drivers/dsp/bridge/core/ue_deh.c | 10 -
4 files changed, 118 insertions(+), 523 deletions(-)
diff --git a/drivers/dsp/bridge/core/_tiomap.h
b/drivers/dsp/bridge/core/_tiomap.h
index bf0164e..d13677a 100644
--- a/drivers/dsp/bridge/core/_tiomap.h
+++ b/drivers/dsp/bridge/core/_tiomap.h
@@ -23,6 +23,8 @@
#include plat/clockdomain.h
#include mach-omap2/prm-regbits-34xx.h
#include mach-omap2/cm-regbits-34xx.h
+#include plat/iommu.h
+#include plat/iovmm.h
#include dspbridge/devdefs.h
#include hw_defs.h
#include dspbridge/dspioctl.h/* for bridge_ioctl_extproc defn */
@@ -330,6 +332,7 @@ struct bridge_dev_context {
u32 dw_internal_size; /* Internal memory size */
struct omap_mbox *mbox; /* Mail box handle */
+ struct iommu *dsp_mmu; /* iommu for iva2 handler */
struct cfg_hostres *resources; /* Host Resources */
@@ -374,4 +377,17 @@ extern s32 dsp_debug;
*/
int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val);
+static inline void dsp_iotlb_init(struct iotlb_entry *e, u32 da, u32 pa,
+ u32 pgsz)
+{
+ e-da = da;
+ e-pa = pa;
+ e-valid = 1;
+ e-prsvd = 1;
+ e-pgsz = pgsz MMU_CAM_PGSZ_MASK;
+ e-endian = MMU_RAM_ENDIAN_LITTLE;
+ e-elsz = MMU_RAM_ELSZ_32;
+ e-mixed = 0;
+}
+
#endif /* _TIOMAP_ */
diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
index 7fb840d..1f47f8b 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -290,6 +290,8 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct cod_manager *cod_man;
struct chnl_mgr *hchnl_mgr;
struct msg_mgr *hmsg_mgr;
+ struct iommu *mmu;
+ struct iotlb_entry e;
u32 ul_shm_base;
u32 ul_shm_base_offset;
u32 ul_shm_limit;
@@ -312,7 +314,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct bridge_ioctl_extproc ae_proc[BRDIOCTL_NUMOFMMUTLB];
struct cfg_hostres *host_res;
struct bridge_dev_context *pbridge_context;
- u32 map_attrs;
u32 shm0_end;
u32 ul_dyn_ext_base;
u32 ul_seg1_size = 0;
@@ -336,6 +337,21 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
status = -EFAULT;
goto func_end;
}
+
+ mmu = pbridge_context-dsp_mmu;
+
+ if (mmu)
+ iommu_put(mmu);
+ mmu = iommu_get(iva2);
+ mmu = iommu_get(iva2, mmu_fault_isr);
I'm considering that it might be better to pass a mmu fault callback
at this iommu_get.
What do you think?
--
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: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Tue, 29 Jun 2010 07:57:44 +0300 (EEST) Hi Tony, From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Wed, 02 Jun 2010 10:50:54 +0300 (EEST) Hi Tony, Patches for for-next for omap iommu module. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu Hiroshi DOYU (3): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer Kanigeri, Hari (2): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- 4 files changed, 65 insertions(+), 16 deletions(-) Any chance to merge? I have added 2 patches which were dropped from omap iommu fix as below. Please pull the following branch. Hi Tony, Do you have any plan for pulling for-next patches? I have some omap iommu and omap mailbox patches for for-next. Now the merge window seems so small and I don't want to miss it. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-iommu-for-next Hiroshi DOYU (4): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (3): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt omap iommu: update ducati mmu irq define name arch/arm/mach-omap2/Makefile|5 +++- arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/mach-omap2/omap-iommu.c|2 +- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- 6 files changed, 70 insertions(+), 18 deletions(-) -- 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 0/2] pandora updates for .36
* Gadiyar, Anand gadi...@ti.com [100701 23:25]: Grazvydas Ignotas wrote: Hi Tony, here are some updates for Pandora, which we have now around 700 units shipped (finally!) after years of developemt hell. More are being made at the moment. Neat! Hope you sell a zillion. I'll try and buy one someday. Yeah congrats! I'll be buying one too at some point :) Looking at all the patches for the merge window now, will queue up the pandora changes too. 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
[PATCH resend 1/3] AM35x: Add musb support
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It has USB phy built inside the IP itself.
Also added ARCH_AM35x which is required to differentiate musb ips
between OMAP3x and AM35x. This config would be used for below purposes,
- Select am35x.c instead of omap2430.c for compilation
at drivers/usb/musb directory. Please note there are
significant differneces in these two files as musb ip
in quite different on AM35x.
- Select workaround codes applicable for AM35x musb issues.
one such workaround is for bytewise read issue on AM35x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patches created against recent linus's tree.
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/board-am3517evm.c | 30 ++
arch/arm/mach-omap2/usb-musb.c|4
arch/arm/plat-omap/Kconfig|8
arch/arm/plat-omap/include/plat/usb.h | 21 +
5 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b31b6f1..52a6752 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -84,6 +84,7 @@ config MACH_OMAP3517EVM
bool OMAP3517/ AM3517 EVM board
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
+ select ARCH_AM35x
config MACH_OMAP3_PANDORA
bool OMAP3 Pandora
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index af383a8..7f42a1b 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include plat/control.h
#include mux.h
@@ -375,6 +376,30 @@ static void __init am3517_evm_init_irq(void)
omap_gpio_init();
}
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
+
+static __init void am3517_evm_musb_init(void)
+{
+ u32 devconf2;
+
+ /*
+* Set up USB clock/mode in the DEVCONF2 register.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ /* USB2.0 PHY reference clock is 13 MHz */
+ devconf2 = ~(CONF2_REFFREQ | CONF2_OTGMODE);
+ devconf2 |= CONF2_REFFREQ_13MHZ | CONF2_SESENDEN | CONF2_VBDTCTEN;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ usb_musb_init(musb_board_data);
+}
+
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -393,6 +418,8 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* USB OTG DRVVBUS offset = 0x212 */
+ OMAP3_MUX(SAD2D_MCAD23, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -459,6 +486,9 @@ static void __init am3517_evm_init(void)
ARRAY_SIZE(am3517evm_i2c1_boardinfo));
/*Ethernet*/
am3517_evm_ethernet_init(am3517_evm_emac_pdata);
+
+ /* MUSB */
+ am3517_evm_musb_init();
}
static void __init am3517_evm_map_io(void)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 96f6787..a54f360 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -29,6 +29,7 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/mux.h
+#include mach/am35xx.h
#include plat/usb.h
#ifdef CONFIG_USB_MUSB_SOC
@@ -90,6 +91,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
{
if (cpu_is_omap243x()) {
musb_resources[0].start = OMAP243X_HS_BASE;
+ } else if (cpu_is_omap3517() || cpu_is_omap3505()) {
+ musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
+ musb_resources[1].start = INT_35XX_USBOTG_IRQ;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 78b49a6..3f33d75 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,14 @@ menu TI OMAP Implementations
config ARCH_OMAP_OTG
bool
+config ARCH_AM35x
+ bool
+ help
+ Select this option if your platform is based on AM35x. As
+ AM35x has an updated MUSB with CPPI4.1 DMA so this config
+ is introduced to differentiate musb ip between OMAP3x and
+ AM35x platforms.
+
choice
prompt OMAP System Type
default ARCH_OMAP2PLUS
diff --git a/arch/arm/plat-omap/include/plat/usb.h
[PATCH resend 3/3] musb: AM35x: Workaround for fifo read issue
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/am35x.c | 30 ++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 0cdc6bf..cdcd6f3 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -517,3 +517,33 @@ void musb_platform_restore_context(struct musb *musb,
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 (unsigned long) dst) == 0) len = 4) {
+ readsl(fifo, dst, len 2);
+ dst += len ~0x03;
+ len = 0x03;
+ }
+ /*
+* Now read the rest 1 to 3 bytes or complete length if
+* unaligned address.
+*/
+ if (len 4) {
+ for (i = 0; i (len 2); i++) {
+ *(u32 *) dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
+ len %= 4;
+ }
+ if (len 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3b795c5..e22e98b 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -272,6 +272,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
}
}
+#if !defined(CONFIG_ARCH_AM35x)
/*
* Unload an endpoint's FIFO
*/
@@ -309,6 +310,7 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
*dst)
readsb(fifo, dst, len);
}
}
+#endif
#endif /* normal PIO */
--
1.6.2.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 resend 2/3] musb: add musb support for AM35x
AM35x has musb interface and uses CPPI4.1 DMA engine. Current patch supports only PIO mode. DMA support can be added later once basic CPPI4.1 DMA patch is accepted. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/Kconfig |4 +- drivers/usb/musb/Makefile |4 + drivers/usb/musb/am35x.c | 519 + 3 files changed, 525 insertions(+), 2 deletions(-) create mode 100644 drivers/usb/musb/am35x.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..87d73fa 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -10,7 +10,7 @@ comment Enable Host or Gadget support to see Inventra options config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) - select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN || ARCH_AM35x) select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' @@ -144,7 +144,7 @@ config USB_MUSB_HDRC_HCD config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC - default y if USB_TUSB6010 + default USB_TUSB6010 || ARCH_AM35x help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index 9705f71..f99f675 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -19,7 +19,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y) endif ifeq ($(CONFIG_ARCH_OMAP3430),y) + ifeq ($(CONFIG_ARCH_AM35x),y) + musb_hdrc-objs += am35x.o + else musb_hdrc-objs += omap2430.o + endif endif ifeq ($(CONFIG_ARCH_OMAP4),y) diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c new file mode 100644 index 000..0cdc6bf --- /dev/null +++ b/drivers/usb/musb/am35x.c @@ -0,0 +1,519 @@ +/* + * Texas Instruments AM35x glue layer + * + * Copyright (c) 2010, by Texas Instruments + * + * Based on the DA8xx glue layer code. + * Copyright (C) 2005-2006 by Texas Instruments + * Copyright (c) 2008, MontaVista Software, Inc. sou...@mvista.com + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux 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. + * + * The Inventra Controller Driver for Linux is distributed in + * the hope that it will be useful, but WITHOUT ANY WARRANTY; + * without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public + * License for more details. + * + * You should have received a copy of the GNU General Public License + * along with The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include linux/init.h +#include linux/clk.h +#include linux/io.h + +#include plat/control.h +#include plat/usb.h + +#include musb_core.h + +/* + * AM35x specific definitions + */ +/* USB 2.0 OTG module registers */ +#define USB_REVISION_REG 0x00 +#define USB_CTRL_REG 0x04 +#define USB_STAT_REG 0x08 +#define USB_EMULATION_REG 0x0c +/* 0x10 Reserved */ +#define USB_AUTOREQ_REG0x14 +#define USB_SRP_FIX_TIME_REG 0x18 +#define USB_TEARDOWN_REG 0x1c +#define EP_INTR_SRC_REG0x20 +#define EP_INTR_SRC_SET_REG0x24 +#define EP_INTR_SRC_CLEAR_REG 0x28 +#define EP_INTR_MASK_REG 0x2c +#define EP_INTR_MASK_SET_REG 0x30 +#define EP_INTR_MASK_CLEAR_REG 0x34 +#define EP_INTR_SRC_MASKED_REG 0x38 +#define CORE_INTR_SRC_REG 0x40 +#define CORE_INTR_SRC_SET_REG 0x44 +#define CORE_INTR_SRC_CLEAR_REG0x48 +#define CORE_INTR_MASK_REG 0x4c +#define CORE_INTR_MASK_SET_REG 0x50 +#define CORE_INTR_MASK_CLEAR_REG 0x54 +#define CORE_INTR_SRC_MASKED_REG 0x58 +/* 0x5c Reserved */ +#define USB_END_OF_INTR_REG0x60 + +/* Control register bits */ +#define USB_SOFT_RESET_MASK1 +#define A_WAIT_BCON_TIMEOUT1100/* in ms */ + +/* USB interrupt register bits */ +#define USB_INTR_USB_SHIFT 16 +#define USB_INTR_USB_MASK (0x1ff USB_INTR_USB_SHIFT) +#define USB_INTR_DRVVBUS 0x100 +#define USB_INTR_RX_SHIFT 16 +#define USB_INTR_TX_SHIFT 0 +#define AM35X_TX_EP_MASK 0x /* EP0 + 15 Tx EPs */ +#define AM35X_RX_EP_MASK 0xfffe /* 15 Rx EPs */ +#define AM35X_TX_INTR_MASK (AM35X_TX_EP_MASK USB_INTR_TX_SHIFT) +#define AM35X_RX_INTR_MASK (AM35X_RX_EP_MASK USB_INTR_RX_SHIFT) + +#define USB_MENTOR_CORE_OFFSET 0x400 + +static inline void
Re: [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Thu, Jul 01, 2010 at 12:16:18AM -0700, Zach Pfeffer wrote: Thank you for the corrections. I'm correcting them now. Some responses: Randy Dunlap wrote: +struct vcm *vcm_create(size_t start_addr, size_t len); Seems odd to use size_t for start_addr. I used size_t because I wanted to allow the start_addr the same range as len. Is there a better type to use? I see 'unsigned long' used throughout the mm code. Perhaps that's better for both the start_addr and len. phys_addr_t or resource_size_t. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Hari Kanigeri wrote: He demonstrated the usage of his code in one of the emails he sent out initially. Did you go over that, and what (or how many) step would you use with the current code to do the same thing? -- So is this patch set adding layers and abstractions to help the User ? If the idea is to share some memory across multiple devices, I guess you can achieve the same by calling the map function provided by iommu module and sharing the mapped address to the 10's or 100's of devices to access the buffers. You would only need a dedicated virtual pool per IOMMU device to manage its virtual memory allocations. Yeah, you can do that. My idea is to get away from explicit addressing and encapsulate the device address to physical address link into a mapping. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Hari Kanigeri wrote: The VCMM takes the long view. Its designed for a future in which the number of IOMMUs will go up and the ways in which these IOMMUs are composed will vary from system to system, and may vary at runtime. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). -- Sounds good. Did you think of a way to handle the cases where one of the Device that is using the mapped address crashed ? How is the physical address unbacked in this case ? Actually the API takes care of that by design. Since the physical space is managed apart from the mapper the mapper can crash and not affect the physical memory allocation. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Daniel Walker wrote: On Thu, 2010-07-01 at 15:00 -0700, Zach Pfeffer wrote: Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs unless the user explicitly wrote a muxed device underneith the IOMMU interface. This also could be done, but would have to be done for every such use case. Since the particular topology is run-time configurable all of these use-cases and more can be expressed without pushing the topology into the low-level IOMMU driver. The VCMM takes the long view. Its designed for a future in which the number of IOMMUs will go up and the ways in which these IOMMUs are composed will vary from system to system, and may vary at runtime. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). So if we include this code which map implementations could you collapse into this implementations ? Generally , what currently existing code can VCMM help to eliminate? In theory, it can eliminate all code the interoperates between IOMMU, CPU and non-IOMMU based devices and all the mapping code, alignment, mapping attribute and special block size support that's been implemented. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote: Andi Kleen wrote: The VCMM provides a more abstract, global view with finer-grained control of each mapping a user wants to create. For instance, the semantics of iommu_map preclude its use in setting up just the IOMMU side of a mapping. With a one-sided map, two IOMMU devices can be Hmm? dma_map_* does not change any CPU mappings. It only sets up DMA mapping(s). Sure, but I was saying that iommu_map() doesn't just set up the IOMMU mappings, its sets up both the iommu and kernel buffer mappings. Normally the data is already in the kernel or mappings, so why would you need another CPU mapping too? Sometimes the CPU code has to scatter-gather, but that is considered acceptable (and if it really cannot be rewritten to support sg it's better to have an explicit vmap operation) In general on larger systems with many CPUs changing CPU mappings also gets expensive (because you have to communicate with all cores), and is not a good idea on frequent IO paths. Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs unless the user explicitly That assumes that all the IOMMUs on the system support the same page table format, right? Actually no. Since the VCMM abstracts a page-table as a Virtual Contiguous Region (VCM) a VCM can be associated with any device, regardless of their individual page table format. But then there is no real page table sharing, isn't it? The real information should be in the page tables, nowhere else. The standard Linux approach to such a problem is to write a library that drivers can use for common functionality, not put a middle layer in between. Libraries are much more flexible than layers. That's true up to the, is this middle layer so useful that its worth it point. The VM is a middle layer, you could make the same argument about it, the mapping code isn't too hard, just map in the memory that you need and be done with it. But the VM middle layer provides a clean separation between page frames and pages which turns out to be Actually we use both PFNs and struct page *s in many layers up and down, there's not really any layering in that. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
* Hiroshi DOYU hiroshi.d...@nokia.com [100702 09:29]: Do you have any plan for pulling for-next patches? I have some omap iommu and omap mailbox patches for for-next. Now the merge window seems so small and I don't want to miss it. Pulled now into omap-for-linus for the next merge window. Sorry for the delay. BTW, I did not add that Makefile fix into omap-fixes-for-linus, I figured we should first make sure to get the pending fixes in, and then maybe do another set of fixes. But looks like that's in your for-next, so we might as well keep it there. If there's urgent need to get that in as a fix, let me know ASAP, I can still rebuild omap-for-linus as that's the only set merged there. Regards, Tony The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-iommu-for-next Hiroshi DOYU (4): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (3): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt omap iommu: update ducati mmu irq define name arch/arm/mach-omap2/Makefile|5 +++- arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/mach-omap2/omap-iommu.c|2 +- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- 6 files changed, 70 insertions(+), 18 deletions(-) -- 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 09/13] OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
Hi, On Thu, 24 Jun 2010, Kevin Hilman wrote: The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Just FYI, this patch has been converted to use an array index instead of pointer arithmetic - edited patch below. - Paul OMAP: omap_device: ensure hwmod tracks attached omap_device pointer From: Kevin Hilman khil...@deeprootsystems.com The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com [p...@pwsan.com: use an array index rather than pointer arithmetic] Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/omap_device.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index f899603..f9dec0d 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -359,7 +359,7 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_device *od; char *pdev_name2; struct resource *res = NULL; - int res_count; + int i, res_count; struct omap_hwmod **hwmods; if (!ohs || oh_cnt == 0 || !pdev_name) @@ -416,6 +416,9 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, else ret = omap_device_register(od); + for (i = 0; i oh_cnt; i++) + hwmods[i]-od = od; + if (ret) goto odbs_exit4; -- 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: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
From: ext Tony Lindgren t...@atomide.com Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Fri, 2 Jul 2010 11:04:11 +0200 * Hiroshi DOYU hiroshi.d...@nokia.com [100702 09:29]: Do you have any plan for pulling for-next patches? I have some omap iommu and omap mailbox patches for for-next. Now the merge window seems so small and I don't want to miss it. Pulled now into omap-for-linus for the next merge window. Sorry for the delay. BTW, I did not add that Makefile fix into omap-fixes-for-linus, I figured we should first make sure to get the pending fixes in, and then maybe do another set of fixes. But looks like that's in your for-next, so we might as well keep it there. If there's urgent need to get that in as a fix, let me know ASAP, I can still rebuild omap-for-linus as that's the only set merged there. Ok, Thanks. I'll send another pull request for omap mailbox for-next. -- 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
[RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API
This patch updates the cpufreq driver to use the device
set rate API to scale the mpu frequency for OMAP3.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/cpu-omap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 9467827..cde02b5 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -29,6 +29,7 @@
#include mach/hardware.h
#include plat/clock.h
#include asm/system.h
+#include plat/omap_device.h
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
#include plat/omap-pm.h
@@ -84,7 +85,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
-#ifdef CONFIG_ARCH_OMAP1
+#ifdef CONFIG_ARiCH_OMAP1
struct cpufreq_freqs freqs;
#endif
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
@@ -117,7 +118,7 @@ static int omap_target(struct cpufreq_policy *policy,
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
freq = target_freq * 1000;
if (opp_find_freq_ceil(mpu_dev, freq))
- omap_pm_cpu_set_freq(freq);
+ omap_device_set_rate(mpu_dev, freq);
#endif
return ret;
}
--
1.7.0.rc1.33.g07cf0f
--
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
[RFC 4/7] OMAP: Voltage layer changes to support DVFS.
This patch introduces a list of scalable devices associated with
a particular voltage domain instance. This list is obtained from
the opp layer during init. This patch also introduces an API
to take in the voltage domain and the new voltage as parameter
and to scale all the scalable devices associated with the the
voltage domain to the rate corresponding to the new voltage and
scale the voltage domain to the new voltage.
This patch renames the previous omap_voltage_scale API to
omap_voltage_scale_vdd.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 89 -
arch/arm/plat-omap/include/plat/voltage.h |4 +-
2 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index a2f30a4..1e6712e 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -137,6 +137,8 @@ struct omap_vdd_info{
struct omap_volt_domain volt_domain;
spinlock_t user_lock;
struct plist_head user_list;
+ struct device **dev_list;
+ int dev_count;
int volt_data_count;
unsigned long nominal_volt;
u8 cmdval_reg;
@@ -387,6 +389,10 @@ static void __init omap3_vdd_data_configure(struct
omap_vdd_info *vdd)
spin_lock_init(vdd-user_lock);
plist_head_init(vdd-user_list, vdd-user_lock);
+ /* Get the devices associated with this VDD */
+ vdd-dev_list = opp_init_voltage_params(vdd-volt_domain,
+ vdd-dev_count);
+
if (!strcmp(vdd-volt_domain.name, mpu)) {
if (cpu_is_omap3630()) {
vdd-vp_reg.vlimitto_vddmin =
@@ -1073,7 +1079,8 @@ void omap_voltageprocessor_disable(struct
omap_volt_domain *volt_domain)
}
/**
- * omap_voltage_scale : API to scale voltage of a particular voltage domain.
+ * omap_voltage_scale_vdd : API to scale voltage of a particular
+ * voltage domain.
* @volt_domain: pointer to the VDD which is to be scaled.
* @target_vsel : The target voltage of the voltage domain
* @current_vsel : the current voltage of the voltage domain.
@@ -1081,7 +1088,7 @@ void omap_voltageprocessor_disable(struct
omap_volt_domain *volt_domain)
* This API should be called by the kernel to do the voltage scaling
* for a particular voltage domain during dvfs or any other situation.
*/
-int omap_voltage_scale(struct omap_volt_domain *volt_domain,
+int omap_voltage_scale_vdd(struct omap_volt_domain *volt_domain,
unsigned long target_volt)
{
struct omap_vdd_info *vdd;
@@ -1290,6 +1297,84 @@ struct omap_volt_domain *omap_volt_domain_get(char *name)
}
/**
+ * omap_voltage_scale : API to scale the devices associated with a
+ * voltage domain vdd voltage.
+ * @volt_domain : the voltage domain to be scaled
+ * @volt : the new voltage for the voltage domain
+ *
+ * This API runs through the list of devices associated with the
+ * voltage domain and scales the device rates to those corresponding
+ * to the new voltage of the voltage domain. This API also scales
+ * the voltage domain voltage to the new value. Returns 0 on success
+ * else the error value.
+ */
+int omap_voltage_scale(struct omap_volt_domain *volt_domain,
+ unsigned long volt)
+{
+ unsigned long curr_volt;
+ int is_volt_scaled = 0, i;
+ struct omap_vdd_info *vdd;
+
+ if (!volt_domain || IS_ERR(volt_domain)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return -EINVAL;
+ }
+
+ vdd = container_of(volt_domain, struct omap_vdd_info, volt_domain);
+ curr_volt = get_curr_voltage(volt_domain);
+
+ if (curr_volt == volt) {
+ is_volt_scaled = 1;
+ } else if (curr_volt volt) {
+ omap_voltage_scale_vdd(volt_domain, volt);
+ is_volt_scaled = 1;
+ }
+
+ for (i = 0; i vdd-dev_count; i++) {
+ struct device_opp *dev_opp;
+ struct omap_opp *opp;
+ unsigned long freq;
+
+ dev_opp = opp_find_dev_opp(vdd-dev_list[i]);
+ if (IS_ERR(dev_opp)) {
+ dev_err(vdd-dev_list[i], %s: Unable to find device
+ opp table\n, __func__);
+ continue;
+ }
+ if (!dev_opp-set_rate) {
+ dev_err(vdd-dev_list[i], %s: No set_rate API
+ for scaling opp\n, __func__);
+ continue;
+ }
+
+ opp = opp_find_voltage(vdd-dev_list[i], volt);
+ if (IS_ERR(opp)) {
+ dev_err(vdd-dev_list[i], %s: Unable to find OPP for
+ volt%ld\n, __func__, volt);
+ continue;
+ }
+
+ freq =
[RFC 5/7] OMAP: Introduce set_rate and get_rate API in omap device layer
This patch adds omap_device_set_rate and omap_device_get_rate
API's which can be used to generic device rate scaling.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/omap_device.c | 87 +
2 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 3694b62..e0d06bb 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -114,6 +114,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_set_rate(struct device *dev, unsigned long rate);
+unsigned long omap_device_get_rate(struct device *dev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 6614cba..900bb5d 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,8 @@
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/opp.h
+#include plat/voltage.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -734,3 +736,88 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+/**
+ * omap_device_set_rate - Set a new rate at which the device is to operate
+ * @dev : the device pointer
+ * @rate : the rnew rate for the device.
+ *
+ * This API gets the device opp table associated with this device and
+ * tries putting the device to the requested rate and the voltage domain
+ * associated with the device to the voltage corresponding to the
+ * requested rate. Since multiple devices can be assocciated with a
+ * voltage domain this API finds out the possible voltage the
+ * voltage domain can enter and then decides on the final device
+ * rate. Return 0 on success else the error value
+ */
+int omap_device_set_rate(struct device *dev, unsigned long rate)
+{
+ struct device_opp *dev_opp;
+ struct omap_opp *opp;
+ unsigned long volt, freq;
+ int ret;
+
+ dev_opp = opp_find_dev_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_warn(dev, %s: Unable to find device opp table\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ /* Get the possible rate from the opp layer */
+ freq = rate;
+ opp = opp_find_freq_ceil(dev, freq);
+ if (IS_ERR(opp)) {
+ dev_err(dev, %s: Unable to find OPP for freq%ld\n,
+ __func__, rate);
+ return -ENODEV;
+ }
+ if (unlikely(freq != rate))
+ dev_warn(dev, %s: Available freq %ld != dpll freq %ld.\n,
+ __func__, freq, rate);
+
+ /* Get the voltage corresponding to the requested frequency */
+ volt = opp_get_voltage(opp);
+
+ /*
+* Call into the voltage layer to get the final voltage possible
+* for the voltage domain associated with the device.
+*/
+
+ ret = omap_volt_get_final(dev_opp-volt_domain, dev, volt);
+ if (ret) {
+ dev_err(dev, %s: Unable to get the final volt for scaling\n,
+ __func__);
+ return ret;
+ }
+
+ /* Do the actual scaling */
+ return omap_voltage_scale(dev_opp-volt_domain, volt);
+}
+
+/**
+ * omap_device_get_rate - Gets the current operating rate of the device
+ * @dev - the device pointer
+ *
+ * This API returns the current operating rate of the device on success.
+ * Else returns the error value.
+ */
+unsigned long omap_device_get_rate(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ dev_opp = opp_find_dev_opp(dev);
+
+ if (IS_ERR(dev_opp)) {
+ dev_warn(dev, %s: Unable to find device opp table\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ if (!dev_opp-get_rate) {
+ dev_warn(dev, %s: No get_rate API\n, __func__);
+ return -EINVAL;
+ }
+
+ return dev_opp-get_rate(dev);
+}
--
1.7.0.rc1.33.g07cf0f
--
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
[RFC 6/7] OMAP3: Update OMAP3 opp tables to contain the voltage domain and device set rate get rate info
This patch updates the omap3 opp tables to contain the voltage domain
associated with the opp. This patch also introduces
omap3_mpu_set_rate, omap3_iva_set_rate, omap3_l3_set_rate,
omap3_mpu_get_rate, omap3_iva_get_rate, omap3_l3_get_rate as device
specific set rate and get rate API's for OMAP3 mpu, iva and l3_main devices
and hooks them up in the correspoinding opp table entries.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/cpufreq34xx.c | 160 +++--
1 files changed, 136 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
index 1589542..1f65f7e 100644
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -21,22 +21,41 @@
#include linux/module.h
#include linux/err.h
+#include linux/cpufreq.h
#include plat/opp.h
#include plat/cpu.h
+#include plat/clock.h
+#include cm-regbits-34xx.h
+#include prm.h
#include omap3-opp.h
+static int omap3_mpu_set_rate(struct device *dev, unsigned long rate);
+static int omap3_iva_set_rate(struct device *dev, unsigned long rate);
+static int omap3_l3_set_rate(struct device *dev, unsigned long rate);
+
+static unsigned long omap3_mpu_get_rate(struct device *dev);
+static unsigned long omap3_iva_get_rate(struct device *dev);
+static unsigned long omap3_l3_get_rate(struct device *dev);
+
+struct clk *dpll1_clk, *dpll2_clk, *dpll3_clk;
+
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
- OMAP_OPP_DEF(mpu, true, 12500, 975000),
+ OMAP_OPP_DEF(mpu, mpu, omap3_mpu_set_rate, omap3_mpu_get_rate,
+ true, 12500, 975000),
/* MPU OPP2 */
- OMAP_OPP_DEF(mpu, true, 25000, 1075000),
+ OMAP_OPP_DEF(mpu, mpu, omap3_mpu_set_rate, omap3_mpu_get_rate,
+ true, 25000, 1075000),
/* MPU OPP3 */
- OMAP_OPP_DEF(mpu, true, 5, 120),
+ OMAP_OPP_DEF(mpu, mpu, omap3_mpu_set_rate, omap3_mpu_get_rate,
+ true, 5, 120),
/* MPU OPP4 */
- OMAP_OPP_DEF(mpu, true, 55000, 127),
+ OMAP_OPP_DEF(mpu, mpu, omap3_mpu_set_rate, omap3_mpu_get_rate,
+ true, 55000, 127),
/* MPU OPP5 */
- OMAP_OPP_DEF(mpu, true, 6, 135),
+ OMAP_OPP_DEF(mpu, mpu, omap3_mpu_set_rate, omap3_mpu_get_rate,
+ true, 6, 135),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -46,52 +65,141 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
* impact that frequency will do to the MPU and the whole system in
* general.
*/
- OMAP_OPP_DEF(l3_main, false, 4150, 975000),
+ OMAP_OPP_DEF(l3_main, core, omap3_l3_set_rate, omap3_l3_get_rate,
+ false, 4150, 975000),
/* L3 OPP2 */
- OMAP_OPP_DEF(l3_main, true, 8300, 105),
+ OMAP_OPP_DEF(l3_main, core, omap3_l3_set_rate, omap3_l3_get_rate,
+ true, 8300, 105),
/* L3 OPP3 */
- OMAP_OPP_DEF(l3_main, true, 16600, 115),
-
+ OMAP_OPP_DEF(l3_main, core, omap3_l3_set_rate, omap3_l3_get_rate,
+ true, 16600, 115),
/* DSP OPP1 */
- OMAP_OPP_DEF(iva, true, 9000, 975000),
+ OMAP_OPP_DEF(iva, mpu, omap3_iva_set_rate, omap3_iva_get_rate,
+ true, 9000, 975000),
/* DSP OPP2 */
- OMAP_OPP_DEF(iva, true, 18000, 1075000),
+ OMAP_OPP_DEF(iva, mpu, omap3_iva_set_rate, omap3_iva_get_rate,
+ true, 18000, 1075000),
/* DSP OPP3 */
- OMAP_OPP_DEF(iva, true, 36000, 120),
+ OMAP_OPP_DEF(iva, mpu, omap3_iva_set_rate, omap3_iva_get_rate,
+ true, 36000, 120),
/* DSP OPP4 */
- OMAP_OPP_DEF(iva, true, 4, 127),
+ OMAP_OPP_DEF(iva, mpu, omap3_iva_set_rate, omap3_iva_get_rate,
+ true, 4, 127),
/* DSP OPP5 */
- OMAP_OPP_DEF(iva, true, 43000, 135),
+ OMAP_OPP_DEF(iva, mpu, omap3_iva_set_rate, omap3_iva_get_rate,
+ true, 43000, 135),
};
static u32 omap34xx_opp_def_size = ARRAY_SIZE(omap34xx_opp_def_list);
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
- OMAP_OPP_DEF(mpu, true, 3, 93),
+ OMAP_OPP_DEF(mpu, mpu, omap3_mpu_set_rate, omap3_mpu_get_rate,
+ true, 3, 93),
/* MPU OPP2 - OPP100 */
- OMAP_OPP_DEF(mpu, true, 6, 110),
+ OMAP_OPP_DEF(mpu, mpu, omap3_mpu_set_rate, omap3_mpu_get_rate,
+ true, 6, 110),
/* MPU OPP3 - OPP-Turbo */
- OMAP_OPP_DEF(mpu, false, 8,
[RFC 2/7] OMAP: Introduce API in the OPP layer to find the opp entry corresponding to a voltage.
This patch adds an API in the opp layer to get the opp table entry
corresponding to the voltage passed as the parameter.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/opp.h |2 ++
arch/arm/plat-omap/opp.c | 28
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 29e3d03..893731f 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -75,6 +75,8 @@ struct omap_opp *opp_find_freq_floor(struct device *dev,
unsigned long *freq);
struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long *freq);
+struct omap_opp *opp_find_voltage(struct device *dev, unsigned long volt);
+
int opp_add(const struct omap_opp_def *opp_def);
int opp_enable(struct omap_opp *opp);
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index 0273497..070ff5b 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -302,6 +302,34 @@ struct omap_opp *opp_find_freq_floor(struct device *dev,
unsigned long *freq)
return opp;
}
+/**
+ * opp_find_voltage() - search for an exact voltage
+ * @dev: device pointer associated with the opp type
+ * @volt: voltage to search for
+ *
+ * Searches for exact match in the opp list and returns handle to the matching
+ * opp if found, else returns ERR_PTR in case of error and should be handled
+ * using IS_ERR.
+ */
+struct omap_opp *opp_find_voltage(struct device *dev, unsigned long volt)
+{
+ struct device_opp *dev_opp;
+ struct omap_opp *temp_opp, *opp = ERR_PTR(-ENODEV);
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return opp;
+
+ list_for_each_entry(temp_opp, dev_opp-opp_list, node) {
+ if (temp_opp-enabled temp_opp-u_volt == volt) {
+ opp = temp_opp;
+ break;
+ }
+ }
+
+ return opp;
+}
+
/* wrapper to reuse converting opp_def to opp struct */
static void omap_opp_populate(struct omap_opp *opp,
const struct omap_opp_def *opp_def)
--
1.7.0.rc1.33.g07cf0f
--
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
[RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
This patch extends the device opp structure to contain
info about the voltage domain to which the device belongs to
and to contain pointers to scale the operating rate of the
device. This patch also adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance and the device list should
be stored. This approach makes it easy during dvfs to scale
all the devices associated with a voltage domain and then
scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/opp.h | 37 +-
arch/arm/plat-omap/opp.c | 47 +---
2 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 893731f..15e1e70 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -16,6 +16,7 @@
#include linux/err.h
#include linux/cpufreq.h
+#include linux/clk.h
#include plat/common.h
@@ -38,21 +39,45 @@
*/
struct omap_opp_def {
char *hwmod_name;
+ char *vdd_name;
unsigned long freq;
unsigned long u_volt;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+
bool enabled;
};
+struct device_opp {
+ struct list_head node;
+ char *vdd_name;
+
+ struct omap_hwmod *oh;
+ struct device *dev;
+ struct omap_volt_domain *volt_domain;
+
+ struct list_head opp_list;
+ u32 opp_count;
+ u32 enabled_opp_count;
+
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+};
+
/*
* Initialization wrapper used to define an OPP.
* To point at the end of a terminator of a list of OPPs,
* use OMAP_OPP_DEF(0, 0, 0)
*/
-#define OMAP_OPP_DEF(_hwmod_name, _enabled, _freq, _uv)\
+#define OMAP_OPP_DEF(_hwmod_name, _vdd_name, _set_rate, _get_rate, \
+ _enabled, _freq, _uv) \
{ \
.hwmod_name = _hwmod_name, \
+ .vdd_name = _vdd_name,\
+ .set_rate = _set_rate,\
+ .get_rate = _get_rate,\
.enabled= _enabled, \
.freq = _freq,\
.u_volt = _uv, \
@@ -77,6 +102,8 @@ struct omap_opp *opp_find_freq_ceil(struct device *dev,
unsigned long *freq);
struct omap_opp *opp_find_voltage(struct device *dev, unsigned long volt);
+struct device_opp *opp_find_dev_opp(struct device *dev);
+
int opp_add(const struct omap_opp_def *opp_def);
int opp_enable(struct omap_opp *opp);
@@ -89,6 +116,9 @@ u8 __deprecated opp_get_opp_id(struct omap_opp *opp);
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
+
+struct device **opp_init_voltage_params(struct omap_volt_domain *volt_domain,
+ int *dev_count);
#else
static inline unsigned long opp_get_voltage(const struct omap_opp *opp)
{
@@ -124,6 +154,11 @@ static inline struct omap_opp *opp_find_freq_ceil(struct
omap_opp *oppl,
return ERR_PTR(-EINVAL);
}
+static inline struct device_opp *opp_find_dev_opp(struct device *dev)
+{
+ return ERR_PTR(-EINVAL);
+}
+
static inline struct omap_opp *opp_add(struct omap_opp *oppl,
const struct omap_opp_def *opp_def)
{
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index 070ff5b..9bc53e8 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -22,6 +22,7 @@
#include plat/opp_twl_tps.h
#include plat/opp.h
#include plat/omap_device.h
+#include plat/voltage.h
/**
* struct omap_opp - OMAP OPP description structure
@@ -43,17 +44,6 @@ struct omap_opp {
struct device_opp *dev_opp; /* containing device_opp struct */
};
-struct device_opp {
- struct list_head node;
-
- struct omap_hwmod *oh;
- struct device *dev;
-
- struct list_head opp_list;
- u32 opp_count;
- u32 enabled_opp_count;
-};
-
static LIST_HEAD(dev_opp_list);
/**
@@ -330,6 +320,11 @@ struct omap_opp *opp_find_voltage(struct device *dev,
unsigned long volt)
return opp;
}
+struct device_opp *opp_find_dev_opp(struct device *dev)
+{
+ return find_device_opp(dev);
+}
+
/* wrapper to reuse converting opp_def to opp struct */
static void omap_opp_populate(struct omap_opp *opp,
const struct omap_opp_def *opp_def)
@@ -385,6 +380,11 @@ int opp_add(const struct omap_opp_def *opp_def)
dev_opp-oh = oh;
dev_opp-dev =
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
* Nicolas Pitre n...@fluxnic.net [100702 05:31]:
On Thu, 1 Jul 2010, Jamie Lokier wrote:
Tony Lindgren wrote:
+static void __init kuser_get_tls_init(unsigned long vectors)
+{
+ /*
+ * vectors + 0xfe0 = __kuser_get_tls
+ * vectors + 0xfe8 = hardware TLS instruction at 0x0fe8
+ */
+ if (tls_emu || has_tls)
+ memcpy((void *)vectors + 0xfe0, (void *)vectors + 0xfe8, 4);
+}
Just a little opinion: Perhaps has_tls_reg would be a clearer name.
All variants have TLS after all.
Good point.
I like that too. Updated patch below.
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 2 Jul 2010 11:33:31 +0300
Subject: [PATCH] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
The TLS register is only available on ARM1136 r1p0 and later.
Set HWCAP_TLS flags if hardware TLS is available and test for
it if CONFIG_CPU_32v6K is not set for V6.
Note that we set the TLS instruction in __kuser_get_tls
dynamically as suggested by Jamie Lokier ja...@shareable.org.
Also the __switch_to code is optimized out in most cases as
suggested by Nicolas Pitre n...@fluxnic.net.
Signed-off-by: Tony Lindgren t...@atomide.com
Reviewed-by: Nicolas Pitre nicolas.pi...@linaro.org
diff --git a/arch/arm/include/asm/hwcap.h b/arch/arm/include/asm/hwcap.h
index f7bd52b..c1062c3 100644
--- a/arch/arm/include/asm/hwcap.h
+++ b/arch/arm/include/asm/hwcap.h
@@ -19,6 +19,7 @@
#define HWCAP_NEON 4096
#define HWCAP_VFPv3 8192
#define HWCAP_VFPv3D16 16384
+#define HWCAP_TLS 32768
#if defined(__KERNEL__) !defined(__ASSEMBLY__)
/*
diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
new file mode 100644
index 000..e71d6ff
--- /dev/null
+++ b/arch/arm/include/asm/tls.h
@@ -0,0 +1,46 @@
+#ifndef __ASMARM_TLS_H
+#define __ASMARM_TLS_H
+
+#ifdef __ASSEMBLY__
+ .macro set_tls_none, tp, tmp1, tmp2
+ .endm
+
+ .macro set_tls_v6k, tp, tmp1, tmp2
+ mcr p15, 0, \tp, c13, c0, 3 @ set TLS register
+ .endm
+
+ .macro set_tls_v6, tp, tmp1, tmp2
+ ldr \tmp1, =elf_hwcap
+ ldr \tmp1, [\tmp1, #0]
+ mov \tmp2, #0x0fff
+ tst \tmp1, #HWCAP_TLS @ hardware TLS available?
+ mcrne p15, 0, \tp, c13, c0, 3 @ yes, set TLS register
+ streq \tp, [\tmp2, #-15] @ set TLS value at 0x0ff0
+ .endm
+
+ .macro set_tls_software, tp, tmp1, tmp2
+ mov \tmp1, #0x0fff
+ str \tp, [\tmp1, #-15] @ set TLS value at 0x0ff0
+ .endm
+#endif
+
+#ifdef CONFIG_TLS_REG_EMUL
+#define tls_emu 1
+#define has_tls_reg 1
+#define set_tls set_tls_none
+#elif __LINUX_ARM_ARCH__ = 7 || \
+ (__LINUX_ARM_ARCH__ == 6 defined(CONFIG_CPU_32v6K))
+#define tls_emu 0
+#define has_tls_reg 1
+#define set_tls set_tls_v6k
+#elif __LINUX_ARM_ARCH__ == 6
+#define tls_emu 0
+#define has_tls_reg (elf_hwcap HWCAP_TLS)
+#define set_tls set_tls_v6
+#else
+#define tls_emu 0
+#define has_tls_reg 0
+#define set_tls set_tls_software
+#endif
+
+#endif /* __ASMARM_TLS_H */
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 7ee48e7..a6cfb17 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -22,6 +22,7 @@
#include asm/thread_notify.h
#include asm/unwind.h
#include asm/unistd.h
+#include asm/tls.h
#include entry-header.S
@@ -739,12 +740,7 @@ ENTRY(__switch_to)
#ifdef CONFIG_MMU
ldr r6, [r2, #TI_CPU_DOMAIN]
#endif
-#if defined(CONFIG_HAS_TLS_REG)
- mcr p15, 0, r3, c13, c0, 3 @ set TLS register
-#elif !defined(CONFIG_TLS_REG_EMUL)
- mov r4, #0x0fff
- str r3, [r4, #-15] @ TLS val at 0x0ff0
-#endif
+ set_tls r3, r4, r5
#ifdef CONFIG_MMU
mcr p15, 0, r6, c3, c0, 0 @ Set domain register
#endif
@@ -1009,17 +1005,12 @@ kuser_cmpxchg_fixup:
*/
__kuser_get_tls:@ 0x0fe0
-
-#if !defined(CONFIG_HAS_TLS_REG) !defined(CONFIG_TLS_REG_EMUL)
- ldr r0, [pc, #(16 - 8)] @ TLS stored at 0x0ff0
-#else
- mrc p15, 0, r0, c13, c0, 3 @ read TLS register
-#endif
+ ldr r0, [pc, #(16 - 8)] @ read TLS, set in kuser_get_tls_init
usr_ret lr
-
- .rep 5
- .word 0 @ pad up to __kuser_helper_version
- .endr
+ mrc p15, 0, r0, c13, c0, 3 @ 0x0fe8 hardware TLS code
+ .rep 4
+ .word 0 @ 0x0ff0 software TLS value, then
+ .endr@ pad up to __kuser_helper_version
/*
* Reference declaration:
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 122d999..73921f1 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -269,6 +269,21 @@ static void __init cacheid_init(void)
extern struct proc_info_list *lookup_processor_type(unsigned int);
extern struct machine_desc *lookup_machine_type(unsigned int);
+static void __init feat_v6_fixup(void)
+{
+ int id = read_cpuid_id();
+
+ if ((id 0xff0f) != 0x4107)
+ return;
+
+ /*
+ * HWCAP_TLS is available only on 1136 r1p0 and later,
+ * see also kuser_get_tls_init.
+ */
+ if id 4) 0xfff) == 0xb36) (((id 20) 3) == 0))
+ elf_hwcap = ~HWCAP_TLS;
+}
+
static void __init setup_processor(void)
{
struct proc_info_list *list;
@@
Re: [PATCH 07/13] OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME
Hi,
On Wed, 23 Jun 2010, Kevin Hilman wrote:
When runtime PM is disabled, the pm_runtime_idle() and _enable()
functions will be effectively noops and will not result in enable
and idle calls at the hwmod level.
In order for drivers to still work when runtime PM is disabled, ensure
that all hwmods are left in an enabled state so that even without
runtime PM management, they will still work.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
I'd prefer to keep the hwmod code free of references to higher-layer code,
so I'll use the following patch instead.
- Paul
OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in _setup()
From: Paul Walmsley p...@pwsan.com
On kernels that don't use the omap_device_enable() calls to enable
devices, leave all on-chip devices enabled in hwmod _setup().
Otherwise, accesses to those devices are likely to fail, crashing the
system. It's expected that kernels built without CONFIG_PM_RUNTIME
will be the primary use-case for this. This functionality is
controlled by adding an extra parameter to omap_hwmod_late_init().
This patch is based on the patch OMAP: hwmod: don't auto-disable
hwmod when !CONFIG_PM_RUNTIME by Kevin Hilman
khil...@deeprootsystems.com.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/io.c |9 ++
arch/arm/mach-omap2/omap_hwmod.c | 37 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |5 ++--
3 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..05c9cdb 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -313,6 +313,8 @@ static int __init _omap2_init_reprogram_sdrc(void)
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
+ u8 skip_setup_idle = 0;
+
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
@@ -337,8 +339,13 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
pr_err(Could not init clock framework - unknown CPU\n);
omap_serial_early_init();
+
+#ifndef CONFIG_PM_RUNTIME
+ skip_setup_idle = 1;
+#endif
if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
- omap_hwmod_late_init();
+ omap_hwmod_late_init(skip_setup_idle);
+
omap_pm_if_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 47943ec..d9e96fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -761,6 +761,7 @@ static struct omap_hwmod *_lookup(const char *name)
/**
* _init_clocks - clk_get() all clocks associated with this hwmod
* @oh: struct omap_hwmod *
+ * @data: not used; pass NULL
*
* Called by omap_hwmod_late_init() (after omap2_clk_init()).
* Resolves all clock names embedded in the hwmod. Must be called
@@ -768,7 +769,7 @@ static struct omap_hwmod *_lookup(const char *name)
* has not yet been registered or if the clocks have already been
* initialized, 0 on success, or a non-zero error on failure.
*/
-static int _init_clocks(struct omap_hwmod *oh)
+static int _init_clocks(struct omap_hwmod *oh, void *data)
{
int ret = 0;
@@ -993,19 +994,25 @@ static int _shutdown(struct omap_hwmod *oh)
/**
* _setup - do initial configuration of omap_hwmod
* @oh: struct omap_hwmod *
+ * @skip_setup_idle_p: do not idle hwmods at the end of the fn if 1
*
* Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh
- * OCP_SYSCONFIG register. Must be called with omap_hwmod_mutex
- * held. Returns -EINVAL if the hwmod is in the wrong state or returns
- * 0.
+ * OCP_SYSCONFIG register. Must be called with omap_hwmod_mutex held.
+ * @skip_setup_idle is intended to be used on a system that will not
+ * call omap_hwmod_enable() to enable devices (e.g., a system without
+ * PM runtime). Returns -EINVAL if the hwmod is in the wrong state or
+ * returns 0.
*/
-static int _setup(struct omap_hwmod *oh)
+static int _setup(struct omap_hwmod *oh, void *data)
{
int i, r;
+ u8 skip_setup_idle;
- if (!oh)
+ if (!oh || !data)
return -EINVAL;
+ skip_setup_idle = *(u8 *)data;
+
/* Set iclk autoidle mode */
if (oh-slaves_cnt 0) {
for (i = 0; i oh-slaves_cnt; i++) {
@@ -1047,7 +1054,7 @@ static int _setup(struct omap_hwmod *oh)
}
}
- if (!(oh-flags HWMOD_INIT_NO_IDLE))
+ if (!(oh-flags HWMOD_INIT_NO_IDLE) !skip_setup_idle)
_omap_hwmod_idle(oh);
return 0;
@@ -1161,6 +1168,7 @@ struct omap_hwmod
Re: [PATCH 09/13] OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
Hi, On Wed, 23 Jun 2010, Kevin Hilman wrote: The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com This patch has been modified to use array indexing rather than pointer arithmetic; I think it is easier to read and debug; revised patch below. - Paul OMAP: omap_device: ensure hwmod tracks attached omap_device pointer From: Kevin Hilman khil...@deeprootsystems.com The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com [p...@pwsan.com: use an array index rather than pointer arithmetic] Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/omap_device.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index f899603..f9dec0d 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -359,7 +359,7 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_device *od; char *pdev_name2; struct resource *res = NULL; - int res_count; + int i, res_count; struct omap_hwmod **hwmods; if (!ohs || oh_cnt == 0 || !pdev_name) @@ -416,6 +416,9 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, else ret = omap_device_register(od); + for (i = 0; i oh_cnt; i++) + hwmods[i]-od = od; + if (ret) goto odbs_exit4; -- 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 10/13] OMAP: create omap_devices for MPU, DSP, L3
Hi,
On Tue, 29 Jun 2010, Kevin Hilman wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
So that these primary devices are available for early PM initialization,
they are created as early platform_devices.
I've reworked this patch so that it is no longer using early devices,
updated version below.
This requires delaying some other PM init as well (OMAP PM layer, OPP
layer etc.) so a common_pm_init() function was created and initialized
as a device_initcall().
My pm-hwmods branch has been updated with this version, and the PM
branch now has corresponding changes to the SR/voltage layers to
initialize them as device_initcalls as well.
Thanks for these changes, this seems better than the early_platform_device
approach. I've made a few more changes:
- the newly-created functions have been moved to a new file,
mach-omap2/pm.c. I'm not convinced that this file is the right place
for these functions either, but it didn't make sense to me to create
these functions in mach-omap2/io.c;
- the functions have been renamed to start with omap2 to indicate that
they are OMAP2+-only functions;
- sparse warnings have been resolved.
Revised patch below.
- Paul
OMAP: PM: create omap_devices for MPU, DSP, L3
From: Kevin Hilman khil...@deeprootsystems.com
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
Also, move these common PM init functions into a common_pm_init call
that is called as a device_initcall(). The PM init is done at this level
to ensure that the driver core is initialized before initialized.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
[p...@pwsan.com: sparse warnings cleaned up; newly-created functions moved
from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed
to start with omap2 rather than omap]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |2 -
arch/arm/mach-omap2/io.c |2 -
arch/arm/mach-omap2/pm.c | 84 ++
arch/arm/plat-omap/include/plat/common.h |4 +
4 files changed, 90 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2fa3418..213f1df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
omap-2-3-common= irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 05c9cdb..2b983ac 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -44,6 +44,7 @@
#include plat/clockdomain.h
#include clockdomains.h
+
#include plat/omap_hwmod.h
/*
@@ -346,7 +347,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
omap_hwmod_late_init(skip_setup_idle);
- omap_pm_if_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
new file mode 100644
index 000..68f9f2e
--- /dev/null
+++ b/arch/arm/mach-omap2/pm.c
@@ -0,0 +1,84 @@
+/*
+ * pm.c - Common OMAP2+ power management-related code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * 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/io.h
+#include linux/err.h
+
+#include plat/omap-pm.h
+#include plat/omap_device.h
+#include plat/common.h
+
+static struct omap_device_pm_latency *pm_lats;
+
+static struct device *mpu_dev;
+static struct device *dsp_dev;
+static struct device *l3_dev;
+
+struct device *omap2_get_mpuss_device(void)
+{
+ WARN_ON_ONCE(!mpu_dev);
+ return mpu_dev;
+}
+
+struct device *omap2_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+
+struct device *omap2_get_l3_device(void)
+{
+ WARN_ON_ONCE(!l3_dev);
+ return l3_dev;
+}
+
+/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
+static int _init_omap_device(char *name, struct device **new_dev)
+{
+
RE: [RFC 1/7] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Friday, July 02, 2010 3:48 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Basak, Partha; Gopinath, Thara
Subject: [RFC 1/7] OMAP: Introduce a user list for each voltage domain
instance in
the voltage driver.
This patch introduces a user list of devices associated with each
voltage domain instance. The user list is implemented using plist
structure with priority node populated with the voltage values.
This patch also adds an API which will take in a device and
requested voltage as parameters, adds the info to the user list
and returns back the maximum voltage requested by all the user
devices. This can be used anytime to get the voltage that the
voltage domain instance can be transitioned into.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 83
+
arch/arm/plat-omap/include/plat/voltage.h |2 +
2 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 30f1770..a2f30a4 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -24,6 +24,9 @@
#include linux/clk.h
#include linux/err.h
#include linux/debugfs.h
+#include linux/spinlock.h
+#include linux/plist.h
+#include linux/slab.h
#include plat/omap-pm.h
#include plat/omap34xx.h
@@ -93,6 +96,20 @@ struct vp_reg_val {
};
/**
+ * omap_vdd_user_list- The per vdd user list
+ *
+ * @dev : The device asking for the vdd to be set at a
particular
+ * voltage
+ * @node : The list head entry
+ * @volt : The voltage requested by the device dev
+ */
+struct omap_vdd_user_list {
+ struct device *dev;
+ struct plist_node node;
+ u32 volt;
+};
+
+/**
* omap_vdd_info - Per Voltage Domain info
*
* @volt_data: voltage table having the distinct voltages
supported
@@ -103,6 +120,9 @@ struct vp_reg_val {
* vp registers
* @volt_clk : the clock associated with the vdd.
* @opp_dev : the 'struct device' associated with this vdd.
+ * @user_lock: the lock to be used by the plist user_list
+ * @user_list: the list head maintaining the various users
+ * of this vdd with the voltage requested by each user.
* @volt_data_count : Number of distinct voltages supported by this vdd.
* @nominal_volt : Nominal voltaged for this vdd.
* cmdval_reg: Voltage controller cmdval register.
@@ -115,6 +135,8 @@ struct omap_vdd_info{
struct clk *volt_clk;
struct device *opp_dev;
struct omap_volt_domain volt_domain;
+ spinlock_t user_lock;
+ struct plist_head user_list;
int volt_data_count;
unsigned long nominal_volt;
u8 cmdval_reg;
@@ -361,6 +383,10 @@ static void __init omap3_vdd_data_configure(struct
omap_vdd_info *vdd)
struct clk *sys_ck;
u32 sys_clk_speed, timeout_val, waittime;
+ /* Init the plist */
+ spin_lock_init(vdd-user_lock);
+ plist_head_init(vdd-user_list, vdd-user_lock);
+
if (!strcmp(vdd-volt_domain.name, mpu)) {
if (cpu_is_omap3630()) {
vdd-vp_reg.vlimitto_vddmin =
@@ -881,6 +907,63 @@ unsigned long omap_voltageprocessor_get_curr_volt(
}
/**
+ * omap_voltage_get_final : API to keep track of various requests to
[minor] This name does not match the actual API
+ * scale the VDD and returns the best possible
+ * voltage the VDD can be put to.
+ * @volt_domain: pointer to the voltage domain.
+ * @dev : the device pointer.
+ * @volt : the voltage which is requested by the device.
+ *
+ * This API is to be called before the actual voltage scaling is
+ * done to determine what is the best possible voltage the VDD can
+ * be put to. This API adds the device dev in the user list of the
+ * vdd volt_domain with volt as the requested voltage. The user list
+ * is a plist with the priority element absolute voltage values.
+ * The API then finds the maximum of all the requested voltages for
+ * the VDD and returns it back through volt pointer itself.
+ * Returns error value in case of any errors.
+ */
+int omap_volt_get_final(struct omap_volt_domain *volt_domain,
+ struct device *dev, unsigned long *volt)
+{
+ struct omap_vdd_info *vdd;
+ struct omap_vdd_user_list *user;
+ struct plist_node *node;
+ int found = 0;
+
+ if (!volt_domain || IS_ERR(volt_domain)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return -EINVAL;
+ }
+
+ vdd = container_of(volt_domain, struct omap_vdd_info, volt_domain);
+
+
Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
Hi, On Wed, 23 Jun 2010, Kevin Hilman wrote: From: Rajendra Nayak rna...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com This patch has been updated to include Benoît's compile fix; revised patch below. - Paul OMAP4: hwmod: Enable omap_device build for OMAP4 From: Rajendra Nayak rna...@ti.com Enable omap_device layer support for OMAP4, so that drivers can use them to enable/idle/shutdown devices. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/plat-omap/Makefile |1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6c6d7c6..2fa3418 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -15,7 +15,7 @@ clock-common = clock.o clock_common_data.o \ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) -obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) +obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) $(hwmod-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..9405831 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_ARCH_OMAP2) += omap_device.o obj-$(CONFIG_ARCH_OMAP3) += omap_device.o +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
Re: [PATCH 05/13] OMAP23: hwmod: Remove _hwmod prefix in name string
Hi, On Wed, 23 Jun 2010, Kevin Hilman wrote: From: Benoit Cousson b-cous...@ti.com In the lastest OMAP4 hwmod data file, the _hwmod was removed in order to save some memory space and because it does not bring a lot. Align OMAP2420, 2430 and 3430 data files with the same convention. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com I've taken Benoît's original patch for this, so have converted your Signed-off-by: into an Acked-by: for this patch. - Paul
Re: [PATCH v2 04/13] OMAP: hwmod: Fix the missing braces
Hi, On Thu, 24 Jun 2010, Kevin Hilman wrote: From: Benoit Cousson b-cous...@ti.com As reported by Sergei, a couple of braces were missing after the WARM removal patch. [07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed https://patchwork.kernel.org/patch/100756/ Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Sergei Shtylyov sshtyl...@mvista.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com This one has already been sent to Tony as part of the -rc series, so I've dropped this one. - Paul -- 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 00/13] OMAP: CM, hwmod, omap_device fixes and updates
Hi, On Thu, 24 Jun 2010, Kevin Hilman wrote: This is a series of fixes updates mostly to hwmod and omap_device that are required for the on-going hwmod conversions and runtime PM conversion of drivers. I've taken patches 1, 3, 6, 11, 12, and 13 as-is; and handled the rest as per the mailing list comments on the individual patches. Thanks Kevin, - Paul -- 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 5/7] OMAP: Introduce set_rate and get_rate API in omap device layer
-Original Message-
From: Gopinath, Thara
Sent: Friday, July 02, 2010 3:48 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Basak, Partha; Gopinath, Thara
Subject: [RFC 5/7] OMAP: Introduce set_rate and get_rate API in omap device
layer
This patch adds omap_device_set_rate and omap_device_get_rate
API's which can be used to generic device rate scaling.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/omap_device.c | 87
+
2 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-
omap/include/plat/omap_device.h
index 3694b62..e0d06bb 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -114,6 +114,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_set_rate(struct device *dev, unsigned long rate);
+unsigned long omap_device_get_rate(struct device *dev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 6614cba..900bb5d 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,8 @@
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/opp.h
+#include plat/voltage.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -734,3 +736,88 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+/**
+ * omap_device_set_rate - Set a new rate at which the device is to operate
+ * @dev : the device pointer
+ * @rate : the rnew rate for the device.
+ *
+ * This API gets the device opp table associated with this device and
+ * tries putting the device to the requested rate and the voltage domain
+ * associated with the device to the voltage corresponding to the
+ * requested rate. Since multiple devices can be assocciated with a
+ * voltage domain this API finds out the possible voltage the
+ * voltage domain can enter and then decides on the final device
+ * rate. Return 0 on success else the error value
+ */
+int omap_device_set_rate(struct device *dev, unsigned long rate)
+{
+ struct device_opp *dev_opp;
+ struct omap_opp *opp;
+ unsigned long volt, freq;
+ int ret;
+
+ dev_opp = opp_find_dev_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_warn(dev, %s: Unable to find device opp table\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ /* Get the possible rate from the opp layer */
+ freq = rate;
+ opp = opp_find_freq_ceil(dev, freq);
+ if (IS_ERR(opp)) {
+ dev_err(dev, %s: Unable to find OPP for freq%ld\n,
+ __func__, rate);
+ return -ENODEV;
+ }
+ if (unlikely(freq != rate))
+ dev_warn(dev, %s: Available freq %ld != dpll freq %ld.\n,
+ __func__, freq, rate);
+
+ /* Get the voltage corresponding to the requested frequency */
+ volt = opp_get_voltage(opp);
+
+ /*
+ * Call into the voltage layer to get the final voltage possible
+ * for the voltage domain associated with the device.
+ */
+
+ ret = omap_volt_get_final(dev_opp-volt_domain, dev, volt);
+ if (ret) {
+ dev_err(dev, %s: Unable to get the final volt for scaling\n,
+ __func__);
+ return ret;
+ }
+
+ /* Do the actual scaling */
+ return omap_voltage_scale(dev_opp-volt_domain, volt);
This function also needs to be lock protected to avoid race conditions involved
when multiple guys try to scale the voltage simultaneously.
+}
+
+/**
+ * omap_device_get_rate - Gets the current operating rate of the device
+ * @dev - the device pointer
+ *
+ * This API returns the current operating rate of the device on success.
+ * Else returns the error value.
+ */
+unsigned long omap_device_get_rate(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ dev_opp = opp_find_dev_opp(dev);
+
+ if (IS_ERR(dev_opp)) {
+ dev_warn(dev, %s: Unable to find device opp table\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ if (!dev_opp-get_rate) {
+ dev_warn(dev, %s: No get_rate API\n, __func__);
+ return -EINVAL;
+ }
+
+ return dev_opp-get_rate(dev);
+}
--
1.7.0.rc1.33.g07cf0f
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
[PATCH 2/3] omap mailbox: prevent multiple concurrent receivers race
From: ext Ohad Ben-Cohen o...@wizery.com
We currently maintain only a single mailbox receiver callback.
To prevent multiple receivers race scenarios (in which receivers
will end up overwriting each other's callback pointers), we make
sure that mailbox instances cannot be taken by more than
one receiver at the same time.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c | 12 +++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0b45664..5df35b4 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -57,6 +57,7 @@ struct omap_mbox {
struct omap_mbox_ops*ops;
struct device *dev;
void*priv;
+ atomic_tcount;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 14b716d..aafa63f 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -320,9 +320,17 @@ struct omap_mbox *omap_mbox_get(const char *name, int
(*callback)(void *))
if (!mbox)
return ERR_PTR(-ENOENT);
+ if (atomic_inc_return(mbox-count) 1) {
+ pr_err(%s: mbox %s already in use\n, __func__, name);
+ atomic_dec(mbox-count);
+ return ERR_PTR(-EBUSY);
+ }
+
ret = omap_mbox_startup(mbox);
- if (ret)
+ if (ret) {
+ atomic_dec(mbox-count);
return ERR_PTR(-ENODEV);
+ }
mbox-rxq-callback = callback;
@@ -333,6 +341,7 @@ EXPORT_SYMBOL(omap_mbox_get);
void omap_mbox_put(struct omap_mbox *mbox)
{
omap_mbox_fini(mbox);
+ atomic_dec(mbox-count);
}
EXPORT_SYMBOL(omap_mbox_put);
@@ -349,6 +358,7 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox **list)
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
+ atomic_set(mbox-count, 0);
mbox-dev = device_create(omap_mbox_class,
parent, 0, mbox, %s, mbox-name);
if (IS_ERR(mbox-dev)) {
--
1.7.1.rc2
--
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 3/3] omap mailbox: remove mbox_configured scheme
From: ext Ohad Ben-Cohen o...@wizery.com
mbox_configured is global and therefore does not support
concurrent usage of multiple mailbox instances.
Instead of fixing this, we can just eliminate mbox_configured
(and its locking) entirely, since any given mailbox instance
can only be taken by a single receiver now.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index aafa63f..6a9dfe5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -35,9 +35,6 @@ static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
static bool rq_full;
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, Size of omap's mailbox kfifo (bytes));
@@ -240,16 +237,9 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
struct omap_mbox_queue *mq;
if (mbox-ops-startup) {
- mutex_lock(mbox_configured_lock);
- if (!mbox_configured)
- ret = mbox-ops-startup(mbox);
-
- if (ret) {
- mutex_unlock(mbox_configured_lock);
+ ret = mbox-ops-startup(mbox);
+ if (ret)
return ret;
- }
- mbox_configured++;
- mutex_unlock(mbox_configured_lock);
}
ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
@@ -295,14 +285,8 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mbox_queue_free(mbox-txq);
mbox_queue_free(mbox-rxq);
- if (mbox-ops-shutdown) {
- mutex_lock(mbox_configured_lock);
- if (mbox_configured 0)
- mbox_configured--;
- if (!mbox_configured)
- mbox-ops-shutdown(mbox);
- mutex_unlock(mbox_configured_lock);
- }
+ if (mbox-ops-shutdown)
+ mbox-ops-shutdown(mbox);
}
struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
--
1.7.1.rc2
--
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 1/3] omap mailbox: extend API to take a callback param
From: ext Ohad Ben-Cohen o...@wizery.com
Let mailbox users set the callback pointer via the
omap_mbox_get API, instead of having users directly
manipulating the mailbox structures.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/include/plat/mailbox.h |2 +-
arch/arm/plat-omap/mailbox.c |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..0b45664 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -62,7 +62,7 @@ struct omap_mbox {
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *));
void omap_mbox_put(struct omap_mbox *);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..14b716d 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -305,7 +305,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
}
}
-struct omap_mbox *omap_mbox_get(const char *name)
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
{
struct omap_mbox *mbox;
int ret;
@@ -324,6 +324,8 @@ struct omap_mbox *omap_mbox_get(const char *name)
if (ret)
return ERR_PTR(-ENODEV);
+ mbox-rxq-callback = callback;
+
return mbox;
}
EXPORT_SYMBOL(omap_mbox_get);
--
1.7.1.rc2
--
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 v3 4/4] omap: mailbox: convert block api to kfifo
On Wed, 23 Jun 2010 02:29:00 +0200 ext Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Jun 16, 2010 at 8:50 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Ohad Ben-Cohen o...@wizery.com Thanks, I'll prepare them and resubmit You can use the following branch which has accumulateed unmerged mailbox patches. git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-mailbox Done. Thansk. [PATCH 1-3/4] are queued on the above branch and will be pulled soon. The following should be taken care of dspbridge: [PATCH 4/4] dspbridge: use mailbox API to set rx callback -- 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 1/3] omap mailbox: extend API to take a callback param
Hi Hiroshi,
Please consider waiting with pulling of these three patches.
After discussions in l-o, we realized some more work is needed to
support OMAP4 multiple senders scenarios.
Such work can completely replace these 3 patches (retaining their
functionality but adding multiple senders/receivers support).
Thanks,
Ohad.
On Fri, Jul 2, 2010 at 3:05 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Ohad Ben-Cohen o...@wizery.com
Let mailbox users set the callback pointer via the
omap_mbox_get API, instead of having users directly
manipulating the mailbox structures.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
 arch/arm/plat-omap/include/plat/mailbox.h |   2 +-
 arch/arm/plat-omap/mailbox.c        |   4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..0b45664 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -62,7 +62,7 @@ struct omap_mbox {
 int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
 void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *));
 void omap_mbox_put(struct omap_mbox *);
 int omap_mbox_register(struct device *parent, struct omap_mbox **);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..14b716d 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -305,7 +305,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
    }
 }
-struct omap_mbox *omap_mbox_get(const char *name)
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
 {
    struct omap_mbox *mbox;
    int ret;
@@ -324,6 +324,8 @@ struct omap_mbox *omap_mbox_get(const char *name)
    if (ret)
        return ERR_PTR(-ENODEV);
+ Â Â Â mbox-rxq-callback = callback;
+
    return mbox;
 }
 EXPORT_SYMBOL(omap_mbox_get);
--
1.7.1.rc2
--
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
Re: [PATCH 1/3] omap mailbox: extend API to take a callback param
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH 1/3] omap mailbox: extend API to take a callback param Date: Fri, 2 Jul 2010 14:16:29 +0200 Hi Hiroshi, Please consider waiting with pulling of these three patches. After discussions in l-o, we realized some more work is needed to support OMAP4 multiple senders scenarios. Such work can completely replace these 3 patches (retaining their functionality but adding multiple senders/receivers support). Ok. It would be nice if you send patches to LOML and LAKML too for next time. -- 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 resend 2/3] musb: add musb support for AM35x
Hello.
Ajay Kumar Gupta wrote:
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[...]
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
new file mode 100644
index 000..0cdc6bf
--- /dev/null
+++ b/drivers/usb/musb/am35x.c
[...]
+#define USB_SOFT_RESET_MASK1
Need a empty line here.
+#define A_WAIT_BCON_TIMEOUT1100/* in ms */
I think this #define should be dropped -- see below...
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ /*
+* Start the on-chip PHY and its PLL.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN |
+ CONF2_PHY_GPIOMODE);
BWT, what's thet GPIOMODE bit for?
+ devconf2 |= CONF2_PHY_PLLON | CONF2_DATPOL;
So, AM35x always uses the reversed data polarity?
+static void otg_timer(unsigned long _musb)
+{
+ struct musb *musb = (void *)_musb;
+ void __iomem*mregs = musb-mregs;
+ u8 devctl;
+ unsigned long flags;
+
+ /*
+* We poll because AM35x's won't expose several OTG-critical
+* status change events (from the transceiver) otherwise.
+*/
+ devctl = musb_readb(mregs, MUSB_DEVCTL);
+ DBG(7, Poll devctl %02x (%s)\n, devctl, otg_state_string(musb));
+
+ spin_lock_irqsave(musb-lock, flags);
+ switch (musb-xceiv-state) {
[...]
+ case OTG_STATE_A_WAIT_VFALL:
So, are you sure there's no need to call mod_timer() here for RTL 1.8?
+ musb-xceiv-state = OTG_STATE_A_WAIT_VRISE;
+ musb_writel(musb-ctrl_base, CORE_INTR_SRC_SET_REG,
+ MUSB_INTR_VBUSERROR USB_INTR_USB_SHIFT);
+ break;
+ case OTG_STATE_B_IDLE:
+ if (!is_peripheral_enabled(musb))
+ break;
Hm, davinci.c sets DevCtl.Session here and I'm also doing it in da8xx.c --
can you comment why you don't do that too?
+ devctl = musb_readb(mregs, MUSB_DEVCTL);
+ if (devctl MUSB_DEVCTL_BDEVICE)
+ mod_timer(otg_workaround, jiffies + POLL_SECONDS * HZ);
+ else
+ musb-xceiv-state = OTG_STATE_A_IDLE;
+ break;
[...]
+static irqreturn_t am35x_interrupt(int irq, void *hci)
+{
+ struct musb *musb = hci;
+ void __iomem *reg_base = musb-ctrl_base;
+ unsigned long flags;
+ irqreturn_t ret = IRQ_NONE;
+ u32 epintr, usbintr, lvl_intr;
+
+ spin_lock_irqsave(musb-lock, flags);
+
+ /* Get endpoint interrupts */
+ epintr = musb_readl(reg_base, EP_INTR_SRC_MASKED_REG);
+
+ if (epintr) {
+ musb_writel(reg_base, EP_INTR_SRC_CLEAR_REG, epintr);
+
+ musb-int_rx =
+ (epintr AM35X_RX_INTR_MASK) USB_INTR_RX_SHIFT;
+ musb-int_tx =
+ (epintr AM35X_TX_INTR_MASK) USB_INTR_TX_SHIFT;
+ }
Perhaps this should be placed after the following check...
+ /* Get usb core interrupts */
+ usbintr = musb_readl(reg_base, CORE_INTR_SRC_MASKED_REG);
+ if (!usbintr !epintr)
+ goto eoi;
+
+ if (usbintr) {
+ musb_writel(reg_base, CORE_INTR_SRC_CLEAR_REG, usbintr);
+
+ musb-int_usb =
+ (usbintr USB_INTR_USB_MASK) USB_INTR_USB_SHIFT;
+ }
[...]
+ if (usbintr (USB_INTR_DRVVBUS USB_INTR_USB_SHIFT)) {
+ int drvvbus = musb_readl(reg_base, USB_STAT_REG);
+ void __iomem *mregs = musb-mregs;
+ u8 devctl = musb_readb(mregs, MUSB_DEVCTL);
+ int err;
[...]
+ } else if (is_host_enabled(musb) drvvbus) {
+ musb-is_active = 1;
I dropped this line from da8xx.c as per this change to davinci.c:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=89368d3d11a5b2eff83ad8e752be67f77a372bad
[...]
+int __init musb_platform_init(struct musb *musb, void *board_data)
+{
+ void __iomem *reg_base = musb-ctrl_base;
+ struct clk *otg_fck;
+ u32 rev, lvl_intr, sw_reset;
+
+ musb-mregs += USB_MENTOR_CORE_OFFSET;
+
+ if (musb-set_clock)
+ musb-set_clock(musb-clock, 1);
+ else
+ clk_enable(musb-clock);
+ DBG(2, usbotg_ck=%lud\n, clk_get_rate(musb-clock));
+
+ otg_fck = clk_get(musb-controller, fck);
Can't this fail?
+ clk_enable(otg_fck);
+ DBG(2, usbotg_phy_ck=%lud\n, clk_get_rate(otg_fck));
+
+ /* Returns zero if e.g. not clocked */
+ rev =
Re: [PATCH 1/3] omap mailbox: extend API to take a callback param
On Fri, Jul 2, 2010 at 3:23 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: It would be nice if you send patches to LOML and LAKML too for next time. Sure. -- 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
Re: [PATCH v2 10/13] OMAP: create omap_devices for MPU, DSP, L3
Hi,
On Fri, 2 Jul 2010, Paul Walmsley wrote:
On Tue, 29 Jun 2010, Kevin Hilman wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Create simple omap_devices for the main processors and busses.
I've reworked this patch so that it is no longer using early devices,
updated version below.
Thanks for these changes, this seems better than the early_platform_device
approach. I've made a few more changes:
Just FYI, after this patch, 2420 platforms (and presumably 2430 platforms
also) emit this warning on boot:
[0.057067] WARNING: at arch/arm/mach-omap2/pm.c:53
_init_omap_device+0x80/0xa0()
[0.057098] _init_omap_device: could not find omap_hwmod for iva
[0.057128] Modules linked in:
[0.057189] [c002a580] (unwind_backtrace+0x0/0xec) from [c004a084]
(warn_slowpath_common+0x4c/0x64)
[0.057250] [c004a084] (warn_slowpath_common+0x4c/0x64) from [c004a11c]
(warn_slowpath_fmt+0x2c/0x3)
[0.057342] [c004a11c] (warn_slowpath_fmt+0x2c/0x3c) from [c002ef90]
(_init_omap_device+0x80/0xa0)
[0.057403] [c002ef90] (_init_omap_device+0x80/0xa0) from [c000e360]
(omap2_common_pm_init+0x20/0x4)
[0.057495] [c000e360] (omap2_common_pm_init+0x20/0x48) from [c0024384]
(do_one_initcall+0x5c/0x1b4)
[0.057556] [c0024384] (do_one_initcall+0x5c/0x1b4) from [c00083f8]
(kernel_init+0x90/0x144)
[0.057647] [c00083f8] (kernel_init+0x90/0x144) from [c0025dd0]
(kernel_thread_exit+0x0/0x8)
[0.057708] ---[ end trace dec6997083161631 ]---
This appears to be due to the lack of an IVA hwmod for 2420/2430, so I've
added one based on Benoît's patch for 3xxx (below). This fixes the
warnings.
- Paul
OMAP2: hwmod data: add IVA1 (2420), IVA2 (2430) hwmods
From: Paul Walmsley p...@pwsan.com
Add IVA1 hwmod data for OMAP2420 and IVA2 hwmod data for 2430. The data
is based on Benoît Cousson's hwmod data for the OMAP3 IVA blocks.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 30 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 32 ++--
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 8c90b27..3cc768e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -30,6 +30,7 @@
*/
static struct omap_hwmod omap2420_mpu_hwmod;
+static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
@@ -136,11 +137,40 @@ static struct omap_hwmod omap2420_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/*
+ * IVA1 interface data
+ */
+
+/* IVA - L3 interface */
+static struct omap_hwmod_ocp_if omap2420_l3__iva = {
+ .master = omap2420_l3_main_hwmod,
+ .slave = omap2420_iva_hwmod,
+ .clk= iva1_ifck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap2420_iva_masters[] = {
+ omap2420_l3__iva,
+};
+
+/*
+ * IVA2 (IVA2)
+ */
+
+static struct omap_hwmod omap2420_iva_hwmod = {
+ .name = iva,
+ .class = iva_hwmod_class,
+ .masters= omap2420_iva_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_iva_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
omap2420_l4_wkup_hwmod,
omap2420_mpu_hwmod,
+ omap2420_iva_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c0f3311..4526628 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -30,6 +30,7 @@
*/
static struct omap_hwmod omap2430_mpu_hwmod;
+static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
@@ -70,8 +71,6 @@ static struct omap_hwmod omap2430_l3_main_hwmod = {
};
static struct omap_hwmod omap2430_l4_wkup_hwmod;
-static struct omap_hwmod omap2430_mmc1_hwmod;
-static struct omap_hwmod omap2430_mmc2_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2430_l4_core__l4_wkup = {
@@ -138,11 +137,40 @@ static struct omap_hwmod omap2430_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * IVA2_1 interface data
+ */
+
+/* IVA2 - L3 interface */
+static struct omap_hwmod_ocp_if omap2430_l3__iva = {
+ .master = omap2430_l3_main_hwmod,
+ .slave = omap2430_iva_hwmod,
+ .clk= dsp_fck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
[PATCH 00/20] OMAP: clock, hwmod, omap_device, PM constraints: patches for 2.6.36
Hello,
Here are some OMAP clock, hwmod, omap_device, and PM constraint patches
for the 2.6.36 merge window.
Notable changes include:
- a fix for sporadic USBTLL clk_enable() crashes on OMAP3
- many hwmod fixes and improvements
- kerneldoc documentation for OMAP clock-related structures
- a minimum clock rate power management constraint interface
This series has been compile-tested with omap_osk_5912_defconfig,
n8x0_defconfig, omap_2430sdp_defconfig, omap3_defconfig,
omap3_beagle_defconfig, omap_3630sdp_defconfig, and
omap_4430sdp_defconfig. Boot-tested on N800 and OMAP3530 Beagle.
- Paul
---
Anand Gadiyar (1):
OMAP3: wait on IDLEST after enabling USBTLL fclk
Benoit Cousson (1):
OMAP23: hwmod: Remove _hwmod prefix in name string
Kevin Hilman (8):
OMAP24xx: CM: fix mask used for checking IDLEST status
OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
OMAP: hwmod: add non-locking versions of enable and idle functions
OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
OMAP: PM: create omap_devices for MPU, DSP, L3
OMAP: hwmod data: add class for IVA hwmods
OMAP23: hwmod: Replace l3 - l3_main
OMAP3: hwmod data: add data for OMAP3 IVA2
Paul Walmsley (9):
OMAP: clock: add kerneldoc for structures; move flags closer to structs
OMAP1: OPP: add KConfig entry for 96MHz ARM rate (using a 12MHz
oscillator)
OMAP1: clock: some cleanup
OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in
_setup()
OMAP2: hwmod data: add IVA1 (2420), IVA2 (2430) hwmods
OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_va
OMAP2+: hwmod/device: update documentation and copyright
OMAP: PM constraints: add return values; add requesting device param to
omap_pm_set_max_dev_wakeup_lat()
OMAP: PM constraints: add omap_pm_set_min_clk_rate()
Rajendra Nayak (1):
OMAP4: hwmod: Enable omap_device build for OMAP4
size:
textdata bss dec hex filename
6104613 1919040 5708833 13732486 d18a86 vmlinux.omap3defconfig.orig
6106345 1919424 5708833 13734602 d192ca vmlinux.omap3defconfig.patched
arch/arm/mach-omap1/Kconfig |6 +
arch/arm/mach-omap1/clock.c | 22 ++--
arch/arm/mach-omap1/clock.h |2
arch/arm/mach-omap1/clock_data.c | 129 -
arch/arm/mach-omap2/Makefile |4 -
arch/arm/mach-omap2/clock3xxx_data.c |2
arch/arm/mach-omap2/cm.c |6 +
arch/arm/mach-omap2/io.c | 11 ++
arch/arm/mach-omap2/omap_hwmod.c | 106 +++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c| 79 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c| 81 +++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 92 --
arch/arm/mach-omap2/omap_hwmod_common_data.c |3 +
arch/arm/mach-omap2/omap_hwmod_common_data.h |1
arch/arm/mach-omap2/pm.c | 84
arch/arm/plat-omap/Makefile |1
arch/arm/plat-omap/i2c.c | 12 ++
arch/arm/plat-omap/include/plat/clock.h | 130 +
arch/arm/plat-omap/include/plat/common.h |4 +
arch/arm/plat-omap/include/plat/omap-pm.h | 130 +++--
arch/arm/plat-omap/include/plat/omap_device.h |2
arch/arm/plat-omap/include/plat/omap_hwmod.h | 14 ++-
arch/arm/plat-omap/omap-pm-noop.c | 61 +---
arch/arm/plat-omap/omap_device.c | 33 ++
24 files changed, 790 insertions(+), 225 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm.c
--
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 01/20] OMAP3: wait on IDLEST after enabling USBTLL fclk
From: Anand Gadiyar gadi...@ti.com
We need to wait on the IDLEST bit after the clocks are enabled
before attempting to access any register.
Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
i-clock is enabled first, the clkops_omap2_dflt_wait is
short-circuited as the companion f-clock is not enabled.
This can cause a data abort if the IDLEST has not transitioned,
and we try to access a USBTLL register.
Since the USBTLL i-clock and f-clock could be enabled in any order,
this is a bug. Fix it by changing the clkops for the f-clock.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 41b155a..c226798 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1408,7 +1408,7 @@ static struct clk ts_fck = {
static struct clk usbtll_fck = {
.name = usbtll_fck,
- .ops= clkops_omap2_dflt,
+ .ops= clkops_omap2_dflt_wait,
.parent = dpll5_m2_ck,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
.enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT,
--
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 02/20] OMAP: clock: add kerneldoc for structures; move flags closer to structs
Add kerneldoc for struct clk, struct clksel_rate, struct clksel. Move
flag macros for struct clk.flags and struct clksel_rate.flags closer
to the structures.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/plat/clock.h | 130 ++-
1 files changed, 107 insertions(+), 23 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index dfc472c..fef4696 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -19,6 +19,22 @@ struct module;
struct clk;
struct clockdomain;
+/**
+ * struct clkops - some clock function pointers
+ * @enable: fn ptr that enables the current clock in hardware
+ * @disable: fn ptr that enables the current clock in hardware
+ * @find_idlest: function returning the IDLEST register for the clock's IP blk
+ * @find_companion: function returning the companion clk reg for the clock
+ *
+ * A companion clk is an accompanying clock to the one being queried
+ * that must be enabled for the IP module connected to the clock to
+ * become accessible by the hardware. Neither @find_idlest nor
+ * @find_companion should be needed; that information is IP
+ * block-specific; the hwmod code has been created to handle this, but
+ * until hwmod data is ready and drivers have been converted to use PM
+ * runtime calls in place of clk_enable()/clk_disable(), @find_idlest and
+ * @find_companion must, unfortunately, remain.
+ */
struct clkops {
int (*enable)(struct clk *);
void(*disable)(struct clk *);
@@ -30,12 +46,45 @@ struct clkops {
#ifdef CONFIG_ARCH_OMAP2PLUS
+/* struct clksel_rate.flags possibilities */
+#define RATE_IN_242X (1 0)
+#define RATE_IN_243X (1 1)
+#define RATE_IN_3XXX (1 2)/* rates common to all OMAP3 */
+#define RATE_IN_3430ES2(1 3)/* 3430ES2 rates only */
+#define RATE_IN_36XX (1 4)
+#define RATE_IN_4430 (1 5)
+
+#define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
+#define RATE_IN_3430ES2PLUS(RATE_IN_3430ES2 | RATE_IN_36XX)
+
+/**
+ * struct clksel_rate - register bitfield values corresponding to clk divisors
+ * @val: register bitfield value (shifted to bit 0)
+ * @div: clock divisor corresponding to @val
+ * @flags: (see struct clksel_rate.flags possibilities above)
+ *
+ * @val should match the value of a read from struct clk.clksel_reg
+ * AND'ed with struct clk.clksel_mask, shifted right to bit 0.
+ *
+ * @div is the divisor that should be applied to the parent clock's rate
+ * to produce the current clock's rate.
+ *
+ * XXX @flags probably should be replaced with an struct omap_chip.
+ */
struct clksel_rate {
u32 val;
u8 div;
u8 flags;
};
+/**
+ * struct clksel - available parent clocks, and a pointer to their divisors
+ * @parent: struct clk * to a possible parent clock
+ * @rates: available divisors for this parent clock
+ *
+ * A struct clksel is always associated with one or more struct clks
+ * and one or more struct clksel_rates.
+ */
struct clksel {
struct clk *parent;
const struct clksel_rate *rates;
@@ -116,6 +165,60 @@ struct dpll_data {
#endif
+/* struct clk.flags possibilities */
+#define ENABLE_REG_32BIT (1 0)/* Use 32-bit access */
+#define CLOCK_IDLE_CONTROL (1 1)
+#define CLOCK_NO_IDLE_PARENT (1 2)
+#define ENABLE_ON_INIT (1 3)/* Enable upon framework init */
+#define INVERT_ENABLE (1 4)/* 0 enables, 1 disables */
+
+/**
+ * struct clk - OMAP struct clk
+ * @node: list_head connecting this clock into the full clock list
+ * @ops: struct clkops * for this clock
+ * @name: the name of the clock in the hardware (used in hwmod data and debug)
+ * @parent: pointer to this clock's parent struct clk
+ * @children: list_head connecting to the child clks' @sibling list_heads
+ * @sibling: list_head connecting this clk to its parent clk's @children
+ * @rate: current clock rate
+ * @enable_reg: register to write to enable the clock (see @enable_bit)
+ * @recalc: fn ptr that returns the clock's current rate
+ * @set_rate: fn ptr that can change the clock's current rate
+ * @round_rate: fn ptr that can round the clock's current rate
+ * @init: fn ptr to do clock-specific initialization
+ * @enable_bit: bitshift to write to enable/disable the clock (see @enable_reg)
+ * @usecount: number of users that have requested this clock to be enabled
+ * @fixed_div: when 0, this clock's rate is its parent's rate / @fixed_div
+ * @flags: see struct clk.flags possibilities above
+ * @clksel_reg: for clksel clks, register va containing src/divisor select
+ * @clksel_mask: bitmask in @clksel_reg for the src/divisor selector
+ * @clksel: for clksel clks, pointer to struct clksel for this
[PATCH 03/20] OMAP1: OPP: add KConfig entry for 96MHz ARM rate (using a 12MHz oscillator)
Add KConfig entry for one of the OMAP1 DVFS rates that was missing it. Based on the surrounding rate KConfigs and the oscillator frequency, this patch marks it as valid for all OMAP1 platforms -- Richard, Tuukka, Tony, perhaps you can comment if this does not look right? In the long term, all of these CONFIG_OMAP_ARM_*MHZ should be removed. The OPP settings should be associated with the platform information in the structure data (perhaps by extending the omap_chip defines). The selection of which rates to use should be handled at runtime; rates that are impossible due to xtal frequency mismatch or SoC-type mismatch should not be included. If implemented correctly, this should save some CPU time and some memory on OMAP1 kernels. Reported-by: Christoph Egger sicce...@cs.fau.de Reported-by: The VAMOS Research Project va...@i4.informatik.uni-erlangen.de Cc: Marek Vasut marek.va...@gmail.com Cc: Richard Woodruff r-woodru...@ti.com Cc: Tuukka Tikkanen tuukka.tikka...@nokia.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap1/Kconfig |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index b18d7c2..b9f0c4c 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -224,6 +224,12 @@ config OMAP_ARM_120MHZ help Enable 120MHz clock for OMAP CPU. If unsure, say N. +config OMAP_ARM_96MHZ + bool OMAP ARM 96 MHz CPU + depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_OMAP850) + help + Enable 96MHz clock for OMAP CPU. If unsure, say N. + config OMAP_ARM_60MHZ bool OMAP ARM 60 MHz CPU depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_OMAP850) -- 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 06/20] OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
From: Kevin Hilman khil...@deeprootsystems.com
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index e5530c5..a8b57a6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2420_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
.slaves = omap2420_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
@@ -95,7 +96,8 @@ static struct omap_hwmod omap2420_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
.slaves = omap2420_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -115,7 +117,8 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
.slaves = omap2420_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0852d95..8b1f74b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2430_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
.slaves = omap2430_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2430_l4_wkup_hwmod;
@@ -97,7 +98,8 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
.slaves = omap2430_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -117,7 +119,8 @@ static struct omap_hwmod omap2430_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
.slaves = omap2430_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 39b0c0e..e288b20 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -76,7 +76,8 @@ static struct omap_hwmod omap3xxx_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
.slaves = omap3xxx_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
@@ -106,7 +107,8 @@ static struct omap_hwmod omap3xxx_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
.slaves = omap3xxx_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_PER interconnect */
@@ -126,7 +128,8 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.masters_cnt=
[PATCH 04/20] OMAP1: clock: some cleanup
Convert most of the magic numbers in mach-omap1/clock_data.c to use
macros. Clean up a few comments to conform with Documentation/CodingStyle.
Mark the current clkops_uart as being OMAP16xx-only, and add some comments
to indicate that it does not belong there, for future cleanup.
This patch should not cause any functional changes.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/clock.c | 22 --
arch/arm/mach-omap1/clock.h |2 -
arch/arm/mach-omap1/clock_data.c | 129 ++
3 files changed, 116 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 6bbb1b8..b8c7fb9 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -11,7 +11,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include linux/module.h
#include linux/kernel.h
#include linux/list.h
#include linux/errno.h
@@ -34,9 +33,9 @@
__u32 arm_idlect1_mask;
struct clk *api_ck_p, *ck_dpll1_p, *ck_ref_p;
-/*-
+/*
* Omap1 specific clock functions
- *-*/
+ */
unsigned long omap1_uart_recalc(struct clk *clk)
{
@@ -523,7 +522,8 @@ const struct clkops clkops_dspck = {
.disable= omap1_clk_disable_dsp_domain,
};
-static int omap1_clk_enable_uart_functional(struct clk *clk)
+/* XXX SYSC register handling does not belong in the clock framework */
+static int omap1_clk_enable_uart_functional_16xx(struct clk *clk)
{
int ret;
struct uart_clk *uclk;
@@ -539,7 +539,8 @@ static int omap1_clk_enable_uart_functional(struct clk *clk)
return ret;
}
-static void omap1_clk_disable_uart_functional(struct clk *clk)
+/* XXX SYSC register handling does not belong in the clock framework */
+static void omap1_clk_disable_uart_functional_16xx(struct clk *clk)
{
struct uart_clk *uclk;
@@ -550,9 +551,10 @@ static void omap1_clk_disable_uart_functional(struct clk
*clk)
omap1_clk_disable_generic(clk);
}
-const struct clkops clkops_uart = {
- .enable = omap1_clk_enable_uart_functional,
- .disable= omap1_clk_disable_uart_functional,
+/* XXX SYSC register handling does not belong in the clock framework */
+const struct clkops clkops_uart_16xx = {
+ .enable = omap1_clk_enable_uart_functional_16xx,
+ .disable= omap1_clk_disable_uart_functional_16xx,
};
long omap1_clk_round_rate(struct clk *clk, unsigned long rate)
@@ -572,9 +574,9 @@ int omap1_clk_set_rate(struct clk *clk, unsigned long rate)
return ret;
}
-/*-
+/*
* Omap1 clock reset and init functions
- *-*/
+ */
#ifdef CONFIG_OMAP_RESET_CLOCKS
diff --git a/arch/arm/mach-omap1/clock.h b/arch/arm/mach-omap1/clock.h
index 75d0d7d..eaf09ef 100644
--- a/arch/arm/mach-omap1/clock.h
+++ b/arch/arm/mach-omap1/clock.h
@@ -107,7 +107,7 @@ extern struct clk *api_ck_p, *ck_dpll1_p, *ck_ref_p;
extern const struct clkops clkops_dspck;
extern const struct clkops clkops_dummy;
-extern const struct clkops clkops_uart;
+extern const struct clkops clkops_uart_16xx;
extern const struct clkops clkops_generic;
#endif
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index aa8558a..ca4bd86 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -8,6 +8,10 @@
* 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.
+ *
+ * To do:
+ * - Clocks that are only available on some chips should be marked with the
+ * chips that they are present on.
*/
#include linux/kernel.h
@@ -23,9 +27,49 @@
#include clock.h
-/*
+/* Some ARM_IDLECT1 bit shifts - used in struct arm_idlect1_clk */
+#define IDL_CLKOUT_ARM_SHIFT 12
+#define IDLTIM_ARM_SHIFT 9
+#define IDLAPI_ARM_SHIFT 8
+#define IDLIF_ARM_SHIFT6
+#define IDLLB_ARM_SHIFT4 /*
undocumented? */
+#define OMAP1510_IDLLCD_ARM_SHIFT 3 /* undocumented? */
+#define IDLPER_ARM_SHIFT 2
+#define IDLXORP_ARM_SHIFT 1
+#define IDLWDT_ARM_SHIFT 0
+
+/* Some MOD_CONF_CTRL_0 bit shifts - used in struct clk.enable_bit */
+#define CONF_MOD_UART3_CLK_MODE_R 31
+#define CONF_MOD_UART2_CLK_MODE_R 30
+#define CONF_MOD_UART1_CLK_MODE_R 29
[PATCH 08/20] OMAP: hwmod: add non-locking versions of enable and idle functions
From: Kevin Hilman khil...@deeprootsystems.com
Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.
Most users should not need these and usage of theses should be
controlled to understand why access is being done in atomic context.
For this reason, the non-locking functions are only exposed at the
hwmod level and not at the omap-device level.
The use-case that led to the need for the non-locking versions is
hwmods that are enabled/idled from within the core idle/suspend path.
Since interrupts are already disabled here, the mutex-based locking in
hwmod can sleep and will cause potential deadlocks.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 19 ++-
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 95c9a5f..47943ec 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -883,7 +883,7 @@ static int _reset(struct omap_hwmod *oh)
}
/**
- * _enable - enable an omap_hwmod
+ * _omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
* Enables an omap_hwmod @oh such that the MPU can access the hwmod's
@@ -891,7 +891,7 @@ static int _reset(struct omap_hwmod *oh)
* Returns -EINVAL if the hwmod is in the wrong state or passes along
* the return value of _wait_target_ready().
*/
-static int _enable(struct omap_hwmod *oh)
+int _omap_hwmod_enable(struct omap_hwmod *oh)
{
int r;
@@ -936,7 +936,7 @@ static int _enable(struct omap_hwmod *oh)
* no further work. Returns -EINVAL if the hwmod is in the wrong
* state or returns 0.
*/
-static int _idle(struct omap_hwmod *oh)
+int _omap_hwmod_idle(struct omap_hwmod *oh)
{
if (oh-_state != _HWMOD_STATE_ENABLED) {
WARN(1, omap_hwmod: %s: idle state can only be entered from
@@ -1026,7 +1026,7 @@ static int _setup(struct omap_hwmod *oh)
oh-_state = _HWMOD_STATE_INITIALIZED;
- r = _enable(oh);
+ r = _omap_hwmod_enable(oh);
if (r) {
pr_warning(omap_hwmod: %s: cannot be enabled (%d)\n,
oh-name, oh-_state);
@@ -1038,7 +1038,7 @@ static int _setup(struct omap_hwmod *oh)
* XXX Do the OCP_SYSCONFIG bits need to be
* reprogrammed after a reset? If not, then this can
* be removed. If they do, then probably the
-* _enable() function should be split to avoid the
+* _omap_hwmod_enable() function should be split to avoid the
* rewrite of the OCP_SYSCONFIG register.
*/
if (oh-class-sysc) {
@@ -1048,7 +1048,7 @@ static int _setup(struct omap_hwmod *oh)
}
if (!(oh-flags HWMOD_INIT_NO_IDLE))
- _idle(oh);
+ _omap_hwmod_idle(oh);
return 0;
}
@@ -1289,12 +1289,13 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
return -EINVAL;
mutex_lock(omap_hwmod_mutex);
- r = _enable(oh);
+ r = _omap_hwmod_enable(oh);
mutex_unlock(omap_hwmod_mutex);
return r;
}
+
/**
* omap_hwmod_idle - idle an omap_hwmod
* @oh: struct omap_hwmod *
@@ -1308,7 +1309,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
return -EINVAL;
mutex_lock(omap_hwmod_mutex);
- _idle(oh);
+ _omap_hwmod_idle(oh);
mutex_unlock(omap_hwmod_mutex);
return 0;
@@ -1410,7 +1411,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
mutex_lock(omap_hwmod_mutex);
r = _reset(oh);
if (!r)
- r = _enable(oh);
+ r = _omap_hwmod_enable(oh);
mutex_unlock(omap_hwmod_mutex);
return r;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0eccc09..253f6e5 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -486,7 +486,9 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh));
int omap_hwmod_late_init(void);
int omap_hwmod_enable(struct omap_hwmod *oh);
+int _omap_hwmod_enable(struct omap_hwmod *oh);
int omap_hwmod_idle(struct omap_hwmod *oh);
+int _omap_hwmod_idle(struct omap_hwmod *oh);
int omap_hwmod_shutdown(struct omap_hwmod *oh);
int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
--
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 10/20] OMAP4: hwmod: Enable omap_device build for OMAP4
From: Rajendra Nayak rna...@ti.com Enable omap_device layer support for OMAP4, so that drivers can use them to enable/idle/shutdown devices. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/plat-omap/Makefile |1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6c6d7c6..2fa3418 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -15,7 +15,7 @@ clock-common = clock.o clock_common_data.o \ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) -obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) +obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) $(hwmod-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..9405831 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_ARCH_OMAP2) += omap_device.o obj-$(CONFIG_ARCH_OMAP3) += omap_device.o +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o -- 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 14/20] OMAP23: hwmod: Replace l3 - l3_main
From: Kevin Hilman khil...@deeprootsystems.com
Replace all the struct that contain l3 with l3_main in order
to be consistent with the OMAP4 naming convention.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 34 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 34 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 42 ++--
3 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 646386c..8c90b27 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -30,41 +30,41 @@
*/
static struct omap_hwmod omap2420_mpu_hwmod;
-static struct omap_hwmod omap2420_l3_hwmod;
+static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
/* L3 - L4_CORE interface */
-static struct omap_hwmod_ocp_if omap2420_l3__l4_core = {
- .master = omap2420_l3_hwmod,
+static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
+ .master = omap2420_l3_main_hwmod,
.slave = omap2420_l4_core_hwmod,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* MPU - L3 interface */
-static struct omap_hwmod_ocp_if omap2420_mpu__l3 = {
+static struct omap_hwmod_ocp_if omap2420_mpu__l3_main = {
.master = omap2420_mpu_hwmod,
- .slave = omap2420_l3_hwmod,
+ .slave = omap2420_l3_main_hwmod,
.user = OCP_USER_MPU,
};
/* Slave interfaces on the L3 interconnect */
-static struct omap_hwmod_ocp_if *omap2420_l3_slaves[] = {
- omap2420_mpu__l3,
+static struct omap_hwmod_ocp_if *omap2420_l3_main_slaves[] = {
+ omap2420_mpu__l3_main,
};
/* Master interfaces on the L3 interconnect */
-static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
- omap2420_l3__l4_core,
+static struct omap_hwmod_ocp_if *omap2420_l3_main_masters[] = {
+ omap2420_l3_main__l4_core,
};
/* L3 */
-static struct omap_hwmod omap2420_l3_hwmod = {
+static struct omap_hwmod omap2420_l3_main_hwmod = {
.name = l3_main,
.class = l3_hwmod_class,
- .masters= omap2420_l3_masters,
- .masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
- .slaves = omap2420_l3_slaves,
- .slaves_cnt = ARRAY_SIZE(omap2420_l3_slaves),
+ .masters= omap2420_l3_main_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_l3_main_masters),
+ .slaves = omap2420_l3_main_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_l3_main_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
.flags = HWMOD_NO_IDLEST,
};
@@ -80,7 +80,7 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] = {
- omap2420_l3__l4_core,
+ omap2420_l3_main__l4_core,
};
/* Master interfaces on the L4_CORE interconnect */
@@ -123,7 +123,7 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
/* Master interfaces on the MPU device */
static struct omap_hwmod_ocp_if *omap2420_mpu_masters[] = {
- omap2420_mpu__l3,
+ omap2420_mpu__l3_main,
};
/* MPU */
@@ -137,7 +137,7 @@ static struct omap_hwmod omap2420_mpu_hwmod = {
};
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
- omap2420_l3_hwmod,
+ omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
omap2420_l4_wkup_hwmod,
omap2420_mpu_hwmod,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index b2100cf..c0f3311 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -30,41 +30,41 @@
*/
static struct omap_hwmod omap2430_mpu_hwmod;
-static struct omap_hwmod omap2430_l3_hwmod;
+static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
/* L3 - L4_CORE interface */
-static struct omap_hwmod_ocp_if omap2430_l3__l4_core = {
- .master = omap2430_l3_hwmod,
+static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
+ .master = omap2430_l3_main_hwmod,
.slave = omap2430_l4_core_hwmod,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* MPU - L3 interface */
-static struct omap_hwmod_ocp_if omap2430_mpu__l3 = {
+static struct omap_hwmod_ocp_if omap2430_mpu__l3_main = {
.master = omap2430_mpu_hwmod,
- .slave = omap2430_l3_hwmod,
+ .slave = omap2430_l3_main_hwmod,
.user = OCP_USER_MPU,
};
/* Slave interfaces on the L3 interconnect */
-static struct omap_hwmod_ocp_if *omap2430_l3_slaves[] = {
- omap2430_mpu__l3,
+static struct omap_hwmod_ocp_if *omap2430_l3_main_slaves[]
[PATCH 20/20] OMAP: PM constraints: add omap_pm_set_min_clk_rate()
Add omap_pm_set_min_clk_rate(). This constraint is meant for use by device drivers to translate a certain device-specific performance constraint (e.g., minimum polygons per second) to a clock rate for the driver's device, given the driver's intimate knowledge of the device hardware (e.g., device type, device hardware revision, firmware revision, etc.) From a general PM core perspective, clock rate is probably the closest general analog to performance that is available, but the exact mapping from a use-case-specific performance constraint to clock rate must be done by the driver. Drivers intended for upstream merging shouldn't hardcode specific clock rates in their code without basing those rates on some performance criteria requested through the driver's subsystem (ideally, from userspace). Imre Deak imre.d...@nokia.com described the need and use-case for this constraint, and discussed the implementation - thanks, Imre. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Imre Deak imre.d...@nokia.com --- arch/arm/plat-omap/include/plat/omap-pm.h | 61 + arch/arm/plat-omap/omap-pm-noop.c | 27 + 2 files changed, 88 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-omap/include/plat/omap-pm.h index 3d468ba..728fbb9 100644 --- a/arch/arm/plat-omap/include/plat/omap-pm.h +++ b/arch/arm/plat-omap/include/plat/omap-pm.h @@ -16,6 +16,7 @@ #include linux/device.h #include linux/cpufreq.h +#include linux/clk.h #include powerdomain.h @@ -212,6 +213,66 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev, int omap_pm_set_max_sdma_lat(struct device *dev, long t); +/** + * omap_pm_set_min_clk_rate - set minimum clock rate requested by @dev + * @dev: struct device * requesting the constraint + * @clk: struct clk * to set the minimum rate constraint on + * @r: minimum rate in Hz + * + * Request that the minimum clock rate on the device @dev's clk @clk + * be no less than @r Hz. + * + * It is expected that the OMAP PM code will use this information to + * find an OPP or clock setting that will satisfy this clock rate + * constraint, along with any other applicable system constraints on + * the clock rate or corresponding voltage, etc. + * + * omap_pm_set_min_clk_rate() differs from the clock code's + * clk_set_rate() in that it considers other constraints before taking + * any hardware action, and may change a system OPP rather than just a + * clock rate. clk_set_rate() is intended to be a low-level + * interface. + * + * omap_pm_set_min_clk_rate() is easily open to abuse. A better API + * would be something like omap_pm_set_min_dev_performance(); + * however, there is no easily-generalizable concept of performance + * that applies to all devices. Only a device (and possibly the + * device subsystem) has both the subsystem-specific knowledge, and + * the hardware IP block-specific knowledge, to translate a constraint + * on touchscreen sampling accuracy or number of pixels or polygons + * rendered per second to a clock rate. This translation can be + * dependent on the hardware IP block's revision, or firmware version, + * and the driver is the only code on the system that has this + * information and can know how to translate that into a clock rate. + * + * The intended use-case for this function is for userspace or other + * kernel code to communicate a particular performance requirement to + * a subsystem; then for the subsystem to communicate that requirement + * to something that is meaningful to the device driver; then for the + * device driver to convert that requirement to a clock rate, and to + * then call omap_pm_set_min_clk_rate(). + * + * Users of this function (such as device drivers) should not simply + * call this function with some high clock rate to ensure high + * performance. Rather, the device driver should take a performance + * constraint from its subsystem, such as render at least X polygons + * per second, and use some formula or table to convert that into a + * clock rate constraint given the hardware type and hardware + * revision. Device drivers or subsystems should not assume that they + * know how to make a power/performance tradeoff - some device use + * cases may tolerate a lower-fidelity device function for lower power + * consumption; others may demand a higher-fidelity device function, + * no matter what the power consumption. + * + * Multiple calls to omap_pm_set_min_clk_rate() will replace the + * previous rate value for the device @dev. To remove the minimum clock + * rate constraint for the device, call with r = 0. + * + * Returns -EINVAL for an invalid argument, -ERANGE if the constraint + * is not satisfiable, or 0 upon success. + */ +int omap_pm_set_min_clk_rate(struct device *dev, struct clk *c, long r); + /* * DSP Bridge-specific constraints */ diff --git a/arch/arm/plat-omap/omap-pm-noop.c
[PATCH 19/20] OMAP: PM constraints: add return values; add requesting device param to omap_pm_set_max_dev_wakeup_lat()
Add return values to the PM constraint functions. This allows the PM
core to provide feedback to the caller if a constraint is not
possible. Update the one upstream user of omap_pm_set_max_mpu_wakeup_lat()
to add a compatibility wrapper, needed until the driver is changed.
Update some of the documentation to conform more closely to kerneldoc style.
Add an additional device parameter to omap_pm_set_max_dev_wakeup_lat()
to identify the device requesting the constraint. This is so repeated calls
to omap_pm_set_max_dev_wakeup_lat() with the same requesting device can
override the device's previously-set constraint. Also, it allows the PM
core to make a decision as to whether or not the constraint should be
satisfied, based on the caller's identity.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/i2c.c | 12 +
arch/arm/plat-omap/include/plat/omap-pm.h | 69 -
arch/arm/plat-omap/omap-pm-noop.c | 34 +-
3 files changed, 71 insertions(+), 44 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index eec2b49..a5ce4f0 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -138,6 +138,16 @@ static inline int omap1_i2c_add_bus(struct platform_device
*pdev, int bus_id)
return platform_device_register(pdev);
}
+/*
+ * XXX This function is a temporary compatibility wrapper - only
+ * needed until the I2C driver can be converted to call
+ * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
+ */
+static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, t);
+}
+
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int bus_id)
{
struct resource *res;
@@ -168,7 +178,7 @@ static inline int omap2_i2c_add_bus(struct platform_device
*pdev, int bus_id)
struct omap_i2c_bus_platform_data *pd;
pd = pdev-dev.platform_data;
- pd-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat;
+ pd-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
}
return platform_device_register(pdev);
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 3ee41d7..3d468ba 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -1,8 +1,8 @@
/*
* omap-pm.h - OMAP power management interface
*
- * Copyright (C) 2008-2009 Texas Instruments, Inc.
- * Copyright (C) 2008-2009 Nokia Corporation
+ * Copyright (C) 2008-2010 Texas Instruments, Inc.
+ * Copyright (C) 2008-2010 Nokia Corporation
* Paul Walmsley
*
* Interface developed by (in alphabetical order): Karthik Dasu, Jouni
@@ -89,7 +89,7 @@ void omap_pm_if_exit(void);
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
- * greater than 't' microseconds. Interrupt latency in this case is
+ * greater than @t microseconds. Interrupt latency in this case is
* defined as the elapsed time from the occurrence of a hardware or
* timer interrupt to the time when the device driver's interrupt
* service routine has been entered by the MPU.
@@ -105,15 +105,19 @@ void omap_pm_if_exit(void);
* elapsed from when a device driver enables a hardware device with
* clk_enable(), to when the device is ready for register access or
* other use. To control this device wakeup latency, use
- * set_max_dev_wakeup_lat()
+ * omap_pm_set_max_dev_wakeup_lat()
*
- * Multiple calls to set_max_mpu_wakeup_lat() will replace the
+ * Multiple calls to omap_pm_set_max_mpu_wakeup_lat() will replace the
* previous t value. To remove the latency target for the MPU, call
* with t = -1.
*
- * No return value.
+ * XXX This constraint will be deprecated soon in favor of the more
+ * general omap_pm_set_max_dev_wakeup_lat()
+ *
+ * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
+ * is not satisfiable, or 0 upon success.
*/
-void omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
/**
@@ -123,8 +127,8 @@ void omap_pm_set_max_mpu_wakeup_lat(struct device *dev,
long t);
* @r: minimum throughput (in KiB/s)
*
* Request that the minimum data throughput on the OCP interconnect
- * attached to device 'dev' interconnect agent 'tbus_id' be no less
- * than 'r' KiB/s.
+ * attached to device @dev interconnect agent @tbus_id be no less
+ * than @r KiB/s.
*
* It is expected that the OMAP PM or bus code will use this
* information to set the interconnect clock to run at the lowest
@@ -138,40 +142,44 @@ void omap_pm_set_max_mpu_wakeup_lat(struct device *dev,
long t);
* code will also need to add an minimum L3 interconnect speed
* constraint,
*
- * Multiple calls to set_min_bus_tput() will replace the previous rate
- *
[PATCH 18/20] OMAP2+: hwmod/device: update documentation and copyright
Update some minor documentation issues and update copyright for
omap_device/omap_hwmod code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 17 -
arch/arm/plat-omap/omap_device.c |9 ++---
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b012057..4002774 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -422,7 +422,7 @@ static int _init_main_clk(struct omap_hwmod *oh)
}
/**
- * _init_interface_clk - get a struct clk * for the the hwmod's interface clks
+ * _init_interface_clks - get a struct clk * for the the hwmod's interface clks
* @oh: struct omap_hwmod *
*
* Called from _init_clocks(). Populates the @oh OCP slave interface
@@ -1074,6 +1074,21 @@ void omap_hwmod_writel(u32 v, struct omap_hwmod *oh, u16
reg_offs)
__raw_writel(v, oh-_mpu_rt_va + reg_offs);
}
+/**
+ * omap_hwmod_set_slave_idlemode - set the hwmod's OCP slave idlemode
+ * @oh: struct omap_hwmod *
+ * @idlemode: SIDLEMODE field bits (shifted to bit 0)
+ *
+ * Sets the IP block's OCP slave idlemode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the SIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_slave_idlemode().
+ *
+ * XXX Does this function have any current users? If not, we should
+ * remove it; it is better to let the rest of the hwmod code handle this.
+ * Any users of this function should be scrutinized carefully.
+ */
int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode)
{
u32 v;
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index dee4629..ea0d659 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -1,7 +1,7 @@
/*
* omap_device implementation
*
- * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009-2010 Nokia Corporation
* Paul Walmsley, Kevin Hilman
*
* Developed in collaboration with (alphabetical order): Benoit
@@ -90,8 +90,11 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
-
-#define OMAP_DEVICE_MAGIC 0xf00dcafe
+/*
+ * OMAP_DEVICE_MAGIC: used to determine whether a struct omap_device
+ * obtained via container_of() is in fact a struct omap_device
+ */
+#define OMAP_DEVICE_MAGIC 0xf00dcafe
/* Private functions */
--
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 15/20] OMAP3: hwmod data: add data for OMAP3 IVA2
From: Kevin Hilman khil...@deeprootsystems.com
Add hwmod data for IVA2 module on OMAP3.
Naming of iva instead of iva2 to be aligned with OMAP4 naming done
by Benoit Cousson.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 30
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9d9cfb9..5d8eb58 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -32,6 +32,7 @@
*/
static struct omap_hwmod omap3xxx_mpu_hwmod;
+static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
@@ -168,12 +169,41 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * IVA2_2 interface data
+ */
+
+/* IVA2 - L3 interface */
+static struct omap_hwmod_ocp_if omap3xxx_l3__iva = {
+ .master = omap3xxx_l3_main_hwmod,
+ .slave = omap3xxx_iva_hwmod,
+ .clk= iva2_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_iva_masters[] = {
+ omap3xxx_l3__iva,
+};
+
+/*
+ * IVA2 (IVA2)
+ */
+
+static struct omap_hwmod omap3xxx_iva_hwmod = {
+ .name = iva,
+ .class = iva_hwmod_class,
+ .masters= omap3xxx_iva_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_iva_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
omap3xxx_l4_per_hwmod,
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
+ omap3xxx_iva_hwmod,
NULL,
};
--
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 13/20] OMAP: hwmod data: add class for IVA hwmods
From: Kevin Hilman khil...@deeprootsystems.com
Add a new hwmod class for IVA devices. To be used when hwmods
are created for IVA2 on OMAP3.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_common_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 1e80b91..08a1342 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -66,3 +66,6 @@ struct omap_hwmod_class mpu_hwmod_class = {
.name = mpu
};
+struct omap_hwmod_class iva_hwmod_class = {
+ .name = iva
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 3645a28..c34e98b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -20,5 +20,6 @@
extern struct omap_hwmod_class l3_hwmod_class;
extern struct omap_hwmod_class l4_hwmod_class;
extern struct omap_hwmod_class mpu_hwmod_class;
+extern struct omap_hwmod_class iva_hwmod_class;
#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 16/20] OMAP2: hwmod data: add IVA1 (2420), IVA2 (2430) hwmods
Add IVA1 hwmod data for OMAP2420 and IVA2 hwmod data for 2430. The data
is based on Benoît Cousson's hwmod data for the OMAP3 IVA blocks.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 30 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 32 ++--
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 8c90b27..3cc768e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -30,6 +30,7 @@
*/
static struct omap_hwmod omap2420_mpu_hwmod;
+static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
@@ -136,11 +137,40 @@ static struct omap_hwmod omap2420_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/*
+ * IVA1 interface data
+ */
+
+/* IVA - L3 interface */
+static struct omap_hwmod_ocp_if omap2420_l3__iva = {
+ .master = omap2420_l3_main_hwmod,
+ .slave = omap2420_iva_hwmod,
+ .clk= iva1_ifck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap2420_iva_masters[] = {
+ omap2420_l3__iva,
+};
+
+/*
+ * IVA2 (IVA2)
+ */
+
+static struct omap_hwmod omap2420_iva_hwmod = {
+ .name = iva,
+ .class = iva_hwmod_class,
+ .masters= omap2420_iva_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_iva_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
omap2420_l4_wkup_hwmod,
omap2420_mpu_hwmod,
+ omap2420_iva_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c0f3311..4526628 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -30,6 +30,7 @@
*/
static struct omap_hwmod omap2430_mpu_hwmod;
+static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
@@ -70,8 +71,6 @@ static struct omap_hwmod omap2430_l3_main_hwmod = {
};
static struct omap_hwmod omap2430_l4_wkup_hwmod;
-static struct omap_hwmod omap2430_mmc1_hwmod;
-static struct omap_hwmod omap2430_mmc2_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2430_l4_core__l4_wkup = {
@@ -138,11 +137,40 @@ static struct omap_hwmod omap2430_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * IVA2_1 interface data
+ */
+
+/* IVA2 - L3 interface */
+static struct omap_hwmod_ocp_if omap2430_l3__iva = {
+ .master = omap2430_l3_main_hwmod,
+ .slave = omap2430_iva_hwmod,
+ .clk= dsp_fck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap2430_iva_masters[] = {
+ omap2430_l3__iva,
+};
+
+/*
+ * IVA2 (IVA2)
+ */
+
+static struct omap_hwmod omap2430_iva_hwmod = {
+ .name = iva,
+ .class = iva_hwmod_class,
+ .masters= omap2430_iva_masters,
+ .masters_cnt= ARRAY_SIZE(omap2430_iva_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+};
+
static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_l3_main_hwmod,
omap2430_l4_core_hwmod,
omap2430_l4_wkup_hwmod,
omap2430_mpu_hwmod,
+ omap2430_iva_hwmod,
NULL,
};
--
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 12/20] OMAP: PM: create omap_devices for MPU, DSP, L3
From: Kevin Hilman khil...@deeprootsystems.com
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
Also, move these common PM init functions into a common_pm_init call
that is called as a device_initcall(). The PM init is done at this level
to ensure that the driver core is initialized before initialized.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
[p...@pwsan.com: sparse warnings cleaned up; newly-created functions moved
from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed
to start with omap2 rather than omap]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |2 -
arch/arm/mach-omap2/io.c |2 -
arch/arm/mach-omap2/pm.c | 84 ++
arch/arm/plat-omap/include/plat/common.h |4 +
4 files changed, 90 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2fa3418..213f1df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
omap-2-3-common= irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 05c9cdb..2b983ac 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -44,6 +44,7 @@
#include plat/clockdomain.h
#include clockdomains.h
+
#include plat/omap_hwmod.h
/*
@@ -346,7 +347,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
omap_hwmod_late_init(skip_setup_idle);
- omap_pm_if_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
new file mode 100644
index 000..68f9f2e
--- /dev/null
+++ b/arch/arm/mach-omap2/pm.c
@@ -0,0 +1,84 @@
+/*
+ * pm.c - Common OMAP2+ power management-related code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * 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/io.h
+#include linux/err.h
+
+#include plat/omap-pm.h
+#include plat/omap_device.h
+#include plat/common.h
+
+static struct omap_device_pm_latency *pm_lats;
+
+static struct device *mpu_dev;
+static struct device *dsp_dev;
+static struct device *l3_dev;
+
+struct device *omap2_get_mpuss_device(void)
+{
+ WARN_ON_ONCE(!mpu_dev);
+ return mpu_dev;
+}
+
+struct device *omap2_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+
+struct device *omap2_get_l3_device(void)
+{
+ WARN_ON_ONCE(!l3_dev);
+ return l3_dev;
+}
+
+/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
+static int _init_omap_device(char *name, struct device **new_dev)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+
+ oh = omap_hwmod_lookup(name);
+ if (WARN(!oh, %s: could not find omap_hwmod for %s\n,
+__func__, name))
+ return -ENODEV;
+
+ od = omap_device_build(oh-name, 0, oh, NULL, 0, pm_lats, 0, false);
+ if (WARN(IS_ERR(od), %s: could not build omap_device for %s\n,
+__func__, name))
+ return -ENODEV;
+
+ *new_dev = od-pdev.dev;
+
+ return 0;
+}
+
+/*
+ * Build omap_devices for processors and bus.
+ */
+static void omap2_init_processor_devices(void)
+{
+ _init_omap_device(mpu, mpu_dev);
+ _init_omap_device(iva, dsp_dev);
+ _init_omap_device(l3_main, l3_dev);
+}
+
+static int __init omap2_common_pm_init(void)
+{
+ omap2_init_processor_devices();
+ omap_pm_if_init();
+
+ return 0;
+}
+device_initcall(omap2_common_pm_init);
+
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 5e4afbe..5cf9509 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -89,4 +89,8 @@ void omap2_set_globals_uart(struct omap_globals *);
} \
})
+extern struct device *omap2_get_mpuss_device(void);
+extern struct device *omap2_get_dsp_device(void);
+extern struct device *omap2_get_l3_device(void);
+
#endif /*
[PATCH 11/20] OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
From: Kevin Hilman khil...@deeprootsystems.com The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com [p...@pwsan.com: use an array index rather than pointer arithmetic] Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/omap_device.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index f899603..f9dec0d 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -359,7 +359,7 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_device *od; char *pdev_name2; struct resource *res = NULL; - int res_count; + int i, res_count; struct omap_hwmod **hwmods; if (!ohs || oh_cnt == 0 || !pdev_name) @@ -416,6 +416,9 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, else ret = omap_device_register(od); + for (i = 0; i oh_cnt; i++) + hwmods[i]-od = od; + if (ret) goto odbs_exit4; -- 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 09/20] OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in _setup()
On kernels that don't use the omap_device_enable() calls to enable
devices, leave all on-chip devices enabled in hwmod _setup().
Otherwise, accesses to those devices are likely to fail, crashing the
system. It's expected that kernels built without CONFIG_PM_RUNTIME
will be the primary use-case for this. This functionality is
controlled by adding an extra parameter to omap_hwmod_late_init().
This patch is based on the patch OMAP: hwmod: don't auto-disable
hwmod when !CONFIG_PM_RUNTIME by Kevin Hilman
khil...@deeprootsystems.com.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/io.c |9 ++
arch/arm/mach-omap2/omap_hwmod.c | 37 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |5 ++--
3 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..05c9cdb 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -313,6 +313,8 @@ static int __init _omap2_init_reprogram_sdrc(void)
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
+ u8 skip_setup_idle = 0;
+
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
@@ -337,8 +339,13 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
pr_err(Could not init clock framework - unknown CPU\n);
omap_serial_early_init();
+
+#ifndef CONFIG_PM_RUNTIME
+ skip_setup_idle = 1;
+#endif
if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
- omap_hwmod_late_init();
+ omap_hwmod_late_init(skip_setup_idle);
+
omap_pm_if_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 47943ec..d9e96fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -761,6 +761,7 @@ static struct omap_hwmod *_lookup(const char *name)
/**
* _init_clocks - clk_get() all clocks associated with this hwmod
* @oh: struct omap_hwmod *
+ * @data: not used; pass NULL
*
* Called by omap_hwmod_late_init() (after omap2_clk_init()).
* Resolves all clock names embedded in the hwmod. Must be called
@@ -768,7 +769,7 @@ static struct omap_hwmod *_lookup(const char *name)
* has not yet been registered or if the clocks have already been
* initialized, 0 on success, or a non-zero error on failure.
*/
-static int _init_clocks(struct omap_hwmod *oh)
+static int _init_clocks(struct omap_hwmod *oh, void *data)
{
int ret = 0;
@@ -993,19 +994,25 @@ static int _shutdown(struct omap_hwmod *oh)
/**
* _setup - do initial configuration of omap_hwmod
* @oh: struct omap_hwmod *
+ * @skip_setup_idle_p: do not idle hwmods at the end of the fn if 1
*
* Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh
- * OCP_SYSCONFIG register. Must be called with omap_hwmod_mutex
- * held. Returns -EINVAL if the hwmod is in the wrong state or returns
- * 0.
+ * OCP_SYSCONFIG register. Must be called with omap_hwmod_mutex held.
+ * @skip_setup_idle is intended to be used on a system that will not
+ * call omap_hwmod_enable() to enable devices (e.g., a system without
+ * PM runtime). Returns -EINVAL if the hwmod is in the wrong state or
+ * returns 0.
*/
-static int _setup(struct omap_hwmod *oh)
+static int _setup(struct omap_hwmod *oh, void *data)
{
int i, r;
+ u8 skip_setup_idle;
- if (!oh)
+ if (!oh || !data)
return -EINVAL;
+ skip_setup_idle = *(u8 *)data;
+
/* Set iclk autoidle mode */
if (oh-slaves_cnt 0) {
for (i = 0; i oh-slaves_cnt; i++) {
@@ -1047,7 +1054,7 @@ static int _setup(struct omap_hwmod *oh)
}
}
- if (!(oh-flags HWMOD_INIT_NO_IDLE))
+ if (!(oh-flags HWMOD_INIT_NO_IDLE) !skip_setup_idle)
_omap_hwmod_idle(oh);
return 0;
@@ -1161,6 +1168,7 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
/**
* omap_hwmod_for_each - call function for each registered omap_hwmod
* @fn: pointer to a callback function
+ * @data: void * data to pass to callback function
*
* Call @fn for each registered omap_hwmod, passing @data to each
* function. @fn must return 0 for success or any other value for
@@ -1169,7 +1177,8 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
* caller of omap_hwmod_for_each(). @fn is called with
* omap_hwmod_for_each() held.
*/
-int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh))
+int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
+ void *data)
{
struct omap_hwmod *temp_oh;
[PATCH 07/20] OMAP23: hwmod: Remove _hwmod prefix in name string
From: Benoit Cousson b-cous...@ti.com
In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.
Align OMAP2420, 2430 and 3430 data files with the same convention.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a8b57a6..646386c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap2420_l3_hwmod = {
- .name = l3_hwmod,
+ .name = l3_main,
.class = l3_hwmod_class,
.masters= omap2420_l3_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
@@ -90,7 +90,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] =
{
/* L4 CORE */
static struct omap_hwmod omap2420_l4_core_hwmod = {
- .name = l4_core_hwmod,
+ .name = l4_core,
.class = l4_hwmod_class,
.masters= omap2420_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
@@ -111,7 +111,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap2420_l4_wkup_hwmod = {
- .name = l4_wkup_hwmod,
+ .name = l4_wkup,
.class = l4_hwmod_class,
.masters= omap2420_l4_wkup_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8b1f74b..b2100cf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2430_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap2430_l3_hwmod = {
- .name = l3_hwmod,
+ .name = l3_main,
.class = l3_hwmod_class,
.masters= omap2430_l3_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
@@ -92,7 +92,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_core_masters[] =
{
/* L4 CORE */
static struct omap_hwmod omap2430_l4_core_hwmod = {
- .name = l4_core_hwmod,
+ .name = l4_core,
.class = l4_hwmod_class,
.masters= omap2430_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
@@ -113,7 +113,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap2430_l4_wkup_hwmod = {
- .name = l4_wkup_hwmod,
+ .name = l4_wkup,
.class = l4_hwmod_class,
.masters= omap2430_l4_wkup_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index e288b20..ec6a5f8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -70,7 +70,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap3xxx_l3_hwmod = {
- .name = l3_hwmod,
+ .name = l3_main,
.class = l3_hwmod_class,
.masters= omap3xxx_l3_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
@@ -101,7 +101,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[]
= {
/* L4 CORE */
static struct omap_hwmod omap3xxx_l4_core_hwmod = {
- .name = l4_core_hwmod,
+ .name = l4_core,
.class = l4_hwmod_class,
.masters= omap3xxx_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
@@ -122,7 +122,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[]
= {
/* L4 PER */
static struct omap_hwmod omap3xxx_l4_per_hwmod = {
- .name = l4_per_hwmod,
+ .name = l4_per,
.class = l4_hwmod_class,
.masters= omap3xxx_l4_per_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_per_masters),
@@ -143,7 +143,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
- .name = l4_wkup_hwmod,
+ .name = l4_wkup,
.class =
[PATCH 05/20] OMAP24xx: CM: fix mask used for checking IDLEST status
From: Kevin Hilman khil...@deeprootsystems.com On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3. The mask used to check this was using the bit position instead of the bit mask. This patch fixes the problem by using the bit mask instead of the bit field. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/cm.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cm.c b/arch/arm/mach-omap2/cm.c index 2d83565..721c3b6 100644 --- a/arch/arm/mach-omap2/cm.c +++ b/arch/arm/mach-omap2/cm.c @@ -50,15 +50,15 @@ int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id, u8 idlest_shift) cm_idlest_reg = cm_idlest_offs[idlest_id - 1]; + mask = 1 idlest_shift; + if (cpu_is_omap24xx()) - ena = idlest_shift; + ena = mask; else if (cpu_is_omap34xx()) ena = 0; else BUG(); - mask = 1 idlest_shift; - /* XXX should be OMAP2 CM */ omap_test_timeout(((cm_read_mod_reg(prcm_mod, cm_idlest_reg) mask) == ena), MAX_MODULE_READY_TIME, i); -- 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 8/9] dspbridge: add map support for big buffers
Hi Hari, -Original Message- From: Kanigeri, Hari Sent: Thursday, July 01, 2010 6:36 PM To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers Fernando, - for_each_sg(sgt-sgl, sg, sgt-nents, i) - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | + IOVMF_ELSZ_32); -- iommu_vmap does the Kernel mapping to the buffers you are mapping to DSP MMU. Why do you need Kernel mappings ? If there is no benefit in maintaining Kernel mapping I would rather call iopgtable_store_entry directly to map the entries. Where inside iommu_vmap is the mapping done? I thought the kernel can access to that buffer after get_user_pages() where the user pages are pin and we can get a kernel address. The intention using iommu_vmap was to use api's proved by the iovmmu module. iommu_vmap() it is also tracking the mapped areas, so maybe the next step could be: remove dmm.c/h files and also proc_reserve/unreserved functions. If you think the function is unneeded steps and could affect the performance I can do the change to use only iopgtable_store_entry(). I think a kernel mapping is needed for flush/invalidate api's, please correct me if I am wrong. Regards, Fernando. Thank you, Best regards, Hari -- 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 5/9] dspbridge: add mmufault support
Hi Hiroshi,
-Original Message-
From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
Sent: Friday, July 02, 2010 1:28 AM
To: Guzman Lugo, Fernando
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
o...@wizery.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com
Subject: Re: [PATCH 5/9] dspbridge: add mmufault support
Hi Fernando,
From: ext Fernando Guzman Lugo x0095...@ti.com
Subject: [PATCH 5/9] dspbridge: add mmufault support
Date: Thu, 1 Jul 2010 02:20:56 +0200
With changes for iommu migration mmu fault report and dsp track
dump is broken, this patch fixes that.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/core/mmu_fault.c | 93 ++-
--
drivers/dsp/bridge/core/mmu_fault.h |5 +-
drivers/dsp/bridge/core/tiomap3430.c |2 +
drivers/dsp/bridge/core/ue_deh.c | 31 +---
4 files changed, 34 insertions(+), 97 deletions(-)
diff --git a/drivers/dsp/bridge/core/mmu_fault.c
b/drivers/dsp/bridge/core/mmu_fault.c
index 5c0124f..d991c6a 100644
--- a/drivers/dsp/bridge/core/mmu_fault.c
+++ b/drivers/dsp/bridge/core/mmu_fault.c
@@ -23,9 +23,12 @@
/* --- Trace Debug */
#include dspbridge/host_os.h
#include dspbridge/dbc.h
+#include plat/iommu.h
/* --- OS Adaptation Layer */
#include dspbridge/drv.h
+#include dspbridge/dev.h
+
/* --- Link Driver */
#include dspbridge/dspdeh.h
@@ -40,11 +43,6 @@
#include _tiomap.h
#include mmu_fault.h
-static u32 dmmu_event_mask;
-u32 fault_addr;
-
-static bool mmu_check_if_fault(struct bridge_dev_context *dev_context);
-
/*
* mmu_fault_dpc
* Deferred procedure call to handle DSP MMU fault.
@@ -62,78 +60,21 @@ void mmu_fault_dpc(IN unsigned long pRefData)
* mmu_fault_isr
* ISR to be triggered by a DSP MMU fault interrupt.
*/
-irqreturn_t mmu_fault_isr(int irq, IN void *pRefData)
-{
- struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)pRefData;
- struct bridge_dev_context *dev_context;
- struct cfg_hostres *resources;
-
- DBC_REQUIRE(irq == INT_DSP_MMU_IRQ);
- DBC_REQUIRE(deh_mgr_obj);
-
- if (deh_mgr_obj) {
-
- dev_context =
- (struct bridge_dev_context *)deh_mgr_obj-hbridge_context;
-
- resources = dev_context-resources;
-
- if (!resources) {
- dev_dbg(bridge, %s: Failed to get Host Resources\n,
- __func__);
- return IRQ_HANDLED;
- }
- if (mmu_check_if_fault(dev_context)) {
- printk(KERN_INFO * DSPMMU FAULT * IRQStatus
- 0x%x\n, dmmu_event_mask);
- printk(KERN_INFO * DSPMMU FAULT * fault_addr
- 0x%x\n, fault_addr);
- /*
-* Schedule a DPC directly. In the future, it may be
-* necessary to check if DSP MMU fault is intended for
-* Bridge.
-*/
- tasklet_schedule(deh_mgr_obj-dpc_tasklet);
-
- /* Reset err_info structure before use. */
- deh_mgr_obj-err_info.dw_err_mask = DSP_MMUFAULT;
- deh_mgr_obj-err_info.dw_val1 = fault_addr 16;
- deh_mgr_obj-err_info.dw_val2 = fault_addr 0x;
- deh_mgr_obj-err_info.dw_val3 = 0L;
- /* Disable the MMU events, else once we clear it will
-* start to raise INTs again */
- hw_mmu_event_disable(resources-dw_dmmu_base,
-HW_MMU_TRANSLATION_FAULT);
- } else {
- hw_mmu_event_disable(resources-dw_dmmu_base,
-HW_MMU_ALL_INTERRUPTS);
- }
- }
- return IRQ_HANDLED;
-}
+int mmu_fault_isr(struct iommu *mmu)
-/*
- * mmu_check_if_fault
- * Check to see if MMU Fault is valid TLB miss from DSP
- * Note: This function is called from an ISR
- */
-static bool mmu_check_if_fault(struct bridge_dev_context *dev_context)
{
+ struct deh_mgr *dm;
+ u32 da;
+
+ dev_get_deh_mgr(dev_get_first(), dm);
+
+ if (!dm)
+ return -EPERM;
+
+ da = iommu_read_reg(mmu, MMU_FAULT_AD);
+ iommu_write_reg(mmu, 0, MMU_IRQENABLE);
+ dm-err_info.dw_val1 = da;
+ tasklet_schedule(dm-dpc_tasklet);
I think that the following iommu_disable() does disabling MMU.
In this point the intention is no disable the mmu, because after the mmu fault
the DSP dumps its stack in the share memory and that area is mapped using iommu
module,
RE: [PATCH 1/9] dspbridge: replace iommu custom for opensource implementation
-Original Message-
From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
Sent: Friday, July 02, 2010 1:32 AM
To: Guzman Lugo, Fernando
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
o...@wizery.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com
Subject: Re: [PATCH 1/9] dspbridge: replace iommu custom for opensource
implementation
Hi Fernando,
From: ext Fernando Guzman Lugo x0095...@ti.com
Subject: [PATCH 1/9] dspbridge: replace iommu custom for opensource
implementation
Date: Thu, 1 Jul 2010 02:20:52 +0200
This patch replace the call to custom dsp mmu implemenation
for the once on iommu module.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/core/_tiomap.h| 16 +
drivers/dsp/bridge/core/io_sm.c | 114 ++--
drivers/dsp/bridge/core/tiomap3430.c | 501 +--
---
drivers/dsp/bridge/core/ue_deh.c | 10 -
4 files changed, 118 insertions(+), 523 deletions(-)
diff --git a/drivers/dsp/bridge/core/_tiomap.h
b/drivers/dsp/bridge/core/_tiomap.h
index bf0164e..d13677a 100644
--- a/drivers/dsp/bridge/core/_tiomap.h
+++ b/drivers/dsp/bridge/core/_tiomap.h
@@ -23,6 +23,8 @@
#include plat/clockdomain.h
#include mach-omap2/prm-regbits-34xx.h
#include mach-omap2/cm-regbits-34xx.h
+#include plat/iommu.h
+#include plat/iovmm.h
#include dspbridge/devdefs.h
#include hw_defs.h
#include dspbridge/dspioctl.h/* for bridge_ioctl_extproc defn
*/
@@ -330,6 +332,7 @@ struct bridge_dev_context {
u32 dw_internal_size; /* Internal memory size */
struct omap_mbox *mbox; /* Mail box handle */
+ struct iommu *dsp_mmu; /* iommu for iva2 handler */
struct cfg_hostres *resources; /* Host Resources */
@@ -374,4 +377,17 @@ extern s32 dsp_debug;
*/
int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16
mb_val);
+static inline void dsp_iotlb_init(struct iotlb_entry *e, u32 da, u32
pa,
+ u32 pgsz)
+{
+ e-da = da;
+ e-pa = pa;
+ e-valid = 1;
+ e-prsvd = 1;
+ e-pgsz = pgsz MMU_CAM_PGSZ_MASK;
+ e-endian = MMU_RAM_ENDIAN_LITTLE;
+ e-elsz = MMU_RAM_ELSZ_32;
+ e-mixed = 0;
+}
+
#endif /* _TIOMAP_ */
diff --git a/drivers/dsp/bridge/core/io_sm.c
b/drivers/dsp/bridge/core/io_sm.c
index 7fb840d..1f47f8b 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -290,6 +290,8 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct cod_manager *cod_man;
struct chnl_mgr *hchnl_mgr;
struct msg_mgr *hmsg_mgr;
+ struct iommu *mmu;
+ struct iotlb_entry e;
u32 ul_shm_base;
u32 ul_shm_base_offset;
u32 ul_shm_limit;
@@ -312,7 +314,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct bridge_ioctl_extproc ae_proc[BRDIOCTL_NUMOFMMUTLB];
struct cfg_hostres *host_res;
struct bridge_dev_context *pbridge_context;
- u32 map_attrs;
u32 shm0_end;
u32 ul_dyn_ext_base;
u32 ul_seg1_size = 0;
@@ -336,6 +337,21 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
status = -EFAULT;
goto func_end;
}
+
+ mmu = pbridge_context-dsp_mmu;
+
+ if (mmu)
+ iommu_put(mmu);
+ mmu = iommu_get(iva2);
+ mmu = iommu_get(iva2, mmu_fault_isr);
I'm considering that it might be better to pass a mmu fault callback
at this iommu_get.
What do you think?
That sounds good.
Thanks and regards,
Fernando.
--
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 8/9] dspbridge: add map support for big buffers
Fernando, -Original Message- From: Guzman Lugo, Fernando Sent: Friday, July 02, 2010 11:27 AM To: Kanigeri, Hari; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers Hi Hari, -Original Message- From: Kanigeri, Hari Sent: Thursday, July 01, 2010 6:36 PM To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers Fernando, - for_each_sg(sgt-sgl, sg, sgt-nents, i) - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | + IOVMF_ELSZ_32); -- iommu_vmap does the Kernel mapping to the buffers you are mapping to DSP MMU. Why do you need Kernel mappings ? If there is no benefit in maintaining Kernel mapping I would rather call iopgtable_store_entry directly to map the entries. Where inside iommu_vmap is the mapping done? -- The mapping is done to track down the Device mappings. But since you already have it in dmm.c this is kind of redundant right now, and we might see performance impact due to this. I think it might be good to transition to iovmm when we phase out dmm.c. Few things to take into account transitioning to iovmm approach: - DSPBridge used to have linked list approach to track down the mapped entries and profiling showed it took considerable amount of traversing through the list. Jeff Taylor's algorithm in dmm.c helped to reduce this impact. - How would you manage the Device virtual pool moving to iovmm ? And how about the reservation ? Thank you, Best regards, Hari -- 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 8/9] dspbridge: add map support for big buffers
Hi Hari, -Original Message- From: Kanigeri, Hari Sent: Friday, July 02, 2010 12:03 PM To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers Fernando, -Original Message- From: Guzman Lugo, Fernando Sent: Friday, July 02, 2010 11:27 AM To: Kanigeri, Hari; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers Hi Hari, -Original Message- From: Kanigeri, Hari Sent: Thursday, July 01, 2010 6:36 PM To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers Fernando, - for_each_sg(sgt-sgl, sg, sgt-nents, i) - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | + IOVMF_ELSZ_32); -- iommu_vmap does the Kernel mapping to the buffers you are mapping to DSP MMU. Why do you need Kernel mappings ? If there is no benefit in maintaining Kernel mapping I would rather call iopgtable_store_entry directly to map the entries. Where inside iommu_vmap is the mapping done? -- The mapping is done to track down the Device mappings. But since you already have it in dmm.c this is kind of redundant right now, and we might see performance impact due to this. I think it might be good to transition to iovmm when we phase out dmm.c. it could be a good time now, I think. Few things to take into account transitioning to iovmm approach: - DSPBridge used to have linked list approach to track down the mapped entries and profiling showed it took considerable amount of traversing through the list. Jeff Taylor's algorithm in dmm.c helped to reduce this impact. That can be implemented in the iovmmu without too many changes, right? - How would you manage the Device virtual pool moving to iovmm ? And how about the reservation ? I think, it would be good if we get rid of DMMPOOL size, if the liked list grow up as it is needed, there is no memory penalty of have all the possible iommu addresses valid (1100 - ). The reservation will only fail when there is no memory. If a software restriction is needed we could define a start and end addresses for iommu module (maybe as a parameter when the iommu handle for iva2 is got) and that boundaries can be taking in account at the moment of reserve the memory. I think the reserve/unreserved dspbridge api can disappear and just return the da address in the map function. Please let me know what you think. Thanks for the comments, Fernando. Thank you, Best regards, Hari -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Andi Kleen wrote: On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote: Andi Kleen wrote: The VCMM provides a more abstract, global view with finer-grained control of each mapping a user wants to create. For instance, the semantics of iommu_map preclude its use in setting up just the IOMMU side of a mapping. With a one-sided map, two IOMMU devices can be Hmm? dma_map_* does not change any CPU mappings. It only sets up DMA mapping(s). Sure, but I was saying that iommu_map() doesn't just set up the IOMMU mappings, its sets up both the iommu and kernel buffer mappings. Normally the data is already in the kernel or mappings, so why would you need another CPU mapping too? Sometimes the CPU code has to scatter-gather, but that is considered acceptable (and if it really cannot be rewritten to support sg it's better to have an explicit vmap operation) In general on larger systems with many CPUs changing CPU mappings also gets expensive (because you have to communicate with all cores), and is not a good idea on frequent IO paths. That's all true, but what a VCMM allows is for these trade-offs to be made by the user for future systems. It may not be too expensive to change the IO path around on future chips or the user may be okay with the performance penalty. A VCMM doesn't enforce a policy on the user, it lets the user make their own policy. Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs unless the user explicitly That assumes that all the IOMMUs on the system support the same page table format, right? Actually no. Since the VCMM abstracts a page-table as a Virtual Contiguous Region (VCM) a VCM can be associated with any device, regardless of their individual page table format. But then there is no real page table sharing, isn't it? The real information should be in the page tables, nowhere else. Yeah, and the implementation ensures that it. The VCMM just adds a few fields like start_addr, len and the device. The device still manages the its page-tables. The standard Linux approach to such a problem is to write a library that drivers can use for common functionality, not put a middle layer in between. Libraries are much more flexible than layers. That's true up to the, is this middle layer so useful that its worth it point. The VM is a middle layer, you could make the same argument about it, the mapping code isn't too hard, just map in the memory that you need and be done with it. But the VM middle layer provides a clean separation between page frames and pages which turns out to be Actually we use both PFNs and struct page *s in many layers up and down, there's not really any layering in that. Sure, but the PFNs and the struct page *s are the middle layer. Its just that things haven't been layered on top of them. A VCMM is the higher level abstraction, since it allows the size of the PFs to vary and the consumers of the VCM's to be determined at run-time. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
FBIO_WAITFORVSYNC is a stardard ioctl for waiting vsync, already
used by some userspace, so add it as an alias for OMAPFB_WAITFORVSYNC.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
Tomi,
I know I already sent this earlier, but as now FBIO_WAITFORVSYNC is a
standard ioctl, so why don't we support it? I know you might not like
that omapfb_ioctl will have one standard ioctl handler between all OMAP
specific ones, but that's something plenty of other drivers do.
drivers/video/omap2/omapfb/omapfb-ioctl.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 9c73618..32fab5a 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -490,6 +490,7 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
struct omapfb_vram_info vram_info;
struct omapfb_tearsync_info tearsync_info;
struct omapfb_display_info display_info;
+ u32 crt;
} p;
int r = 0;
@@ -648,6 +649,17 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
r = -EFAULT;
break;
+ case FBIO_WAITFORVSYNC:
+ if (get_user(p.crt, (__u32 __user *)arg)) {
+ r = -EFAULT;
+ break;
+ }
+ if (p.crt != 0) {
+ r = -ENODEV;
+ break;
+ }
+ /* FALLTHROUGH */
+
case OMAPFB_WAITFORVSYNC:
DBG(ioctl WAITFORVSYNC\n);
if (!display) {
--
1.6.3.3
--
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
multipath mux question
Hi, on OMAP3 CBB package GPIO126 can be muxed on 2 pins: mmc1_dat4 and cam_strobe. On pandora mmc1_dat4 is connected to mmc1 write protect, this makes omap2_mmc_mux() call omap_mux_init_gpio() on GPIO126, which muxes both pins and warns: mux: Multiple gpio paths for gpio126 This results in unusable GPIO. I wonder how should I handle this, perhaps overriding mux by calling omap_mux_init_signal() after omap2_hsmmc_init() call? Or maybe omap_mux_init_gpio() should be patched not to set up GPIOs if it encounters multiple paths? -- 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
[RFC v.3] omap: hwspinlock: Added hwspinlock driver
Hello, I have updated my draft of the spinlock driver patch based on feedback from the Linux-OMAP community. The changes I have made since RFC v.2: - Only one device initialization per IP (in this case, OMAP4) -- this means the driver's probe func will only be called once. - Spinlock address is obtained by calling platform_get_resource from driver, and ioremapped by driver. This makes better use of hwmod. - Device initialization only provides spinlock register offsets, not mapped or raw addresses. - Determining number of locks and lock register addresses is done in driver, not device init. - Calling pm_runtime_get and pm_runtime_put when acquiring/releasing lock. - Fixed file header comment: hwspinlocks.c should be called device initialization not driver Please see attached patch or inline patch below, and provide feedback. I hope to submit the finalized patch on Tuesday July 6. Thanks, Simon From 86223480bb46177b4c625b01122d0a4f40eb95c0 Mon Sep 17 00:00:00 2001 From: Simon Que s...@ti.com Date: Wed, 23 Jun 2010 18:40:30 -0500 Subject: [PATCH] omap: hwspinlock: Added hwspinlock driver Created driver for OMAP hardware spinlock. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization uses hwmod to configure the devices. One device will be created for each hardware spinlock. It will pass spinlock register addresses to the driver. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in data passed in device initialization. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address provided by the device initialization. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of a hardware spinlock. It returns the handle to the next available (unallocated) spinlock. If no more locks are available, it returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a specific hardware spinlock. This allows the system to use a specific spinlock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. Otherwise it returns a spinlock handle. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). Signed-off-by: Simon Que s...@ti.com --- arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/hwspinlocks.c| 72 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/Makefile |3 +- arch/arm/plat-omap/hwspinlock.c | 298 ++ arch/arm/plat-omap/include/plat/hwspinlock.h | 29 +++ arch/arm/plat-omap/include/plat/omap44xx.h |2 + 7 files changed, 406 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/hwspinlocks.c create mode 100644 arch/arm/plat-omap/hwspinlock.c create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6725b3a..5f5c87b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -170,3 +170,5 @@ obj-y += $(nand-m) $(nand-y) smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o obj-y += $(smc91x-m) $(smc91x-y) + +obj-$(CONFIG_ARCH_OMAP4) += hwspinlocks.o \ No newline at end of file diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-omap2/hwspinlocks.c new file mode 100644 index 000..f0b212b --- /dev/null +++ b/arch/arm/mach-omap2/hwspinlocks.c @@ -0,0 +1,72 @@ +/* + * OMAP hardware spinlock device initialization + * + * Copyright (C) 2010 Texas Instruments. All rights reserved. + * + * Contact: Simon Que s...@ti.com + * + * 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. + * + *
RE: [PATCH resend 2/3] musb: add musb support for AM35x
+#define USB_SOFT_RESET_MASK1
Need a empty line here.
Hmm, ok.
+#define A_WAIT_BCON_TIMEOUT1100/* in ms */
I think this #define should be dropped -- see below...
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ /*
+* Start the on-chip PHY and its PLL.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN |
+ CONF2_PHY_GPIOMODE);
BWT, what's thet GPIOMODE bit for?
If GPIO Mode is set to '1' then UART3 Tx/Rx would come on DP and
DM pins of USBPHY.
+ devconf2 |= CONF2_PHY_PLLON | CONF2_DATPOL;
So, AM35x always uses the reversed data polarity?
It's getting set to '1' so its always normal polarity.
+static void otg_timer(unsigned long _musb)
+{
+ struct musb *musb = (void *)_musb;
+ void __iomem*mregs = musb-mregs;
+ u8 devctl;
+ unsigned long flags;
+
+ /*
+* We poll because AM35x's won't expose several OTG-critical
+* status change events (from the transceiver) otherwise.
+*/
+ devctl = musb_readb(mregs, MUSB_DEVCTL);
+ DBG(7, Poll devctl %02x (%s)\n, devctl, otg_state_string(musb));
+
+ spin_lock_irqsave(musb-lock, flags);
+ switch (musb-xceiv-state) {
[...]
+ case OTG_STATE_A_WAIT_VFALL:
So, are you sure there's no need to call mod_timer() here for RTL 1.8?
What issue did you see on earlier RTLs ? As such I didn't see issue
In my normal testing.
+ musb-xceiv-state = OTG_STATE_A_WAIT_VRISE;
+ musb_writel(musb-ctrl_base, CORE_INTR_SRC_SET_REG,
+ MUSB_INTR_VBUSERROR USB_INTR_USB_SHIFT);
+ break;
+ case OTG_STATE_B_IDLE:
+ if (!is_peripheral_enabled(musb))
+ break;
Hm, davinci.c sets DevCtl.Session here and I'm also doing it in
da8xx.c --
can you comment why you don't do that too?
I remember this was causing some issue in OTG testing.
+ devctl = musb_readb(mregs, MUSB_DEVCTL);
+ if (devctl MUSB_DEVCTL_BDEVICE)
+ mod_timer(otg_workaround, jiffies + POLL_SECONDS * HZ);
+ else
+ musb-xceiv-state = OTG_STATE_A_IDLE;
+ break;
[...]
+static irqreturn_t am35x_interrupt(int irq, void *hci)
+{
+ struct musb *musb = hci;
+ void __iomem *reg_base = musb-ctrl_base;
+ unsigned long flags;
+ irqreturn_t ret = IRQ_NONE;
+ u32 epintr, usbintr, lvl_intr;
+
+ spin_lock_irqsave(musb-lock, flags);
+
+ /* Get endpoint interrupts */
+ epintr = musb_readl(reg_base, EP_INTR_SRC_MASKED_REG);
+
+ if (epintr) {
+ musb_writel(reg_base, EP_INTR_SRC_CLEAR_REG, epintr);
+
+ musb-int_rx =
+ (epintr AM35X_RX_INTR_MASK) USB_INTR_RX_SHIFT;
+ musb-int_tx =
+ (epintr AM35X_TX_INTR_MASK) USB_INTR_TX_SHIFT;
+ }
Perhaps this should be placed after the following check...
Hmm, ok.
+ /* Get usb core interrupts */
+ usbintr = musb_readl(reg_base, CORE_INTR_SRC_MASKED_REG);
+ if (!usbintr !epintr)
+ goto eoi;
+
+ if (usbintr) {
+ musb_writel(reg_base, CORE_INTR_SRC_CLEAR_REG, usbintr);
+
+ musb-int_usb =
+ (usbintr USB_INTR_USB_MASK) USB_INTR_USB_SHIFT;
+ }
[...]
+ if (usbintr (USB_INTR_DRVVBUS USB_INTR_USB_SHIFT)) {
+ int drvvbus = musb_readl(reg_base, USB_STAT_REG);
+ void __iomem *mregs = musb-mregs;
+ u8 devctl = musb_readb(mregs, MUSB_DEVCTL);
+ int err;
[...]
+ } else if (is_host_enabled(musb) drvvbus) {
+ musb-is_active = 1;
I dropped this line from da8xx.c as per this change to davinci.c:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
2.6.git;a=commit;h=89368d3d11a5b2eff83ad8e752be67f77a372bad
Would test on this.
[...]
+int __init musb_platform_init(struct musb *musb, void *board_data)
+{
+ void __iomem *reg_base = musb-ctrl_base;
+ struct clk *otg_fck;
+ u32 rev, lvl_intr, sw_reset;
+
+ musb-mregs += USB_MENTOR_CORE_OFFSET;
+
+ if (musb-set_clock)
+ musb-set_clock(musb-clock, 1);
+ else
+ clk_enable(musb-clock);
+ DBG(2, usbotg_ck=%lud\n, clk_get_rate(musb-clock));
+
+ otg_fck = clk_get(musb-controller, fck);
Can't this fail?
Yup, need to correct.
+ clk_enable(otg_fck);
+ DBG(2, usbotg_phy_ck=%lud\n, clk_get_rate(otg_fck));
+
+ /* Returns zero if e.g. not clocked */
+ rev = musb_readl(reg_base, USB_REVISION_REG);
+ if (!rev)
+ return -ENODEV;
You forgot to disable the clocks you just enabled above.
+
[RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
This patch contains the documentation for the API, termed the Virtual Contiguous Memory Manager. Its use would allow all of the IOMMU to VM, VM to device and device to IOMMU interoperation code to be refactored into platform independent code. Comments, suggestions and criticisms are welcome and wanted. Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org --- Documentation/vcm.txt | 587 + 1 files changed, 587 insertions(+), 0 deletions(-) create mode 100644 Documentation/vcm.txt diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt new file mode 100644 index 000..1c6a8be --- /dev/null +++ b/Documentation/vcm.txt @@ -0,0 +1,587 @@ +What is this document about? + + +This document covers how to use the Virtual Contiguous Memory Manager +(VCMM), how the first implementation works with a specific low-level +Input/Output Memory Management Unit (IOMMU) and the way the VCMM is used +from user-space. It also contains a section that describes why something +like the VCMM is needed in the kernel. + +If anything in this document is wrong, please send patches to the +maintainer of this file, listed at the bottom of the document. + + +The Virtual Contiguous Memory Manager += + +The VCMM was built to solve the system-wide memory mapping issues that +occur when many bus-masters have IOMMUs. + +An IOMMU maps device addresses to physical addresses. It also insulates +the system from spurious or malicious device bus transactions and allows +fine-grained mapping attribute control. The Linux kernel core does not +contain a generic API to handle IOMMU mapped memory; device driver writers +must implement device specific code to interoperate with the Linux kernel +core. As the number of IOMMUs increases, coordinating the many address +spaces mapped by all discrete IOMMUs becomes difficult without in-kernel +support. + +The VCMM API enables device independent IOMMU control, virtual memory +manager (VMM) interoperation and non-IOMMU enabled device interoperation +by treating devices with or without IOMMUs and all CPUs with or without +MMUs, their mapping contexts and their mappings using common +abstractions. Physical hardware is given a generic device type and mapping +contexts are abstracted into Virtual Contiguous Memory (VCM) +regions. Users reserve memory from VCMs and back their reservations +with physical memory. + +Why the VCMM is Needed +-- + +Driver writers who control devices with IOMMUs must contend with device +control and memory management. Driver writers have a large device driver +API that they can leverage to control their devices, but they are lacking +a unified API to help them program mappings into IOMMUs and share those +mappings with other devices and CPUs in the system. + +Sharing is complicated by Linux's CPU-centric VMM. The CPU-centric model +generally makes sense because average hardware only contains a MMU for the +CPU and possibly a graphics MMU. If every device in the system has one or +more MMUs the CPU-centric memory management (MM) programming model breaks +down. + +Abstracting IOMMU device programming into a common API has already begun +in the Linux kernel. It was built to abstract the difference between AMD +and Intel IOMMUs to support x86 virtualization on both platforms. The +interface is listed in include/linux/iommu.h. It contains +interfaces for mapping and unmapping as well as domain management. This +interface has not gained widespread use outside the x86; PA-RISC, Alpha +and SPARC architectures and ARM and PowerPC platforms all use their own +mapping modules to control their IOMMUs. The VCMM contains an IOMMU +programming layer, but since its abstraction supports map management +independent of device control, the layer is not used directly. This +higher-level view enables a new kernel service, not just an IOMMU +interoperation layer. + +The General Idea: Map Management using Graphs +- + +Looking at mapping from a system-wide perspective reveals a general graph +problem. The VCMM's API is built to manage the general mapping graph. Each +node that talks to memory, either through an MMU or directly (physically +mapped) can be thought of as the device-end of a mapping edge. The other +edge is the physical memory (or intermediate virtual space) that is +mapped. + +In the direct-mapped case the device is assigned a one-to-one MMU. This +scheme allows direct mapped devices to participate in general graph +management. + +The CPU nodes can also be brought under the same mapping abstraction with +the use of a light overlay on the existing VMM. This light overlay allows +VMM-managed mappings to interoperate with the common API. The light +overlay enables this without substantial modifications to the existing +VMM. + +In addition to CPU nodes that are running Linux (and the VMM), remote CPU +nodes that may be
