* [PATCH 1/2] omap: add dsp platform device
2010-10-04 16:09 [PATCH 0/2] omap: dsp: make the driver actually work Felipe Contreras
@ 2010-10-04 16:09 ` Felipe Contreras
2010-10-05 15:56 ` Greg KH
2010-10-04 16:09 ` [PATCH 2/2] staging: tidspbridge: use omap_dsp_platform_data Felipe Contreras
2010-10-05 19:07 ` [PATCH 0/2] omap: dsp: make the driver actually work Greg KH
2 siblings, 1 reply; 13+ messages in thread
From: Felipe Contreras @ 2010-10-04 16:09 UTC (permalink / raw)
To: linux-omap, linux-main
Cc: Greg KH, Ohad Ben-Cohen, Tony Lindgren, Omar Ramirez Luna,
Hiroshi Doyu, Felipe Contreras
Otherwise tidspbridge cannot work.
It looks like this was dropped in the conversion to staging. I took the
liberty of doing some cleaning up.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
arch/arm/mach-omap2/Makefile | 4 ++
arch/arm/mach-omap2/dsp.c | 85 +++++++++++++++++++++++++++++++++
arch/arm/plat-omap/common.c | 2 +
arch/arm/plat-omap/devices.c | 30 ++++++++++++
arch/arm/plat-omap/include/plat/dsp.h | 31 ++++++++++++
5 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/dsp.c
create mode 100644 arch/arm/plat-omap/include/plat/dsp.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..58288a4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -102,6 +102,10 @@ obj-y += $(iommu-m) $(iommu-y)
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-y)
+ifneq ($(CONFIG_TIDSPBRIDGE),)
+obj-y += dsp.o
+endif
+
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
new file mode 100644
index 0000000..6feeeae
--- /dev/null
+++ b/arch/arm/mach-omap2/dsp.c
@@ -0,0 +1,85 @@
+/*
+ * TI's OMAP DSP platform device registration
+ *
+ * Copyright (C) 2005-2006 Texas Instruments, Inc.
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU <Hiroshi.DOYU@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.
+ */
+
+#include <linux/platform_device.h>
+#include "prm.h"
+#include "cm.h"
+#ifdef CONFIG_BRIDGE_DVFS
+#include <plat/omap-pm.h>
+#endif
+
+#include <plat/dsp.h>
+
+extern phys_addr_t omap_dsp_get_mempool_base(void);
+
+static struct platform_device *omap_dsp_pdev;
+
+static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
+#ifdef CONFIG_BRIDGE_DVFS
+ .dsp_set_min_opp = omap_pm_dsp_set_min_opp,
+ .dsp_get_opp = omap_pm_dsp_get_opp,
+ .cpu_set_freq = omap_pm_cpu_set_freq,
+ .cpu_get_freq = omap_pm_cpu_get_freq,
+#endif
+ .dsp_prm_read = prm_read_mod_reg,
+ .dsp_prm_write = prm_write_mod_reg,
+ .dsp_prm_rmw_bits = prm_rmw_mod_reg_bits,
+ .dsp_cm_read = cm_read_mod_reg,
+ .dsp_cm_write = cm_write_mod_reg,
+ .dsp_cm_rmw_bits = cm_rmw_mod_reg_bits,
+};
+
+static int __init omap_dsp_init(void)
+{
+ struct platform_device *pdev;
+ int err = -ENOMEM;
+ struct omap_dsp_platform_data *pdata = &omap_dsp_pdata;
+
+ pdata->phys_mempool_base = omap_dsp_get_mempool_base();
+
+ if (pdata->phys_mempool_base) {
+ pdata->phys_mempool_size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+ pr_info("%s: %x bytes @ %x\n", __func__,
+ pdata->phys_mempool_size, pdata->phys_mempool_base);
+ }
+
+ pdev = platform_device_alloc("omap-dsp", -1);
+ if (!pdev)
+ goto err_out;
+
+ err = platform_device_add_data(pdev, pdata, sizeof(*pdata));
+ if (err)
+ goto err_out;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+
+ omap_dsp_pdev = pdev;
+ return 0;
+
+err_out:
+ platform_device_put(pdev);
+ return err;
+}
+module_init(omap_dsp_init);
+
+static void __exit omap_dsp_exit(void)
+{
+ platform_device_unregister(omap_dsp_pdev);
+}
+module_exit(omap_dsp_exit);
+
+MODULE_AUTHOR("Hiroshi DOYU");
+MODULE_DESCRIPTION("TI's OMAP DSP platform device registration");
+MODULE_LICENSE("GPL");
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 3008e71..57205a4 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -37,6 +37,7 @@
#include <plat/fpga.h>
#include <plat/serial.h>
#include <plat/vram.h>
+#include <plat/dsp.h>
#include <plat/clock.h>
@@ -87,6 +88,7 @@ void __init omap_reserve(void)
{
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
+ omap_dsp_reserve_sdram_memblock();
}
/*
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index d1920be..4c8f9b9 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -15,6 +15,7 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/slab.h>
+#include <linux/memblock.h>
#include <mach/hardware.h>
#include <asm/mach-types.h>
@@ -272,6 +273,35 @@ static void omap_init_wdt(void)
static inline void omap_init_wdt(void) {}
#endif
+#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
+
+static phys_addr_t omap_dsp_phys_mempool_base;
+
+void __init omap_dsp_reserve_sdram_memblock(void)
+{
+ phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+ phys_addr_t paddr;
+
+ if (!size)
+ return;
+
+ paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
+ if (!paddr) {
+ pr_err("%s: failed to reserve %x bytes\n",
+ __func__, size);
+ return;
+ }
+
+ omap_dsp_phys_mempool_base = paddr;
+}
+
+phys_addr_t omap_dsp_get_mempool_base(void)
+{
+ return omap_dsp_phys_mempool_base;
+}
+EXPORT_SYMBOL(omap_dsp_get_mempool_base);
+#endif
+
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
diff --git a/arch/arm/plat-omap/include/plat/dsp.h b/arch/arm/plat-omap/include/plat/dsp.h
new file mode 100644
index 0000000..9c604b3
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/dsp.h
@@ -0,0 +1,31 @@
+#ifndef __OMAP_DSP_H__
+#define __OMAP_DSP_H__
+
+#include <linux/types.h>
+
+struct omap_dsp_platform_data {
+ void (*dsp_set_min_opp) (u8 opp_id);
+ u8 (*dsp_get_opp) (void);
+ void (*cpu_set_freq) (unsigned long f);
+ unsigned long (*cpu_get_freq) (void);
+ unsigned long mpu_speed[6];
+
+ /* functions to write and read PRCM registers */
+ void (*dsp_prm_write)(u32, s16 , u16);
+ u32 (*dsp_prm_read)(s16 , u16);
+ u32 (*dsp_prm_rmw_bits)(u32, u32, s16, s16);
+ void (*dsp_cm_write)(u32, s16 , u16);
+ u32 (*dsp_cm_read)(s16 , u16);
+ u32 (*dsp_cm_rmw_bits)(u32, u32, s16, s16);
+
+ phys_addr_t phys_mempool_base;
+ phys_addr_t phys_mempool_size;
+};
+
+#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
+extern void omap_dsp_reserve_sdram_memblock(void);
+#else
+static inline void omap_dsp_reserve_sdram_memblock(void) { }
+#endif
+
+#endif
--
1.7.3.1.2.g7fe2b
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 1/2] omap: add dsp platform device
2010-10-04 16:09 ` [PATCH 1/2] omap: add dsp platform device Felipe Contreras
@ 2010-10-05 15:56 ` Greg KH
2010-10-05 16:28 ` Tony Lindgren
0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2010-10-05 15:56 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Omar Ramirez Luna, Hiroshi Doyu
On Mon, Oct 04, 2010 at 07:09:14PM +0300, Felipe Contreras wrote:
> Otherwise tidspbridge cannot work.
>
> It looks like this was dropped in the conversion to staging. I took the
> liberty of doing some cleaning up.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> arch/arm/mach-omap2/Makefile | 4 ++
> arch/arm/mach-omap2/dsp.c | 85 +++++++++++++++++++++++++++++++++
> arch/arm/plat-omap/common.c | 2 +
> arch/arm/plat-omap/devices.c | 30 ++++++++++++
> arch/arm/plat-omap/include/plat/dsp.h | 31 ++++++++++++
I need an ack from some omap maintainers before I can take this into the
staging tree.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] omap: add dsp platform device
2010-10-05 15:56 ` Greg KH
@ 2010-10-05 16:28 ` Tony Lindgren
2010-10-05 19:04 ` Greg KH
0 siblings, 1 reply; 13+ messages in thread
From: Tony Lindgren @ 2010-10-05 16:28 UTC (permalink / raw)
To: Greg KH
Cc: Felipe Contreras, linux-omap, linux-main, Ohad Ben-Cohen,
Omar Ramirez Luna, Hiroshi Doyu
* Greg KH <greg@kroah.com> [101005 09:01]:
> On Mon, Oct 04, 2010 at 07:09:14PM +0300, Felipe Contreras wrote:
> > Otherwise tidspbridge cannot work.
> >
> > It looks like this was dropped in the conversion to staging. I took the
> > liberty of doing some cleaning up.
> >
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> > arch/arm/mach-omap2/Makefile | 4 ++
> > arch/arm/mach-omap2/dsp.c | 85 +++++++++++++++++++++++++++++++++
> > arch/arm/plat-omap/common.c | 2 +
> > arch/arm/plat-omap/devices.c | 30 ++++++++++++
> > arch/arm/plat-omap/include/plat/dsp.h | 31 ++++++++++++
>
> I need an ack from some omap maintainers before I can take this into the
> staging tree.
Looks good to me
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] omap: add dsp platform device
2010-10-05 16:28 ` Tony Lindgren
@ 2010-10-05 19:04 ` Greg KH
0 siblings, 0 replies; 13+ messages in thread
From: Greg KH @ 2010-10-05 19:04 UTC (permalink / raw)
To: Tony Lindgren
Cc: Felipe Contreras, linux-omap, linux-main, Ohad Ben-Cohen,
Omar Ramirez Luna, Hiroshi Doyu
On Tue, Oct 05, 2010 at 09:28:30AM -0700, Tony Lindgren wrote:
> * Greg KH <greg@kroah.com> [101005 09:01]:
> > On Mon, Oct 04, 2010 at 07:09:14PM +0300, Felipe Contreras wrote:
> > > Otherwise tidspbridge cannot work.
> > >
> > > It looks like this was dropped in the conversion to staging. I took the
> > > liberty of doing some cleaning up.
> > >
> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > > ---
> > > arch/arm/mach-omap2/Makefile | 4 ++
> > > arch/arm/mach-omap2/dsp.c | 85 +++++++++++++++++++++++++++++++++
> > > arch/arm/plat-omap/common.c | 2 +
> > > arch/arm/plat-omap/devices.c | 30 ++++++++++++
> > > arch/arm/plat-omap/include/plat/dsp.h | 31 ++++++++++++
> >
> > I need an ack from some omap maintainers before I can take this into the
> > staging tree.
>
> Looks good to me
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Thanks, I'll go queue it up now.
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2/2] staging: tidspbridge: use omap_dsp_platform_data
2010-10-04 16:09 [PATCH 0/2] omap: dsp: make the driver actually work Felipe Contreras
2010-10-04 16:09 ` [PATCH 1/2] omap: add dsp platform device Felipe Contreras
@ 2010-10-04 16:09 ` Felipe Contreras
2010-10-05 19:07 ` [PATCH 0/2] omap: dsp: make the driver actually work Greg KH
2 siblings, 0 replies; 13+ messages in thread
From: Felipe Contreras @ 2010-10-04 16:09 UTC (permalink / raw)
To: linux-omap, linux-main
Cc: Greg KH, Ohad Ben-Cohen, Tony Lindgren, Omar Ramirez Luna,
Hiroshi Doyu, Felipe Contreras
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
drivers/staging/tidspbridge/core/tiomap3430.c | 14 ++++++++------
drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 14 ++++++++------
drivers/staging/tidspbridge/core/tiomap_io.c | 4 +++-
.../tidspbridge/include/dspbridge/host_os.h | 19 -------------------
drivers/staging/tidspbridge/rmgr/drv_interface.c | 10 ++++++----
5 files changed, 25 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c
index f914829..5aefc95 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -16,6 +16,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
+#include <plat/dsp.h>
+
#include <linux/types.h>
/* ----------------------------------- Host OS */
#include <dspbridge/host_os.h>
@@ -264,8 +266,8 @@ static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt)
{
struct bridge_dev_context *dev_context = dev_ctxt;
u32 temp;
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata =
+ omap_dspbridge_dev->dev.platform_data;
temp = (*pdata->dsp_prm_read)(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST) &
OMAP_POWERSTATEST_MASK;
@@ -374,8 +376,8 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
u32 clk_cmd;
struct io_mgr *hio_mgr;
u32 ul_load_monitor_timer;
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata =
+ omap_dspbridge_dev->dev.platform_data;
/* The device context contains all the mmu setup info from when the
* last dsp base image was loaded. The first entry is always
@@ -627,8 +629,8 @@ static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt)
struct pg_table_attrs *pt_attrs;
u32 dsp_pwr_state;
int clk_status;
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata =
+ omap_dspbridge_dev->dev.platform_data;
if (dev_context->dw_brd_state == BRD_STOPPED)
return status;
diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
index b789f8f..1bea23f 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
@@ -16,6 +16,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
+#include <plat/dsp.h>
+
/* ----------------------------------- DSP/BIOS Bridge */
#include <dspbridge/dbdefs.h>
#include <dspbridge/cfg.h>
@@ -54,8 +56,8 @@ int handle_constraints_set(struct bridge_dev_context *dev_context,
{
#ifdef CONFIG_TIDSPBRIDGE_DVFS
u32 *constraint_val;
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata =
+ omap_dspbridge_dev->dev.platform_data;
constraint_val = (u32 *) (pargs);
/* Read the target value requested by DSP */
@@ -83,8 +85,8 @@ int handle_hibernation_from_dsp(struct bridge_dev_context *dev_context)
u32 opplevel;
struct io_mgr *hio_mgr;
#endif
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata =
+ omap_dspbridge_dev->dev.platform_data;
pwr_state = (*pdata->dsp_prm_read)(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST) &
OMAP_POWERSTATEST_MASK;
@@ -152,8 +154,8 @@ int sleep_dsp(struct bridge_dev_context *dev_context, u32 dw_cmd,
#endif /* CONFIG_TIDSPBRIDGE_NTFY_PWRERR */
u16 timeout = PWRSTST_TIMEOUT / 10;
u32 pwr_state, target_pwr_state;
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata =
+ omap_dspbridge_dev->dev.platform_data;
/* Check if sleep code is valid */
if ((dw_cmd != PWR_DEEPSLEEP) && (dw_cmd != PWR_EMERGENCYDEEPSLEEP))
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c b/drivers/staging/tidspbridge/core/tiomap_io.c
index 190c028..2a3cd45 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -16,6 +16,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
+#include <plat/dsp.h>
+
/* ----------------------------------- DSP/BIOS Bridge */
#include <dspbridge/dbdefs.h>
@@ -388,7 +390,7 @@ int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val)
#ifdef CONFIG_TIDSPBRIDGE_DVFS
u32 opplevel = 0;
#endif
- struct dspbridge_platform_data *pdata =
+ struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev->dev.platform_data;
struct cfg_hostres *resources = dev_context->resources;
int status = 0;
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index 6b4feb4..6549898 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -52,25 +52,6 @@
/* TODO -- Remove, once BP defines them */
#define INT_DSP_MMU_IRQ 28
-struct dspbridge_platform_data {
- void (*dsp_set_min_opp) (u8 opp_id);
- u8(*dsp_get_opp) (void);
- void (*cpu_set_freq) (unsigned long f);
- unsigned long (*cpu_get_freq) (void);
- unsigned long mpu_speed[6];
-
- /* functions to write and read PRCM registers */
- void (*dsp_prm_write)(u32, s16 , u16);
- u32 (*dsp_prm_read)(s16 , u16);
- u32 (*dsp_prm_rmw_bits)(u32, u32, s16, s16);
- void (*dsp_cm_write)(u32, s16 , u16);
- u32 (*dsp_cm_read)(s16 , u16);
- u32 (*dsp_cm_rmw_bits)(u32, u32, s16, s16);
-
- u32 phys_mempool_base;
- u32 phys_mempool_size;
-};
-
#define PRCM_VDD1 1
extern struct platform_device *omap_dspbridge_dev;
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c b/drivers/staging/tidspbridge/rmgr/drv_interface.c
index 7ee8949..b5b3a08 100644
--- a/drivers/staging/tidspbridge/rmgr/drv_interface.c
+++ b/drivers/staging/tidspbridge/rmgr/drv_interface.c
@@ -18,6 +18,8 @@
/* ----------------------------------- Host OS */
+#include <plat/dsp.h>
+
#include <dspbridge/host_os.h>
#include <linux/types.h>
#include <linux/platform_device.h>
@@ -171,7 +173,7 @@ const struct omap_opp vdd1_rate_table_bridge[] = {
#endif
#endif
-struct dspbridge_platform_data *omap_dspbridge_pdata;
+struct omap_dsp_platform_data *omap_dspbridge_pdata;
u32 vdd1_dsp_freq[6][4] = {
{0, 0, 0, 0},
@@ -218,8 +220,8 @@ void bridge_recover_schedule(void)
static int dspbridge_scale_notification(struct notifier_block *op,
unsigned long val, void *ptr)
{
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata =
+ omap_dspbridge_dev->dev.platform_data;
if (CPUFREQ_POSTCHANGE == val && pdata->dsp_get_opp)
pwr_pm_post_scale(PRCM_VDD1, pdata->dsp_get_opp());
@@ -242,7 +244,7 @@ static struct notifier_block iva_clk_notifier = {
*/
static int omap3_bridge_startup(struct platform_device *pdev)
{
- struct dspbridge_platform_data *pdata = pdev->dev.platform_data;
+ struct omap_dsp_platform_data *pdata = pdev->dev.platform_data;
struct drv_data *drv_datap = NULL;
u32 phys_membase, phys_memsize;
int err;
--
1.7.3.1.2.g7fe2b
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 0/2] omap: dsp: make the driver actually work
2010-10-04 16:09 [PATCH 0/2] omap: dsp: make the driver actually work Felipe Contreras
2010-10-04 16:09 ` [PATCH 1/2] omap: add dsp platform device Felipe Contreras
2010-10-04 16:09 ` [PATCH 2/2] staging: tidspbridge: use omap_dsp_platform_data Felipe Contreras
@ 2010-10-05 19:07 ` Greg KH
2010-10-05 19:23 ` Felipe Contreras
2 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2010-10-05 19:07 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Omar Ramirez Luna, Hiroshi Doyu
On Mon, Oct 04, 2010 at 07:09:13PM +0300, Felipe Contreras wrote:
> Hi,
>
> It seems the platform device was dropped from the migration of tidspbridge into
> staging, plus the sdram meblock (previously bootmem) required for it work are
> gone.
>
> Withouth these patches the driver loads, but doesn't do anything.
>
> A second issue with ioremap() still remains, but that can be solved by
> reverting 309caa9.
>
> I think these might be worth to get into 2.6.36, if not, I have versions with
> more changes; cleanups and so on.
I've applied this to my staging-next tree, for .37, as it's not a big
deal for .36.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/2] omap: dsp: make the driver actually work
2010-10-05 19:07 ` [PATCH 0/2] omap: dsp: make the driver actually work Greg KH
@ 2010-10-05 19:23 ` Felipe Contreras
2010-10-05 19:52 ` Ramirez Luna, Omar
0 siblings, 1 reply; 13+ messages in thread
From: Felipe Contreras @ 2010-10-05 19:23 UTC (permalink / raw)
To: Greg KH
Cc: linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Omar Ramirez Luna, Hiroshi Doyu
On Tue, Oct 5, 2010 at 10:07 PM, Greg KH <greg@kroah.com> wrote:
> On Mon, Oct 04, 2010 at 07:09:13PM +0300, Felipe Contreras wrote:
>> It seems the platform device was dropped from the migration of tidspbridge into
>> staging, plus the sdram meblock (previously bootmem) required for it work are
>> gone.
>>
>> Withouth these patches the driver loads, but doesn't do anything.
>>
>> A second issue with ioremap() still remains, but that can be solved by
>> reverting 309caa9.
>>
>> I think these might be worth to get into 2.6.36, if not, I have versions with
>> more changes; cleanups and so on.
>
> I've applied this to my staging-next tree, for .37, as it's not a big
> deal for .36.
Well, I thought it would be nice if the driver actually worked on .36,
but anyway, I'll rebase the rest of my cleanup patches and send them.
Hopefully I find a way to get rid of the ioremap() issue.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH 0/2] omap: dsp: make the driver actually work
2010-10-05 19:23 ` Felipe Contreras
@ 2010-10-05 19:52 ` Ramirez Luna, Omar
2010-10-05 20:02 ` Felipe Contreras
0 siblings, 1 reply; 13+ messages in thread
From: Ramirez Luna, Omar @ 2010-10-05 19:52 UTC (permalink / raw)
To: Felipe Contreras, Greg KH
Cc: linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Hiroshi Doyu
Felipe Contreras wrote:
...
>
> Well, I thought it would be nice if the driver actually worked on
> .36, but anyway, I'll rebase the rest of my cleanup patches and send
> them. Hopefully I find a way to get rid of the ioremap() issue.
>
phys_to_virt instead of ioremap should work fine, still need to try it though.
Regards,
omar
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/2] omap: dsp: make the driver actually work
2010-10-05 19:52 ` Ramirez Luna, Omar
@ 2010-10-05 20:02 ` Felipe Contreras
2010-10-05 20:09 ` Ramirez Luna, Omar
0 siblings, 1 reply; 13+ messages in thread
From: Felipe Contreras @ 2010-10-05 20:02 UTC (permalink / raw)
To: Ramirez Luna, Omar
Cc: Greg KH, linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Hiroshi Doyu
On Tue, Oct 5, 2010 at 10:52 PM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
> Felipe Contreras wrote:
> ...
>>
>> Well, I thought it would be nice if the driver actually worked on
>> .36, but anyway, I'll rebase the rest of my cleanup patches and send
>> them. Hopefully I find a way to get rid of the ioremap() issue.
>>
>
> phys_to_virt instead of ioremap should work fine, still need to try it though.
I tried that... Didn't work. I guess we need to flush at some points
(since the memory is cacheable).
--
Felipe Contreras
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH 0/2] omap: dsp: make the driver actually work
2010-10-05 20:02 ` Felipe Contreras
@ 2010-10-05 20:09 ` Ramirez Luna, Omar
2010-10-05 21:05 ` Felipe Contreras
0 siblings, 1 reply; 13+ messages in thread
From: Ramirez Luna, Omar @ 2010-10-05 20:09 UTC (permalink / raw)
To: Felipe Contreras
Cc: Greg KH, linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Hiroshi Doyu
Felipe Contreras wrote:
...
>>
>> phys_to_virt instead of ioremap should work fine, still need to try
>> it though.
>
> I tried that... Didn't work. I guess we need to flush at some points
> (since the memory is cacheable).
Hmmm, because my other option was to move the reserved memory outside the kernel, but that involves specifying bootargs again and using dma_alloc_coherent with their restrictions.
If you are working on a different method and need any help let me know.
Regards,
Omar
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/2] omap: dsp: make the driver actually work
2010-10-05 20:09 ` Ramirez Luna, Omar
@ 2010-10-05 21:05 ` Felipe Contreras
2010-10-07 1:32 ` Omar Ramirez Luna
0 siblings, 1 reply; 13+ messages in thread
From: Felipe Contreras @ 2010-10-05 21:05 UTC (permalink / raw)
To: Ramirez Luna, Omar
Cc: Greg KH, linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Hiroshi Doyu
On Tue, Oct 5, 2010 at 11:09 PM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
> Felipe Contreras wrote:
> ...
>>>
>>> phys_to_virt instead of ioremap should work fine, still need to try
>>> it though.
>>
>> I tried that... Didn't work. I guess we need to flush at some points
>> (since the memory is cacheable).
>
> Hmmm, because my other option was to move the reserved memory outside the kernel, but that involves specifying bootargs again and using dma_alloc_coherent with their restrictions.
Huh, if there's no contiguous memory region reserved, then the driver
is doing dma_alloc_coherent already, but that fails (apparently 5M is
too much). Plus I've read that dma_alloc_coherent is "precious";
shouldn't be used for that.
> If you are working on a different method and need any help let me know.
So, first I wanted to try reserving some region with mem=X boot param,
but that solution is ugly. If that worked, then I wanted ti see if
flushing each time we access that shm memory block works, but in the
process I wanted to reorganize the whole initialization code because
right now it's very ugly and confusing.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/2] omap: dsp: make the driver actually work
2010-10-05 21:05 ` Felipe Contreras
@ 2010-10-07 1:32 ` Omar Ramirez Luna
0 siblings, 0 replies; 13+ messages in thread
From: Omar Ramirez Luna @ 2010-10-07 1:32 UTC (permalink / raw)
To: Felipe Contreras
Cc: Greg KH, linux-omap, linux-main, Ohad Ben-Cohen, Tony Lindgren,
Hiroshi Doyu
On 10/5/2010 4:05 PM, Felipe Contreras wrote:
> On Tue, Oct 5, 2010 at 11:09 PM, Ramirez Luna,
> Omar<omar.ramirez@ti.com> wrote:
>> Felipe Contreras wrote:
...
>>
>> Hmmm, because my other option was to move the reserved memory
>> outside the kernel, but that involves specifying bootargs again and
>> using dma_alloc_coherent with their restrictions.
>
> Huh, if there's no contiguous memory region reserved, then the
> driver is doing dma_alloc_coherent already, but that fails
> (apparently 5M is too much). Plus I've read that dma_alloc_coherent
> is "precious"; shouldn't be used for that.
Initially bridge was using the memory on the upper part of the RAM,
specifying in bootargs mem=MAX-6MB, so reintroducing the parameter works
fine; dma_alloc_coherent was also used when bridge was compiled as
built-in the kernel but now it is not working either.
>
> So, first I wanted to try reserving some region with mem=X boot
> param, but that solution is ugly. If that worked, then I wanted ti
> see if flushing each time we access that shm memory block works, but
> in the process I wanted to reorganize the whole initialization code
> because right now it's very ugly and confusing.
>
Yes, I can help with that, I'm sending a patch to reintroduce the
parameter for phys_mempool_base, however we need to remove or disable
the memblock functions related with dspbridge. I was thinking of a
menuconfig parameter to specify mempool base for built-in compilation.
Regards,
Omar
^ permalink raw reply [flat|nested] 13+ messages in thread