Re: [PATCH 0/5] staging: tidspbridge: for 3.9
Hi Greg, On Thu, Jan 17, 2013 at 6:47 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote: Patches for staging-next, fixing comments and suggestions provided by Chen Gang. There is an additional scm patch, that removes hardcoded defines related to direct register handling for SCM, it was dependent on changes that already made it to mainline. What is the status on getting this out of the staging tree? I'm currently working to do this. What needs to be done still? - There is a tasklet that I'm working to remove. - Some portions could be fitted into remoteproc (as Tony mentions). - Migration to generic iommu framework. - Need to rework patches to use request_firmware. - And a thorough cleanup to get rid of if-else nesting. At some point I should be able to work on all the items (since I have the time), but any help is appreciated. Cheers, Omar -- 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/5] staging: tidspbridge: for 3.9
Hi Tony, On Thu, Jan 17, 2013 at 8:01 PM, Tony Lindgren t...@atomide.com wrote: * Greg Kroah-Hartman gre...@linuxfoundation.org [130117 16:51]: On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote: Patches for staging-next, fixing comments and suggestions provided by Chen Gang. There is an additional scm patch, that removes hardcoded defines related to direct register handling for SCM, it was dependent on changes that already made it to mainline. What is the status on getting this out of the staging tree? What needs to be done still? Omar, please correct me if I'm wrong. This thing should be reimplemented using remoteproc AFAIK. tidspbridge might be able to use remoteproc, however it can't get rid of all the infrastructure to support the SN interface, given that the SN and firmware are distributed as binaries. OTOH, remoteproc can also implement support for omap3 dsp, but the major drawback is that we will lose the distributed codecs along with gst-dsp support. But I doubt that anybody is working on making it happen? I'm not aware of anybody working on remoteproc for omap3 (eventually I could pick it up) but I'm more focused on getting tidspbridge out of staging right now. Cheers, Omar -- 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/5] staging: tidspbridge: for 3.9
On Sun, Jan 20, 2013 at 5:51 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: That looks good, care to update the TODO file for the driver in the kernel to reflect this? I'll update it. Cheers, Omar -- 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/9] mailbox: OMAP: introduce mailbox framework
On Wed, Jan 9, 2013 at 6:29 AM, Loic PALLARDY loic.palla...@st.com wrote: Hi Vaibhav, On 01/09/2013 01:11 PM, Bedia, Vaibhav wrote: Hi Loic, On Fri, Dec 21, 2012 at 16:23:24, Loic PALLARDY wrote: On 12/21/2012 11:49 AM, Bedia, Vaibhav wrote: On Fri, Dec 21, 2012 at 14:24:26, Loic PALLARDY wrote: I have a few patches which are dependent on this patch series. Could you please keep me in cc for the future versions. Sure, I'll. When do you plan to post an updated version of these patches? I'm synchronizing with Omar to include TI RPMsg and tidspbridge patches in next update. So I plan update for end of the week, beginning of next week. Here are my patches, I didn't post them to the list since they are meant to be squashed, I also prepared a squashed version of the original set, in case it is easier to take that one, all rebased into 3.8-rc1. Branches: mailbox-3.8-rc1-separate-changes and mailbox-3.8-rc1, respectively. From tree: https://github.com/omarrmz/upstream-wip Cheers, Omar -- 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 0/5] staging: tidspbridge: for 3.9
Patches for staging-next, fixing comments and suggestions provided by Chen Gang. There is an additional scm patch, that removes hardcoded defines related to direct register handling for SCM, it was dependent on changes that already made it to mainline. Omar Ramirez Luna (5): staging: tidspbridge: fix potential array out of bounds write staging: tidspbridge: fix memory corruption on long string names staging: tidspbridge: fix uninitialized variable sym_name staging: tidspbridge: use scm functions to set boot address and mode staging: tidspbridge: remove unused code to handle iva_img drivers/staging/tidspbridge/core/tiomap3430.c | 34 --- .../staging/tidspbridge/include/dspbridge/proc.h |2 - drivers/staging/tidspbridge/rmgr/dbdcd.c |3 +- drivers/staging/tidspbridge/rmgr/drv_interface.c |1 - drivers/staging/tidspbridge/rmgr/nldr.c|6 ++- drivers/staging/tidspbridge/rmgr/node.c| 12 +++--- drivers/staging/tidspbridge/rmgr/proc.c|6 +--- 7 files changed, 19 insertions(+), 45 deletions(-) -- 1.7.4.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 1/5] staging: tidspbridge: fix potential array out of bounds write
The name of the firmware (drv_datap-base_img) could potentially become equal to 255 valid characters (size of exec_file), this will result in an out of bounds write, given that the 255 chars along with a '\0' terminator will be copied into an array of 255 chars. Produce an error on this cases, because the driver expects the NULL ending to be among the 255 char limit. Reported-by: Chen Gang gang.c...@asianux.com Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com --- drivers/staging/tidspbridge/rmgr/proc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tidspbridge/rmgr/proc.c b/drivers/staging/tidspbridge/rmgr/proc.c index 5e43938..ac016ed 100644 --- a/drivers/staging/tidspbridge/rmgr/proc.c +++ b/drivers/staging/tidspbridge/rmgr/proc.c @@ -394,7 +394,7 @@ static int get_exec_file(struct cfg_devnode *dev_node_obj, if (!drv_datap || !drv_datap-base_img) return -EFAULT; - if (strlen(drv_datap-base_img) size) + if (strlen(drv_datap-base_img) = size) return -EINVAL; strcpy(exec_file, drv_datap-base_img); -- 1.7.4.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 2/5] staging: tidspbridge: fix memory corruption on long string names
The value allocated doesn't match the one that is meant to be
stored, resulting in corruption of memory for longer strings
that can't be held in such space.
Fix by allocating the correct byte value for the string meant to
be stored.
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---
drivers/staging/tidspbridge/rmgr/dbdcd.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/dbdcd.c
b/drivers/staging/tidspbridge/rmgr/dbdcd.c
index 9d52c3c..3d2a26f 100644
--- a/drivers/staging/tidspbridge/rmgr/dbdcd.c
+++ b/drivers/staging/tidspbridge/rmgr/dbdcd.c
@@ -852,8 +852,7 @@ int dcd_register_object(struct dsp_uuid *uuid_obj,
goto func_end;
}
- dcd_key-path = kmalloc(strlen(sz_reg_key) + 1,
- GFP_KERNEL);
+ dcd_key-path = kmalloc(dw_path_size, GFP_KERNEL);
if (!dcd_key-path) {
kfree(dcd_key);
--
1.7.4.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 3/5] staging: tidspbridge: fix uninitialized variable sym_name
On both counts, sym_name could be printed uninitialized, this
is solved by moving the pr_* statement to be triggered if the
value is assigned.
Reported-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---
drivers/staging/tidspbridge/rmgr/nldr.c |6 --
drivers/staging/tidspbridge/rmgr/node.c | 12 ++--
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/nldr.c
b/drivers/staging/tidspbridge/rmgr/nldr.c
index 6309221..ca38050 100644
--- a/drivers/staging/tidspbridge/rmgr/nldr.c
+++ b/drivers/staging/tidspbridge/rmgr/nldr.c
@@ -1802,8 +1802,6 @@ int nldr_find_addr(struct nldr_nodeobject *nldr_node, u32
sym_addr,
bool status1 = false;
s32 i = 0;
struct lib_node root = { NULL, 0, NULL };
- pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__, (u32) nldr_node,
- sym_addr, offset_range, (u32) offset_output, sym_name);
if (nldr_node-dynamic *nldr_node-phase_split) {
switch (nldr_node-phase) {
@@ -1852,6 +1850,10 @@ int nldr_find_addr(struct nldr_nodeobject *nldr_node,
u32 sym_addr,
pr_debug(%s: Address 0x%x not found in range %d.\n,
__func__, sym_addr, offset_range);
status = -ESPIPE;
+ } else {
+ pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n,
+__func__, (u32) nldr_node, sym_addr, offset_range,
+(u32) offset_output, sym_name);
}
return status;
diff --git a/drivers/staging/tidspbridge/rmgr/node.c
b/drivers/staging/tidspbridge/rmgr/node.c
index 737f4a9..87dfa92 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -3012,16 +3012,16 @@ int node_find_addr(struct node_mgr *node_mgr, u32
sym_addr,
struct node_object *node_obj;
int status = -ENOENT;
- pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__,
- (unsigned int) node_mgr,
- sym_addr, offset_range,
- (unsigned int) sym_addr_output, sym_name);
-
list_for_each_entry(node_obj, node_mgr-node_list, list_elem) {
status = nldr_find_addr(node_obj-nldr_node_obj, sym_addr,
offset_range, sym_addr_output, sym_name);
- if (!status)
+ if (!status) {
+ pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__,
+(unsigned int) node_mgr,
+sym_addr, offset_range,
+(unsigned int) sym_addr_output, sym_name);
break;
+ }
}
return status;
--
1.7.4.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 4/5] staging: tidspbridge: use scm functions to set boot address and mode
Instead of ioremapping SCM registers, use the correspondent layer
to write into them.
This allows us to get rid of a layer violation, since the registers
are no longer touched by driver code.
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 34 +---
1 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index f619fb3..b770b22 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -70,14 +70,9 @@
#define PAGES_II_LVL_TABLE 512
#define PHYS_TO_PAGE(phys) pfn_to_page((phys) PAGE_SHIFT)
-/*
- * This is a totally ugly layer violation, but needed until
- * omap_ctrl_set_dsp_boot*() are provided.
- */
-#define OMAP3_IVA2_BOOTMOD_IDLE 1
-#define OMAP2_CONTROL_GENERAL 0x270
-#define OMAP343X_CONTROL_IVA2_BOOTADDR (OMAP2_CONTROL_GENERAL + 0x0190)
-#define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194)
+/* IVA Boot modes */
+#define DIRECT 0
+#define IDLE 1
/* Forward Declarations: */
static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt);
@@ -423,29 +418,14 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
/* Assert RST1 i.e only the RST only for DSP megacell */
if (!status) {
- /*
-* XXX: OMAP343X_CTRL_BASE ioremapping MUST be removed
once ctrl
-* function is made available.
-*/
- void __iomem *ctrl = ioremap(0x48002000, SZ_4K);
- if (!ctrl) {
- iounmap(sync_addr);
- return -ENOMEM;
- }
-
(*pdata-dsp_prm_rmw_bits)(OMAP3430_RST1_IVA2_MASK,
OMAP3430_RST1_IVA2_MASK,
OMAP3430_IVA2_MOD,
OMAP2_RM_RSTCTRL);
- /* Mask address with 1K for compatibility */
- __raw_writel(dsp_addr OMAP3_IVA2_BOOTADDR_MASK,
- ctrl + OMAP343X_CONTROL_IVA2_BOOTADDR);
- /*
-* Set bootmode to self loop if dsp_debug flag is true
-*/
- __raw_writel((dsp_debug) ? OMAP3_IVA2_BOOTMOD_IDLE : 0,
- ctrl + OMAP343X_CONTROL_IVA2_BOOTMOD);
- iounmap(ctrl);
+ /* Mask address with 1K for compatibility */
+ pdata-set_bootaddr(dsp_addr
+ OMAP3_IVA2_BOOTADDR_MASK);
+ pdata-set_bootmode(dsp_debug ? IDLE : DIRECT);
}
}
if (!status) {
--
1.7.4.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 5/5] staging: tidspbridge: remove unused code to handle iva_img
There is no way to specify the value of iva_img and since this code
is not being used, remove it.
This analysis resulted from a report by
Chen Gang gang.c...@asianux.com, mentioning that the existing code
was wrongly specifying the size to be copied.
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---
.../staging/tidspbridge/include/dspbridge/proc.h |2 --
drivers/staging/tidspbridge/rmgr/drv_interface.c |1 -
drivers/staging/tidspbridge/rmgr/proc.c|4
3 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/proc.h
b/drivers/staging/tidspbridge/include/dspbridge/proc.h
index 851b356..774a3f6 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/proc.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/proc.h
@@ -23,8 +23,6 @@
#include dspbridge/devdefs.h
#include dspbridge/drv.h
-extern char *iva_img;
-
/*
* proc_attach
* Purpose:
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
b/drivers/staging/tidspbridge/rmgr/drv_interface.c
index e6f31d8..df0f37e 100644
--- a/drivers/staging/tidspbridge/rmgr/drv_interface.c
+++ b/drivers/staging/tidspbridge/rmgr/drv_interface.c
@@ -65,7 +65,6 @@ static struct class *bridge_class;
static u32 driver_context;
static s32 driver_major;
static char *base_img;
-char *iva_img;
static s32 shm_size = 0x50;/* 5 MB */
static int tc_wordswapon; /* Default value is always false */
#ifdef CONFIG_TIDSPBRIDGE_RECOVERY
diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
b/drivers/staging/tidspbridge/rmgr/proc.c
index ac016ed..e1bdf6e 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -382,7 +382,6 @@ static int get_exec_file(struct cfg_devnode *dev_node_obj,
u32 size, char *exec_file)
{
u8 dev_type;
- s32 len;
struct drv_data *drv_datap = dev_get_drvdata(bridge);
dev_get_dev_type(hdev_obj, (u8 *) dev_type);
@@ -398,9 +397,6 @@ static int get_exec_file(struct cfg_devnode *dev_node_obj,
return -EINVAL;
strcpy(exec_file, drv_datap-base_img);
- } else if (dev_type == IVA_UNIT iva_img) {
- len = strlen(iva_img);
- strncpy(exec_file, iva_img, len + 1);
} else {
return -ENOENT;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] staging: tidspbridge: fix breakages due to CM reorganization
On Mon, Jan 7, 2013 at 5:03 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Dec 24, 2012 at 08:10:24AM -0600, Omar Ramirez Luna wrote: 3.8-rc1 introduced changes in the clock management header files, this resulted in compilation breakages for this driver. Define this locally while APIs are made available, given that driver code shouldn't include mach header files. This fixes: drivers/staging/tidspbridge/core/tiomap3430.c:550:13: error: 'OMAP3430_CM_AUTOIDLE_PLL' undeclared (first use in this function) drivers/staging/tidspbridge/core/tiomap_io.c:416:13: error: 'OMAP3430_CM_CLKEN_PLL' undeclared (first use in this function) Reported-by: Chen Gang gang.c...@asianux.com Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com Enric sent me a patch that just includes the proper .h file, which should be better than doing this: It looks better because the driver is already including related headers in a similar fashion, but in reality those headers are under arch/arm/mach-omap2 and the driver shouldn't have any business in including headers from there. --- a/drivers/staging/tidspbridge/core/_tiomap.h +++ b/drivers/staging/tidspbridge/core/_tiomap.h @@ -40,6 +40,14 @@ #include dspbridge/sync.h #include dspbridge/clk.h +/* + * XXX These mach-omap2/ defines are wrong and should be removed. No + * driver should read or write to PRM/CM registers directly; they + * should rely on OMAP core code to do this. + */ +#define OMAP3430_CM_AUTOIDLE_PLL 0x0034 +#define OMAP3430_CM_CLKEN_PLL0x0004 Don't define things that are already defined elsewhere... I'll not apply this. Ok, not a problem, I'll be working on the real fix which is to get APIs from the core code for the driver to use. Cheers, Omar -- 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 2/2] staging: tidspbridge: use prepare/unprepare on dsp clocks
This solves runtime failures while trying to enable WDT3 related
functionality on firmware load, however it does affect other clocks
controlled by the driver. Seen on 3.8-rc1.
CCF provides clk_prepare and clk_unprepare for enable and disable
operations respectively, this needs to be called in the correct
order while handling clocks.
Code path to enable/disable dsp clocks can still be reached from an
atomic context, hence we can't use clk_prepare_enable and
clk_disable_unprepare yet.
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---
drivers/staging/tidspbridge/core/dsp-clock.c | 13 -
drivers/staging/tidspbridge/core/wdt.c | 12 ++--
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/dsp-clock.c
b/drivers/staging/tidspbridge/core/dsp-clock.c
index b647207..2f084e18 100644
--- a/drivers/staging/tidspbridge/core/dsp-clock.c
+++ b/drivers/staging/tidspbridge/core/dsp-clock.c
@@ -121,9 +121,13 @@ void dsp_clk_exit(void)
for (i = 0; i DM_TIMER_CLOCKS; i++)
omap_dm_timer_free(timer[i]);
+ clk_unprepare(iva2_clk);
clk_put(iva2_clk);
+ clk_unprepare(ssi.sst_fck);
clk_put(ssi.sst_fck);
+ clk_unprepare(ssi.ssr_fck);
clk_put(ssi.ssr_fck);
+ clk_unprepare(ssi.ick);
clk_put(ssi.ick);
}
@@ -145,14 +149,21 @@ void dsp_clk_init(void)
iva2_clk = clk_get(dspbridge_device.dev, iva2_ck);
if (IS_ERR(iva2_clk))
dev_err(bridge, failed to get iva2 clock %p\n, iva2_clk);
+ else
+ clk_prepare(iva2_clk);
ssi.sst_fck = clk_get(dspbridge_device.dev, ssi_sst_fck);
ssi.ssr_fck = clk_get(dspbridge_device.dev, ssi_ssr_fck);
ssi.ick = clk_get(dspbridge_device.dev, ssi_ick);
- if (IS_ERR(ssi.sst_fck) || IS_ERR(ssi.ssr_fck) || IS_ERR(ssi.ick))
+ if (IS_ERR(ssi.sst_fck) || IS_ERR(ssi.ssr_fck) || IS_ERR(ssi.ick)) {
dev_err(bridge, failed to get ssi: sst %p, ssr %p, ick %p\n,
ssi.sst_fck, ssi.ssr_fck, ssi.ick);
+ } else {
+ clk_prepare(ssi.sst_fck);
+ clk_prepare(ssi.ssr_fck);
+ clk_prepare(ssi.ick);
+ }
}
/**
diff --git a/drivers/staging/tidspbridge/core/wdt.c
b/drivers/staging/tidspbridge/core/wdt.c
index 1dce36f..7ff0e6c 100644
--- a/drivers/staging/tidspbridge/core/wdt.c
+++ b/drivers/staging/tidspbridge/core/wdt.c
@@ -63,11 +63,15 @@ int dsp_wdt_init(void)
dsp_wdt.fclk = clk_get(NULL, wdt3_fck);
if (!IS_ERR(dsp_wdt.fclk)) {
+ clk_prepare(dsp_wdt.fclk);
+
dsp_wdt.iclk = clk_get(NULL, wdt3_ick);
if (IS_ERR(dsp_wdt.iclk)) {
clk_put(dsp_wdt.fclk);
dsp_wdt.fclk = NULL;
ret = -EFAULT;
+ } else {
+ clk_prepare(dsp_wdt.iclk);
}
} else
ret = -EFAULT;
@@ -95,10 +99,14 @@ void dsp_wdt_exit(void)
free_irq(INT_34XX_WDT3_IRQ, dsp_wdt);
tasklet_kill(dsp_wdt.wdt3_tasklet);
- if (dsp_wdt.fclk)
+ if (dsp_wdt.fclk) {
+ clk_unprepare(dsp_wdt.fclk);
clk_put(dsp_wdt.fclk);
- if (dsp_wdt.iclk)
+ }
+ if (dsp_wdt.iclk) {
+ clk_unprepare(dsp_wdt.iclk);
clk_put(dsp_wdt.iclk);
+ }
dsp_wdt.fclk = NULL;
dsp_wdt.iclk = NULL;
--
1.7.4.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 1/2] staging: tidspbridge: fix breakages due to CM reorganization
3.8-rc1 introduced changes in the clock management header files,
this resulted in compilation breakages for this driver.
Define this locally while APIs are made available, given that driver
code shouldn't include mach header files.
This fixes:
drivers/staging/tidspbridge/core/tiomap3430.c:550:13: error:
'OMAP3430_CM_AUTOIDLE_PLL' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap_io.c:416:13: error:
'OMAP3430_CM_CLKEN_PLL' undeclared (first use in this function)
Reported-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---
drivers/staging/tidspbridge/core/_tiomap.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index 543a127..61ea135 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -40,6 +40,14 @@
#include dspbridge/sync.h
#include dspbridge/clk.h
+/*
+ * XXX These mach-omap2/ defines are wrong and should be removed. No
+ * driver should read or write to PRM/CM registers directly; they
+ * should rely on OMAP core code to do this.
+ */
+#define OMAP3430_CM_AUTOIDLE_PLL 0x0034
+#define OMAP3430_CM_CLKEN_PLL 0x0004
+
struct map_l4_peripheral {
u32 phys_addr;
u32 dsp_virt_addr;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] drivers: mailbox: framework creation
Hi Loic/Ohad, On Fri, Dec 21, 2012 at 2:52 AM, Loic PALLARDY loic.palla...@st.com wrote: On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote: On Thu, Dec 20, 2012 at 9:19 PM, Olof Johanssono...@lixom.net wrote: While we can make the branch stable, would it make sense to make remoteproc for omap depend on !multiplatform during the transition, to reduce dependencies a little? Either way works, but it'd be nice to keep them independent if we can. I'm not sure multiplatform is the culprit; OMAP's remoteproc driver heavily depends on this mailbox code, and obviously breaks with this patch-set if only for the the naming changes. We'll need this patch set to update omap's remoteproc as well so at least we don't break bisectibility, though running a sanity test before merging would be even nicer (Loic I can help if you don't have a panda board). Hi Ohad, Yes tidspbridge and remoteproc must be adapted. This new mailbox fw has been tested on TI environment by Omar, who did adaptation at least for tidspbridge. Omar, do you have patch series ready for TI adaptations to new mailbox framework? Else I can do it, but I won't be able to test it (no panda board) Yes, I made the changes, for tidspbridge and remoteproc, I will submit both for review, based on this series. Cheers, Omar -- 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 v5 2/5] iommu/omap: keep mmu enabled when requested
The purpose of the mmu is to handle the memory accesses requested by its users. Typically, the mmu is bundled with the processing unit in a single IP block, which makes them to share the same clock to be functional. Currently, iommu code assumes that its user will be indirectly clocking it, but being a separate mmu driver, it should handle its own clocks, so as long as the mmu is requested it will be powered ON and once detached it will be powered OFF. The remaining clock handling out of iommu_enable and iommu_disable corresponds to paths that can be accessed through debugfs, some of them doesn't work if the module is not enabled first, but in future if the mmu is idled withouth freeing, these are needed to debug. Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org --- drivers/iommu/omap-iommu.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 6b1288c..f8082da 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -154,7 +154,6 @@ static int iommu_enable(struct omap_iommu *obj) err = arch_iommu-enable(obj); - clk_disable(obj-clk); return err; } @@ -163,8 +162,6 @@ static void iommu_disable(struct omap_iommu *obj) if (!obj) return; - clk_enable(obj-clk); - arch_iommu-disable(obj); clk_disable(obj-clk); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/5] iommu/omap: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/omap-iommu.c | 168 +++---
drivers/iommu/omap-iommu.c | 23 +++-
drivers/iommu/omap-iommu2.c | 19
include/linux/platform_data/iommu-omap.h |8 ++-
5 files changed, 64 insertions(+), 156 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include linux/platform_data/iommu-omap.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
-#include soc.h
-#include common.h
-
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
- {
- .base = OMAP4_MMU2_BASE,
- .irq = 28 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = tesla,
- .nr_tlb_entries = 32,
- .clk_name = dsp_fck,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
{
- int i, err;
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
+ struct platform_device *pdev;
+ struct iommu_platform_data *pdata;
+ struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+ static int i;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata-name = oh-name;
+ pdata-clk_name = oh-main_clk;
+ pdata-nr_tlb_entries = a-nr_tlb_entries;
+ pdata-da_start = a-da_start;
+ pdata-da_end = a-da_end;
+
+ if (oh-rst_lines_cnt == 1
[PATCH v5 5/5] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks
This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk-enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.
According to comments received[1] for related patches the idea is
to get rid of leaf clocks in future. So remove these two while at it.
[1] http://lkml.org/lkml/2012/8/20/226
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/clock44xx_data.c | 22 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..067c486 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1316,16 +1316,6 @@ static struct clk dmic_fck = {
.clkdm_name = abe_clkdm,
};
-static struct clk dsp_fck = {
- .name = dsp_fck,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = tesla_clkdm,
- .parent = dpll_iva_m4x2_ck,
- .recalc = followparent_recalc,
-};
-
static struct clk dss_sys_clk = {
.name = dss_sys_clk,
.ops= clkops_omap2_dflt,
@@ -1696,16 +1686,6 @@ static struct clk i2c4_fck = {
.recalc = followparent_recalc,
};
-static struct clk ipu_fck = {
- .name = ipu_fck,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = ducati_clkdm,
- .parent = ducati_clk_mux_ck,
- .recalc = followparent_recalc,
-};
-
static struct clk iss_ctrlclk = {
.name = iss_ctrlclk,
.ops= clkops_omap2_dflt,
@@ -3151,7 +3131,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, div_ts_ck,div_ts_ck,
CK_446X),
CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck,
CK_443X),
CLK(NULL, dmic_fck, dmic_fck,
CK_443X),
- CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
CLK(NULL, dss_sys_clk, dss_sys_clk,
CK_443X),
CLK(NULL, dss_tv_clk, dss_tv_clk,
CK_443X),
CLK(NULL, dss_48mhz_clk,dss_48mhz_clk,
CK_443X),
@@ -3183,7 +3162,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, i2c2_fck, i2c2_fck,
CK_443X),
CLK(NULL, i2c3_fck, i2c3_fck,
CK_443X),
CLK(NULL, i2c4_fck, i2c4_fck,
CK_443X),
- CLK(NULL, ipu_fck, ipu_fck,
CK_443X),
CLK(NULL, iss_ctrlclk, iss_ctrlclk,
CK_443X),
CLK(NULL, iss_fck, iss_fck,
CK_443X),
CLK(NULL, iva_fck, iva_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aab5c12..1f61093 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -650,7 +650,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.mpu_irqs = omap44xx_dsp_irqs,
.rst_lines = omap44xx_dsp_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
- .main_clk = dsp_fck,
+ .main_clk = dpll_iva_m4x2_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
@@ -1677,7 +1677,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.mpu_irqs = omap44xx_ipu_irqs,
.rst_lines = omap44xx_ipu_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_resets),
- .main_clk = ipu_fck,
+ .main_clk = ducati_clk_mux_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/5] iommu/omap: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Due to reset sequence, pm_runtime_[get|put]_sync must be used, to
avoid possible operations with the module under reset. Because of
this and given that the driver uses spin_locks to protect their
critical sections, we must use pm_runtime_irq_safe in order for the
runtime ops to be happy, otherwise might_sleep_if checks in runtime
framework will complain.
The remaining pm_runtime out of iommu_enable and iommu_disable
corresponds to paths that can be accessed through debugfs, some of
them doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap-iommu.c |1 -
drivers/iommu/omap-iommu.c | 40 ++---
drivers/iommu/omap-iommu.h |3 --
drivers/iommu/omap-iommu2.c | 17
include/linux/platform_data/iommu-omap.h |1 -
5 files changed, 19 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index af9b4f3..18108c14 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/omap-iommu.h
#include linux/mutex.h
#include linux/spinlock.h
#include linux/io.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -160,7 +160,7 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
@@ -177,7 +177,7 @@ static void iommu_disable(struct omap_iommu *obj)
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
@@ -303,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
if (!obj || !obj-nr_tlb_entries || !e)
return -EINVAL;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
iotlb_lock_get(obj, l);
if (l.base == obj-nr_tlb_entries) {
@@ -333,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return PTR_ERR(cr);
}
@@ -347,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, l);
out:
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return err;
}
@@ -377,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
for_each_iotlb_cr(obj, obj-nr_tlb_entries, i, cr) {
u32 start;
@@ -396,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (i == obj-nr_tlb_entries)
dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
@@ -410,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
{
struct iotlb_lock l;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
l.base = 0;
l.vict = 0;
@@ -418,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
iommu_write_reg(obj, 1, MMU_GFLUSH);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
}
#if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -428,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char
*buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
bytes = arch_iommu-dump_ctx(obj, buf, bytes);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev
[PATCH v5 0/5] OMAP: iommu: hwmod, reset handling and runtime PM
These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. A couple of patches were added (first two) to be clearer on the reasons for such changes, they were previosuly bundled as part of runtime PM changes. The last patch corresponds to a change in the leaf clocks used and it depends on this series to work properly. Due to single Image support, I rebased these on top of k3.7-rc5 and DEPEND on: [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu http://thread.gmane.org/gmane.linux.kernel/1387788 Minor rebasing might be needed if these are included on top of linux-omap, since they are affected by changes on headers being moved to include/linux/platform_data and arch/arm/mach-omap2. Omar Ramirez Luna (5): iommu/omap: remove redundant clock handling on ISR iommu/omap: keep mmu enabled when requested iommu/omap: migrate to hwmod framework iommu/omap: adapt to runtime pm ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks arch/arm/mach-omap2/clock44xx_data.c | 22 arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/omap-iommu.c | 167 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +- drivers/iommu/omap-iommu.c | 68 ++- drivers/iommu/omap-iommu.h |3 - drivers/iommu/omap-iommu2.c| 36 -- include/linux/platform_data/iommu-omap.h |9 +- 8 files changed, 84 insertions(+), 227 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/5] iommu/omap: remove redundant clock handling on ISR
For the interrupt to be generated, the mmu clock should be already enabled while translating a virtual address, so, this call to clock handling is just increasing/decreasing the counter. This works now, because its users need the same clock and they indirectly power the mmu, in this interrupt context the handling of clocks inside the ISR doesn't seem to be needed nor helping. Next patch should also correct the dependency on clients to handle iommu clocks. Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org --- drivers/iommu/omap-iommu.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index badc17c..6b1288c 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -807,9 +807,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!obj-refcount) return IRQ_NONE; - clk_enable(obj-clk); errs = iommu_report_fault(obj, da); - clk_disable(obj-clk); if (errs == 0) return IRQ_HANDLED; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks
Hi, On 14 November 2012 09:44, Paul Walmsley p...@pwsan.com wrote: Hi On Tue, 13 Nov 2012, Omar Ramirez Luna wrote: This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path from enabling modulemode inside CLKCTRL using its clk-enable_reg field. Instead is left to _omap4_enable_module though soc_ops, as the one in charge of this setting. According to comments received[1] for related patches the idea is to get rid of leaf clocks in future. So remove these two while at it. [1] http://lkml.org/lkml/2012/8/20/226 Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org Does this one belong as part of the OMAP: iommu: hwmod, reset handling and runtime PM series? Looks like applying this one separately might cause these clocks not to be disabled by either the clock code's disable-unused-clocks code, or the hwmod code? You are right, if applied right now, without the others it will break the current clocks iommu code uses. I will put it along with the other series or wait for the acceptance of the other patches first. Thanks, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm
Hi Ohad, On 14 November 2012 03:54, Ohad Ben-Cohen o...@wizery.com wrote: Hi Omar, On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna omar.l...@linaro.org wrote: Use runtime PM functionality interfaced with hwmod enable/idle functions, to replace direct clock operations and sysconfig handling. Dues to reset sequence, pm_runtime_put_sync must be used, to avoid possible operations with the module under reset. There are some changes here that might not be trivial to understand in hindsight; any chance you can add more explanations (even only in the commit log) regarding: I have discussed exactly the same changes in the list with Felipe, but yes I did forget to add the explanations (I thought I did in some version of the patch or cover-letter), but will update this description. Below is the discussion just in case, I'll be replying to your comments anyway ;) https://patchwork.kernel.org/patch/1585741/ @@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj) ... - clk_enable(obj-clk); + pm_runtime_get_sync(obj-dev); err = arch_iommu-enable(obj); - clk_disable(obj-clk); return err; } Why do we remove clk_disable here (instead of replacing it with a _put variant) ? Basically, with the previous clk management, the iommu driver assumes that its clock is shared with its client, which is the case for ipu and dsp, but I don't like that assumption. So by doing clock_enable/disable, the functional clock required for translations it is indirectly provided by the user of the iommu (let's say ipu). E.g. IPU enables the iommu and maps, at the end of the maps the clock will be disabled, but given that ipu clock is the same the mmu stays functional. By changing this to get_sync only, the mmu stays enabled as long as the iommu has been requested (except for the power transitions). @@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct iotlb_entry *e) if (!obj || !obj-nr_tlb_entries || !e) return -EINVAL; - clk_enable(obj-clk); + pm_runtime_get_sync(obj-dev); If iommu_enable no longer disables obj-clk before returning, do we really need to call -get here (and in all the other similar instances) ? You can access this paths through debugfs, some of them doesn't work if the module is not enabled first, but in future if you just want to idle the iommu without freeing, these are needed to debug. @@ -816,9 +813,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!obj-refcount) return IRQ_NONE; - clk_enable(obj-clk); errs = iommu_report_fault(obj, da); - clk_disable(obj-clk); Why do we remove the clk_ invocations here (instead of replacing them with get/put variants) ? Because in order to get an interrupt from the mmu device it implies that the mmu was functional already (with a clock), so I don't see how clk_enable/disable are needed here. Even if you rely on the IPU to maintain the clock enabled. Most of the above questions imply this patch not only converts the iommu to runtime PM, but may carry additional changes that may imply previous implementation is sub-optimal. I hope we can clearly document the motivation behind these changes too (maybe even consider extracting them to a different patch ?). I didn't want to extract this changes into different patches since they could be included in this one, otherwise it would look like lines adding and then deleting runtime pm functions. I do agree description is missing, again I thought I had done this somewhere but looks like I didn't, will update these. If you think these should be different patches please let me know, otherwise I would like to keep a single *documented* patch. @@ -990,6 +981,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) goto err_irq; platform_set_drvdata(pdev, obj); + pm_runtime_irq_safe(obj-dev); Let's also document why _irq_safe is needed here ? Ok. Thanks for the comments, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm
On 15 November 2012 11:39, Ohad Ben-Cohen o...@wizery.com wrote: I do agree description is missing, again I thought I had done this somewhere but looks like I didn't, will update these. If you think these should be different patches please let me know, otherwise I would like to keep a single *documented* patch. It seems like there are 3 different logical changes here: 1. remove clk_* invocations from iommu_fault_handler() 2. keep clocks enabled as long as iommu is enabled 3. convert to runtime pm If we split this to three patches in this order, you won't have to add and remove runtime pm functions. Let's do it, please. It's a small nuisance now, but may be really helpful in the future when someone tries to debug stuff and understand the motivation behind these changes. It'd make it much easier for you to document the changes, too: you have an entire commit log per change. Ok, not a problem then. Cheers, Omar -- 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 7/8] ARM: OMAP: Remove unnecessary inclusion of dmtimer.h
Hi Jon, On 14 November 2012 09:53, Jon Hunter jon-hun...@ti.com wrote: diff --git a/drivers/staging/tidspbridge/core/ue_deh.c b/drivers/staging/tidspbridge/core/ue_deh.c index 3d28b23..6aea6f1 100644 --- a/drivers/staging/tidspbridge/core/ue_deh.c +++ b/drivers/staging/tidspbridge/core/ue_deh.c @@ -19,7 +19,6 @@ #include linux/kernel.h #include linux/interrupt.h -#include plat/dmtimer.h #include dspbridge/dbdefs.h #include dspbridge/dspdeh.h Hi Omar, I should have had you in copy on this one. Are you ok with the removal of the above dmtimer.h include? It does not appear that this file needs to include dmtimer.h. Indeed, we don't use it here. Is it ok for this to go through Tony's tree? If so, care to ACK? Looks fine to me, but I believe you will want to let Greg know if this patch will bypass staging tree. Acked-by: Omar Ramirez Luna omar.l...@linaro.org Cheers, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] OMAP: iommu: hwmod, reset handling and runtime PM
These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. For this series I dropped the patches already included in mainline, along with cleanup and refactoring patches for save and restore of mmu context, and DT bindings. Due to single Image support, I rebased these on top of k3.7-rc5 and DEPEND on: [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu http://thread.gmane.org/gmane.linux.kernel/1387788 Minor rebasing might be needed if these are included on top of linux-omap, since they are affected by changes on headers being moved to include/linux/platform_data and arch/arm/mach-omap2. Omar Ramirez Luna (2): ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP3/4: iommu: adapt to runtime pm arch/arm/mach-omap2/devices.c|2 +- arch/arm/mach-omap2/omap-iommu.c | 167 +++--- drivers/iommu/omap-iommu.c | 68 +++-- drivers/iommu/omap-iommu.h |3 - drivers/iommu/omap-iommu2.c | 36 --- include/linux/platform_data/iommu-omap.h |9 ++- 6 files changed, 82 insertions(+), 203 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] ARM: OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/omap-iommu.c | 168 +++---
drivers/iommu/omap-iommu.c | 23 +++-
drivers/iommu/omap-iommu2.c | 19
include/linux/platform_data/iommu-omap.h |8 ++-
5 files changed, 64 insertions(+), 156 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include linux/platform_data/iommu-omap.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
-#include soc.h
-#include common.h
-
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
- {
- .base = OMAP4_MMU2_BASE,
- .irq = 28 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = tesla,
- .nr_tlb_entries = 32,
- .clk_name = dsp_fck,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
{
- int i, err;
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
+ struct platform_device *pdev;
+ struct iommu_platform_data *pdata;
+ struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+ static int i;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata-name = oh-name;
+ pdata-clk_name = oh-main_clk;
+ pdata-nr_tlb_entries = a-nr_tlb_entries;
+ pdata-da_start = a-da_start;
+ pdata-da_end = a-da_end;
+
+ if (oh-rst_lines_cnt == 1
[PATCH v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap-iommu.c |1 -
drivers/iommu/omap-iommu.c | 45 -
drivers/iommu/omap-iommu.h |3 --
drivers/iommu/omap-iommu2.c | 17 ---
include/linux/platform_data/iommu-omap.h |1 -
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 0a6a901..b42b3d1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/omap-iommu.h
#include linux/mutex.h
#include linux/spinlock.h
#include linux/io.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
return err;
}
@@ -176,11 +175,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj-clk);
-
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
@@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
if (!obj || !obj-nr_tlb_entries || !e)
return -EINVAL;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
iotlb_lock_get(obj, l);
if (l.base == obj-nr_tlb_entries) {
@@ -336,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return PTR_ERR(cr);
}
@@ -350,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, l);
out:
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return err;
}
@@ -380,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
for_each_iotlb_cr(obj, obj-nr_tlb_entries, i, cr) {
u32 start;
@@ -399,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (i == obj-nr_tlb_entries)
dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
@@ -413,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
{
struct iotlb_lock l;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
l.base = 0;
l.vict = 0;
@@ -421,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
iommu_write_reg(obj, 1, MMU_GFLUSH);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
}
#if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -431,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char
*buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
bytes = arch_iommu-dump_ctx(obj, buf, bytes);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return bytes;
}
@@ -449,7 +446,7 @@ __dump_tlb_entries(struct omap_iommu *obj, struct cr_regs
*crs, int num)
struct cr_regs tmp;
struct cr_regs *p = crs;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
iotlb_lock_get(obj, saved);
for_each_iotlb_cr(obj, num, i, tmp) {
@@ -459,7 +456,7
[PATCH] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks
This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk-enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.
According to comments received[1] for related patches the idea is
to get rid of leaf clocks in future. So remove these two while at it.
[1] http://lkml.org/lkml/2012/8/20/226
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/clock44xx_data.c | 22 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..067c486 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1316,16 +1316,6 @@ static struct clk dmic_fck = {
.clkdm_name = abe_clkdm,
};
-static struct clk dsp_fck = {
- .name = dsp_fck,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = tesla_clkdm,
- .parent = dpll_iva_m4x2_ck,
- .recalc = followparent_recalc,
-};
-
static struct clk dss_sys_clk = {
.name = dss_sys_clk,
.ops= clkops_omap2_dflt,
@@ -1696,16 +1686,6 @@ static struct clk i2c4_fck = {
.recalc = followparent_recalc,
};
-static struct clk ipu_fck = {
- .name = ipu_fck,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = ducati_clkdm,
- .parent = ducati_clk_mux_ck,
- .recalc = followparent_recalc,
-};
-
static struct clk iss_ctrlclk = {
.name = iss_ctrlclk,
.ops= clkops_omap2_dflt,
@@ -3151,7 +3131,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, div_ts_ck,div_ts_ck,
CK_446X),
CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck,
CK_443X),
CLK(NULL, dmic_fck, dmic_fck,
CK_443X),
- CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
CLK(NULL, dss_sys_clk, dss_sys_clk,
CK_443X),
CLK(NULL, dss_tv_clk, dss_tv_clk,
CK_443X),
CLK(NULL, dss_48mhz_clk,dss_48mhz_clk,
CK_443X),
@@ -3183,7 +3162,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, i2c2_fck, i2c2_fck,
CK_443X),
CLK(NULL, i2c3_fck, i2c3_fck,
CK_443X),
CLK(NULL, i2c4_fck, i2c4_fck,
CK_443X),
- CLK(NULL, ipu_fck, ipu_fck,
CK_443X),
CLK(NULL, iss_ctrlclk, iss_ctrlclk,
CK_443X),
CLK(NULL, iss_fck, iss_fck,
CK_443X),
CLK(NULL, iva_fck, iva_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aab5c12..1f61093 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -650,7 +650,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.mpu_irqs = omap44xx_dsp_irqs,
.rst_lines = omap44xx_dsp_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
- .main_clk = dsp_fck,
+ .main_clk = dpll_iva_m4x2_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
@@ -1677,7 +1677,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.mpu_irqs = omap44xx_ipu_irqs,
.rst_lines = omap44xx_ipu_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_resets),
- .main_clk = ipu_fck,
+ .main_clk = ducati_clk_mux_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
Hi, On 11 November 2012 03:39, Ohad Ben-Cohen o...@wizery.com wrote: On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren t...@atomide.com wrote: We need to move the iommu code to live under drivers for arm common zImage support. For the iommu changes in the entire series: Acked-by: Ohad Ben-Cohen o...@wizery.com Joerg, it might relieve some pain if this will go through Tony's tree, as there are some OMAP platform iommu changes coming in from Omar as well (part of which might have already been merged in the omap branches). Hope it's ok with both of you guys? Omar, do you still have any iommu changes coming in ? Yes, I have the hwmod and runtime pm changes for iommu, I was waiting for Tony to publish a branch with these changes to submit (as per Tony's suggestion), but I already have the patches rebased onto these. I will submit them. Cheers, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
Hi Stephen, On 5 November 2012 21:40, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote: Actually moving it from plat-omap, as this framework/driver code is supposed to be under drivers/ folder. The framework should work with the current supported OMAP processors (OMAP1+) that have mailbox and can be used as a method of interprocessor communication. The mailbox hardware (in OMAP) uses a queued mailbox-interrupt mechanism that provides a communication channel between processors through a set of registers and their associated interrupt signals by sending and receiving messages. diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? Is this a generic interface to any mailbox driver? If so, then I don't think having omap in the symbol names is appropriate. If the header is specific to the OMAP driver, I don't think using the very generic filename mailbox.h is appropriate; use omap_mailbox.h instead? It was a mixture between the two, the next patch splits the API from the mailbox driver interfaces. I kept the files named as plain mailbox.[ch], in hopes that we could progress with the cleanup after moving the files from plat-omap, as it seems they interfere with the current single Image effort, but if it is preferred (as it seems to be) I can resend again after removing the omap_ prefixes from the intended-to-be generic code. Thanks, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
Hi Greg, On 6 November 2012 02:59, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote: On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren swar...@wwwdotorg.org wrote: Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? I think the split out of the public header is done in patch 2/2. Yes, but the names are still omap_*, which doesn't make much sense here. Ok, I have no problem with this... I was under the impression that moving this code out of plat-omap was blocking single zImage support hence the minimal changes to move it to drivers/. I will strip the generic portions from omap_ prefixes and resend. Cheers, Omar -- 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 2/2] mailbox: split internal header from API header
Hi Loic,
On 6 November 2012 06:53, Loic PALLARDY loic.palla...@st.com wrote:
On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
Now internal structures can remain hidden to the user and just API
related functions and defines are made available.
Signed-off-by: Omar Ramirez Lunaomar.l...@linaro.org
---
drivers/mailbox/mailbox.c | 34
drivers/mailbox/mailbox.h | 48
+
include/linux/mailbox.h | 22 +++
I agree with the file split but I think mailbox framework API should be
more generic.
omap_ prefix should not be used. mailbox_ prefix will be better.
Ok.
Message type must be more opened like for example:
struct mailbox_msg {
int size;
unsigned char header;
unsigned char *pdata;
};
We can analyze the requirement for having such structure, presumably
you expect variable size messages, in OMAP case it is a 4 byte value,
but I'm open to change in order to accommodate other users needs.
Cheers,
Omar
--
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 v2 0/2] drivers: mailbox: omap-mailbox out of plat code
As part of plat-omap code cleanup, move omap-mailbox framework to a newly drivers/mailbox folder, right now this code is specific to OMAP platforms, but with some clean up it could be the base for a generic framework; living under drivers/mailbox could give it some exposure for interested developers to give feedback and propose changes. In the past there was a mailbox-like driver in mach-ux500, I was hoping both could live under the same folder, however the platform using it, was dropped a couple of kernel releases back and with it the other similar mailbox implementation. However and as per Loic's comments[1], it looks like there could be another potential mailbox candidate to live under drivers/mailbox in the works, along with some proposed changes that could make the original framework to evolve towards a generic implementation. So for now, lets move the mailbox code to drivers/mailbox and split internal structures from common API for others to use. Based on 3.7-rc4. 1. https://lkml.org/lkml/2012/10/31/123 Omar Ramirez Luna (2): mailbox: OMAP: introduce mailbox framework mailbox: split internal header from API header arch/arm/configs/omap1_defconfig |3 +- arch/arm/mach-omap1/Makefile |4 - arch/arm/mach-omap1/mailbox.c | 199 arch/arm/mach-omap2/Makefile |3 - arch/arm/mach-omap2/devices.c |4 +- arch/arm/mach-omap2/mailbox.c | 430 -- arch/arm/plat-omap/Kconfig| 16 - arch/arm/plat-omap/Makefile |3 - arch/arm/plat-omap/include/plat/mailbox.h | 105 --- arch/arm/plat-omap/mailbox.c | 435 -- drivers/Kconfig |2 + drivers/Makefile |1 + drivers/mailbox/Kconfig | 37 +++ drivers/mailbox/Makefile |4 + drivers/mailbox/mailbox-omap1.c | 200 drivers/mailbox/mailbox-omap2.c | 430 ++ drivers/mailbox/mailbox.c | 469 + drivers/mailbox/mailbox.h | 59 include/linux/mailbox.h | 22 ++ 19 files changed, 1228 insertions(+), 1198 deletions(-) delete mode 100644 arch/arm/mach-omap1/mailbox.c delete mode 100644 arch/arm/mach-omap2/mailbox.c delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h delete mode 100644 arch/arm/plat-omap/mailbox.c create mode 100644 drivers/mailbox/Kconfig create mode 100644 drivers/mailbox/Makefile create mode 100644 drivers/mailbox/mailbox-omap1.c create mode 100644 drivers/mailbox/mailbox-omap2.c create mode 100644 drivers/mailbox/mailbox.c create mode 100644 drivers/mailbox/mailbox.h create mode 100644 include/linux/mailbox.h -- 1.7.9.5 -- 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 v2 2/2] mailbox: split internal header from API header
Now internal structures can remain hidden to the user and just API
related functions and defines are made available.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/mailbox/mailbox.c | 34
drivers/mailbox/mailbox.h | 48 +
include/linux/mailbox.h | 22 +
3 files changed, 57 insertions(+), 47 deletions(-)
create mode 100644 include/linux/mailbox.h
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 6346ad3..aab9a13 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -116,6 +116,40 @@ out:
}
EXPORT_SYMBOL(omap_mbox_msg_send);
+void omap_mbox_save_ctx(struct omap_mbox *mbox)
+{
+ if (!mbox-ops-save_ctx) {
+ dev_err(mbox-dev, %s:\tno save\n, __func__);
+ return;
+ }
+
+ mbox-ops-save_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_save_ctx);
+
+void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+{
+ if (!mbox-ops-restore_ctx) {
+ dev_err(mbox-dev, %s:\tno restore\n, __func__);
+ return;
+ }
+
+ mbox-ops-restore_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_restore_ctx);
+
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+ mbox-ops-enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
+
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+ mbox-ops-disable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
+
static void mbox_tx_tasklet(unsigned long tx_data)
{
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
index cc3921e..b05f64c 100644
--- a/drivers/mailbox/mailbox.h
+++ b/drivers/mailbox/mailbox.h
@@ -8,17 +8,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/kfifo.h
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+#include linux/mailbox.h
struct omap_mbox_ops {
omap_mbox_type_ttype;
@@ -61,45 +51,9 @@ struct omap_mbox {
struct blocking_notifier_head notifier;
};
-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 notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
int omap_mbox_register(struct device *parent, struct omap_mbox **);
int omap_mbox_unregister(void);
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
- if (!mbox-ops-save_ctx) {
- dev_err(mbox-dev, %s:\tno save\n, __func__);
- return;
- }
-
- mbox-ops-save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
- if (!mbox-ops-restore_ctx) {
- dev_err(mbox-dev, %s:\tno restore\n, __func__);
- return;
- }
-
- mbox-ops-restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
- omap_mbox_irq_t irq)
-{
- mbox-ops-enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
- mbox-ops-disable_irq(mbox, irq);
-}
-
#endif /* MAILBOX_H */
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
new file mode 100644
index 000..e8e4131
--- /dev/null
+++ b/include/linux/mailbox.h
@@ -0,0 +1,22 @@
+/* mailbox.h */
+
+typedef u32 mbox_msg_t;
+struct omap_mbox;
+
+typedef int __bitwise omap_mbox_irq_t;
+#define IRQ_TX ((__force omap_mbox_irq_t) 1)
+#define IRQ_RX ((__force omap_mbox_irq_t) 2)
+
+typedef int __bitwise omap_mbox_type_t;
+#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
+#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+
+int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
+
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
+
+void omap_mbox_save_ctx(struct omap_mbox *mbox);
+void omap_mbox_restore_ctx(struct omap_mbox *mbox);
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
--
1.7.9.5
--
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/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
Hi Greg, On 30 October 2012 16:02, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: OK. Greg, do these patches look OK to you to move to live under drivers/mailbox? Um, I don't know, I wasn't paying attention here, sorry. As part of plat-omap code cleanup, I was planning to move omap-mailbox framework to a newly drivers/mailbox folder, right now this code is specific to OMAP platforms, but with some clean up it could be the base for a generic framework. And living under drivers/mailbox could give it some exposure for interested developers to give feedback and propose changes. In the past there was a mailbox-like driver in mach-ux500, I was hoping both could live under the same folder, however the platform using it, was dropped a couple of kernel releases back and with it the other similar mailbox implementation. So, here it is the thread with the patches: http://thread.gmane.org/gmane.linux.kernel/1384603, if you think it is OK for them to be moved under drivers/mailbox, I just need to re-spin them to move the mailbox header file to include/linux/mailbox instead of include/linux/platform_data. Cheers, Omar -- 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/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
Tony, On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote: --- /dev/null +++ b/include/linux/platform_data/omap_mailbox.h @@ -0,0 +1,105 @@ This file should only contain pure platform data needed by the core omap code to pass to the mailbox driver. Ok, looking at it closely, this header file is related to the API itself, there is nothing that could be actually considered as pure platform data, the structures are related with the mailbox framework and even if I split this file into two, the additional header would end up including the platform_data header unless I move save/restore_ctx functions and then export them as symbols for the API. So, it might be better for the entire file to sit in linux/include/mailbox/ then. The mailbox API header should be somewhere else, like include/linux/mailbox/mailbox-omap.h or similar. Ok. But shouldn't this all now be handled by using the remoteproc framework? Remoteproc doesn't handle the mailbox hardware directly, it still relies in the mailbox framework for the low level communications. E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses mailbox msg to generate an interrupt to Proc2, Proc2 queries the message (virtqueue) based on the mailbox message received. Regards, Omar -- 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 2/2] mailbox: OMAP: introduce mailbox framework
Actually moving it from plat-omap code as this is supposed to be
under drivers/ folder. This framework should work with the current
OMAP processors that have mailbox and can be used as a method of
interprocessor communication.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/Kconfig | 16 --
arch/arm/plat-omap/Makefile |3 -
arch/arm/plat-omap/mailbox.c | 435 --
drivers/Kconfig |2 +
drivers/Makefile |1 +
drivers/mailbox/Kconfig | 28 +++
drivers/mailbox/Makefile |1 +
drivers/mailbox/mailbox.c| 435 ++
8 files changed, 467 insertions(+), 454 deletions(-)
delete mode 100644 arch/arm/plat-omap/mailbox.c
create mode 100644 drivers/mailbox/Kconfig
create mode 100644 drivers/mailbox/Makefile
create mode 100644 drivers/mailbox/mailbox.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 82fcb20..419648f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -116,22 +116,6 @@ config OMAP_MUX_WARNINGS
to change the pin multiplexing setup. When there are no warnings
printed, it's safe to deselect OMAP_MUX for your product.
-config OMAP_MBOX_FWK
- tristate Mailbox framework support
- depends on ARCH_OMAP
- help
- Say Y here if you want to use OMAP Mailbox framework support for
- DSP, IVA1.0 and IVA2 in OMAP1/2/3.
-
-config OMAP_MBOX_KFIFO_SIZE
- int Mailbox kfifo default buffer size (bytes)
- depends on OMAP_MBOX_FWK
- default 256
- help
- Specify the default size of mailbox's kfifo buffers (bytes).
- This can also be changed at runtime (via the mbox_kfifo_size
- module parameter).
-
config OMAP_IOMMU_IVA2
bool
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 4bd0ace..4702d1f 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -16,7 +16,4 @@ obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-y)
-# OMAP mailbox framework
-obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
deleted file mode 100644
index cae8692..000
--- a/arch/arm/plat-omap/mailbox.c
+++ /dev/null
@@ -1,435 +0,0 @@
-/*
- * OMAP mailbox driver
- *
- * Copyright (C) 2006-2009 Nokia Corporation. All rights reserved.
- *
- * Contact: Hiroshi DOYU hiroshi.d...@nokia.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.
- *
- * This program 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 this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include linux/interrupt.h
-#include linux/spinlock.h
-#include linux/mutex.h
-#include linux/delay.h
-#include linux/slab.h
-#include linux/kfifo.h
-#include linux/err.h
-#include linux/notifier.h
-#include linux/module.h
-
-#include linux/platform_data/omap_mailbox.h
-
-static struct omap_mbox **mboxes;
-
-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));
-
-/* Mailbox FIFO handle functions */
-static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
-{
- return mbox-ops-fifo_read(mbox);
-}
-static inline void mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
- mbox-ops-fifo_write(mbox, msg);
-}
-static inline int mbox_fifo_empty(struct omap_mbox *mbox)
-{
- return mbox-ops-fifo_empty(mbox);
-}
-static inline int mbox_fifo_full(struct omap_mbox *mbox)
-{
- return mbox-ops-fifo_full(mbox);
-}
-
-/* Mailbox IRQ handle functions */
-static inline void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
- if (mbox-ops-ack_irq)
- mbox-ops-ack_irq(mbox, irq);
-}
-static inline int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
- return mbox-ops-is_irq(mbox, irq);
-}
-
-/*
- * message sender
- */
-static int __mbox_poll_for_space(struct omap_mbox *mbox)
-{
- int ret = 0, i = 1000;
-
- while (mbox_fifo_full(mbox)) {
- if (mbox-ops-type == OMAP_MBOX_TYPE2)
- return -1;
- if (--i == 0
[PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: de...@driverdev.osuosl.org
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/mailbox.c |2 +-
arch/arm/plat-omap/include/plat/mailbox.h | 105
arch/arm/plat-omap/mailbox.c |2 +-
.../tidspbridge/include/dspbridge/host_os.h|2 +-
include/linux/platform_data/omap_mailbox.h | 105
5 files changed, 108 insertions(+), 108 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
create mode 100644 include/linux/platform_data/omap_mailbox.h
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..f69e659 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -17,7 +17,7 @@
#include linux/io.h
#include linux/pm_runtime.h
-#include plat/mailbox.h
+#include linux/platform_data/omap_mailbox.h
#include soc.h
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
deleted file mode 100644
index cc3921e..000
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ /dev/null
@@ -1,105 +0,0 @@
-/* mailbox.h */
-
-#ifndef MAILBOX_H
-#define MAILBOX_H
-
-#include linux/spinlock.h
-#include linux/workqueue.h
-#include linux/interrupt.h
-#include linux/device.h
-#include linux/kfifo.h
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
-
-struct omap_mbox_ops {
- omap_mbox_type_ttype;
- int (*startup)(struct omap_mbox *mbox);
- void(*shutdown)(struct omap_mbox *mbox);
- /* fifo */
- mbox_msg_t (*fifo_read)(struct omap_mbox *mbox);
- void(*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
- int (*fifo_empty)(struct omap_mbox *mbox);
- int (*fifo_full)(struct omap_mbox *mbox);
- /* irq */
- void(*enable_irq)(struct omap_mbox *mbox,
- omap_mbox_irq_t irq);
- void(*disable_irq)(struct omap_mbox *mbox,
- omap_mbox_irq_t irq);
- void(*ack_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
- int (*is_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
- /* ctx */
- void(*save_ctx)(struct omap_mbox *mbox);
- void(*restore_ctx)(struct omap_mbox *mbox);
-};
-
-struct omap_mbox_queue {
- spinlock_t lock;
- struct kfifofifo;
- struct work_struct work;
- struct tasklet_struct tasklet;
- struct omap_mbox*mbox;
- bool full;
-};
-
-struct omap_mbox {
- char*name;
- unsigned intirq;
- struct omap_mbox_queue *txq, *rxq;
- struct omap_mbox_ops*ops;
- struct device *dev;
- void*priv;
- int use_count;
- struct blocking_notifier_head notifier;
-};
-
-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 notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
-int omap_mbox_register(struct device *parent, struct omap_mbox **);
-int omap_mbox_unregister(void);
-
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
- if (!mbox-ops-save_ctx) {
- dev_err(mbox-dev, %s:\tno save\n, __func__);
- return;
- }
-
- mbox-ops-save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
- if (!mbox-ops-restore_ctx) {
- dev_err(mbox-dev, %s:\tno restore\n, __func__);
- return;
- }
-
- mbox-ops-restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
- omap_mbox_irq_t irq)
-{
- mbox-ops-enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
- mbox-ops-disable_irq(mbox, irq);
-}
-
-#endif /* MAILBOX_H */
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 42377ef..cae8692 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -31,7 +31,7 @@
#include linux/notifier.h
#include linux/module.h
-#include plat/mailbox.h
+#include linux/platform_data/omap_mailbox.h
static struct omap_mbox **mboxes;
diff
[PATCH 0/2] ARM: OMAP: mailbox out of plat code
From: Omar Ramirez Luna omar.rami...@copitl.com Move Mailbox's headers and driver out of platform code as per current plat-omap cleanup activities. While at it move mailbox code out of platform and to drivers/ folder, given that this is an OMAP specific framework, some people might frown upon this, however it seemed worth to try to move it now. I was expecting this could also pull out the mailbox code from ux-500 platform, but the platform with a similar mailbox mechanism has been deleted during 3.5 rc cycle. So, are there any other mailbox-like drivers out there? Omar Ramirez Luna (2): ARM: OMAP2+: move mailbox.h out of plat-omap headers mailbox: OMAP: introduce mailbox framework arch/arm/mach-omap2/mailbox.c |2 +- arch/arm/plat-omap/Kconfig | 16 - arch/arm/plat-omap/Makefile|3 - arch/arm/plat-omap/include/plat/mailbox.h | 105 - arch/arm/plat-omap/mailbox.c | 435 drivers/Kconfig|2 + drivers/Makefile |1 + drivers/mailbox/Kconfig| 28 ++ drivers/mailbox/Makefile |1 + drivers/mailbox/mailbox.c | 435 .../tidspbridge/include/dspbridge/host_os.h|2 +- include/linux/platform_data/omap_mailbox.h | 105 + 12 files changed, 574 insertions(+), 561 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h delete mode 100644 arch/arm/plat-omap/mailbox.c create mode 100644 drivers/mailbox/Kconfig create mode 100644 drivers/mailbox/Makefile create mode 100644 drivers/mailbox/mailbox.c create mode 100644 include/linux/platform_data/omap_mailbox.h -- 1.7.9.5 -- 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
tidspbridge: ARM common zImage?
Hi, On 26 October 2012 13:00, Tony Lindgren t...@atomide.com wrote: ... I would also like to move the tidspbridge to the DMA API, but I think we'll need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an intermediate step would allow splitting patches in reviewable chunks. I know it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a temporary nuisance to make the leap easier. Since tidspbridge is in staging I guess it's not a problem, though it sounds to me like using the correct API in the first place is going to make less churn. Not related to these patches, but also sounds like we may need to drop some staging/tidspbridge code to be able to move forward with the ARM common zImage plans. See the [GIT PULL] omap plat header removal for v3.8 merge window, part1 thread for more info. I was trying to find some more info on this, but only found one patch for tidspbridge to delete an include... it seems that I must try with these patches and see what explodes since we heavily abuse prcm code too. Thanks, Omar -- 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: Beagleboard xM - play video file : BUG: scheduling while atomic: queue1:src/92/0x0000008e , then kernel panic
Hi, On Wed, Oct 24, 2012 at 10:34 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Hi, Selso, hopefully you don't mind, but I'll forward this to the linux-omap mailing list, as this seems to be an interesting kernel problem in tidspbridge. Omar, any ideas? I don't see tidspbridge trace paths (but I don't discard something wrong either ;)), however I do see a framebuffer, dss, dispc trace, might be a good point to start checking: [ 467.404663] BUG: scheduling while atomic: dspvdec0:src/94/0x008d ht=(int)400, pix[ 467.420623] Modules linked in:el-aspect-ratio= tidspbridge(C)(fraction)1/1, f mailbox_machramerate=(fracti mailboxon)143/6 Pipeli ne is PREROLLED [ 467.442810] [c001369c] (unwind_backtrace+0x0/0xe0) from [c05b99e4] (__schedule_bug+0x48/0x5c) ... Setting pip[ 467.462066] [c05b99e4] (__schedule_bug+0x48/0x5c) from [c05c2d1c] (__schedule+0x60/0x798) eline to PLAYING[ 467.480987] [c05c2d1c] (__schedule+0x60/0x798) from [c05c183c] (schedule_timeout+0x1dc/0x218) ... New clock:[ 467.500213] [c05c183c] (schedule_timeout+0x1dc/0x218) from [c05c2a34] (wait_for_common+0x104/0x1bc) [ 467.520050] [c05c2a34] (wait_for_common+0x104/0x1bc) from [c0362f00] (omap_dispc_wait_for_irq_interruptible_timeout+0x4c/0x84) [ 467.542510] [c0362f00] (omap_dispc_wait_for_irq_interruptible_timeout+0x4c/0x84) from [c0364158] (dss_mgr_wait_for_vsync+0x50/0x60) [ 467.564208] [c0364158] (dss_mgr_wait_for_vsync+0x50/0x60) from [c03773fc] (omapfb_ioctl+0x9cc/0xed0) [ 467.583099] [c03773fc] (omapfb_ioctl+0x9cc/0xed0) from [c0345e9c] (do_fb_ioctl+0x56c/0x5a8) [ 467.601196] [c0345e9c] (do_fb_ioctl+0x56c/0x5a8) from [c011ffa4] (vfs_ioctl+0x24/0x40) [ 467.618804] [c011ffa4] (vfs_ioctl+0x24/0x40) from [c0120ab4] (do_vfs_ioctl+0x560/0x5a8) [ 467.636535] [c0120ab4] (do_vfs_ioctl+0x560/0x5a8) from [c0120b48] (sys_ioctl+0x4c/0x6c) [ 467.654205] [c0120b48] (sys_ioctl+0x4c/0x6c) from [c000d4c0] (ret_fast_syscall+0x0/0x30) ... CONFIG_TIDSPBRIDGE_CACHE_LINE_CHECK=y I wasn't aware that now gst-dsp supported this, might be time to update mine. Anyway, right now I have lots of debugging enabled and specifically the one that spits scheduling while atomic with kernel 3.7-rc2, and I'm not seeing this with the fakesink decode, and the encoder to a file, I don't have framebuffer nor display though. What kernel is this? If non-mainline, I might try it out of curiosity. Regards, Omar -- 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 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
Tony, On 18 October 2012 18:52, Tony Lindgren t...@atomide.com wrote: Thanks, the related patches are now posted in thread [PATCH v3 0/6] omap iommu changes to remove plat includes. Ok. Also, can you please take a look at the Updated status of the removal of plat headers thread? I've tagged you to remove the omap plat/mailbox.h :) Yes, got the request from Benoit too, but just now had the time to look at it. Cheers, Omar -- 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: Updated status of the removal of plat headers
Hi, On 16 October 2012 18:00, Tony Lindgren t...@atomide.com wrote: Hi all, Here's a quick status update on the removal of remaining #include plat/*.h files. Most files are now fixed up, and we only have the following remaining: cpu.h wrapper only left, will be removed as soon as drivers are fixed dmtimer.h Jon is fixing this mailbox.h Omar, are you fixing this? Yes, I'm taking this. Regards, Omar -- 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 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote: On probe this patch does pm_runtime_enable, however this doesn't mean the device is turned ON or resumed or kept ON all the time. In fact it's the other way around; pm_runtime_enable turns off the power (if it's ON). pm_runtime_enable just decrements the disable_depth counter. Doesn't turn off anything by itself. @@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct platform_device *pdev) release_mem_region(res-start, resource_size(res)); iounmap(obj-regbase); - clk_put(obj-clk); + pm_runtime_disable(obj-dev); This will turn on the device unnecessarily, wasting power, and there's no need for that, kfree will take care of that without resuming. Left aside the aesthetics of having balanced calls, the device will be enabled if there was a pending resume to be executed, otherwise it won't, kfree won't increment the disable_depth counter and I don't think that freeing the pointer is enough reason to ignore pm_runtime_disable. You are doing __pm_runtime_disable(dev, true), kfree will do __pm_runtime_disable(dev, false), which is what we want. Both will decrement the disable_depth. I'm quite confused here, could you please point me to the kfree snip that does __pm_runtime_disable(dev, false)? Sorry, not kfree, but the device removal process: device_del device_pm_remove pm_runtime_remove __pm_runtime_disable - HERE I'm not entirely convinced _iommu_ follows this path, it doesn't create any devices nor register them... whereas mailbox does create devices and mailbox does follow this path for the devices created which are child devices. So this path won't take care of the omap-iommu device pm_runtime_disable. But at least you agree that there's a chance that the device will be waken up. Of course, if there is a pending resume to be executed, it must honor that resume request and then turn off the device before removing the iommu, IMHO. Who will turn off the device afterwards? What I meant is that omap_iommu_detach should turn off the device before removing the iommu. Cheers, Omar -- 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 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
On 16 October 2012 12:22, Tony Lindgren t...@atomide.com wrote: * Omar Ramirez Luna omar.l...@linaro.org [121011 18:07]: These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. Although IOMMU hwmod patches were already submitted in the past, this series adds few more changes, like: - New reset handling. - Save and restore context code rework. - Device tree bindings for OMAP3 and OMAP4. For this series I just dropped the patches already included in mainline. These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu when I have that pushed out as that removes plat/*iommu*.h files. Ok, will wait and rebase on top of it. Thanks, Omar -- 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 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
Hi Felipe,
On 12 October 2012 16:25, Felipe Contreras felipe.contre...@gmail.com wrote:
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
The device will never go to sleep, until iommu_disable is called.
clk_enable - pm_runtime_get_sync, clk_disable pm_runtime_put.
Which is what you want... why would you want your iommu to be disabled
if the client of that iommu could request a translation?
That's the whole point of *dynamic* pm; _when_ the client wants to
request a translation, _then_ the device is waken up, which is what I
believe the code currently does.
No it doesn't, current code is working because the processor and the
iommu share the same clock, so enabling the processor is implicitly
guaranteeing that the iommu will be enabled. IMHO, there shouldn't be
such assumption that you can control both with the same clock.
So, once the remote processor is enabled, any dynamic pm from iommu
with current code has no effect because the clock was already enabled
for the processor.
After your patch, even if I don't use the camera, or the DSP, the
iommu devices will be enabled, and will be consuming energy *all the
time*. Which I don't think is what we want.
Wrong, the iommu device will be enabled by pm_runtime_get_sync once
you decide to attach with iommu_attach_device, if you do not use
camera or the dsp, you won't turn ON the iommus.
On probe this patch does pm_runtime_enable, however this doesn't mean
the device is turned ON or resumed or kept ON all the time.
I'm not saying I have a solution, I'm simply saying that's what's
going to happen if I'm correct.
Ok, but that is not what happens here.
Remember that these iommus, sit along of other processors not on the
main processor side. So, this code should enable it for the other
processor to use, and there is no point where the processor can say
I'm not using it, shut it down or I'm using it, turn it on in the
middle of execution, other than suspend/resume and if supported,
autosuspend.
I understand, but perhaps there should be?
Autosuspend is a feature missing and should handle the scenario where
the remote processor can sleep dynamically, this scenario should turn
off the iommu and the remote processor itself when there is no
workload but it depends on the remote processor activity not the iommu
activity.
@@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
release_mem_region(res-start, resource_size(res));
iounmap(obj-regbase);
- clk_put(obj-clk);
+ pm_runtime_disable(obj-dev);
This will turn on the device unnecessarily, wasting power, and there's
no need for that, kfree will take care of that without resuming.
Left aside the aesthetics of having balanced calls, the device will be
enabled if there was a pending resume to be executed, otherwise it
won't, kfree won't increment the disable_depth counter and I don't
think that freeing the pointer is enough reason to ignore
pm_runtime_disable.
You are doing __pm_runtime_disable(dev, true), kfree will do
__pm_runtime_disable(dev, false), which is what we want. Both will
decrement the disable_depth.
I'm quite confused here, could you please point me to the kfree snip
that does __pm_runtime_disable(dev, false)?
But at least you agree that there's a chance that the device will be waken up.
Of course, if there is a pending resume to be executed, it must honor
that resume request and then turn off the device before removing the
iommu, IMHO.
Also, I still think that something like this is needed:
...
+static struct clk cam_fck = {
+ .name = cam_fck,
+ .ops= clkops_omap2_iclk_dflt,
+ .parent = l3_ick,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_CAM_MOD, CM_ICLKEN),
a cam_fck name to enable the ick?
Yeap, according to the TRM. Take a look at 12.3 Camera ISP Integration
Fig 12-50.
What I meant is that, you are using the CM_ICLKEN to enable a clock
named cam_fck which has l3_ick as a parent. And that is not
consistent with what that register is meant to do, which is:
4.14.1.10 CAM_CM Registers
CM_ICKLEN_CAM
0x0: CAM_L3_ICK and CAM_L4_ICLK are disabled
0x1: CAM_L3_ICK and CAM_L4_ICLK are enabled
So, I'm complaining about the name cam_fck, for an interface clock
with parent l3_ick. However I don't know why on section 12.3 they
refer to CAM_FCK to a l3_ick child clock.
Cheers,
Omar
--
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 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
On 12 October 2012 02:48, Felipe Contreras felipe.contre...@gmail.com wrote:
I already made most of these comments, but here they go again.
I replied to all, but here it goes again:
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
The device will never go to sleep, until iommu_disable is called.
clk_enable - pm_runtime_get_sync, clk_disable pm_runtime_put.
Which is what you want... why would you want your iommu to be disabled
if the client of that iommu could request a translation?
Remember that these iommus, sit along of other processors not on the
main processor side. So, this code should enable it for the other
processor to use, and there is no point where the processor can say
I'm not using it, shut it down or I'm using it, turn it on in the
middle of execution, other than suspend/resume and if supported,
autosuspend.
@@ -288,7 +285,7 @@ static int load_iotlb_entry(struct omap_iommu *obj,
struct iotlb_entry *e)
if (!obj || !obj-nr_tlb_entries || !e)
return -EINVAL;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
iotlb_lock_get(obj, l);
if (l.base == obj-nr_tlb_entries) {
@@ -318,7 +315,7 @@ static int load_iotlb_entry(struct omap_iommu *obj,
struct iotlb_entry *e)
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return PTR_ERR(cr);
}
If I'm correct, the above pm_runtime_get/put are redundant, because
the count can't possibly reach 0 because of the reason I explained
before.
The same for all the cases below.
You can access this paths through debugfs, some of them doesn't work
if the module is not enabled first, but in future if you just want to
idle the iommu withouth freeing, these are needed to debug.
BTW, the next patch in the series: ARM: OMAP: iommu: pm runtime save
and restore context, let's you do a pm_runtime_[enable|put] through
save/restore ctx functions, which is just for compatibility on how isp
code uses the save and restore code.
@@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
release_mem_region(res-start, resource_size(res));
iounmap(obj-regbase);
- clk_put(obj-clk);
+ pm_runtime_disable(obj-dev);
This will turn on the device unnecessarily, wasting power, and there's
no need for that, kfree will take care of that without resuming.
Left aside the aesthetics of having balanced calls, the device will be
enabled if there was a pending resume to be executed, otherwise it
won't, kfree won't increment the disable_depth counter and I don't
think that freeing the pointer is enough reason to ignore
pm_runtime_disable.
Also, I still think that something like this is needed:
...
+static struct clk cam_fck = {
+ .name = cam_fck,
+ .ops= clkops_omap2_iclk_dflt,
+ .parent = l3_ick,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_CAM_MOD, CM_ICLKEN),
a cam_fck name to enable the ick?
Cheers,
Omar
--
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 v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. Although IOMMU hwmod patches were already submitted in the past, this series adds few more changes, like: - New reset handling. - Save and restore context code rework. - Device tree bindings for OMAP3 and OMAP4. For this series I just dropped the patches already included in mainline. Previous work can be found at: [v2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg75701.html [v1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70447.html [old iteration without reset, save/restore and device tree] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60133.html Omar Ramirez Luna (6): ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP3/4: iommu: adapt to runtime pm ARM: OMAP: iommu: pm runtime save and restore context ARM: OMAP: iommu: optimize save and restore routines ARM: OMAP: iommu: add device tree support arm/dts: OMAP3/4: Add iommu nodes .../devicetree/bindings/arm/omap/iommu.txt | 10 ++ arch/arm/boot/dts/omap3.dtsi | 12 +- arch/arm/boot/dts/omap4.dtsi | 17 +- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/iommu2.c | 74 ++-- arch/arm/mach-omap2/omap-iommu.c | 176 +--- arch/arm/plat-omap/include/plat/iommu.h| 20 ++- arch/arm/plat-omap/include/plat/iommu2.h |4 - drivers/iommu/omap-iommu.c | 163 ++ 9 files changed, 245 insertions(+), 233 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt -- 1.7.9.5 -- 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 v3 1/6] ARM: OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 165 +++
arch/arm/plat-omap/include/plat/iommu.h |8 +-
drivers/iommu/omap-iommu.c | 23 -
5 files changed, 64 insertions(+), 153 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..e084b94 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l MMU_SYS_RESETDONE)) {
- dev_err(obj-dev, can't take mmu out of reset\n);
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..e400845 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,64 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include plat/iommu.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include soc.h
#include common.h
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0
[PATCH 1/6] ARM: OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 165 +++
arch/arm/plat-omap/include/plat/iommu.h |8 +-
drivers/iommu/omap-iommu.c | 23 -
5 files changed, 64 insertions(+), 153 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..e084b94 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l MMU_SYS_RESETDONE)) {
- dev_err(obj-dev, can't take mmu out of reset\n);
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..e400845 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,64 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include plat/iommu.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include soc.h
#include common.h
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0
[PATCH v3 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 17 ---
arch/arm/mach-omap2/omap-iommu.c |1 -
arch/arm/plat-omap/include/plat/iommu.h |2 --
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c | 45 +-
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 35cab47..3e47786 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
*/
#define IOMMU_ARCH_VERSION 0x0011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l = ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -243,8 +228,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index e400845..82a422a 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -34,7 +34,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 0fa913d..902d193 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -30,7 +30,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
@@ -120,7 +119,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
const char *reset_name;
int nr_tlb_entries;
u32 da_start;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index d4116b5..1579694 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c1caee4..37644c4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/mutex.h
#include linux/spinlock.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
return err;
}
@@ -158,11 +157,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj-clk);
-
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (pdata-assert_reset
[PATCH 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 17 ---
arch/arm/mach-omap2/omap-iommu.c |1 -
arch/arm/plat-omap/include/plat/iommu.h |2 --
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c | 45 +-
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 35cab47..3e47786 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
*/
#define IOMMU_ARCH_VERSION 0x0011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l = ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -243,8 +228,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index e400845..82a422a 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -34,7 +34,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 0fa913d..902d193 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -30,7 +30,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
@@ -120,7 +119,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
const char *reset_name;
int nr_tlb_entries;
u32 da_start;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index d4116b5..1579694 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c1caee4..37644c4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/mutex.h
#include linux/spinlock.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
return err;
}
@@ -158,11 +157,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj-clk);
-
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (pdata-assert_reset
[PATCH v3 3/6] ARM: OMAP: iommu: pm runtime save and restore context
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 37644c4..875e894 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -97,7 +97,7 @@ void omap_iommu_save_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-save_ctx(obj);
+ pm_runtime_put_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
@@ -109,7 +109,7 @@ void omap_iommu_restore_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-restore_ctx(obj);
+ pm_runtime_get_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
@@ -1008,11 +1008,36 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_iommu_runtime_suspend(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-save_ctx(obj);
+
+ return 0;
+}
+
+static int omap_iommu_runtime_resume(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-restore_ctx(obj);
+
+ return 0;
+}
+
+static const struct dev_pm_ops iommu_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap_iommu_runtime_suspend,
+ omap_iommu_runtime_resume,
+ NULL)
+};
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
+ .pm = iommu_pm_ops,
},
};
--
1.7.9.5
--
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/6] ARM: OMAP: iommu: pm runtime save and restore context
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 37644c4..875e894 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -97,7 +97,7 @@ void omap_iommu_save_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-save_ctx(obj);
+ pm_runtime_put_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
@@ -109,7 +109,7 @@ void omap_iommu_restore_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-restore_ctx(obj);
+ pm_runtime_get_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
@@ -1008,11 +1008,36 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_iommu_runtime_suspend(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-save_ctx(obj);
+
+ return 0;
+}
+
+static int omap_iommu_runtime_resume(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-restore_ctx(obj);
+
+ return 0;
+}
+
+static const struct dev_pm_ops iommu_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap_iommu_runtime_suspend,
+ omap_iommu_runtime_resume,
+ NULL)
+};
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
+ .pm = iommu_pm_ops,
},
};
--
1.7.9.5
--
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 v3 4/6] ARM: OMAP: iommu: optimize save and restore routines
These functions save and restore registers irrespectively of their
read or write permissions, this ends up in registers being saved
that can't be restored because of read only attributes. OTOH, so
far only 3 of them need to be saved.
In future GP_REG (which is present only on OMAP4 ipu) needs to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 38 ++
arch/arm/plat-omap/include/plat/iommu.h | 10 +++-
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c |3 +--
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 3e47786..cd77abb 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -19,6 +19,7 @@
#include linux/stringify.h
#include plat/iommu.h
+#include plat/omap-pm.h
/*
* omap2 architecture specific register bit definitions
@@ -55,20 +56,26 @@
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
- u32 l = iommu_read_reg(obj, MMU_CNTL);
+ u32 l;
if (on)
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TWL_MASK;
else
- iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TLB_MISS_MASK;
+
+ iommu_write_reg(obj, l, MMU_IRQENABLE);
+ obj-context.irqen = l;
+ l = iommu_read_reg(obj, MMU_CNTL);
l = ~MMU_CNTL_MASK;
+
if (on)
l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
else
l |= (MMU_CNTL_MMU_EN);
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
}
@@ -88,6 +95,7 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
(l 4) 0xf, l 0xf);
iommu_write_reg(obj, pa, MMU_TTB);
+ obj-context.ttb = pa;
__iommu_set_twl(obj, true);
@@ -100,6 +108,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -249,28 +258,17 @@ out:
static void omap2_iommu_save_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- p[i] = iommu_read_reg(obj, i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
-
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ obj-ctx_loss_cnt = omap_pm_get_dev_context_loss_count(obj-dev);
}
static void omap2_iommu_restore_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- iommu_write_reg(obj, p[i], i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
+ if (omap_pm_get_dev_context_loss_count(obj-dev) == obj-ctx_loss_cnt)
+ return;
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ iommu_write_reg(obj, obj-context.ttb, MMU_TTB);
+ iommu_write_reg(obj, obj-context.irqen, MMU_IRQENABLE);
+ iommu_write_reg(obj, obj-context.cntl, MMU_CNTL);
}
static void omap2_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 902d193..af14486 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -27,6 +27,13 @@ struct iotlb_entry {
};
};
+/* context registers */
+struct iommu_regs {
+ u32 irqen;
+ u32 cntl;
+ u32 ttb;
+};
+
struct omap_iommu {
const char *name;
struct module *owner;
@@ -50,7 +57,8 @@ struct omap_iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- void *ctx; /* iommu context: registres saved area */
+ struct iommu_regs context;
+ int ctx_loss_cnt;
u32 da_start;
u32 da_end;
};
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index 1579694..bc43d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -35,8 +35,6 @@
#define MMU_READ_RAM 0x6c
#define MMU_EMU_FAULT_AD 0x70
-#define MMU_REG_SIZE 256
-
/*
* MMU Register bit definitions
*/
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 875e894..e266ad7 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -924,14 +924,13 @@ static int __devinit
[PATCH v3 5/6] ARM: OMAP: iommu: add device tree support
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
.../devicetree/bindings/arm/omap/iommu.txt | 10 +++
arch/arm/mach-omap2/omap-iommu.c |4 ++
drivers/iommu/omap-iommu.c | 65 +++-
3 files changed, 78 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/iommu.txt
b/Documentation/devicetree/bindings/arm/omap/iommu.txt
new file mode 100644
index 000..2bb780f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/iommu.txt
@@ -0,0 +1,10 @@
+* MMU (Memory Management Unit)
+
+MMU present in OMAP subsystems.
+
+Required properties:
+ compatible : should be ti,omap3-iommu for OMAP3 MMUs
+ compatible : should be ti,omap4-iommu for OMAP4 MMUs
+
+Optional properties:
+ None
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 82a422a..4d6145d 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -11,6 +11,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/err.h
#include linux/slab.h
@@ -29,6 +30,9 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
static int i;
+ if (of_have_populated_dt())
+ return 0;
+
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index e266ad7..946366f 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -21,12 +21,15 @@
#include linux/mutex.h
#include linux/spinlock.h
#include linux/pm_runtime.h
+#include linux/of.h
#include asm/cacheflush.h
#include plat/iommu.h
#include plat/iopgtable.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0; \
@@ -916,13 +919,63 @@ static void omap_iommu_detach(struct omap_iommu *obj)
/*
* OMAP Device MMU(IOMMU) detection
*/
+static int __devinit
+iommu_add_platform_data_from_dt(struct platform_device *pdev)
+{
+ struct iommu_platform_data *pdata;
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_hwmod *oh;
+ struct omap_mmu_dev_attr *a;
+ int ret = 0;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ of_property_read_string(node, ti,hwmods, pdata-name);
+ oh = omap_hwmod_lookup(pdata-name);
+ if (!oh) {
+ dev_err(pdev-dev, Cannot lookup hwmod '%s'\n, pdata-name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+ pdata-nr_tlb_entries = a-nr_tlb_entries;
+ pdata-da_start = a-da_start;
+ pdata-da_end = a-da_end;
+
+ if (oh-rst_lines_cnt == 1) {
+ pdata-reset_name = oh-rst_lines-name;
+ pdata-assert_reset = omap_device_assert_hardreset;
+ pdata-deassert_reset = omap_device_deassert_hardreset;
+ }
+
+ ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
+ if (ret)
+ dev_err(pdev-dev, Cannot add pdata for %s\n, pdata-name);
+
+out:
+ kfree(pdata);
+
+ return ret;
+}
+
static int __devinit omap_iommu_probe(struct platform_device *pdev)
{
int err = -ENODEV;
int irq;
struct omap_iommu *obj;
struct resource *res;
- struct iommu_platform_data *pdata = pdev-dev.platform_data;
+ struct iommu_platform_data *pdata;
+
+ if (of_have_populated_dt()) {
+ err = iommu_add_platform_data_from_dt(pdev);
+ if (err)
+ return err;
+ }
+
+ pdata = pdev-dev.platform_data;
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
if (!obj)
@@ -1031,12 +1084,22 @@ static const struct dev_pm_ops iommu_pm_ops = {
NULL)
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_iommu_of_match[] = {
+ { .compatible = ti,omap3-iommu },
+ { .compatible = ti,omap4-iommu },
+ { },
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+#endif
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
.pm = iommu_pm_ops,
+ .of_match_table = of_match_ptr(omap_iommu_of_match),
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[PATCH 4/6] ARM: OMAP: iommu: optimize save and restore routines
These functions save and restore registers irrespectively of their
read or write permissions, this ends up in registers being saved
that can't be restored because of read only attributes. OTOH, so
far only 3 of them need to be saved.
In future GP_REG (which is present only on OMAP4 ipu) needs to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 38 ++
arch/arm/plat-omap/include/plat/iommu.h | 10 +++-
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c |3 +--
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 3e47786..cd77abb 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -19,6 +19,7 @@
#include linux/stringify.h
#include plat/iommu.h
+#include plat/omap-pm.h
/*
* omap2 architecture specific register bit definitions
@@ -55,20 +56,26 @@
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
- u32 l = iommu_read_reg(obj, MMU_CNTL);
+ u32 l;
if (on)
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TWL_MASK;
else
- iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TLB_MISS_MASK;
+
+ iommu_write_reg(obj, l, MMU_IRQENABLE);
+ obj-context.irqen = l;
+ l = iommu_read_reg(obj, MMU_CNTL);
l = ~MMU_CNTL_MASK;
+
if (on)
l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
else
l |= (MMU_CNTL_MMU_EN);
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
}
@@ -88,6 +95,7 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
(l 4) 0xf, l 0xf);
iommu_write_reg(obj, pa, MMU_TTB);
+ obj-context.ttb = pa;
__iommu_set_twl(obj, true);
@@ -100,6 +108,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -249,28 +258,17 @@ out:
static void omap2_iommu_save_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- p[i] = iommu_read_reg(obj, i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
-
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ obj-ctx_loss_cnt = omap_pm_get_dev_context_loss_count(obj-dev);
}
static void omap2_iommu_restore_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- iommu_write_reg(obj, p[i], i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
+ if (omap_pm_get_dev_context_loss_count(obj-dev) == obj-ctx_loss_cnt)
+ return;
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ iommu_write_reg(obj, obj-context.ttb, MMU_TTB);
+ iommu_write_reg(obj, obj-context.irqen, MMU_IRQENABLE);
+ iommu_write_reg(obj, obj-context.cntl, MMU_CNTL);
}
static void omap2_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 902d193..af14486 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -27,6 +27,13 @@ struct iotlb_entry {
};
};
+/* context registers */
+struct iommu_regs {
+ u32 irqen;
+ u32 cntl;
+ u32 ttb;
+};
+
struct omap_iommu {
const char *name;
struct module *owner;
@@ -50,7 +57,8 @@ struct omap_iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- void *ctx; /* iommu context: registres saved area */
+ struct iommu_regs context;
+ int ctx_loss_cnt;
u32 da_start;
u32 da_end;
};
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index 1579694..bc43d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -35,8 +35,6 @@
#define MMU_READ_RAM 0x6c
#define MMU_EMU_FAULT_AD 0x70
-#define MMU_REG_SIZE 256
-
/*
* MMU Register bit definitions
*/
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 875e894..e266ad7 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -924,14 +924,13 @@ static int __devinit
[PATCH v3 6/6] arm/dts: OMAP3/4: Add iommu nodes
Add nodes for iommu DT, to interface with hwmods.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 12 +++-
arch/arm/boot/dts/omap4.dtsi | 17 -
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f38ea87..c76872e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -37,12 +37,17 @@
};
iva {
- compatible = ti,iva2.2;
+ compatible = ti,iva2.2, simple-bus;
ti,hwmods = iva;
dsp {
compatible = ti,omap3-c64;
};
+
+ mmu_iva: mmu_iva@5d00 {
+ compatible = ti,omap3-iommu;
+ ti,hwmods = mmu_iva;
+ };
};
};
@@ -227,6 +232,11 @@
ti,hwmods = mmc3;
};
+ mmu_isp: mmu_isp@480bd400 {
+ compatible = ti,omap3-iommu;
+ ti,hwmods = mmu_isp;
+ };
+
wdt2: wdt@48314000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3883f94..f084418 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -71,8 +71,23 @@
};
dsp {
- compatible = ti,omap3-c64;
+ compatible = ti,omap3-c64, simple-bus;
ti,hwmods = dsp;
+
+ mmu_dsp: mmu_dsp@4a066000 {
+ compatible = ti,omap4-iommu;
+ ti,hwmods = mmu_dsp;
+ };
+ };
+
+ ipu {
+ compatible = ti,omap4-ipu, simple-bus;
+ ti,hwmods = ipu;
+
+ mmu_ipu: mmu_ipu@55082000 {
+ compatible = ti,omap4-iommu;
+ ti,hwmods = mmu_ipu;
+ };
};
iva {
--
1.7.9.5
--
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: Issue with _are_all_hardreset_lines_asserted()
Hi,
On 9 October 2012 00:38, Paul Walmsley p...@pwsan.com wrote:
cc Vaibhav due to the AM33xx change
Hi
On Thu, 4 Oct 2012, Archit Taneja wrote:
I was trying out the linux-next kernel, and I noticed that DSS MODULEMODE
bits
are never cleared.
In _omap4_disable_module(), there is a check:
...
if (!_are_all_hardreset_lines_asserted(oh))
return 0;
/* MODULEMODE bits cleared here */
...
...
...
The function _are_all_hardreset_lines_asserted() returns false if
'oh-rst_lines_cnt == 0', so we bail out from _omap4_disable_module() before
clearing the MODULEMODE bits.
Is this correct behavior? This would prevent all hwmods who have
rst_lines_cnt
as 0 to not get their MODULEMODE bits cleared.
You're right, that looks bogus. What do you think about the following
patch?
I was a little busy creating the patch but seems like Paul beat me to
it, yes it was a wrong case on disable_module.
From: Paul Walmsley p...@pwsan.com
Date: Mon, 8 Oct 2012 23:08:15 -0600
Subject: [PATCH] ARM: OMAP4/AM335x: hwmod: fix disable_module regression in
hardreset handling
Commit eb05f691290e99ee0bd1672317d6add789523c1e (ARM: OMAP: hwmod:
partially un-reset hwmods might not be properly enabled) added code
to skip the IP block disable sequence if any hardreset lines were left
unasserted. But this did not handle the case when no hardreset lines
were associated with a module, which is the general case. In that
situation, the IP block would be skipped, which is likely to cause PM
regressions.
So, modify _omap4_disable_module() and _am33xx_disable_module() to
only bail out early if there are any hardreset lines asserted. And
move the AM33xx test above the actual module disable code to ensure
that the behavior is consistent.
I think that on _omap4_disable_module() we want to check if the module
is deasserted rather than if it is asserted.
E.g.: If you have 2 hwmods for the same module (ipu with reset cpu0
and mmu_ipu with reset mmu) controlled by different drivers,
depending on which one is idled first, the other one will cause L3
aborts given that the module is already disabled. So, if ipu is idled
and disabled first, then all tear down operations on iommu will cause
L3 aborts.
I created the following:
From: Omar Ramirez Luna omar.l...@linaro.org
Subject: [PATCH] ARM: OMAP: hwmod: allow hwmods without reset lines to be
disabled
_are_all_hardreset_lines_asserted treats hwmods without reset lines
as always deasserted, this is correct for: _enable, _idle and
_shutdown paths, however for _omap4_disable_module it might not
result in the correct behavior, given that:
- hwmod without reset line can be safely disabled.
- hwmod with 1 or more reset lines, must be completely asserted
before disabled or be left to integration code to handle it.
Create a function to check for any hwmod to be partially out of
hardreset and bail of _omap4_disable_module if this is the case.
Hwmods without reset lines can skip these check and continue.
Reported-by: Archit Taneja a0393...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 299ca28..f9d9bfb 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1698,6 +1698,29 @@ static bool
_are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
}
/**
+ * _are_any_hardreset_lines_deasserted - true if part of @oh isn't hard-reset
+ * @oh: struct omap_hwmod *
+ *
+ * If any hardreset line associated with @oh is deasserted, then return true.
+ * Otherwise, if no hardreset lines associated with @oh are deasserted,
+ * then return false. This function is used to avoid SOC's disable_module to
+ * be called while the @oh is still deasserted.
+ *
+ * Check for oh-rst_lines_cnt is left to the caller, since a return value
+ * could mean that a hwmod with no reset lines is deasserted.
+ */
+static bool _are_any_hardreset_lines_deasserted(struct omap_hwmod *oh)
+{
+ int i;
+
+ for (i = 0; i oh-rst_lines_cnt; i++)
+ if (_read_hardreset(oh, oh-rst_lines[i].name) == 0)
+ return true;
+
+ return false;
+}
+
+/**
* _omap4_disable_module - enable CLKCTRL modulemode on OMAP4
* @oh: struct omap_hwmod *
*
@@ -1713,9 +1736,12 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
/*
* Since integration code might still be doing something, only
-* disable if all lines are under hardreset.
+* disable if all lines are under hardreset. Explicitly check for
+* reset lines before the call, otherwise the abscence of a reset
+* line is assumed as a deasserted hwmod and won't execute the
+* disable sequence
Re: [PATCH v2 8/9] ARM: OMAP: iommu: add device tree support
Hi Matt, On 2 October 2012 16:25, Matt Porter mpor...@ti.com wrote: ... I can see why you went this path with the iommu driver as it already had some integration code present here. I have some concerns going forward about how this should be long-term. Take any platform booting only with DT populated, we'd like to avoid having to use this approach where platform private APIs are called via pdata. In fact, it's going to makes thing ugly to carry any sort of pdata for a driver that's otherwise driven exclusively from DT. For AM335x, I can implement this approach, but it means adding some pruss specific integration code just to have it create the pdata for reset_name and assert/deassert. Yes I agree, it looks a bit ugly for devices that have more than one reset line name too, but right now there is no other way to keep the reset names and also provide flexibility to the driver to control them in a given order. From reading all the threads on hardresets and OMAP, it seems we may not be able to come up with a generic OMAP handler for these resets and that's really reflected in the fact that this API exists. So given that, it reasons that OMAP isn't the only one needing a reset API for drivers. I'm thinking that (as trivial as it may seem), this support may need to move to a reset subsystem such that drivers have a clean way to access reset resources in an SoC. Well, there was a point where the OMAP hwmod code contained the reset code and at least for me it was working fine, with iommu and ipu processor, just with a minor misleading warning print... however then this code got stripped out and since there appeared to be people needing to handle their reset lines in unknown ways it was advised that everybody should implement their own reset functions, but in my case I could reuse most of the disabled code at the expense of almost duplicating _enable (omap_hwmod) function while waiting all the reset line users started asking for changes. I'm curious if you or others have thought about where this needs to go next. I haven't planned for a reset subsystem or a more generic implementation, although I have been looking for a way to avoid using the pdata function pointers. When I first thought about a reset subsystem it seemed to trivial to bother with but looking at the reasoning behind the power_seq subsystem, it seems to have similar justification to get this machine specific logic out of the platform code and under standardized control of the driver. IMHO, the reset code even if made a subsystem or a library, would still need to interface with machine specific code and definitions (say omap_hwmod), so I don't see much difference in making the omap_device reset handlers as exported symbols for the time being, with acceptance of the owners of omap_device code. And then if power_seq makes it to mainline perhaps extending it to handle deassert, assert and softreset events, but then again this would have the same hooks to omap_hwmod which is the one with the prcm information. Regards, Omar -- 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 0/2] OMAP: mailbox initial device tree support
Hi Benoit, On 12 September 2012 19:08, Omar Ramirez Luna omar.l...@linaro.org wrote: To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit however it seems it wasn't picked up, so resend. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html Patch: OMAP: mailbox: add device tree support, there wasn't an opposition other than to cleanup the driver too, however I got quite some patches to send before continuing the cleanup. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html Omar Ramirez Luna (2): OMAP: mailbox: add device tree support arm/dts: OMAP2+: Add mailbox nodes .../devicetree/bindings/arm/omap/mailbox.txt |9 + arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |3 +++ arch/arm/mach-omap2/mailbox.c | 12 6 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt Ping. I'm in the understanding that these go through your tree, am I right? Regards, Omar -- 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: tidspbridge build fails
Hi, On Tue, Sep 25, 2012 at 12:39 PM, Selso LIBERADO s...@cioinfoindus.fr wrote: Hi ! Here what's happening when applying the patch : sli@SLI-V420:~/developpement/INTERNE/BEAGLEBOARD/logiciel/linux-omap$ git apply --check ../../archive/10-17-staging-tidspbridge-Prepare-for-irqs.h-removal.patch error: patch failed: drivers/staging/tidspbridge/core/wdt.c:25 error: drivers/staging/tidspbridge/core/wdt.c: patch does not apply Yes, got the same had to rework the patch to apply. If you have the time, you could try: git am --3way patch Then resolve the conflicts[1]. newbie question : Where is the staging-next rep ? http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=summary Regards, Omar --- [1] http://www.kernel.org/pub/software/scm/git/docs/v1.7.3/user-manual.html#resolving-a-merge -- 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: tidspbridge build fails
Hi, On Mon, Sep 24, 2012 at 11:37 AM, Selso LIBERADO s...@cioinfoindus.fr wrote: ... CC [M] drivers/staging/tidspbridge/core/tiomap3430.o drivers/staging/tidspbridge/core/tiomap3430.c: In function 'bridge_brd_start': drivers/staging/tidspbridge/core/tiomap3430.c:421:25: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) drivers/staging/tidspbridge/core/tiomap3430.c:421:25: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1 ... This definition has moved to : arch/arm/mach-omap2/omap34xx.h I don't know if we can include directly this file in tiomap3430.c (I'm newbie) However there is still the symbole OMAP34XX_WDT3_BASE in 'drivers/staging/tidspbridge/core/wdt.c' that is not resolved. This should be solved by Tony's patch: https://patchwork.kernel.org/patch/1435311/ Right now it is on staging-next. Regards, Omar -- 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 7/9] ARM: OMAP: iommu: optimize save and restore routines
Hi Tony,
On 18 September 2012 13:04, Tony Lindgren t...@atomide.com wrote:
* Omar Ramirez Luna omar.l...@linaro.org [120912 12:47]:
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -27,6 +27,13 @@ struct iotlb_entry {
};
};
+/* context registers */
+struct iommu_regs {
+ u32 irqen;
+ u32 cntl;
+ u32 ttb;
+};
+
struct omap_iommu {
const char *name;
struct module *owner;
@@ -50,7 +57,8 @@ struct omap_iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- void *ctx; /* iommu context: registres saved area */
+ struct iommu_regs context;
+ int ctx_loss_cnt;
u32 da_start;
u32 da_end;
};
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -35,8 +35,6 @@
#define MMU_READ_RAM 0x6c
#define MMU_EMU_FAULT_AD 0x70
-#define MMU_REG_SIZE 256
-
/*
* MMU Register bit definitions
*/
These headers should be moved to include/linux/platform_data/iommu-omap.h
or something like that. Care to take care of that too?
I guess there's no reason to have both iommu.h and iommuh2.h?
Agree, can this be made as part of a separate cleanup series? I was
hoping these could make it for 3.7 so we could have a usable rpmsg for
omap4.
Regards,
Omar
--
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 v2 0/9] OMAP: iommu: hwmod, reset handling and runtime PM
These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. Due to compatibility an ifdef needs to be propagated (previously on iommu resource info) to hwmod data in OMAP3, so users of iommu and tidspbridge can avoid issues of two modules managing mmu data/irqs/resets; this until tidspbridge can be safely migrated to iommu framework. Although IOMMU hwmod patches were already submitted in the past, this series adds few more changes, like: - New reset handling, based on a series that was accepted but *NOT YET* in mainline. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg73111.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg75105.html - Fix for compile break if IOMMU_API is not selected. - Save and restore context code rework. - Device tree bindings for OMAP3 and OMAP4. Previous work can be found at: [v1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70447.html [old iteration without reset, save/restore and device tree] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60133.html Omar Ramirez Luna (9): ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected ARM: OMAP3: hwmod data: add mmu data for iva and isp ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP3/4: iommu: adapt to runtime pm ARM: OMAP: iommu: pm runtime save and restore context ARM: OMAP: iommu: optimize save and restore routines ARM: OMAP: iommu: add device tree support arm/dts: OMAP3/4: Add iommu nodes .../devicetree/bindings/arm/omap/iommu.txt | 10 ++ arch/arm/boot/dts/omap3.dtsi | 12 +- arch/arm/boot/dts/omap4.dtsi | 17 +- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/iommu2.c | 74 +++-- arch/arm/mach-omap2/omap-iommu.c | 168 +--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 121 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++- arch/arm/plat-omap/include/plat/iommu.h| 35 +++- arch/arm/plat-omap/include/plat/iommu2.h |4 - drivers/iommu/omap-iommu.c | 163 +++ 11 files changed, 511 insertions(+), 231 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt -- 1.7.9.5 -- 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 v2 8/9] ARM: OMAP: iommu: add device tree support
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
.../devicetree/bindings/arm/omap/iommu.txt | 10 +++
arch/arm/mach-omap2/omap-iommu.c |4 ++
drivers/iommu/omap-iommu.c | 65 +++-
3 files changed, 78 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/iommu.txt
b/Documentation/devicetree/bindings/arm/omap/iommu.txt
new file mode 100644
index 000..2bb780f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/iommu.txt
@@ -0,0 +1,10 @@
+* MMU (Memory Management Unit)
+
+MMU present in OMAP subsystems.
+
+Required properties:
+ compatible : should be ti,omap3-iommu for OMAP3 MMUs
+ compatible : should be ti,omap4-iommu for OMAP4 MMUs
+
+Optional properties:
+ None
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index e8f88dc..4b7912b 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -11,6 +11,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/err.h
#include linux/slab.h
@@ -27,6 +28,9 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
static int i;
+ if (of_have_populated_dt())
+ return 0;
+
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 3f8eb04..fbfec44 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -21,12 +21,15 @@
#include linux/mutex.h
#include linux/spinlock.h
#include linux/pm_runtime.h
+#include linux/of.h
#include asm/cacheflush.h
#include plat/iommu.h
#include plat/iopgtable.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0; \
@@ -909,13 +912,63 @@ static void omap_iommu_detach(struct omap_iommu *obj)
/*
* OMAP Device MMU(IOMMU) detection
*/
+static int __devinit
+iommu_add_platform_data_from_dt(struct platform_device *pdev)
+{
+ struct iommu_platform_data *pdata;
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_hwmod *oh;
+ struct omap_mmu_dev_attr *a;
+ int ret = 0;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ of_property_read_string(node, ti,hwmods, pdata-name);
+ oh = omap_hwmod_lookup(pdata-name);
+ if (!oh) {
+ dev_err(pdev-dev, Cannot lookup hwmod '%s'\n, pdata-name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+ pdata-nr_tlb_entries = a-nr_tlb_entries;
+ pdata-da_start = a-da_start;
+ pdata-da_end = a-da_end;
+
+ if (oh-rst_lines_cnt == 1) {
+ pdata-reset_name = oh-rst_lines-name;
+ pdata-assert_reset = omap_device_assert_hardreset;
+ pdata-deassert_reset = omap_device_deassert_hardreset;
+ }
+
+ ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
+ if (ret)
+ dev_err(pdev-dev, Cannot add pdata for %s\n, pdata-name);
+
+out:
+ kfree(pdata);
+
+ return ret;
+}
+
static int __devinit omap_iommu_probe(struct platform_device *pdev)
{
int err = -ENODEV;
int irq;
struct omap_iommu *obj;
struct resource *res;
- struct iommu_platform_data *pdata = pdev-dev.platform_data;
+ struct iommu_platform_data *pdata;
+
+ if (of_have_populated_dt()) {
+ err = iommu_add_platform_data_from_dt(pdev);
+ if (err)
+ return err;
+ }
+
+ pdata = pdev-dev.platform_data;
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
if (!obj)
@@ -1024,12 +1077,22 @@ static const struct dev_pm_ops iommu_pm_ops = {
NULL)
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_iommu_of_match[] = {
+ { .compatible = ti,omap3-iommu },
+ { .compatible = ti,omap4-iommu },
+ { },
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+#endif
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
.pm = iommu_pm_ops,
+ .of_match_table = of_match_ptr(omap_iommu_of_match),
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[PATCH v2 9/9] arm/dts: OMAP3/4: Add iommu nodes
Add nodes for iommu DT, to interface with hwmods.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 12 +++-
arch/arm/boot/dts/omap4.dtsi | 17 -
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..7500136 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -38,12 +38,17 @@
};
iva {
- compatible = ti,iva2.2;
+ compatible = ti,iva2.2, simple-bus;
ti,hwmods = iva;
dsp {
compatible = ti,omap3-c64;
};
+
+ mmu_iva: mmu_iva@5d00 {
+ compatible = ti,omap3-iommu;
+ ti,hwmods = mmu_iva;
+ };
};
};
@@ -216,6 +221,11 @@
ti,hwmods = mmc3;
};
+ mmu_isp: mmu_isp@480bd400 {
+ compatible = ti,omap3-iommu;
+ ti,hwmods = mmu_isp;
+ };
+
wdt2: wdt@48314000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..07f3587 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -48,8 +48,23 @@
};
dsp {
- compatible = ti,omap3-c64;
+ compatible = ti,omap3-c64, simple-bus;
ti,hwmods = dsp;
+
+ mmu_dsp: mmu_dsp@4a066000 {
+ compatible = ti,omap4-iommu;
+ ti,hwmods = mmu_dsp;
+ };
+ };
+
+ ipu {
+ compatible = ti,omap4-ipu, simple-bus;
+ ti,hwmods = ipu;
+
+ mmu_ipu: mmu_ipu@55082000 {
+ compatible = ti,omap4-iommu;
+ ti,hwmods = mmu_ipu;
+ };
};
iva {
--
1.7.9.5
--
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 v2 7/9] ARM: OMAP: iommu: optimize save and restore routines
These functions save and restore registers irrespectively of their
read or write permissions, this ends up in registers being saved
that can't be restored because of read only attributes. OTOH, so
far only 3 of them need to be saved.
In future GP_REG (which is present only on OMAP4 ipu) needs to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 38 ++
arch/arm/plat-omap/include/plat/iommu.h | 10 +++-
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c |3 +--
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 3e47786..cd77abb 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -19,6 +19,7 @@
#include linux/stringify.h
#include plat/iommu.h
+#include plat/omap-pm.h
/*
* omap2 architecture specific register bit definitions
@@ -55,20 +56,26 @@
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
- u32 l = iommu_read_reg(obj, MMU_CNTL);
+ u32 l;
if (on)
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TWL_MASK;
else
- iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TLB_MISS_MASK;
+
+ iommu_write_reg(obj, l, MMU_IRQENABLE);
+ obj-context.irqen = l;
+ l = iommu_read_reg(obj, MMU_CNTL);
l = ~MMU_CNTL_MASK;
+
if (on)
l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
else
l |= (MMU_CNTL_MMU_EN);
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
}
@@ -88,6 +95,7 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
(l 4) 0xf, l 0xf);
iommu_write_reg(obj, pa, MMU_TTB);
+ obj-context.ttb = pa;
__iommu_set_twl(obj, true);
@@ -100,6 +108,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -249,28 +258,17 @@ out:
static void omap2_iommu_save_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- p[i] = iommu_read_reg(obj, i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
-
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ obj-ctx_loss_cnt = omap_pm_get_dev_context_loss_count(obj-dev);
}
static void omap2_iommu_restore_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- iommu_write_reg(obj, p[i], i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
+ if (omap_pm_get_dev_context_loss_count(obj-dev) == obj-ctx_loss_cnt)
+ return;
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ iommu_write_reg(obj, obj-context.ttb, MMU_TTB);
+ iommu_write_reg(obj, obj-context.irqen, MMU_IRQENABLE);
+ iommu_write_reg(obj, obj-context.cntl, MMU_CNTL);
}
static void omap2_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 004cb9e..a13db90 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -27,6 +27,13 @@ struct iotlb_entry {
};
};
+/* context registers */
+struct iommu_regs {
+ u32 irqen;
+ u32 cntl;
+ u32 ttb;
+};
+
struct omap_iommu {
const char *name;
struct module *owner;
@@ -50,7 +57,8 @@ struct omap_iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- void *ctx; /* iommu context: registres saved area */
+ struct iommu_regs context;
+ int ctx_loss_cnt;
u32 da_start;
u32 da_end;
};
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index 1579694..bc43d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -35,8 +35,6 @@
#define MMU_READ_RAM 0x6c
#define MMU_EMU_FAULT_AD 0x70
-#define MMU_REG_SIZE 256
-
/*
* MMU Register bit definitions
*/
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c4de9a9..3f8eb04 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -917,14 +917,13 @@ static int __devinit
[PATCH v2 5/9] ARM: OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 17 ---
arch/arm/mach-omap2/omap-iommu.c |1 -
arch/arm/plat-omap/include/plat/iommu.h |2 --
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c | 45 +-
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 35cab47..3e47786 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
*/
#define IOMMU_ARCH_VERSION 0x0011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l = ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -243,8 +228,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 96eecd8..e8f88dc 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -32,7 +32,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index bb15b85..004cb9e 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -30,7 +30,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
@@ -120,7 +119,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
const char *reset_name;
int nr_tlb_entries;
u32 da_start;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index d4116b5..1579694 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index af8fe53..20ae946 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/mutex.h
#include linux/spinlock.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
return err;
}
@@ -158,11 +157,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj-clk);
-
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (pdata-assert_reset
[PATCH v2 4/9] ARM: OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 165 +++
arch/arm/plat-omap/include/plat/iommu.h |8 +-
drivers/iommu/omap-iommu.c | 23 -
5 files changed, 64 insertions(+), 153 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..b3ff703 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -214,7 +214,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l MMU_SYS_RESETDONE)) {
- dev_err(obj-dev, can't take mmu out of reset\n);
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 1be8bcb..96eecd8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,151 +12,62 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include plat/iommu.h
#include plat/irqs.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = OMAP44XX_IRQ_DUCATI_MMU,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0,
- .da_end = 0xF000
[PATCH v2 1/9] ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
If included without IOMMU_API being selected it will break
compilation:
arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'
This will be seen when hwmod includes iommu.h to get the
structure for attributes. Also needed for tidspbridge
incremental migration to use iommu code.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/include/plat/iommu.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 88be3e6..e58d571 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -126,6 +126,7 @@ struct omap_iommu_arch_data {
struct omap_iommu *iommu_dev;
};
+#ifdef CONFIG_IOMMU_API
/**
* dev_to_omap_iommu() - retrieves an omap iommu object from a user device
* @dev: iommu client device
@@ -136,6 +137,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
return arch_data-iommu_dev;
}
+#endif
/* IOMMU errors */
#define OMAP_IOMMU_ERR_TLB_MISS(1 0)
--
1.7.9.5
--
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 v2 6/9] ARM: OMAP: iommu: pm runtime save and restore context
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 20ae946..c4de9a9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -97,7 +97,7 @@ void omap_iommu_save_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-save_ctx(obj);
+ pm_runtime_put_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
@@ -109,7 +109,7 @@ void omap_iommu_restore_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-restore_ctx(obj);
+ pm_runtime_get_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
@@ -1001,11 +1001,36 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_iommu_runtime_suspend(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-save_ctx(obj);
+
+ return 0;
+}
+
+static int omap_iommu_runtime_resume(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-restore_ctx(obj);
+
+ return 0;
+}
+
+static const struct dev_pm_ops iommu_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap_iommu_runtime_suspend,
+ omap_iommu_runtime_resume,
+ NULL)
+};
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
+ .pm = iommu_pm_ops,
},
};
--
1.7.9.5
--
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 v2 3/9] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Add mmu hwmod data for ipu and dsp.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++-
1 file changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..c2cf25a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -31,6 +31,7 @@
#include plat/mmc.h
#include plat/dmtimer.h
#include plat/common.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
#include cm1_44xx.h
@@ -612,7 +613,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
{ .name = dsp, .rst_shift = 0 },
- { .name = mmu_cache, .rst_shift = 1 },
};
static struct omap_hwmod omap44xx_dsp_hwmod = {
@@ -1632,7 +1632,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
{ .name = cpu0, .rst_shift = 0 },
{ .name = cpu1, .rst_shift = 1 },
- { .name = mmu_cache, .rst_shift = 2 },
};
static struct omap_hwmod omap44xx_ipu_hwmod = {
@@ -2439,6 +2438,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* mmu ipu */
+
+static struct omap_mmu_dev_attr mmu_ipu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_mmu_ipu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mmu_ipu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_mmu_ipu_resets[] = {
+ { .name = mmu_cache, .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mmu_ipu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main_2 - mmu_ipu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__mmu_ipu = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_mmu_ipu_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_mmu_ipu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
+ .name = mmu_ipu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_mmu_ipu_irqs,
+ .rst_lines = omap44xx_mmu_ipu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_mmu_ipu_resets),
+ .main_clk = ducati_clk_mux_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = mmu_ipu_dev_attr,
+};
+
+/* mmu dsp */
+
+static struct omap_mmu_dev_attr mmu_dsp_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_mmu_dsp_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mmu_dsp_irqs[] = {
+ { .irq = 28 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_mmu_dsp_resets[] = {
+ { .name = mmu_cache, .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mmu_dsp_addrs[] = {
+ {
+ .pa_start = 0x4a066000,
+ .pa_end = 0x4a0660ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_cfg - dsp */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mmu_dsp = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_mmu_dsp_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_mmu_dsp_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_mmu_dsp_hwmod = {
+ .name
[PATCH v2 2/9] ARM: OMAP3: hwmod data: add mmu data for iva and isp
Add mmu hwmod data for iva and isp.
Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be migrated
to iommu framework.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 121
arch/arm/plat-omap/include/plat/iommu.h| 13 +++
2 files changed, 134 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c9e3820..70f14f9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include plat/mcbsp.h
#include plat/mcspi.h
#include plat/dmtimer.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
#include prm-regbits-34xx.h
@@ -2814,6 +2815,122 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* mmu isp */
+
+static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 8,
+};
+
+static struct omap_hwmod omap3xxx_mmu_isp_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_mmu_isp_irqs[] = {
+ { .irq = 24 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mmu_isp_addrs[] = {
+ {
+ .pa_start = 0x480bd400,
+ .pa_end = 0x480bd47f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_core - mmu isp */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_mmu_isp_hwmod,
+ .addr = omap3xxx_mmu_isp_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
+ .name = mmu_isp,
+ .class = omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_mmu_isp_irqs,
+ .main_clk = cam_ick,
+ .dev_attr = mmu_isp_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
+#ifdef CONFIG_OMAP_IOMMU_IVA2
+
+/* mmu iva */
+
+static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
+ .da_start = 0x1100,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap3xxx_mmu_iva_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_mmu_iva_irqs[] = {
+ { .irq = 28 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap3xxx_mmu_iva_resets[] = {
+ { .name = mmu, .rst_shift = 1, .st_shift = 9 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mmu_iva_addrs[] = {
+ {
+ .pa_start = 0x5d00,
+ .pa_end = 0x5d7f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main - iva mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__mmu_iva = {
+ .master = omap3xxx_l3_main_hwmod,
+ .slave = omap3xxx_mmu_iva_hwmod,
+ .addr = omap3xxx_mmu_iva_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
+ .name = mmu_iva,
+ .class = omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_mmu_iva_irqs,
+ .rst_lines = omap3xxx_mmu_iva_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
+ .main_clk = iva2_ck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430_IVA2_MOD,
+ },
+ },
+ .dev_attr = mmu_iva_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
+#endif
+
/* l4_per - gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3312,6 +3429,10 @@ static struct omap_hwmod_ocp_if
*omap3xxx_hwmod_ocp_ifs[] __initdata = {
omap34xx_l4_core__mcspi2,
omap34xx_l4_core__mcspi3,
omap34xx_l4_core__mcspi4,
+ omap3xxx_l4_core__mmu_isp,
+#ifdef CONFIG_OMAP_IOMMU_IVA2
[PATCH v2 0/2] OMAP: mailbox initial device tree support
To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit however it seems it wasn't picked up, so resend. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html Patch: OMAP: mailbox: add device tree support, there wasn't an opposition other than to cleanup the driver too, however I got quite some patches to send before continuing the cleanup. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html Omar Ramirez Luna (2): OMAP: mailbox: add device tree support arm/dts: OMAP2+: Add mailbox nodes .../devicetree/bindings/arm/omap/mailbox.txt |9 + arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |3 +++ arch/arm/mach-omap2/mailbox.c | 12 6 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt -- 1.7.9.5 -- 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 v2 0/2] OMAP: mailbox initial device tree support
To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit however it seems it wasn't picked up, so resend. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html Patch: OMAP: mailbox: add device tree support, there wasn't an opposition other than to cleanup the driver too, however I got quite some patches to send before continuing the cleanup. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html Omar Ramirez Luna (2): OMAP: mailbox: add device tree support arm/dts: OMAP2+: Add mailbox nodes .../devicetree/bindings/arm/omap/mailbox.txt |9 + arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |3 +++ arch/arm/mach-omap2/mailbox.c | 12 6 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt -- 1.7.9.5 -- 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 v2 2/2] arm/dts: OMAP2+: Add mailbox nodes
Add nodes for mailbox DT, to interface with hwmods.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
3 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 581cb08..372d55a 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -48,6 +48,11 @@
reg = 0x480FE000 0x1000;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ ti,hwmods = mailbox;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..ce68604 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -168,6 +168,11 @@
ti,hwmods = i2c3;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap3-mailbox;
+ ti,hwmods = mailbox;
+ };
+
mcspi1: spi@48098000 {
compatible = ti,omap2-mcspi;
#address-cells = 1;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..6677d80 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -210,6 +210,11 @@
ti,hwmods = i2c4;
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ ti,hwmods = mailbox;
+ };
+
mcspi1: spi@48098000 {
compatible = ti,omap4-mcspi;
#address-cells = 1;
--
1.7.9.5
--
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 v2 1/2] OMAP: mailbox: add device tree support
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
.../devicetree/bindings/arm/omap/mailbox.txt |9 +
arch/arm/mach-omap2/devices.c |3 +++
arch/arm/mach-omap2/mailbox.c | 12
3 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/mailbox.txt
b/Documentation/devicetree/bindings/arm/omap/mailbox.txt
new file mode 100644
index 000..c57c0d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/mailbox.txt
@@ -0,0 +1,9 @@
+OMAP Mailbox module
+
+Required properties:
+ compatible : should be ti,omap2-mailbox for OMAP2 mailbox
+ compatible : should be ti,omap3-mailbox for OMAP3 mailbox
+ compatible : should be ti,omap4-mailbox for OMAP4 mailbox
+
+Optional properties:
+ None
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..19093fb 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -279,6 +279,9 @@ static inline void __init omap_init_mbox(void)
struct omap_hwmod *oh;
struct platform_device *pdev;
+ if (of_have_populated_dt())
+ return;
+
oh = omap_hwmod_lookup(mailbox);
if (!oh) {
pr_err(%s: unable to find hwmod\n, __func__);
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 6875be8..80beadf 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/clk.h
#include linux/err.h
+#include linux/of_device.h
#include linux/platform_device.h
#include linux/io.h
#include linux/pm_runtime.h
@@ -400,11 +401,22 @@ static int __devexit omap2_mbox_remove(struct
platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_mailbox_of_match[] = {
+ { .compatible = ti,omap2-mailbox },
+ { .compatible = ti,omap3-mailbox },
+ { .compatible = ti,omap4-mailbox },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+#endif
+
static struct platform_driver omap2_mbox_driver = {
.probe = omap2_mbox_probe,
.remove = __devexit_p(omap2_mbox_remove),
.driver = {
.name = omap-mailbox,
+ .of_match_table = of_match_ptr(omap_mailbox_of_match),
},
};
--
1.7.9.5
--
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 2/2] ARM: OMAP: hwmod: revise deassert sequence
Hi Benoit, On 6 September 2012 10:12, Benoit Cousson b-cous...@ti.com wrote: The sequence is good, I'm just a little bit concern about the duplication of code compared to _enable sequence. That being said, this is the consequence of removing the hardreset sequence outside of the main _enable/_shutdown sequence. So I'm not sure I have any better way of doing that :-( Indeed, it should be exactly the same as putting back the reset sequence into _enable/_shutdown, so with these patches I was expecting we could gather the hard reset users and see if they needed anything else beyond these functions, if not, perhaps just put back the reset code into _enable/_shutdown paths. Thanks, Omar -- 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] OMAP: hwmod: fix hardreset handling
On 22 August 2012 00:42, Omar Ramirez Luna omar.l...@linaro.org wrote: From: Omar Ramirez Luna omar.rami...@ti.com The patch to expose hwmod assert/deassert functions through omap_device has been accepted and queued for 3.7[1], however these two patches are needed to make the API functional. Hence a revised version is being sent according to previous comments: - ARM: OMAP: hwmod: revise deassert sequence Now it uses enable|disable_module to handle the configuration of the modulemode inside CLKCTRL. As part of the cleanup of leaf clocks, the one associated with ipu_mmu will be removed along with the iommu hwmod migration[2]. - ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled More infomation added in the patch description[3]. [1] http://patchwork.kernel.org/patch/1266731/ [2] http://patchwork.kernel.org/patch/1201791/ [3] http://patchwork.kernel.org/patch/1201801/ Omar Ramirez Luna (2): ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled ARM: OMAP: hwmod: revise deassert sequence arch/arm/mach-omap2/omap_hwmod.c | 74 ++ 1 file changed, 59 insertions(+), 15 deletions(-) Ping. Regards, Omar -- 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] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
On 20 August 2012 09:49, Benoit Cousson b-cous...@ti.com wrote: On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote: Some IP blocks might not be using/controlling more than one reset line, this check loosens the restriction to fully use hwmod framework for those drivers. E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. - cpu1 might not be used and hence (with previous check) won't be fully enabled by hwmod code. You mean that you might have some case where you need to enable the mmu_cache and cpu0 and thus deassert only the mmu/cpu0 while keeping the cpu1 under reset? Looks like I didn't reply to this question. Yes, initially cpu1 might not be used and kept under reset. Or even the mmu can be taken out of reset and configured, and cpu0 after it, creating a small window where one is taken out and the other is under reset. So the any_hardreset is indeed not appropriate in that case. In fact, since the hardreset cannot be handled at all by the hwmod fmwk, I'm even wondering if we should take care of checking the state at all. But as Paul stated, if was done due to the lack of understanding about the diver usage, so maybe things will become clearer once we will have that code available. I still think it can, in fact all the code I'm using comes from the hwmod fmwk. _deassert_reset is almost the same as _enable, I left it this way to avoid reintroducing the issues that caused reset code to be stripped out from _enable path. Regards, Omar -- 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 0/2] OMAP: hwmod: fix hardreset handling
From: Omar Ramirez Luna omar.rami...@ti.com The patch to expose hwmod assert/deassert functions through omap_device has been accepted and queued for 3.7[1], however these two patches are needed to make the API functional. Hence a revised version is being sent according to previous comments: - ARM: OMAP: hwmod: revise deassert sequence Now it uses enable|disable_module to handle the configuration of the modulemode inside CLKCTRL. As part of the cleanup of leaf clocks, the one associated with ipu_mmu will be removed along with the iommu hwmod migration[2]. - ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled More infomation added in the patch description[3]. [1] http://patchwork.kernel.org/patch/1266731/ [2] http://patchwork.kernel.org/patch/1201791/ [3] http://patchwork.kernel.org/patch/1201801/ Omar Ramirez Luna (2): ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled ARM: OMAP: hwmod: revise deassert sequence arch/arm/mach-omap2/omap_hwmod.c | 74 ++ 1 file changed, 59 insertions(+), 15 deletions(-) -- 1.7.9.5 -- 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 2/2] ARM: OMAP: hwmod: revise deassert sequence
For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eaedc33..b65e021 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1509,6 +1509,7 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
{
struct omap_hwmod_rst_info ohri;
int ret = -EINVAL;
+ int hwsup = 0;
if (!oh)
return -EINVAL;
@@ -1520,10 +1521,46 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
+ if (oh-clkdm) {
+ /*
+* A clockdomain must be in SW_SUP otherwise reset
+* might not be completed. The clockdomain can be set
+* in HW_AUTO only when the module become ready.
+*/
+ hwsup = clkdm_in_hwsup(oh-clkdm);
+ ret = clkdm_hwmod_enable(oh-clkdm, oh);
+ if (ret) {
+ WARN(1, omap_hwmod: %s: could not enable clockdomain
%s: %d\n,
+oh-name, oh-clkdm-name, ret);
+ return ret;
+ }
+ }
+
+ _enable_clocks(oh);
+ if (soc_ops.enable_module)
+ soc_ops.enable_module(oh);
+
ret = soc_ops.deassert_hardreset(oh, ohri);
+
+ if (soc_ops.disable_module)
+ soc_ops.disable_module(oh);
+ _disable_clocks(oh);
+
if (ret == -EBUSY)
pr_warning(omap_hwmod: %s: failed to hardreset\n, oh-name);
+ if (!ret) {
+ /*
+* Set the clockdomain to HW_AUTO, assuming that the
+* previous state was HW_AUTO.
+*/
+ if (oh-clkdm hwsup)
+ clkdm_allow_idle(oh-clkdm);
+ } else {
+ if (oh-clkdm)
+ clkdm_hwmod_disable(oh-clkdm, oh);
+ }
+
return ret;
}
--
1.7.9.5
--
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/2] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.
E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- As of now cpu1 is not used and hence (with previous check) the
IP block isn't fully enabled by hwmod code.
- Usually ipu and dsp processors configure their mmu module first
and then enable the processors, this involves:
* Deasserting mmu reset line, and enabling the module.
* Deasserting cpu0 reset line, and enabling the processor.
The ones portrayed in this example are controlled through
rproc_fw_boot in drivers/remoteproc/remoteproc_core.c
While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.
This will allow the driver to:
a. Deassert the reset line.
b. Enable the hwmod through runtime PM default callbacks.
c. Do its usecase.
d. Disable hwmod through runtime PM.
e. Assert the reset line.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..eaedc33 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1558,25 +1558,28 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
}
/**
- * _are_any_hardreset_lines_asserted - return true if part of @oh is hard-reset
+ * _are_all_hardreset_lines_asserted - return true if the @oh is hard-reset
* @oh: struct omap_hwmod *
*
- * If any hardreset line associated with @oh is asserted, then return true.
- * Otherwise, if @oh has no hardreset lines associated with it, or if
- * no hardreset lines associated with @oh are asserted, then return false.
+ * If all hardreset lines associated with @oh are asserted, then return true.
+ * Otherwise, if part of @oh is out hardreset or if no hardreset lines
+ * associated with @oh are asserted, then return false.
* This function is used to avoid executing some parts of the IP block
- * enable/disable sequence if a hardreset line is set.
+ * enable/disable sequence if its hardreset line is set.
*/
-static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+static bool _are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
{
- int i;
+ int i, rst_cnt = 0;
if (oh-rst_lines_cnt == 0)
return false;
for (i = 0; i oh-rst_lines_cnt; i++)
if (_read_hardreset(oh, oh-rst_lines[i].name) 0)
- return true;
+ rst_cnt++;
+
+ if (oh-rst_lines_cnt == rst_cnt)
+ return true;
return false;
}
@@ -1595,6 +1598,13 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
return -EINVAL;
+ /*
+* Since integration code might still be doing something, only
+* disable if all lines are under hardreset.
+*/
+ if (!_are_all_hardreset_lines_asserted(oh))
+ return 0;
+
pr_debug(omap_hwmod: %s: %s\n, oh-name, __func__);
omap4_cminst_module_disable(oh-clkdm-prcm_partition,
@@ -1602,9 +1612,6 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
oh-clkdm-clkdm_offs,
oh-prcm.omap4.clkctrl_offs);
- if (_are_any_hardreset_lines_asserted(oh))
- return 0;
-
v = _omap4_wait_target_disable(oh);
if (v)
pr_warn(omap_hwmod: %s: _wait_target_disable failed\n,
@@ -1830,7 +1837,7 @@ static int _enable(struct omap_hwmod *oh)
}
/*
-* If an IP block contains HW reset lines and any of them are
+* If an IP block contains HW reset lines and all of them are
* asserted, we let integration code associated with that
* block handle the enable. We've received very little
* information on what those driver authors need, and until
@@ -1838,7 +1845,7 @@ static int _enable(struct omap_hwmod *oh)
* posted to the public lists, this is probably the best we
* can do.
*/
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
/* Mux pins for device runtime if populated */
@@ -1918,7 +1925,7 @@ static int _idle(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
if (oh-class-sysc)
@@ -2006,7 +2013,7 @@ static int _shutdown(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh
Re: [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
Hi Benoit, On 20 August 2012 09:49, Benoit Cousson b-cous...@ti.com wrote: On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote: Some IP blocks might not be using/controlling more than one reset line, this check loosens the restriction to fully use hwmod framework for those drivers. E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. - cpu1 might not be used and hence (with previous check) won't be fully enabled by hwmod code. You mean that you might have some case where you need to enable the mmu_cache and cpu0 and thus deassert only the mmu/cpu0 while keeping the cpu1 under reset? So the any_hardreset is indeed not appropriate in that case. In fact, since the hardreset cannot be handled at all by the hwmod fmwk, I'm even wondering if we should take care of checking the state at all. But as Paul stated, if was done due to the lack of understanding about the diver usage, so maybe things will become clearer once we will have that code available. So I guess that checking for all the lines for the hardreset state is anyway already a first step toward a good understanding of the reset need for the remote processors. The patch looks fine to me considering that we do not have a lot of information about the usage :-( Maybe you could add more information in the changelog to explain the way you are going to use the reset API. I'll add an updated description with more information. Thanks for the comments, Omar -- 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 2/3] ARM: OMAP: hwmod: revise deassert sequence
Hi Benoit, On 20 August 2012 05:21, Benoit Cousson b-cous...@ti.com wrote: Hi Omar, On 08/03/2012 05:52 PM, Omar Ramirez Luna wrote: On 3 August 2012 00:24, Vaibhav Hiremath hvaib...@ti.com wrote: On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote: So in _enable: _enable_clocks(oh); if (soc_ops.enable_module) soc_ops.enable_module(oh); The enable_module part seems redundant to me, since the module should be already enabled by the first call to _enable_clocks. Yes they do same thing, I believe the plan is to get rid of all clock leaf-nodes in the near future, and let hwmod handle module enable/disable part. If this is the case then an enable_module call is needed in my patch for when these changes are made. The original works fine but only because currently clock framework does what enable_module is doing. Yes, that's the case, but I plan to remove most of the leaf clocks ASAP, so we cannot rely on that. Please let me know if you want me to resend with this change. Yes, could you please repost with that change? Not a problem. It will be good as well that you remove the leaf clock and use the parent clock of current leaf as the main_clock. In that case it will ensure that this is the hwmod fmwk that does enable the modulemode and not the clock fmwk. Ok, let me try that. Thanks for the comments, Omar -- 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 2/3] ARM: OMAP: hwmod: revise deassert sequence
On 3 August 2012 00:24, Vaibhav Hiremath hvaib...@ti.com wrote: On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote: So in _enable: _enable_clocks(oh); if (soc_ops.enable_module) soc_ops.enable_module(oh); The enable_module part seems redundant to me, since the module should be already enabled by the first call to _enable_clocks. Yes they do same thing, I believe the plan is to get rid of all clock leaf-nodes in the near future, and let hwmod handle module enable/disable part. If this is the case then an enable_module call is needed in my patch for when these changes are made. The original works fine but only because currently clock framework does what enable_module is doing. Paul, Please let me know if you want me to resend with this change. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices
On 2 August 2012 02:43, Paul Walmsley p...@pwsan.com wrote: This APIs are meant to be an interface to hwmod assert/deassert function, omap devices can call them through their platform data to control their reset lines, they are expected to know the name of the reset line they are trying to control. Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org This one has been queued for 3.7 with a few changes. Some more detail was added to the function documentationrovement. Also the multiple assignments were removed per Documentation/CodingStyle chapter 1: Don't put multiple assignments on a single line either. Please let me know if you have any comments. Agree. Thanks, Omar -- 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 2/3] ARM: OMAP: hwmod: revise deassert sequence
Hi. On 2 August 2012 02:52, Paul Walmsley p...@pwsan.com wrote: On Mon, 16 Jul 2012, Omar Ramirez Luna wrote: For a reset sequence to complete cleanly, a module needs its associated clocks to be enabled, otherwise the timeout check in prcm code can print a false failure (failed to hardreset) that occurs because the clocks aren't powered ON and the status bit checked can't transition without them. Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org Is enabling the clocks sufficient? During my testing it seemed enough, besides it looks clk framework is doing the same as _omap4_enable_module. Or do we also need to enable the IP block, e.g. by calling if (soc_ops.enable_module) soc_ops.enable_module(oh); as we do on OMAP4+ in _enable() ? Basically this is a call to _omap4_enable_module, and the latter will Enable the modulemode inside CLKCTRL. However, _enable_clocks path which ends calling omap2_dflt_clk_enable does the same thing with its clk-enable_reg field. So in _enable: _enable_clocks(oh); if (soc_ops.enable_module) soc_ops.enable_module(oh); The enable_module part seems redundant to me, since the module should be already enabled by the first call to _enable_clocks. Regards, Omar -- 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/6] OMAP: iommu: hwmod, reset handling and runtime PM
On 17 July 2012 05:51, Ohad Ben-Cohen o...@wizery.com wrote: + Paul On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel joerg.roe...@amd.com wrote: On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote: Omar Ramirez Luna (6): ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected ARM: OMAP3: hwmod data: add mmu data for iva and isp ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP2+: iommu: add reset handling ARM: OMAP3/4: iommu: adapt to runtime pm What happens with this patch-set. Comments anyone? Ohad? Looks like it depends on a few OMAP hwmod changes (reset handling) which require Paul's ACK. That's correct, sorry if I failed to mention that in the cover-letter, but it does depend on: http://lkml.indiana.edu/hypermail/linux/kernel/1207.2/00361.html For the hwmod reset handling. Mainly, I wanted to gather comments for this patch set. - omar -- 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] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.
E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- cpu1 might not be used and hence (with previous check)
won't be fully enabled by hwmod code.
While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3215dad..091c199 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1558,25 +1558,28 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
}
/**
- * _are_any_hardreset_lines_asserted - return true if part of @oh is hard-reset
+ * _are_all_hardreset_lines_asserted - return true if the @oh is hard-reset
* @oh: struct omap_hwmod *
*
- * If any hardreset line associated with @oh is asserted, then return true.
- * Otherwise, if @oh has no hardreset lines associated with it, or if
- * no hardreset lines associated with @oh are asserted, then return false.
+ * If all hardreset lines associated with @oh are asserted, then return true.
+ * Otherwise, if part of @oh is out hardreset or if no hardreset lines
+ * associated with @oh are asserted, then return false.
* This function is used to avoid executing some parts of the IP block
- * enable/disable sequence if a hardreset line is set.
+ * enable/disable sequence if its hardreset line is set.
*/
-static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+static bool _are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
{
- int i;
+ int i, rst_cnt = 0;
if (oh-rst_lines_cnt == 0)
return false;
for (i = 0; i oh-rst_lines_cnt; i++)
if (_read_hardreset(oh, oh-rst_lines[i].name) 0)
- return true;
+ rst_cnt++;
+
+ if (oh-rst_lines_cnt == rst_cnt)
+ return true;
return false;
}
@@ -1595,6 +1598,13 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
return -EINVAL;
+ /*
+* Since integration code might still be doing something, only
+* disable if all lines are under hardreset.
+*/
+ if (!_are_all_hardreset_lines_asserted(oh))
+ return 0;
+
pr_debug(omap_hwmod: %s: %s\n, oh-name, __func__);
omap4_cminst_module_disable(oh-clkdm-prcm_partition,
@@ -1602,9 +1612,6 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
oh-clkdm-clkdm_offs,
oh-prcm.omap4.clkctrl_offs);
- if (_are_any_hardreset_lines_asserted(oh))
- return 0;
-
v = _omap4_wait_target_disable(oh);
if (v)
pr_warn(omap_hwmod: %s: _wait_target_disable failed\n,
@@ -1830,7 +1837,7 @@ static int _enable(struct omap_hwmod *oh)
}
/*
-* If an IP block contains HW reset lines and any of them are
+* If an IP block contains HW reset lines and all of them are
* asserted, we let integration code associated with that
* block handle the enable. We've received very little
* information on what those driver authors need, and until
@@ -1838,7 +1845,7 @@ static int _enable(struct omap_hwmod *oh)
* posted to the public lists, this is probably the best we
* can do.
*/
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
/* Mux pins for device runtime if populated */
@@ -1918,7 +1925,7 @@ static int _idle(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
if (oh-class-sysc)
@@ -2006,7 +2013,7 @@ static int _shutdown(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
pr_debug(omap_hwmod: %s: disabling\n, oh-name);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP: hwmod: revise deassert sequence
For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 091c199..f6f8d99 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1509,6 +1509,7 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
{
struct omap_hwmod_rst_info ohri;
int ret = -EINVAL;
+ int hwsup = 0;
if (!oh)
return -EINVAL;
@@ -1520,10 +1521,42 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
+ if (oh-clkdm) {
+ /*
+* A clockdomain must be in SW_SUP otherwise reset
+* might not be completed. The clockdomain can be set
+* in HW_AUTO only when the module become ready.
+*/
+ hwsup = clkdm_in_hwsup(oh-clkdm);
+ ret = clkdm_hwmod_enable(oh-clkdm, oh);
+ if (ret) {
+ WARN(1, omap_hwmod: %s: could not enable clockdomain
%s: %d\n,
+oh-name, oh-clkdm-name, ret);
+ return ret;
+ }
+ }
+
+ _enable_clocks(oh);
+
ret = soc_ops.deassert_hardreset(oh, ohri);
+
+ _disable_clocks(oh);
+
if (ret == -EBUSY)
pr_warning(omap_hwmod: %s: failed to hardreset\n, oh-name);
+ if (!ret) {
+ /*
+* Set the clockdomain to HW_AUTO, assuming that the
+* previous state was HW_AUTO.
+*/
+ if (oh-clkdm hwsup)
+ clkdm_allow_idle(oh-clkdm);
+ } else {
+ if (oh-clkdm)
+ clkdm_hwmod_disable(oh-clkdm, oh);
+ }
+
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices
This APIs are meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data
to control their reset lines, they are expected to know the name
of the reset line they are trying to control.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/include/plat/omap_device.h |4 ++
arch/arm/plat-omap/omap_device.c | 45 +
2 files changed, 49 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 4327b2c..27bcc24 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -118,6 +118,10 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev);
/* Other */
+int omap_device_assert_hardreset(struct platform_device *pdev,
+const char *name);
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+const char *name);
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..8883074 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -925,6 +925,51 @@ int omap_device_shutdown(struct platform_device *pdev)
}
/**
+ * omap_device_assert_hardreset - set a device's reset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * with the name of the reset line
+ *
+ * According to @name, set the reset line of the hwmods associated
+ * with this @pdev deivce.
+ */
+int omap_device_assert_hardreset(struct platform_device *pdev, const char
*name)
+{
+ int i, ret = 0;
+ struct omap_device *od = to_omap_device(pdev);
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+ ret = omap_hwmod_assert_hardreset(od-hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
+ * omap_device_deassert_hardreset - lift a device's reset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * with the name of the reset line
+ *
+ * According to @name, lift the reset line of the hwmods associated
+ * with this @pdev deivce.
+ */
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+ const char *name)
+{
+ int i, ret = 0;
+ struct omap_device *od = to_omap_device(pdev);
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+ ret = omap_hwmod_deassert_hardreset(od-hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
* omap_device_align_pm_lat - activate/deactivate device to match wakeup lat
lim
* @od: struct omap_device *
*
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend broken on 3.5-rc1?
On 12 July 2012 00:27, Rajendra Nayak rna...@ti.com wrote: On Thursday 12 July 2012 05:28 AM, Omar Ramirez Luna wrote: I suspect this might be specific to 4460 as Rajendra reported it was working for him on 4430 but not on 4460, I haven't tried 4430 but let me see if I can find one. Yes, this is an issue specific to 4460. The patch 'ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change' from Tero's Core retention series [1] fixes it. Unfortunately the patch does not apply on it own and has dependencies with other patches in the series. [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/78399 Thanks, it worked! I took the first two patches of the series and at least I'm able to come back from suspend on Panda 4460. However, the original series no longer applies on 3.5-rc6 and I couldn't find a rebased version on Tero's tree, so I just rebased the first two to 3.5-rc6 in case anybody stomps on this thread and for test purposes only: git://github.com/omarrmz/upstream-wip.git branch: LO-k3.5-rc6-secondary-CPU-resume-hangs I hope at least 1 and 2 from the original series make it for 3.6. Regards, Omar -- 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: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
On 11 July 2012 12:07, Kevin Hilman khil...@ti.com wrote: ... [2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk [2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 [2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk [2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 These are normal because DMA engine is not compiled in with omap2plus_defconfig. MMC wont' work unless you build in DMA engine, but that doesn't matter for trying to figure out your problem. Hijacking this thread a little bit... It looks like a dependency is missing in Kconfig then, as this also fails to boot if the file system is in MMC. As you pointed out CONFIG_DMADEVICES and CONFIG_DMA_OMAP is needed to boot in this case. I'm using a Panda 4460. Regards, Omar -- 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: suspend broken on 3.5-rc1?
On 12 June 2012 07:01, Rajendra Nayak rna...@ti.com wrote: On Friday 08 June 2012 06:46 PM, Rajendra Nayak wrote: On Friday 08 June 2012 06:35 PM, Tero Kristo wrote: On Fri, 2012-06-08 at 17:55 +0530, Rajendra Nayak wrote: On Friday 08 June 2012 04:26 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120608 03:40]: Hi, I don;t seem to be able to get suspend to work on 3.5-rc1 on my 4430 panda. I am not sure if its UART wakeups that are an issue or suspend itself is broken. Is there anything more than setting '/sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup' to 'enabled' that I need to do to get UART to be wakeup capable? 3.4 major works just fine for me. Can you try with the fixes branch that Olof just merged? I tried merging the fixes branch on 3.5-rc1 as well as latest mainline and both didn't work. If it's the UART wake-up events, there's a patch that should help. Tony The patch referenced here helps: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69596.html DSS crashes during wakeup from suspend. great, thats what I found too with no_console_suspend, didn't know a fix already exists. Thanks. The patch above seems to fix suspend on 4430, but on my 4460 ES1.1 panda, I still see its broken.. # echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup # echo mem /sys/power/state [6.549285] PM: Syncing filesystems ... done. [6.581695] Freezing user space processes ... (elapsed 0.02 seconds) done. [6.612823] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [6.674102] PM: suspend of devices complete after 51.391 msecs [6.682006] PM: late suspend of devices complete after 1.739 msecs [6.691650] PM: noirq suspend of devices complete after 3.143 msecs [6.698272] Disabling non-boot CPUs ... [6.705993] CPU1: shutdown [7.298797] Successfully put all powerdomains to target state [7.304992] Enabling non-boot CPUs ... * hang* ..anyone knows of any more fixes going around? I'm seeing the same thing, it gets stuck trying to enable CPU1, tried this with pm-20120710 from linux-omap-pm and current LO master (based on 3.5-rc6), also using a Panda 4460. Would appreciate patches if any. Regards, Omar -- 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: suspend broken on 3.5-rc1?
Hi Kevin, On 11 July 2012 16:42, Kevin Hilman khil...@ti.com wrote: Omar Ramirez Luna omar.l...@linaro.org writes: On 12 June 2012 07:01, Rajendra Nayak rna...@ti.com wrote: [...] ..anyone knows of any more fixes going around? I'm seeing the same thing, it gets stuck trying to enable CPU1, tried this with pm-20120710 from linux-omap-pm and current LO master (based on 3.5-rc6), also using a Panda 4460. When reporing problems like this, it is greatly helpful to report your defconfig (specifically, any changes from omap2plus_defconfig.) Sorry, I missed this since it was omap2plus_defconfig + CONFIG_DMADEVICES and CONFIG_DMA_OMAP. Specifically, do you have CONFIG_MFD_OMAP_USB_HOST in your defconfig? No. There are known bugs that cause the USB host driver to hang suspend in mainline. Because of this, and the fact that the USB developers did not fix try to this for v3.5, current l-o master (and my pm branch) now have this disabled by default in omap2plus_defconfig. Would appreciate patches if any. If it's the USB host problem you need fixed, Russ Dill has posted a couple patches and Keshava has posted a bigger revert, but there hasn't been any conclusion on the fix yet. Can you try to reproduce with omap2plus_defconfig (+ DMA engine if you need MMC rootfs.) With omap2plus_defconfig + initramfs and omap2plus_defconfig + DMAengine for MMC rootfs, this is working fine for me on my 4430 Panda using RTC wakeups: I suspect this might be specific to 4460 as Rajendra reported it was working for him on 4430 but not on 4460, I haven't tried 4430 but let me see if I can find one. Thanks, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Hi Paul,
On 27 June 2012 20:27, Omar Ramirez Luna omar.l...@linaro.org wrote:
On 19 June 2012 12:48, Cousson, Benoit b-cous...@ti.com wrote:
On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
Hi Benoit,
On 19 June 2012 07:36, Cousson, Benoit b-cous...@ti.com wrote:
On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
...
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = ipu_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = ipu_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs =
OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = ipu_mmu_dev_attr,
+};
In fact, the MMU_IPU hwmod is now almost the same one than the previous
IPU one...
If we do that we should maybe just rename the IPU - MMU_IPU and DSP -
MMU_DSP.
But by doing that we will assume that the MMU does represent the
subsystem, which is not necessarily super nice.
I guess that a much better representation will be to keep the subsystem
(IPU) to handle the PRCM part:
+ .main_clk = ipu_fck,
+ .prcm = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
And then the MMU_IPU will handle the configuration registers part and the
reset + irq.
But then, you will have to create a parent child dependency between your
devices to ensure that the IPU subsystem device will be enabled before
trying to access the MMU_IPU.
This is what the DSS is about to do to handle the same kind of power
dependency. The DSS device is the parent of all the DSS IPs (DISPC,
HDMI...)
and thus pm_runtime will ensure that the parent is enabled before trying to
enable the children.
In term of DT, just to illustrate the situation, it will be something
like that:
ipu {
compatible = simple-bus;
ti,hwmods = ipu;
ipu_mmu: mmu@4a066000 {
compatible = omap-mmu;
ti,hwmods = mmu_ipu;
reg...;
irqs...;
}
}
Is it something you can handle with your current framework?
I agree it would be nice only IPU managed the prcm, however we can't
do that right now because hwmod expects the IP block to be out of
reset to continue the _enable sequence. On IPU both reset lines are
asserted at that point and hence _are_any_hardreset_lines_asserted
check will bail out, and ipu resets can't be lifted without a
configured iommu otherwise it might execute random garbage.
That's a good point, but like Paul said, the hard reset was removed outside
of the fmwk due to the lack of understanding about the real usage / need for
it.
If we do have a better understanding, we might add some more support in the
fmwk or at least improve it.
I'm now realizing that aborting the init if some reset lines are asserted is
not what we want to do for the IPU SS hwmod that will contain the IPU
(processor) reset control.
In fact the previous approach with a fake hwmod for the ipu_c0 processor
would have been avoided that issue.
If we do not want to go back with that, we should clearly revise the
_are_any_hardreset_lines_asserted approach and not prevent the init in such
case since it will prevent all the subsystem to start properly.
So, for IPU and DSP the mmu must be deasserted and configured before
the processor reset line (which is more like a parking brake) is
deasserted, and the latter should be made before _enable is called so
it can fully execute the enable sequence.
Yep, so we have to change the way it is handled today.
Paul,
If we consider that the reset lines are stored in the subsystem hwmod (IPU,
DSP or IVA), we cannot prevent the init phase because some line are
asserted. Otherwise we will never allow the MMU or processor to be enabled
later.
We might have to remove that check, maybe based on flag if we want to keep
that functionality or do an explicit reset control like we use to do.
What do you think?
I was waiting for some comments then I realized Paul wasn't actually
in the list of recipients for this email.
Any chance you had time to check on this? While at it, could you please check:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70443.html
Thanks,
Omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
Re: [PATCH 0/3] OMAP: hwmod: reset API proposal
Hi Paul, On 15 June 2012 20:54, Omar Ramirez Luna omar.l...@linaro.org wrote: Recent changes in omap_hwmod framework have reworked the behaviour towards hardreset handling, commit 747834a (ARM: OMAP2+: hwmod: revise hardreset behavior) recommends for drivers to implement their own reset sequences until code out-of-tree hits mainline and then their needs and code can be reviewed. Since it is not clear when this will occur for all drivers and hwmod code was not deleted (presumably because at some point it will handle the resets once again), this series exports functions to handle hardreset lines in an attempt to reduce code duplication for those who have a common reset sequence. These APIs are intended to be used by iommu for now, but were tested with IPU and remoteproc on Pandaboard. Do you have any comments for these patches? Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
+ Paul
On 19 June 2012 12:48, Cousson, Benoit b-cous...@ti.com wrote:
On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
Hi Benoit,
On 19 June 2012 07:36, Cousson, Benoit b-cous...@ti.com wrote:
On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
...
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = ipu_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = ipu_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs =
OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = ipu_mmu_dev_attr,
+};
In fact, the MMU_IPU hwmod is now almost the same one than the previous
IPU one...
If we do that we should maybe just rename the IPU - MMU_IPU and DSP -
MMU_DSP.
But by doing that we will assume that the MMU does represent the
subsystem, which is not necessarily super nice.
I guess that a much better representation will be to keep the subsystem
(IPU) to handle the PRCM part:
+ .main_clk = ipu_fck,
+ .prcm = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
And then the MMU_IPU will handle the configuration registers part and the
reset + irq.
But then, you will have to create a parent child dependency between your
devices to ensure that the IPU subsystem device will be enabled before
trying to access the MMU_IPU.
This is what the DSS is about to do to handle the same kind of power
dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...)
and thus pm_runtime will ensure that the parent is enabled before trying to
enable the children.
In term of DT, just to illustrate the situation, it will be something
like that:
ipu {
compatible = simple-bus;
ti,hwmods = ipu;
ipu_mmu: mmu@4a066000 {
compatible = omap-mmu;
ti,hwmods = mmu_ipu;
reg...;
irqs...;
}
}
Is it something you can handle with your current framework?
I agree it would be nice only IPU managed the prcm, however we can't
do that right now because hwmod expects the IP block to be out of
reset to continue the _enable sequence. On IPU both reset lines are
asserted at that point and hence _are_any_hardreset_lines_asserted
check will bail out, and ipu resets can't be lifted without a
configured iommu otherwise it might execute random garbage.
That's a good point, but like Paul said, the hard reset was removed outside
of the fmwk due to the lack of understanding about the real usage / need for
it.
If we do have a better understanding, we might add some more support in the
fmwk or at least improve it.
I'm now realizing that aborting the init if some reset lines are asserted is
not what we want to do for the IPU SS hwmod that will contain the IPU
(processor) reset control.
In fact the previous approach with a fake hwmod for the ipu_c0 processor
would have been avoided that issue.
If we do not want to go back with that, we should clearly revise the
_are_any_hardreset_lines_asserted approach and not prevent the init in such
case since it will prevent all the subsystem to start properly.
So, for IPU and DSP the mmu must be deasserted and configured before
the processor reset line (which is more like a parking brake) is
deasserted, and the latter should be made before _enable is called so
it can fully execute the enable sequence.
Yep, so we have to change the way it is handled today.
Paul,
If we consider that the reset lines are stored in the subsystem hwmod (IPU,
DSP or IVA), we cannot prevent the init phase because some line are
asserted. Otherwise we will never allow the MMU or processor to be enabled
later.
We might have to remove that check, maybe based on flag if we want to keep
that functionality or do an explicit reset control like we use to do.
What do you think?
I was waiting for some comments then I realized Paul wasn't actually
in the list of recipients for this email.
Regards,
Omar
--
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
