Re: OMAP3 Feature list buggy
Hi, On Fri, Nov 05, 2010 at 10:08:13AM -0500, Arno Steffen wrote: There is a copy/paste bug in arch/arm/plat-omaop/include/control: Please replace: #define OMAP3_IVA_MASK (1 << OMAP3_SGX_SHIFT) by: #define OMAP3_IVA_MASK (1 << OMAP3_IVA_SHIFT) care to send a patch ? -- balbi -- 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: combine zoom2 and zoom3 board-files
They are extremely similar anyway, let's get rid
of one file.
While at that, also remove the empty zoom_config
variable.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/Makefile |4 +-
.../arm/mach-omap2/{board-zoom3.c => board-zoom.c} | 100 ++---
arch/arm/mach-omap2/board-zoom2.c | 117
3 files changed, 61 insertions(+), 160 deletions(-)
rename arch/arm/mach-omap2/{board-zoom3.c => board-zoom.c} (77%)
delete mode 100644 arch/arm/mach-omap2/board-zoom2.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..b0810b9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -144,12 +144,12 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
board-rx51-peripherals.o \
board-rx51-video.o \
hsmmc.o
-obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \
board-zoom-peripherals.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
-obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \
board-zoom-peripherals.o \
board-flash.o \
hsmmc.o \
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom.c
similarity index 77%
rename from arch/arm/mach-omap2/board-zoom3.c
rename to arch/arm/mach-omap2/board-zoom.c
index 5adde12..f10766b 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -1,6 +1,9 @@
/*
- * Copyright (C) 2009 Texas Instruments Inc.
+ * Copyright (C) 2009-2010 Texas Instruments Inc.
+ * Mikkel Christensen
+ * Felipe Balbi
*
+ * Modified from mach-omap2/board-ldp.c
*
* 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
@@ -12,22 +15,55 @@
#include
#include
#include
+#include
#include
#include
-#include
-
#include
#include
#include
+#include
+
#include "board-flash.h"
#include "mux.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
#include "sdram-hynix-h8mbx00u0mer-0em.h"
-static struct omap_board_config_kernel zoom_config[] __initdata = {
+static void __init omap_zoom_init_irq(void)
+{
+ if (machine_is_omap_zoom2())
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
+ mt46h32m32lf6_sdrc_params);
+ else if (machine_is_omap_zoom3())
+ omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
+
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ { .reg_offset = OMAP_MUX_TERMINATOR },
};
+#else
+#define board_mux NULL
+#endif
static struct mtd_partition zoom_nand_partitions[] = {
/* All the partition sizes are listed in terms of NAND block size */
@@ -70,37 +106,6 @@ static struct mtd_partition zoom_nand_partitions[] = {
},
};
-static void __init omap_zoom_init_irq(void)
-{
- omap_board_config = zoom_config;
- omap_board_config_size = ARRAY_SIZE(zoom_config);
- omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
- h8mbx00u0mer0em_sdrc_params);
- omap_init_irq();
- omap_gpio_init();
-}
-
-#ifdef CONFIG_OMAP_MUX
-static struct omap_board_mux board_mux[] __initdata = {
- /* WLAN IRQ - GPIO 162 */
- OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
- /* WLAN POWER ENABLE - GPIO 101 */
- OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
- /* WLAN SDIO: MMC3 CMD */
- OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
- /* WLAN SDIO: MMC3 CLK */
- OMAP3_MUX(ETK_CLK, OMAP
[PATCH 2/2] arm: omap: zoom: substitute gpio number with symbolic name
It's easier to understand what that number means and
also avoids problems if we ever have to change it.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-zoom.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index f10766b..3da69e4 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -31,6 +31,8 @@
#include "sdram-micron-mt46h32m32lf-6.h"
#include "sdram-hynix-h8mbx00u0mer-0em.h"
+#define ZOOM3_EHCI_RESET_GPIO 64
+
static void __init omap_zoom_init_irq(void)
{
if (machine_is_omap_zoom2())
@@ -112,7 +114,7 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
.reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 64,
+ .reset_gpio_port[1] = ZOOM3_EHCI_RESET_GPIO,
.reset_gpio_port[2] = -EINVAL,
};
@@ -122,7 +124,7 @@ static void __init omap_zoom_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
} else if (machine_is_omap_zoom3()) {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
usb_ehci_init(&ehci_pdata);
}
--
1.7.3.2.146.gca209
--
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] combine zoom board-files
Those boards are so similar they don't deserve
separate board files.
Felipe Balbi (2):
arm: omap: combine zoom2 and zoom3 board-files
arm: omap: zoom: substitute gpio number with symbolic name
arch/arm/mach-omap2/Makefile |4 +-
.../arm/mach-omap2/{board-zoom3.c => board-zoom.c} | 104 ++---
arch/arm/mach-omap2/board-zoom2.c | 117
3 files changed, 64 insertions(+), 161 deletions(-)
rename arch/arm/mach-omap2/{board-zoom3.c => board-zoom.c} (75%)
delete mode 100644 arch/arm/mach-omap2/board-zoom2.c
--
1.7.3.2.146.gca209
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap1: devices: need to return with a value
Get rid of the following warning:
arch/arm/mach-omap1/devices.c: In function 'omap_init_wdt':
arch/arm/mach-omap1/devices.c:298: warning: 'return' with
no value, in function returning non-void
while at that, also change:
platform_device_register();
return 0;
into:
return platform_device_register();
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/devices.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index ea0d80a..e7f9ee6 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -321,10 +321,9 @@ static struct platform_device omap_wdt_device = {
static int __init omap_init_wdt(void)
{
if (!cpu_is_omap16xx())
- return;
+ return -ENODEV;
- platform_device_register(&omap_wdt_device);
- return 0;
+ return platform_device_register(&omap_wdt_device);
}
subsys_initcall(omap_init_wdt);
#endif
--
1.7.3.2.146.gca209
--
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 RFC] usb: musb: fail unaligned DMA transfers on v1.8 and above
On 10/31/2010 3:29 PM, Ming Lei wrote: 2010/10/31 Anand Gadiyar: The Inventra DMA engine in version 1.8 and later of the MUSB controller cannot handle DMA addresses that are not aligned to a 4 byte boundary. It ends up ignoring the last two bits programmed in the DMA_ADDR register. This is a deliberate design change in the controller and is documented in the programming guide. Earlier versions of the controller could handle these accesses just fine. Fail dma_channel_program if we see an unaligned address when using the newer controllers, so that the caller can carry out the transfer using PIO mode. (Current callers already have this backup path in place). Signed-off-by: Anand Gadiyar Cc: Felipe Balbi Cc: Ming Lei Cc: Ajay Kumar Gupta Cc: Mike Frysinger Tested-by: Ming Lei This patch is verified OK about g_ether function on beagle xM board, but the revised patch "usb: musb: gadget: Unmapping the dma buffer when switching to PIO mode" [1] should be applied first. --- Patch based on linux-next as of 20101029. I believe Blackfin is also affected by this, but I'm not sure how they're working around this. Mike? MUSB on Blackfin will fallback to PIO too, so no any working around for it, right? I meant Blackfin should also have hit this issue so far. I'm making a change based on the MUSB revision - so this change will affect Blackfin for sure - they use revision 1.9 and 2.0 I think. So I'm just wondering if they really are affected, or they've simply never hit this scenario before. - Anand -- 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] video: omap: vram: remove from normal memory
On Tue, Oct 19, 2010 at 3:03 PM, Tomi Valkeinen
wrote:
> On Tue, 2010-10-19 at 00:55 +0200, ext Tony Lindgren wrote:
>> * Tomi Valkeinen [101018 06:55]:
>> > On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
>> > > Hi,
>> > >
>> > > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> > > > So that we can ioremap happily.
>> > > >
>> > > > Cc: Tomi Valkeinen
>> > > > Signed-off-by: Felipe Contreras
>> > > > ---
>> > > > drivers/video/omap2/vram.c | 2 ++
>> > > > 1 files changed, 2 insertions(+), 0 deletions(-)
>> > > >
>> > > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
>> > > > index f6fdc20..1a99777 100644
>> > > > --- a/drivers/video/omap2/vram.c
>> > > > +++ b/drivers/video/omap2/vram.c
>> > > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
>> > > > }
>> > > > } else {
>> > > > paddr = memblock_alloc_base(size, PAGE_SIZE,
>> > > > MEMBLOCK_REAL_LIMIT);
>> > > > + memblock_free(paddr, size);
>> > > > + memblock_remove(paddr, size);
>> > > > }
>> > > >
>> > > > omap_vram_add_region(paddr, size);
>> > >
>> > > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
>> > > fine, but my test program crashes the kernel (dump below).
>> > >
>> > > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
>> > > phys_to_virt for RAM mappings" patch in (I removed that during testing
>> > > this patch).
>> > >
>> > > I don't know yet what is crashing the kernel, but I'd guess it's the
>> > > fact that my test program reallocates the framebuffer memory with
>> > > OMAPFB_SETUP_MEM ioctl.
>> >
>> > Ah, sorry, I was missing the patch from Russel which you mentioned in
>> > another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
>> > that patch included things seem to work.
>>
>> Tomi, I assume you're queuing these? If so, for both:
>>
>> Acked-by: Tony Lindgren
>
> Yes, I can queue them (when the required memblock stuff is in).
Now it's in :) (v2.6.37-rc1)
--
Felipe Contreras
--
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] omap: dsp: fixes for 2.6.37-rc1
On Mon, Nov 8, 2010 at 12:02 AM, Greg KH wrote: > On Sun, Nov 07, 2010 at 11:43:24PM +0200, Felipe Contreras wrote: >> Paul already sent these, but I did some minor modifications, mostly to >> minimize >> the amount of changes. >> >> Also, I'm re-sending my memblock patch so that the driver can actually be >> compiled. >> >> With these, and reverting the iommu patches[1], the driver should be >> working. I >> don't see a more straight-forward way to achieve that. > > I can't take these through the staging tree unless I get an ack from the > omap maintainers. > > And as you are adding new infrastructure to the core kernel, this really > needed to be there before .37-rc1, I don't think it's acceptable to > merge this late in the development cycle. Isn't that up to omap maintainers to decide? Anyway, there's an alternative that doesn't require omap to ack: --- a/drivers/staging/tidspbridge/core/tiomap3430.c +++ b/drivers/staging/tidspbridge/core/tiomap3430.c @@ -23,7 +23,6 @@ #include #include #include -#include /* --- DSP/BIOS Bridge */ #include @@ -74,6 +73,18 @@ #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) + +#define OMAP343X_CTRL_REGADDR(reg) \ + OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE + (reg)) + /* Forward Declarations: */ static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt); static int bridge_brd_read(struct bridge_dev_context *dev_ctxt, -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Fix build failure on MEMBLOCK_REAL_LIMIT
On Mon, Nov 1, 2010 at 6:30 PM, Namhyung Kim wrote:
> --- a/drivers/video/omap2/vram.c
> +++ b/drivers/video/omap2/vram.c
> @@ -570,7 +570,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
> return;
> }
> } else {
> - paddr = memblock_alloc_base(size, PAGE_SIZE,
> MEMBLOCK_REAL_LIMIT);
> + paddr = memblock_alloc_base(size, PAGE_SIZE,
> + MEMBLOCK_ALLOC_ACCESSIBLE);
This is exactly the same as:
paddr = memblock_alloc(size, PAGE_SIZE);
Let's use that instead.
--
Felipe Contreras
--
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] omap: dsp: fixes for 2.6.37-rc1
On Sun, Nov 07, 2010 at 11:43:24PM +0200, Felipe Contreras wrote: > Hi, > > Paul already sent these, but I did some minor modifications, mostly to > minimize > the amount of changes. > > Also, I'm re-sending my memblock patch so that the driver can actually be > compiled. > > With these, and reverting the iommu patches[1], the driver should be working. > I > don't see a more straight-forward way to achieve that. I can't take these through the staging tree unless I get an ack from the omap maintainers. And as you are adding new infrastructure to the core kernel, this really needed to be there before .37-rc1, I don't think it's acceptable to merge this late in the development cycle. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] staging: tidspbridge: use boot control functions
From: Paul Walmsley
Use the new functions from SCM layer instead of handling registers
directly with __raw_writel, as explained in:
http://marc.info/?l=linux-omap&m=128779652429922&w=2
This fixes the build on 2.6.37 since control.h is not available for
drivers any more.
Signed-off-by: Paul Walmsley
Signed-off-by: Omar Ramirez Luna
Signed-off-by: Felipe Contreras
---
drivers/staging/tidspbridge/core/tiomap3430.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index cb38743..84de0c2 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -23,7 +23,7 @@
#include
#include
#include
-#include
+#include
/* --- DSP/BIOS Bridge */
#include
@@ -412,19 +412,18 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
/* Assert RST1 i.e only the RST only for DSP megacell */
if (!status) {
+ u8 bootmode;
(*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,
- OMAP343X_CTRL_REGADDR(
- OMAP343X_CONTROL_IVA2_BOOTADDR));
+ dsp_addr &= OMAP3_IVA2_BOOTADDR_MASK;
+ (*pdata->set_dsp_bootaddr)(dsp_addr);
/*
* Set bootmode to self loop if dsp_debug flag is true
*/
- __raw_writel((dsp_debug) ? OMAP3_IVA2_BOOTMOD_IDLE : 0,
- OMAP343X_CTRL_REGADDR(
- OMAP343X_CONTROL_IVA2_BOOTMOD));
+ bootmode = dsp_debug ? OMAP_DSP_BOOTMODE_IDLE : 0;
+ (*pdata->set_dsp_bootmode)(bootmode);
}
}
if (!status) {
--
1.7.3.2.3.gf8529
--
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] omap: pm: use control functions in DSP reset code
From: Paul Walmsley
Update the DSP reset code in pm34xx.c to use one of the new SCM DSP boot
control functions, omap_ctrl_set_dsp_bootmode().
This reset code should be moved out to a separate function to be called
by the hwmod reset process at some point. Also, 2430 should be
initializing the DSP in a similar fashion.
Signed-off-by: Paul Walmsley
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/pm34xx.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..86e7e99 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
@@ -614,6 +615,7 @@ static struct platform_suspend_ops omap_pm_ops = {
* function forces the IVA2 into idle state so it can go
* into retention/off and thus allow full-chip retention/off.
*
+ * XXX This should be handled by the hwmod.
**/
static void __init omap3_iva_idle(void)
{
@@ -635,9 +637,7 @@ static void __init omap3_iva_idle(void)
cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK,
OMAP3430_IVA2_MOD, CM_FCLKEN);
- /* Set IVA2 boot mode to 'idle' */
- omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
-OMAP343X_CONTROL_IVA2_BOOTMOD);
+ omap_ctrl_set_dsp_bootmode(OMAP_DSP_BOOTMODE_IDLE);
/* Un-reset IVA2 */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
--
1.7.3.2.3.gf8529
--
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] omap: dsp: add boot control functions
From: Paul Walmsley
Would be needed to avoid using SCM directly.
Signed-off-by: Paul Walmsley
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/dsp.c |4
arch/arm/plat-omap/include/plat/dsp.h |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index 6feeeae..6a21ac6 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -12,6 +12,7 @@
*/
#include
+#include "control.h"
#include "prm.h"
#include "cm.h"
#ifdef CONFIG_BRIDGE_DVFS
@@ -31,6 +32,9 @@ static struct omap_dsp_platform_data omap_dsp_pdata
__initdata = {
.cpu_set_freq = omap_pm_cpu_set_freq,
.cpu_get_freq = omap_pm_cpu_get_freq,
#endif
+ .set_dsp_bootaddr = omap_ctrl_set_dsp_bootaddr,
+ .set_dsp_bootmode = omap_ctrl_set_dsp_bootmode,
+
.dsp_prm_read = prm_read_mod_reg,
.dsp_prm_write = prm_write_mod_reg,
.dsp_prm_rmw_bits = prm_rmw_mod_reg_bits,
diff --git a/arch/arm/plat-omap/include/plat/dsp.h
b/arch/arm/plat-omap/include/plat/dsp.h
index 079691d..b2cf15b 100644
--- a/arch/arm/plat-omap/include/plat/dsp.h
+++ b/arch/arm/plat-omap/include/plat/dsp.h
@@ -10,7 +10,11 @@ struct omap_dsp_platform_data {
unsigned long (*cpu_get_freq) (void);
unsigned long mpu_speed[6];
+ void (*set_dsp_bootaddr)(u32 pa);
+ void (*set_dsp_bootmode)(u8 mode);
+
/* functions to write and read PRCM registers */
+ /* XXX None of this should be here */
void (*dsp_prm_write)(u32, s16 , u16);
u32 (*dsp_prm_read)(s16 , u16);
u32 (*dsp_prm_rmw_bits)(u32, u32, s16, s16);
--
1.7.3.2.3.gf8529
--
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] omap: control: add functions for DSP boot
From: Paul Walmsley
Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These
registers wound up in the System Control Module. Other kernel code that
wishes to control the DSP's boot process should now use these functions
to do so; subsequent patches implement this in the two in-tree users of
these functions.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/control.c | 49 +
arch/arm/mach-omap2/control.h | 10 +++---
arch/arm/plat-omap/include/plat/dsp.h |6
3 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..808abeb 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,6 +209,55 @@ void omap4_ctrl_pad_writel(u32 val, u16 offset)
__raw_writel(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+/* OMAP DSP control functions */
+
+/**
+ * omap_ctrl_set_dsp_bootaddr - set the DSP's boot address
+ * @pa: DSP boot address (in physical memory)
+ *
+ * Set the DSP's boot address. This is an address in physical memory.
+ * No return value. XXX The TRM claims that this is an "index to a
+ * 4kByte page". If so, why is the bitfield 21 bits wide, rather than
+ * 20?
+ */
+void omap_ctrl_set_dsp_bootaddr(u32 pa)
+{
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+ WARN(1, "control: %s: not supported on this SoC\n", __func__);
+ return;
+ }
+
+ WARN(pa & ~OMAP_CTRL_DSP_BOOTADDR_MASK,
+"control: %s: invalid DSP boot address %08x\n", __func__, pa);
+
+ omap_ctrl_writel(pa, OMAP243X_CONTROL_IVA2_BOOTADDR);
+}
+
+/**
+ * omap_ctrl_set_dsp_bootmode - set the DSP's boot mode
+ * @mode: DSP boot mode (described below)
+ *
+ * Sets the DSP boot mode - see OMAP3 TRM revision ZH section 7.4.7.4
+ * "IVA2.2 Boot Registers". Known values of @mode include 0, to boot
+ * directly to the address supplied by omap2_ctrl_set_dsp_bootaddr();
+ * 1, to boot to the DSP's ROM code and idle, waiting for interrupts;
+ * 2, to boot to the DSP's ROM code and spin in an idle loop; 3, to
+ * copy the user's bootstrap code from the DSP's internal memory and
+ * execute it (XXX how does the DSP know where to copy from?); and 4,
+ * to execute the DSP ROM code's context restore code. No return
+ * value.
+ */
+void omap_ctrl_set_dsp_bootmode(u8 mode)
+{
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+ WARN(1, "control: %s: not supported on this SoC\n", __func__);
+ return;
+ }
+
+ omap_ctrl_writel(mode, OMAP243X_CONTROL_IVA2_BOOTMOD);
+}
+
+
#if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
/*
* Clears the scratchpad contents in case of cold boot-
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..105ee00 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -258,11 +258,6 @@
/* CONTROL_PROG_IO1 bits */
#define OMAP3630_PRG_SDMMC1_SPEEDCTRL (1 << 20)
-/* CONTROL_IVA2_BOOTMOD bits */
-#define OMAP3_IVA2_BOOTMOD_SHIFT 0
-#define OMAP3_IVA2_BOOTMOD_MASK(0xf << 0)
-#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 << 0)
-
/* CONTROL_PADCONF_X bits */
#define OMAP3_PADCONF_WAKEUPEVENT0 (1 << 15)
#define OMAP3_PADCONF_WAKEUPENABLE0(1 << 14)
@@ -330,6 +325,8 @@
#defineFEAT_NEON 0
#defineFEAT_NEON_NONE 1
+/* DSP booting-related constants */
+#define OMAP_CTRL_DSP_BOOTADDR_MASK0xfc00
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
@@ -351,6 +348,9 @@ extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
+extern void omap_ctrl_set_dsp_bootaddr(u32 pa);
+extern void omap_ctrl_set_dsp_bootmode(u8 mode);
+
#else
#define omap_ctrl_base_get() 0
#define omap_ctrl_readb(x) 0
diff --git a/arch/arm/plat-omap/include/plat/dsp.h
b/arch/arm/plat-omap/include/plat/dsp.h
index 9c604b3..079691d 100644
--- a/arch/arm/plat-omap/include/plat/dsp.h
+++ b/arch/arm/plat-omap/include/plat/dsp.h
@@ -28,4 +28,10 @@ extern void omap_dsp_reserve_sdram_memblock(void);
static inline void omap_dsp_reserve_sdram_memblock(void) { }
#endif
+#define OMAP_DSP_BOOTMODE_USER 0
+#define OMAP_DSP_BOOTMODE_IDLE 1
+#define OMAP_DSP_BOOTMODE_BUSYLOOP 2
+#define OMAP_DSP_BOOTMODE_COPY 3
+#define OMAP_DSP_BOOTMODE_RESTORE 4
+
#endif
--
1.7.3.2.3.gf8529
--
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] omap: dsp: remove shm from normal memory
Also, don't be picky about the location, which incidentally fixes the
build since MEMBLOCK_REAL_LIMIT is gone on 2.6.37.
Signed-off-by: Felipe Contreras
---
arch/arm/plat-omap/devices.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 6f42a18..fc81912 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -284,12 +284,14 @@ void __init omap_dsp_reserve_sdram_memblock(void)
if (!size)
return;
- paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
+ paddr = memblock_alloc(size, SZ_1M);
if (!paddr) {
pr_err("%s: failed to reserve %x bytes\n",
__func__, size);
return;
}
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
omap_dsp_phys_mempool_base = paddr;
}
--
1.7.3.2.3.gf8529
--
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] omap: dsp: fixes for 2.6.37-rc1
Hi, Paul already sent these, but I did some minor modifications, mostly to minimize the amount of changes. Also, I'm re-sending my memblock patch so that the driver can actually be compiled. With these, and reverting the iommu patches[1], the driver should be working. I don't see a more straight-forward way to achieve that. Cheers. Felipe Contreras (1): omap: dsp: remove shm from normal memory Paul Walmsley (4): omap: control: add functions for DSP boot omap: pm: use control functions in DSP reset code omap: dsp: add boot control functions staging: tidspbridge: use boot control functions arch/arm/mach-omap2/control.c | 49 + arch/arm/mach-omap2/control.h | 10 +++--- arch/arm/mach-omap2/dsp.c |4 ++ arch/arm/mach-omap2/pm34xx.c |6 ++-- arch/arm/plat-omap/devices.c |4 ++- arch/arm/plat-omap/include/plat/dsp.h | 10 + drivers/staging/tidspbridge/core/tiomap3430.c | 13 +++ 7 files changed, 80 insertions(+), 16 deletions(-) [1] git://gitorious.org/~felipec/linux-omap/felipec.git fc-dsp-iommu-revert-v37-rc1 -- 1.7.3.2.3.gf8529 -- 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
[GIT PULL] fixes for tidspbridge 2.6.37-rc1
Hi Greg, The situation of tidspbridge driver on staging has been pretty sad, basically, it has never worked. This is a step backwards from the previous situation where it was clear which branch to use to get it working. Unfortunately, the ARM and OMAP trees haven't made it easy, as changes in those trees have broken it even further. My proposal to get this fixed is: 1) Revert back the iommu changes Presumably, in order to get the migration to omap iommu working many dependencies are needed, which haven't been merged yet. And at least I have never seen it working, although Fernando claims to have the right set of patches to do so. I say merging this was premature. I have reverted back those changes in: git://gitorious.org/~felipec/linux-omap/felipec.git fc-dsp-iommu-revert-v37-rc1 That would have been enough for 2.6.36, but... 2) Apply the fixes for recent omap control changes On 2.6.37-rc1, omap platform internals changed, so the build is broken again. Paul Walmsley provided some reference patches that I have modified slightly. 3) Fix for memblock Changes in memblock also broke this driver, one patch of mine should fix that, as well as prepare it for imminent changes from the ARM tree. All the changes are in: git://gitorious.org/~felipec/linux-omap/felipec.git fc-dsp-fix-v37-rc1 With this, the driver should work on 2.6.37, and would be the first time it does so on staging. I didn't see any point in sending the patches to review the reverts, I'm going to send the rest of the patches on top of the branch fc-dsp-iommu-revert-v37-rc1. These are the changes since v2.6.37-rc1: Felipe Contreras (13): Revert "staging: tidspbridge - update Kconfig to select IOMMU module" Revert "staging: tidspbridge - remove dmm custom module" Revert "staging: tidspbridge - deprecate reserve/unreserve_memory funtions" Revert "staging: tidspbridge - remove reserved memory clean up" Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct" Revert "staging: tidspbridge - move all iommu related code to a new file" Revert "staging: tidspbridge - remove hw directory" Revert "staging: tidspbridge - fix mmufault support" Revert "staging: tidspbridge - remove custom mmu code from tiomap3430.c" Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name" Revert "staging: tidspbridge - move shared memory iommu maps to tiomap3430.c" Revert "staging: tidspbridge: replace iommu custom for opensource implementation" omap: dsp: remove shm from normal memory Paul Walmsley (4): omap: control: add functions for DSP boot omap: pm: use control functions in DSP reset code omap: dsp: add boot control functions staging: tidspbridge: use boot control functions Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: dsp: remove shm from normal memory
On Fri, Nov 5, 2010 at 8:16 PM, Tony Lindgren wrote: > * Felipe Contreras [101105 10:44]: >> On Fri, Nov 5, 2010 at 6:34 PM, Tony Lindgren wrote: >> > * Felipe Contreras [101019 00:28]: >> >> Also, don't be picky about the location. >> > >> > As this code is in CONFIG_TIDSPBRIDGE block and AFAIK that is >> > not working, this should probably wait for the next merge window? >> >> I plan to send a patch to revert the iommu changes to staging so that >> it does work... But this patch would be needed as well. > > OK. Let's wait and see what your minimal set of fixes to make it > work looks. Huh? Reverting the iommu changes will affect only tidspbridge (staging tree) the omap codes is not affected at all. I say this patch needs to be merged regardless. Anyway, I'm about to send a pull request. -- Felipe Contreras -- 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 6/7] omap: mailbox: fix detection for previously supported chips
On Sun, Nov 7, 2010 at 5:15 PM, Ramirez Luna, Omar wrote: > On Sat, Nov 6, 2010 at 1:11 PM, Cousson, Benoit wrote: >>> -#if defined(CONFIG_ARCH_OMAP3430) >>> +#if defined(CONFIG_ARCH_OMAP3) >> >> Ideally you should get rid of all the CONFIG_ARCH_OMAPXXX or cpu_is_omap in >> that code. This is a driver, it should be generic. >> If you have to handle differences between OMAP version, please do that in >> the devices, not in the driver. >> >> This patch just contains a few of them, but the original mailbox.c file is >> full of that kind of test. >> I know that you are not the original writer of this code, but since the >> clean it, it will be good to remove all the legacy code. > > I mentioned it in the cover-letter, I should have put it here too, my bad. > > > This is meant as a short term solution until proper cleanup is done, > as suggested in: > > http://marc.info/?l=linux-arm-kernel&m=128534253231481&w=2 > > > Does nobody care that the driver is not working right now for some > chips (since it was working before!!) and are willing to wait for more > time until the proper cleanup is done? > > For me it is a hassle, because if I need to do something on 3630 I > have to merge this patch, then apply what I'm working into, then > remove the patch, apply everything again to see no dependencies are > there, then send. Huh? The mailbox is working for me on tidspbridge on 2.6.37-rc1. -- Felipe Contreras -- 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 6/6] omap: iommu: code reorganization and cleanup
On Sat, Nov 6, 2010 at 3:34 AM, Felipe Contreras wrote: > On Sat, Nov 6, 2010 at 3:19 AM, Omar Ramirez Luna wrote: >> Since omap-iommu is now using hwmod, there are structures and >> arrays that can be cleaned up to increase the readability of >> the code. >> >> Signed-off-by: Omar Ramirez Luna > > NAK. Mostly agree, no need to discuss as this is going to change, will keep CONFIG_MPU_BRIDGE_IOMMU. 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 08/12] staging: tidspbridge: convert rmgr to list_head
On Sun, Nov 07, 2010 at 02:11:24PM +0200, Ionut Nicu wrote: > Hi Greg, > > On Sat, 2010-11-06 at 11:26 -0700, Greg KH wrote: > > On Sat, Nov 06, 2010 at 08:18:27PM +0200, Ionut Nicu wrote: > > > Hi Rene, > > > > > > On Fri, 2010-11-05 at 18:07 -0600, Sapiens, Rene wrote: > > > > Hi Ionut, > > > > > > > > On Fri, Nov 5, 2010 at 9:13 AM, Ionut Nicu wrote: > > > > > Convert the rmgr module of the tidspbridge driver > > > > > to use struct list_head instead of struct lst_list. > > > > > > > > > > Signed-off-by: Ionut Nicu > > > > > > > > > > > > > > > > > diff --git a/drivers/staging/tidspbridge/rmgr/drv.c > > > > > b/drivers/staging/tidspbridge/rmgr/drv.c > > > > > > > > > > > > > > > > > @@ -492,16 +465,17 @@ u32 drv_get_next_dev_object(u32 hdev_obj) > > > > >u32 dw_next_dev_object = 0; > > > > >struct drv_object *pdrv_obj; > > > > >struct drv_data *drv_datap = dev_get_drvdata(bridge); > > > > > + struct list_head *curr; > > > > > > > > > >DBC_REQUIRE(hdev_obj != 0); > > > > > > > > can we remove the DBC_REQUIRE and always check for !hdev_obj? > > > > > > > > > > Sounds ok to me. > > > > > > As a general remark, I personally think that the DBC_* macros should be > > > replaced with BUG_ON, WARN_ON, but that's a subject for other patches. > > > What do you think? > > > > They should probably be deleted, I will not add any BUG_ON to a driver, > > nor should anyone else. That's just rude behavior to crash the system, > > don't you think? > > > > You're right. Removing them sounds like a better plan. There over 1000 > DBC_* lines in this driver, so I guess it will clean it up a little bit. > > Just out of curiosity, in what cases is it acceptable to use > BUG_ON/WARN_ON? In a driver, almost never. Use dev_err() and friends instead. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] omap: iommu: code reorganization and cleanup
On Sat, Nov 6, 2010 at 4:28 PM, Cousson, Benoit wrote:
> On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
>>
>> Since omap-iommu is now using hwmod, there are structures and
>> arrays that can be cleaned up to increase the readability of
>> the code.
>
> This patch should be merged with the previous one as well.
No problem.
> I do not see the need to split in 3 patches these changes.
> It will be much readable and will avoid people, like me, doing comment on a
> piece of code you will remove 2 patches later.
> That cleanup must be done when the hwmod is introduced since that code was
> already useless at that time.
Yes, I was trying to avoid mixing changes so the review could be
focused on the replacements only, it seems it backfired.
Will do it in one patch and see how it looks.
>> +static char *omap4_devices[] = {
>> + "ducati",
>> + "tesla",
>> + NULL,
>
> Not needed if you iterate over the class.
Ok.
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 5/6] omap: iommu: hwmod device enable/disable routines
On Sat, Nov 6, 2010 at 4:17 PM, Cousson, Benoit wrote: > You should use runtime PM directly. That omap_device step is useless. > > Moreover, this patch should be merged with the previous one. Agree, will check on runtime PM. 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 4/6] omap: iommu: intial hwmod support
On Sat, Nov 6, 2010 at 4:05 PM, Cousson, Benoit wrote:
>> static struct iommu_device omap3_devices[] = {
>
> You should not need that at all, you are just duplicating the data that are
> already in hwmod, and then you are going to create real platform_device.
ok, will try that.
>> for (i = 0; i< num_iommu_devices; i++) {
>
> Don't do that, just iterate over the hwmod class using
> omap_hwmod_for_each_by_class. Please have a look at the drivers with
> multiple devices that are already using hwmod (i2c, uart...).
And this too.
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] OMAP4: hwmod data: add mmu hwmod for ducati and tesla
On Sat, Nov 6, 2010 at 3:47 PM, Cousson, Benoit wrote:
> On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
>>
>> Add mmu hwmod data for ducati and tesla.
>
> s/ducati/ipu/
> s/tesla/dsp/
>
> Please do not use internal codename.
Tried to avoid confusion with what was originally in the driver, agree
with the change.
> Here again, you completely changed the omap4 existing data for (almost)
> nothing.
>
> I agree, the original code was not considering the mmu as a hwmod but only
> the core of the subsystem: mmu + cache.
>
> But as far as I can see, you just added a new mmu class, a dev_attr, and the
> hwmod remain almost the same.
> Otherwise, you replaced the proper names by the bad one, and you removed
> important data (hw reset for ex).
>
> Please start from the original code and fix what is missing or wrong but do
> not re-write everything.
I wrote this one from scratch, I didn't see that there were pieces to
handle some stuff since the code is buried in a private tree.
I cared to dug up the mailbox one, but completely missed this one.
>> +/* mmu */
>> +
>> +static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
>> + .name = "mmu",
>> +};
>
> That change is OK. The remaining part seems to be completely broken.
>
>> +
>> +/* ducati mmu */
>> +
>> +static struct omap_hwmod omap44xx_ducati_mmu_hwmod;
>> +
>> +static struct omap_hwmod_addr_space omap44xx_ducati_mmu_addrs[] = {
>> + {
>> + .pa_start = OMAP4_MMU1_BASE,
>> + .pa_end = OMAP4_MMU1_BASE + SZ_4K - 1,
>> + .flags = ADDR_TYPE_RT,
>> + },
>> +};
>> +
>> +/* l3_main_1 -> ducati mmu */
>> +static struct omap_hwmod_ocp_if omap44xx_l3_main_1__ducati_mmu = {
>> + .master =&omap44xx_l3_main_1_hwmod,
>> + .slave =&omap44xx_ducati_mmu_hwmod,
>> + .addr = omap44xx_ducati_mmu_addrs,
>> + .clk = "dpll_mpu_m2_ck",
>
> Are you sure of that?
No, this was supposed to be the hwmod main_clk... the ocp_if clk
should be l3_div.
I will add these changes and the ones you mention as "mmu + cache",
and see how it goes from there.
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] OMAP3: hwmod data: Add mmu for iva2 and isp
On Sat, Nov 6, 2010 at 2:15 PM, Cousson, Benoit wrote: > On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: >> >> Add mmu hwmod data for iva2 and isp. > > s/iva2/iva/ Where this terminology can be found? I'm basing this naming on what was there or TRM. For omap3 there is no such thing as iva, it is iva2. I can change it but I just wanted to know. > If you do need the version information, you should use the rev field in the > hwmod class. I don't. > All the comments about the structure fields order I did on your mailbox > series will apply here as well. Same for my comments. 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/6] omap: iommu: remove redundant clock usage
On Sat, Nov 6, 2010 at 2:11 PM, Cousson, Benoit wrote: > On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: >> >> iommu driver is meant to provide control of mmu hardware blocks > > A dot is missing here, and a capital letter should follow. Actually it is a comma, it is meant to be part of the same paragraph. > >> its current users (MMUs) are part of larger subsystems and do not >> have a dedicated clock as the one they use is shared with the >> entire subsystem, it doesn't make sense to enable/disable on each >> register read/write operation as the driver using its interface >> should also be handling the same clock. >> >> iommu should only enable/disable the clock on mmu request/free from >> the driver wanting to use it. > > Mmm, I'm not necessarily convinced by that explanation. > If in a next revision, we change the clock partitioning and provide a > dedicated clock for the mmu, it will not work anymore. > I don't thing you should assume anything about the current partitioning. HW wise, only one clock feeds the mmu, iva2_ck is used to generate three clocks but this inside the IVA2 module. I'm assuming omap4 dsp is the same. ISP also depends on cam_ick (among others), and mmu is inside ISP module afaik. >From what I have checked on omap4 TRM it is the same, mmu doesn't have a direct clock, it relies on the main ipu clock to function, but it is my first glance to omap4 and I might be wrong. > That being said, when you will change that code to switch to runtime PM, you > will end up managing the module state in the ISR context. Mainly this patch was sent on my laziness to add device enable/disable calls on all the parts the code is using clk disable/enable, given that they are not really needed. 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: Mistral AM37x (with AM3715) devel board networking broken
sanjeev, Thanks much for the help. > [sp] On first looks I would suspect the u-boot. 2009.11 seems to be quite old. > Can you try using version 2010.09? I had tried 2010.09 on this board originally but found that it wasn't stable, it was almost like the SDRAM wasn't set up correctly. I'd get random panic's on bad pointers in Linux. But I tried it anyway on this new kernel and it does set up the networking about 1 in 5 boots. Here is a boot where it set up the network http://www.efn.org/~rick/pub/boot4.log, it still has the warnings though. Please check my setup of u-boot, here is what I did: wget ftp://ftp.denx.de/pub/u-boot/u-boot-2010.09.tar.bz2 tar jxf u-boot-2010.09.tar.bz2 cd u-boot-2010.09; make omap3_evm_config; make Is this the correct config (omap3_evm_config) to use for this board? Maybe you could tell me what exact u-boot and kernel you'd recommend and the steps to get them for this board. Thanks, Rick -- 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 support and code reorganization
On Sat, Nov 6, 2010 at 1:31 PM, Cousson, Benoit wrote: > s/ducati/ipu/ > s/tesla/dsp/ > > Please do not use internal codename for the changelog or even for the code. I picked this terminology from the driver, I didn't want to cause confusion, agree to the change. > On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: >> >> Boot tested on omap 3430 and 3630, functionality on iva2 only. >> >> Introduced hwmod data and support for omap3 (iva2 mmu& isp mmu) and >> omap4 (ducati mmu& tesla mmu). >> >> Minor cleanup due to this changes. >> >> There is an issue (present without patches too): >> >> Doing a cycle of insmod-rmmod to iommu module and then full >> insmod of bridgedriver (with all dependencies) causes the next >> read of iommu registers to dump an unhandled fault log; this, >> because when rmmod of iommu is called it tries to clean the >> iommu tables and flush any old entry prior to removing the driver, >> however these reads/writes are attempted while the MMU is under >> reset and will timeout on the L3 IVA target agent, which will leave >> MMU unusable until the proper restore sequence to clear this L3 >> error is executed. >> >> Fix would be to move page table allocation to iommu get and its >> correspondent free to iommu put, however it will fall entirely >> under iommu user responsibility, as it needs to clear the mmu >> reset bit, before calling iommu functions that read/write into >> mmu registers (which should apply only for first boot or on >> baseimage reload); trading this restriction in order to keep >> the same generic iommu code for all omap iommu devices. >> >> This issue has been seen on omap3 iva2 mmu, same restriction should > > I'm still not really understanding that issue. > In theory, the reset is deasserted when the omap_device is enabled and will > be re-asserted when the omap_device will be disable. Probably I'm missing the bits telling hwmod to handle its reset bit, I will recheck. > Why is the mmu already under reset when the iommu is trying to clean the > tables? However, the driver disables the device on a call named iommu_put (where, from your comment, reset should be re-asserted ), and cleans the TLBs and page tables on removal of the driver (after iommu_put). > Could please describe the complete sequence? I'm assuming the dependencies are installed. on boot up: 1. insmod iommu.ko - device_enable is not called, unless a call to iommu_get is given, this will mean that the driver has one user and thus device_enable is called (however right now it doesn't matter if you call iommu_get or not) 2. rmmod iommu.ko - remove function will try to cleanup the TLBs writing into MMU registers, since MMU is on reset it will trigger a timeout on its TA. 3. insmod bridgedriver.ko - it is dependent on iommu.ko so it should have been installed before. Whenever bridge calls iommu_get, the external abort will be caused due to a read to MMU. As I commented, cleaning the page tables could be moved from driver's remove function to iommu_put, if omap device enable/disable is handling the reset bit probably this issue shouldn't be hit. 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/7] omap: mailbox: hwmod support and dependent cleanup patches
On Sat, Nov 6, 2010 at 1:32 PM, Cousson, Benoit wrote: > On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote: > Could you please try to use a consistent naming in the subject? > You use OMAP3, OMAP4, OMAP2 so it should be OMAP and not omap. Yes, I'll change it. 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/7] omap: mailbox: remove unreachable return
On Sat, Nov 6, 2010 at 1:21 PM, Cousson, Benoit wrote: > On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote: >> >> Remove unreachable return statement. >> >> Signed-off-by: Omar Ramirez Luna >> --- >> arch/arm/mach-omap2/mailbox.c | 2 -- >> 1 files changed, 0 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c >> index 5e9ea0f..335eb2b 100644 >> --- a/arch/arm/mach-omap2/mailbox.c >> +++ b/arch/arm/mach-omap2/mailbox.c >> @@ -434,8 +434,6 @@ static int __devinit omap2_mbox_probe(struct >> platform_device *pdev) >> return ret; >> } > > Please add a blank line here. ok... > > Otherwise you can add: Acked-by: Benoit Cousson 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 6/7] omap: mailbox: fix detection for previously supported chips
On Sat, Nov 6, 2010 at 1:11 PM, Cousson, Benoit wrote: >> -#if defined(CONFIG_ARCH_OMAP3430) >> +#if defined(CONFIG_ARCH_OMAP3) > > Ideally you should get rid of all the CONFIG_ARCH_OMAPXXX or cpu_is_omap in > that code. This is a driver, it should be generic. > If you have to handle differences between OMAP version, please do that in > the devices, not in the driver. > > This patch just contains a few of them, but the original mailbox.c file is > full of that kind of test. > I know that you are not the original writer of this code, but since the > clean it, it will be good to remove all the legacy code. I mentioned it in the cover-letter, I should have put it here too, my bad. This is meant as a short term solution until proper cleanup is done, as suggested in: http://marc.info/?l=linux-arm-kernel&m=128534253231481&w=2 Does nobody care that the driver is not working right now for some chips (since it was working before!!) and are willing to wait for more time until the proper cleanup is done? For me it is a hassle, because if I need to do something on 3630 I have to merge this patch, then apply what I'm working into, then remove the patch, apply everything again to see no dependencies are there, then send. 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 3/7] OMAP4: hwmod data: add mailbox data
On Sat, Nov 6, 2010 at 12:18 PM, Cousson, Benoit wrote:
> I don't know why, but this patch has nothing to do with my original one.
> Can you stick to the original code?
no, apart from the ordering of structure members, that I will change,
since keeping the order of the original structure doesn't fly, I don't
see anything that needs to be changed.
- The magic numbers replaced for the defines, afaik it gives more clarity.
- mailbox irq has a name.
- overall defining block was improved:
class
ocp_if
slave ports
hwmod
If you see, each dependent reference is right before the structure
that is using it, which at least to me establishes some order, as of
today this ordering doesn't exists.
e.g. you are defining some hwmod and some how you are populating all
the members, if you are looking at your omap_hwmod struct and want to
see the irqs defined you need to scroll beyond the supposed first
reference in omap_hwmod (right now above ocp_if)
>
> On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote:
>> +/* mailbox */
>
> The original comment is missing.
/*
* 'mailbox' class
* mailbox module allowing communication between the on-chip processors
* useusing a queued mailbox-interrupt mechanism.
*/
I don't think it adds anything to the patch, should we start
commenting on the functionality of the drivers for each hwmod?
>> +
>> +static struct omap_hwmod omap44xx_mailbox_hwmod;
>> +
>> +static struct omap_hwmod_addr_space omap44xx_mailbox_addrs[] = {
>> + {
>> + .pa_start = OMAP44XX_MAILBOX_BASE,
>
> If that physical address is not used elsewhere, and it should be the case,
> there is no need to create a define for it. That's why the physical address
> was directly used here.
> There is no added value to create a define for that.
yes there is, apart from readability where '0x4a0f4000' doesn't say much
for me at least, if reviewing I need to open the TRM check if that is
the address and move on, with the define you know that someone have
checked the address before (when creating the define)
besides the define was already there
>> +static struct omap_hwmod omap44xx_mailbox_hwmod = {
>> + .name = "mailbox",
>> + .class =&omap44xx_mailbox_hwmod_class,
>> + .prcm = {
>> + .omap4 = {
>> + .clkctrl_reg = OMAP4430_CM_L4CFG_MAILBOX_CLKCTRL,
>> + },
>> + },
>> + .mpu_irqs = omap44xx_mailbox_irqs,
>> + .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mailbox_irqs),
>
> The order is different than the previous one.
as the order is given by omap4 data, and not the definition of the
structure, I'll keep the consistency with omap4 then.
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 1/7] OMAP2: hwmod data: add mailbox data
Hi Benoit,
On Sat, Nov 6, 2010 at 12:08 PM, Cousson, Benoit wrote:
>> +/* l4_core -> mailbox */
>> +static struct omap_hwmod_ocp_if omap2420_l4_core__mailbox = {
>> + .master =&omap2420_l4_core_hwmod,
>> + .slave =&omap2420_mailbox_hwmod,
>> + .addr = omap2420_mailbox_addrs,
>> + .clk = "mailboxes_ick",
>
> Could you try to be consistent with the omap4 format? it is easier to diff
> between Soc version: .clk is before .addr
In all the randomness of how the data files look, I didn't now omap4
was the standard. For this one, I tried to follow the
"omap_hwmod_ocp_if" structure definition where 'clk' is the 4th member
of that structure.
I'll change it to mimic omap4 looks...
>> +static struct omap_hwmod omap2420_mailbox_hwmod = {
>> + .name = "mailbox",
>> + .class =&omap2420_mailbox_hwmod_class,
>> + .prcm = {
>> + .omap2 = {
>> + .prcm_reg_id = 1,
>> + .module_bit = OMAP24XX_EN_MAILBOXES_SHIFT,
>> + .module_offs = CORE_MOD,
>> + .idlest_reg_id = 1,
>> + .idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
>> + },
>> + },
>
> Same things with the format, put that after irqs_cnt and before slaves.
more or less the same, since 'prcm' was above in the definition order
I kept it a bit up of where it is supposed to be.
I'll change it too
>> @@ -569,6 +635,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[]
>> = {
>> &omap2420_uart3_hwmod,
>> &omap2420_i2c1_hwmod,
>> &omap2420_i2c2_hwmod,
>
> Add a blank line between each class. OK it was not done for i2c, but it
> should.
>
> All the comments are applicable to the 2430 and 3430 data as well.
Will do.
Thanks for your 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 v2 08/12] staging: tidspbridge: convert rmgr to list_head
Ionut Nicu wrote, on 11/07/2010 06:11 AM: Just out of curiosity, in what cases is it acceptable to use BUG_ON/WARN_ON? here is my rule for BUG_ON Vs WARN_ON: imagine this code to be running on your Phone while you are doing sometime important, and this case gets hit - choose: a) you stop the entire phone - BUG_ON b) provide a cryptic info - WARN_ON - just the func name with not much additional data c) provide detailed info : in the order of my personal preference: dev_dbg/dev_info/dev_err/... -> if there is anychange of getting to the struct device * representing the device pr_err/pr_info/pr_warning -> if there is no other alternative keep in mind - few months from now, code would change, function line numbers change etc.. - I'd usually NOT TOUCH BUG_ON, NOT use WARN_ON unless I am threatened by maintainer, and choose one of (c) based on the location in the code I am at.. I know that some folks think that when a case is reached, they'd like to do a BUG_ON so that the issue is caught and fixed immediately - SORRY, I disagree as I see the code running in a endproduct - and BUG_ONs cause system hang and reboots in an end product - which as a personal user of a great Linux phone like N900 is definitely not my personal preference. -- Regards, Nishanth Menon -- 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 07/12] staging: tidspbridge: convert pmgr to list_head
Hi Rene,
On Fri, 2010-11-05 at 16:41 -0600, Sapiens, Rene wrote:
> Hi Ionut,
>
> On Fri, Nov 5, 2010 at 9:13 AM, Ionut Nicu wrote:
> > Convert the pmgr module of the tidspbridge driver
> > to use struct list_head instead of struct lst_list.
>
>
>
> > + * Memory is coalesced back to the appropriate heap when a buffer is
>
> What is being fixed here?
>
It was a typo (s/coelesced/coalesced/).
> > * freed.
> > *
> > * Notes:
>
>
>
> > @@ -833,67 +768,44 @@ static void add_to_free_list(struct cmm_allocator
> > *allocator,
> >DBC_REQUIRE(allocator != NULL);
> >dw_this_pa = pnode->dw_pa;
> >dw_next_pa = NEXT_PA(pnode);
>
> i think it would be good to return with error if !allocator or !pnode
> and remove theresulting duplicated DBC_REQUIRE.
>
Yeah I think pnode should be checked for null. Can allocator ever be
null?
> > - mnode_obj = (struct cmm_mnode
> > *)lst_first(allocator->free_list_head);
> > - while (mnode_obj) {
> > + list_for_each_entry(mnode_obj, &allocator->free_list, link) {
> >if (dw_this_pa == NEXT_PA(mnode_obj)) {
>
>
>
> > @@ -748,18 +736,16 @@ bool dev_init(void)
> > */
> > int dev_notify_clients(struct dev_object *hdev_obj, u32 ret)
> > {
> > - int status = 0;
> > -
> >struct dev_object *dev_obj = hdev_obj;
> > - void *proc_obj;
> > + struct list_head *curr;
>
> can we add a check for !dev_obj and !dev_obj->proc_list just to be
> sure that we get always the correct pointer?
>
proc_list isn't a pointer. Can dev_obj ever be null?
>
>
> > @@ -947,15 +933,17 @@ int dev_insert_proc_object(struct dev_object
> > *hdev_obj,
> >DBC_REQUIRE(refs > 0);
> >DBC_REQUIRE(dev_obj);
> >DBC_REQUIRE(proc_obj != 0);
> > - DBC_REQUIRE(dev_obj->proc_list != NULL);
> >DBC_REQUIRE(already_attached != NULL);
>
> can we check for !hdev_obj, !already_attached even if we have the
> DBC_REQUIRE?, maybe we can actually remove the DBC_REQUIRE that could
> be redundant after applying this.
>
Same question here.
> > - if (!LST_IS_EMPTY(dev_obj->proc_list))
> > + if (!list_empty(&dev_obj->proc_list))
> >*already_attached = true;
>
>
>
> > @@ -986,15 +974,12 @@ int dev_remove_proc_object(struct dev_object
> > *hdev_obj, u32 proc_obj)
> >
> >DBC_REQUIRE(dev_obj);
> >DBC_REQUIRE(proc_obj != 0);
> > - DBC_REQUIRE(dev_obj->proc_list != NULL);
> > - DBC_REQUIRE(!LST_IS_EMPTY(dev_obj->proc_list));
> > + DBC_REQUIRE(!list_empty(&dev_obj->proc_list));
> >
>
> The same comment as above.
>
Regards,
Ionut.
--
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 08/12] staging: tidspbridge: convert rmgr to list_head
Hi Greg, On Sat, 2010-11-06 at 11:26 -0700, Greg KH wrote: > On Sat, Nov 06, 2010 at 08:18:27PM +0200, Ionut Nicu wrote: > > Hi Rene, > > > > On Fri, 2010-11-05 at 18:07 -0600, Sapiens, Rene wrote: > > > Hi Ionut, > > > > > > On Fri, Nov 5, 2010 at 9:13 AM, Ionut Nicu wrote: > > > > Convert the rmgr module of the tidspbridge driver > > > > to use struct list_head instead of struct lst_list. > > > > > > > > Signed-off-by: Ionut Nicu > > > > > > > > > > > > > diff --git a/drivers/staging/tidspbridge/rmgr/drv.c > > > > b/drivers/staging/tidspbridge/rmgr/drv.c > > > > > > > > > > > > > @@ -492,16 +465,17 @@ u32 drv_get_next_dev_object(u32 hdev_obj) > > > >u32 dw_next_dev_object = 0; > > > >struct drv_object *pdrv_obj; > > > >struct drv_data *drv_datap = dev_get_drvdata(bridge); > > > > + struct list_head *curr; > > > > > > > >DBC_REQUIRE(hdev_obj != 0); > > > > > > can we remove the DBC_REQUIRE and always check for !hdev_obj? > > > > > > > Sounds ok to me. > > > > As a general remark, I personally think that the DBC_* macros should be > > replaced with BUG_ON, WARN_ON, but that's a subject for other patches. > > What do you think? > > They should probably be deleted, I will not add any BUG_ON to a driver, > nor should anyone else. That's just rude behavior to crash the system, > don't you think? > You're right. Removing them sounds like a better plan. There over 1000 DBC_* lines in this driver, so I guess it will clean it up a little bit. Just out of curiosity, in what cases is it acceptable to use BUG_ON/WARN_ON? Thanks, Ionut. -- 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
UbiFS + HWECC(?) + BeagleBoard = fail
Hi. After moving to upstream 2.6.3{5,6,7} kernels, i forced to use jffs2
instead of ubifs, because of lot CRC errors. If i use prefetch/dma, i
can attach to ubi, make volume, write data, reboot - and got lots of CRC
errors. Without prefetch i just couldn't do anything to ubi.
Looks like hw/sw bug in ubi
--
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
[no subject]
subscribe linux-omap -- 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
