RE: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do not invalidate clean lines
> > No - Catalin means are the NZCV flags changed by the secure monitor, or > > are they preserved? If they're preserved, you don't need a "cc" clobber. > > If they're not preserved, you do. > I will double check this but IIRC the flags are preserved. I confirm that the flags are restored. Will repost the patch with suggested changes. -- 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] Regulator: Use common regulator supplies and init data structs
> Your common supply file has VMMC2 supply configured for 1.8V which is > wrong for pandora (it uses 3.1V because it has a transceiver attached > to MMC2 that handles level shifting transparently). > > I think you should leave pandora board file alone, because it uses > many supplies differently than your common file configures them > (VAUX1-VAUX4, VSIM differ, only VMMC1, VDAC and VPLL2 match, which is > not that much duplication). [Aggarwal, Anuj] My mistake :( Although I have marked it as RED in my notes, I still modified it. I will leave VMMC2 in this file only. But I am not able to find so many regulators as you mentioned above in this file. I can only see VMMC1 and VMMC2, out of which VMMC2 is different from the common configuration. Where is the gap? -- 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] OMAP3: hwmod: Adding flag to prevent caching of sysconfig register.
Hi Thara, On Tue, 12 Jan 2010, Gopinath, Thara wrote: > >>-Original Message- > >>From: Paul Walmsley [mailto:p...@pwsan.com] > >> > >>Aren't the SmartReflex modules in their own powerdomain that changes with > >>the CORE powerdomain? > > H I think Smartreflex is in Core poweerdomain but sr1_fclk and > sr2_fclk are in the wakeup domain. Slightly complicated :-( According to the TRM rev W figure 4-18 "Device Power Domains", at least, the SmartReflex modules are in their own powerdomain. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of sysconfig register.
>>-Original Message- >>From: Paul Walmsley [mailto:p...@pwsan.com] >>Sent: Tuesday, January 12, 2010 3:51 AM >>To: Gopinath, Thara >>Cc: linux-omap@vger.kernel.org >>Subject: RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of >>sysconfig register. >> >>On Thu, 7 Jan 2010, Gopinath, Thara wrote: >> >>> >>-Original Message- >>> >>From: Paul Walmsley [mailto:p...@pwsan.com] >>> >>Sent: Wednesday, January 06, 2010 6:02 AM >>> >>To: Gopinath, Thara >>> >>Cc: linux-omap@vger.kernel.org >>> >>Subject: RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of >>> >>sysconfig register. >>> >> >>> >>On Wed, 23 Dec 2009, Gopinath, Thara wrote: >>> >> >>> >>> Hi Paul,Kevin.. Does this patch look ok? >>> >> >>> >>Hello Thara, >>> >> >>> >>looking over this patch. Nice job on the descriptive patch comment; >>> >>it explains the problem well. What do you think about a slightly >>> >>different approach -- that is, to add a hook to the hwmod code to >>> >>invalidate the cache if the module's powerdomain has lost context? >>> >>> It should be possible but I feel it is a bit cumbersome. Couple of >>> reasons I have. >>> a. Some modules like smartreflex does not have any power domain >>> associated with it. >> >>Aren't the SmartReflex modules in their own powerdomain that changes with >>the CORE powerdomain? H I think Smartreflex is in Core poweerdomain but sr1_fclk and sr2_fclk are in the wakeup domain. Slightly complicated :-( >> >>> b. Invalidating the cache is not needed for all modules even if the >>> module powerdomain context is lost. This is needed only for modules >>> which employ always restore mechanism. All other modules will do >>> explicit context save and restore of its registers >> >>I think we'll want to move all SYSCONFIG manipulation into the hwmod >>layer, once it is in place. Agreed. >> >>> c. Getting whether power domain context is lost or not is not very >>> straight forward. If I am not mistaken the only way is to keep tab of >>> the powerdomain counters through omap_pm_get_dev_context_loss_count. I >>> might be mistaken. >> >>Yeah. Getting the hook in will take a little bit of work. >> >>Anyway, for the time being, we can take this patch. But the other reason >>that this approach doesn't appeal is that this new flag doesn't have >>anything to do with the hardware -- it's just a software workaround for >>device driver code. Ideally, all of these flags should be generatable >>based on hardware data only. Flags that pertain to how the device driver >>works belong in a different place. Perhaps they should still be connected >>to the hwmod code, but they should exist separately from the hwmod data. Ah.. yes. It will be difficult to auto generate this flag based on h/w info. Maybe once appropriate hooks are available for powerdomain context lost or not, we can do away with this. Else if there are too may of these flags depending on device driver implementations we can generate a separate header file and a hook to these flags in hwmod structure. >> >>Queued for .33-rc (fixes). >> >> >>- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of sysconfig register.
>>-Original Message- >>From: Paul Walmsley [mailto:p...@pwsan.com] >>Sent: Tuesday, January 12, 2010 4:02 AM >>To: Gopinath, Thara >>Cc: linux-omap@vger.kernel.org >>Subject: RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of >>sysconfig register. >> >>On Mon, 11 Jan 2010, Paul Walmsley wrote: >> >>> Queued for .33-rc (fixes). >> >>By the way, the patch had to be slightly tweaked to apply it since the >>original was based on the configurable clockactivity offset patch - here's >>what is queued in the 'for_2.6.33rc_d' branch of >>git://git.pwsan.com/linux-2.6 >> >>- Paul >> Thanks Paul Regards Thara -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] omap2_mcspi interrupt context execution
List,
One of the devices I work with has an ethernet chip connected to an
OMAP2430 by spi and an interrupt gpio. The chip isn't well behaved, so
I end up needing to send spi messages in response to interrupts from
the chip very quickly or it will lose packets.
I've written the high level driver such that it makes spi_async
requests in interrupt context when it gets an interrupt, but it
appears that the omap2_mcspi driver below me is context switching out
of interrupt context to a plain kernel thread. If the scheduler
doesn't run this thread immediately, we overflow the ethernet chip's
buffer and lose packets.
Has anyone looked into making the omap2_mcspi driver run in interrupt
context before? Does anyone have advice how to do so or a similar
driver I could pattern this change after?
Thanks,
David W
PS: Here's the psuedocode I'm imagining for the omap2_mcspi driver.
Maybe it will clarify what I'm thinking.
// Shared fifo of transfers yet to be handled
struct list pending_transfers;
spinlock_t lock;
// Called by upper layer drivers to send spi messages
int omap2_mcspi_transfer(struct spi_transfer * t)
{
spin_lock(lock);
empty = list_empty(pending_transfers);
list_push_back(pending_transfers, t);
if (empty) {
start_transfer();
}
spin_unlock(lock);
return status;
}
void start_transfer()
{
struct spi_transfer * t = pending_transfers.first;
spi_enable(t.channel);
spi_setup(t.channel, t.params);
setup_dma(spi, t.tx_buf, t.rx_buf, t.length, irq_handler);
spi_start();
}
// Called when dma completes to+from mcspi
void irq_handler()
{
struct spi_transfer * t = pending_transfers.first;
spin_lock(lock);
spi_finish(t);
spi_disable(t.channel);
list_remove(pending_transfers, t);
if !list_empty(pending_transfers) {
start_transfer();
}
spin_unlock(lock);
// Call back to the driver to let it know we finished
t.async_callback(t.status);
}
--
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] [I2C-OMAP] Add support for 16-bit registers
On Mon, Jan 11, 2010 at 5:28 PM, Tony Lindgren wrote:
>
> Applied to omap-testing with the following fix. Can you please merge
> it into your original patch?
>
Done, I've attached the new patch to here. I've tested it and it
works perfectly.
- Cory
>From 7c693afce8ffa3978b4fcecc56cd7d4a9d9d3b75 Mon Sep 17 00:00:00 2001
From: Cory Maccarrone
Date: Sat, 5 Dec 2009 22:00:25 -0800
Subject: [PATCH] [I2C-OMAP] Add support for 16-bit registers
The current i2c-omap driver is set up for 32-bit registers, which
corresponds to most OMAP devices. However, OMAP730/850 based
devices use a 16-bit register size.
This change modifies the driver to perform a runtime CPU type check
to determine the register sizes, and uses a bit shift of either 1
or 2 bits to compute the proper register sizes for all registers.
Signed-off-by: Cory Maccarrone
---
drivers/i2c/busses/i2c-omap.c | 45 +++-
1 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0037e31..9c3ce4d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -49,24 +49,24 @@
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG0x04
-#define OMAP_I2C_STAT_REG 0x08
-#define OMAP_I2C_IV_REG0x0c
+#define OMAP_I2C_IE_REG0x01
+#define OMAP_I2C_STAT_REG 0x02
+#define OMAP_I2C_IV_REG0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG0x0c
-#define OMAP_I2C_SYSS_REG 0x10
-#define OMAP_I2C_BUF_REG 0x14
-#define OMAP_I2C_CNT_REG 0x18
-#define OMAP_I2C_DATA_REG 0x1c
-#define OMAP_I2C_SYSC_REG 0x20
-#define OMAP_I2C_CON_REG 0x24
-#define OMAP_I2C_OA_REG0x28
-#define OMAP_I2C_SA_REG0x2c
-#define OMAP_I2C_PSC_REG 0x30
-#define OMAP_I2C_SCLL_REG 0x34
-#define OMAP_I2C_SCLH_REG 0x38
-#define OMAP_I2C_SYSTEST_REG 0x3c
-#define OMAP_I2C_BUFSTAT_REG 0x40
+#define OMAP_I2C_WE_REG0x03
+#define OMAP_I2C_SYSS_REG 0x04
+#define OMAP_I2C_BUF_REG 0x05
+#define OMAP_I2C_CNT_REG 0x06
+#define OMAP_I2C_DATA_REG 0x07
+#define OMAP_I2C_SYSC_REG 0x08
+#define OMAP_I2C_CON_REG 0x09
+#define OMAP_I2C_OA_REG0x0a
+#define OMAP_I2C_SA_REG0x0b
+#define OMAP_I2C_PSC_REG 0x0c
+#define OMAP_I2C_SCLL_REG 0x0d
+#define OMAP_I2C_SCLH_REG 0x0e
+#define OMAP_I2C_SYSTEST_REG 0x0f
+#define OMAP_I2C_BUFSTAT_REG 0x10
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
#define OMAP_I2C_IE_XDR(1 << 14) /* TX Buffer drain int
enable */
@@ -161,6 +161,7 @@ struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
int irq;
+ int reg_shift; /* bit shift for I2C register
addresses */
struct clk *iclk; /* Interface clock */
struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
@@ -189,12 +190,12 @@ struct omap_i2c_dev {
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
int reg, u16 val)
{
- __raw_writew(val, i2c_dev->base + reg);
+ __raw_writew(val, i2c_dev->base + (reg << i2c_dev->reg_shift));
}
static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
{
- return __raw_readw(i2c_dev->base + reg);
+ return __raw_readw(i2c_dev->base + (reg << i2c_dev->reg_shift));
}
static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
@@ -893,6 +894,12 @@ omap_i2c_probe(struct platform_device *pdev)
dev->idle = 1;
dev->dev = &pdev->dev;
dev->irq = irq->start;
+
+ if (cpu_is_omap7xx())
+ dev->reg_shift = 1;
+ else
+ dev->reg_shift = 2;
+
dev->base = ioremap(mem->start, resource_size(mem));
if (!dev->base) {
r = -ENOMEM;
--
1.6.3.3
From 7c693afce8ffa3978b4fcecc56cd7d4a9d9d3b75 Mon Sep 17 00:00:00 2001
From: Cory Maccarrone
Date: Sat, 5 Dec 2009 22:00:25 -0800
Subject: [PATCH] [I2C-OMAP] Add support for 16-bit registers
The current i2c-omap driver is set up for 32-bit registers, which
corresponds to most OMAP devices. However, OMAP730/850 based
devices use a 16-bit register size.
This change modifies the driver to perform a runtime CPU type check
to determine the register sizes, and uses a bit shift of ei
Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers
* Cory Maccarrone [100109 10:34]:
> On Sat, Jan 9, 2010 at 10:33 AM, Tony Lindgren wrote:
> >
> > Let's plan on adding this into omap-testing branch next week so
> > we can make sure things are OK for the other platforms.
> >
> > Then assuming no issues, let's ask Ben can queue it.
> >
>
> Excellent, thank you!
Applied to omap-testing with the following fix. Can you please merge
it into your original patch?
Regards,
Tony
>From 5b640a850de9fb87b9e9e6dd2cfeb7144ada8053 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Mon, 11 Jan 2010 17:22:21 -0800
Subject: [PATCH] i2c-omap: Fix reg_shift init
Otherwise register access won't work during probe
for omap_i2c_unidle.
Signed-off-by: Tony Lindgren
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 913abd7..9c3ce4d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -894,6 +894,12 @@ omap_i2c_probe(struct platform_device *pdev)
dev->idle = 1;
dev->dev = &pdev->dev;
dev->irq = irq->start;
+
+ if (cpu_is_omap7xx())
+ dev->reg_shift = 1;
+ else
+ dev->reg_shift = 2;
+
dev->base = ioremap(mem->start, resource_size(mem));
if (!dev->base) {
r = -ENOMEM;
@@ -925,11 +931,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev->b_hw = 1; /* Enable hardware fixes */
}
- if (cpu_is_omap7xx())
- dev->reg_shift = 1;
- else
- dev->reg_shift = 2;
-
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
[PATCH 05/10] OMAP clockdomains: add usecounting for wakeup and sleep dependencies
Add usecounting for wakeup and sleep dependencies. In the current
situation, if several functions add dependencies on the same clockdomains,
when the first dependency removal function is called, the dependency will
be incorrectly removed from the hardware.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomain.c | 150 ++---
arch/arm/plat-omap/include/plat/clockdomain.h |6 +
2 files changed, 135 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 2af9996..d039df7 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -113,7 +113,6 @@ static struct clkdm_dep *_clkdm_deps_lookup(struct
clockdomain *clkdm,
return ERR_PTR(-EINVAL);
for (cd = deps; cd->clkdm_name; cd++) {
-
if (!omap_chip_is(cd->omap_chip))
continue;
@@ -122,7 +121,6 @@ static struct clkdm_dep *_clkdm_deps_lookup(struct
clockdomain *clkdm,
if (cd->clkdm == clkdm)
break;
-
}
if (!cd->clkdm_name)
@@ -254,6 +252,96 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain
*clkdm, int enable)
}
+/**
+ * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
+ * @clkdm: clockdomain to initialize wkdep usecounts
+ *
+ * Initialize the wakeup dependency usecount variables for clockdomain @clkdm.
+ * If a wakeup dependency is present in the hardware, the usecount will be
+ * set to 1; otherwise, it will be set to 0. Software should clear all
+ * software wakeup dependencies prior to calling this function if it wishes
+ * to ensure that all usecounts start at 0. No return value.
+ */
+static void _init_wkdep_usecount(struct clockdomain *clkdm)
+{
+ u32 v;
+ struct clkdm_dep *cd;
+
+ if (!clkdm->wkdep_srcs)
+ return;
+
+ for (cd = clkdm->wkdep_srcs; cd->clkdm_name; cd++) {
+ if (!omap_chip_is(cd->omap_chip))
+ continue;
+
+ if (!cd->clkdm && cd->clkdm_name)
+ cd->clkdm = _clkdm_lookup(cd->clkdm_name);
+
+ if (!cd->clkdm) {
+ WARN(!cd->clkdm, "clockdomain: %s: wkdep clkdm %s not "
+"found\n", clkdm->name, cd->clkdm_name);
+ continue;
+ }
+
+ v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
+ PM_WKDEP,
+ (1 << cd->clkdm->dep_bit));
+
+ if (v)
+ pr_debug("clockdomain: %s: wakeup dependency already "
+"set to wake up when %s wakes\n",
+clkdm->name, cd->clkdm->name);
+
+ atomic_set(&cd->wkdep_usecount, (v) ? 1 : 0);
+ }
+}
+
+/**
+ * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
+ * @clkdm: clockdomain to initialize sleepdep usecounts
+ *
+ * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
+ * If a sleep dependency is present in the hardware, the usecount will be
+ * set to 1; otherwise, it will be set to 0. Software should clear all
+ * software sleep dependencies prior to calling this function if it wishes
+ * to ensure that all usecounts start at 0. No return value.
+ */
+static void _init_sleepdep_usecount(struct clockdomain *clkdm)
+{
+ u32 v;
+ struct clkdm_dep *cd;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ if (!clkdm->sleepdep_srcs)
+ return;
+
+ for (cd = clkdm->sleepdep_srcs; cd->clkdm_name; cd++) {
+ if (!omap_chip_is(cd->omap_chip))
+ continue;
+
+ if (!cd->clkdm && cd->clkdm_name)
+ cd->clkdm = _clkdm_lookup(cd->clkdm_name);
+
+ if (!cd->clkdm) {
+ WARN(!cd->clkdm, "clockdomain: %s: sleepdep clkdm %s "
+"not found\n", clkdm->name, cd->clkdm_name);
+ continue;
+ }
+
+ v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
+ OMAP3430_CM_SLEEPDEP,
+ (1 << cd->clkdm->dep_bit));
+
+ if (v)
+ pr_debug("clockdomain: %s: sleep dependency already "
+"set to prevent from idling until %s "
+"idles\n", clkdm->name, cd->clkdm->name);
+
+ atomic_set(&cd->sleepdep_usecount, (v) ? 1 : 0);
+ }
+};
/* Public functions */
@@ -272,6 +360,7 @@ void clkdm_init(struct clockdomain **clkdms,
struct clkdm_autodep *init_autodeps)
{
struct clockdomain **c = NULL;
+ struct clockdomain *clkdm;
struct clkdm_a
[PATCH 06/10] OMAP2/3/4 clockdomain: add clkdm_clear_all_{wkdep, sleepdep}s()
Add clkdm_clear_all_wkdeps() and clkdm_clear_all_sleepdeps(). These functions
provide a fast way for code to clear all hardware clockdomain dependencies,
since accesses to these registers can be quite slow. These functions
are currently targeted for use by PM branch code.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/clockdomain.c | 68 +
arch/arm/plat-omap/include/plat/clockdomain.h |2 +
2 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index d039df7..f44d9ea 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -565,6 +565,38 @@ int clkdm_read_wkdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2)
}
/**
+ * clkdm_clear_all_wkdeps - remove all wakeup dependencies from target clkdm
+ * @clkdm: struct clockdomain * to remove all wakeup dependencies from
+ *
+ * Remove all inter-clockdomain wakeup dependencies that could cause
+ * @clkdm to wake. Intended to be used during boot to initialize the
+ * PRCM to a known state, after all clockdomains are put into swsup idle
+ * and woken up. Returns -EINVAL if @clkdm pointer is invalid, or
+ * 0 upon success.
+ */
+int clkdm_clear_all_wkdeps(struct clockdomain *clkdm)
+{
+ struct clkdm_dep *cd;
+ u32 mask = 0;
+
+ if (!clkdm)
+ return -EINVAL;
+
+ for (cd = clkdm->wkdep_srcs; cd->clkdm_name; cd++) {
+ if (!omap_chip_is(cd->omap_chip))
+ continue;
+
+ /* PRM accesses are slow, so minimize them */
+ mask |= 1 << cd->clkdm->dep_bit;
+ atomic_set(&cd->wkdep_usecount, 0);
+ }
+
+ prm_clear_mod_reg_bits(mask, clkdm->pwrdm.ptr->prcm_offs, PM_WKDEP);
+
+ return 0;
+}
+
+/**
* clkdm_add_sleepdep - add a sleep dependency from clkdm2 to clkdm1
* @clkdm1: prevent this struct clockdomain * from sleeping (dependent)
* @clkdm2: when this struct clockdomain * is active (source)
@@ -690,6 +722,42 @@ int clkdm_read_sleepdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2)
}
/**
+ * clkdm_clear_all_sleepdeps - remove all sleep dependencies from target clkdm
+ * @clkdm: struct clockdomain * to remove all sleep dependencies from
+ *
+ * Remove all inter-clockdomain sleep dependencies that could prevent
+ * @clkdm from idling. Intended to be used during boot to initialize the
+ * PRCM to a known state, after all clockdomains are put into swsup idle
+ * and woken up. Returns -EINVAL if @clkdm pointer is invalid, or
+ * 0 upon success.
+ */
+int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
+{
+ struct clkdm_dep *cd;
+ u32 mask = 0;
+
+ if (!cpu_is_omap34xx())
+ return -EINVAL;
+
+ if (!clkdm)
+ return -EINVAL;
+
+ for (cd = clkdm->sleepdep_srcs; cd->clkdm_name; cd++) {
+ if (!omap_chip_is(cd->omap_chip))
+ continue;
+
+ /* PRM accesses are slow, so minimize them */
+ mask |= 1 << cd->clkdm->dep_bit;
+ atomic_set(&cd->sleepdep_usecount, 0);
+ }
+
+ prm_clear_mod_reg_bits(mask, clkdm->pwrdm.ptr->prcm_offs,
+ OMAP3430_CM_SLEEPDEP);
+
+ return 0;
+}
+
+/**
* omap2_clkdm_clktrctrl_read - read the clkdm's current state transition mode
* @clk: struct clk * of a clockdomain
*
diff --git a/arch/arm/plat-omap/include/plat/clockdomain.h
b/arch/arm/plat-omap/include/plat/clockdomain.h
index 192cc95..45b5deb 100644
--- a/arch/arm/plat-omap/include/plat/clockdomain.h
+++ b/arch/arm/plat-omap/include/plat/clockdomain.h
@@ -132,9 +132,11 @@ struct powerdomain *clkdm_get_pwrdm(struct clockdomain
*clkdm);
int clkdm_add_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_del_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_read_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
+int clkdm_clear_all_wkdeps(struct clockdomain *clkdm);
int clkdm_add_sleepdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_del_sleepdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_read_sleepdep(struct clockdomain *clkdm1, struct clockdomain
*clkdm2);
+int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm);
void omap2_clkdm_allow_idle(struct clockdomain *clkdm);
void omap2_clkdm_deny_idle(struct clockdomain *clkdm);
--
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 08/10] OMAP powerdomain: rearrange struct powerdomain to save some memory
This patch rearranges the order of structure members in struct powerdomain
to avoid wasting memory due to alignment restrictions.
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/include/plat/powerdomain.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index c590e2f..87e13f8 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -73,12 +73,12 @@ struct powerdomain {
/* Powerdomain name */
const char *name;
- /* the address offset from CM_BASE/PRM_BASE */
- const s16 prcm_offs;
-
/* Used to represent the OMAP chip types containing this pwrdm */
const struct omap_chip_id omap_chip;
+ /* the address offset from CM_BASE/PRM_BASE */
+ const s16 prcm_offs;
+
/* Possible powerdomain power states */
const u8 pwrsts;
--
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 04/10] OMAP clockdomain/powerdomain: remove runtime register/unregister
OMAP clockdomains and powerdomains are currently defined statically,
only registered at boot, and never unregistered, so we can remove the
unregister function and the locking. A variant of this was originally
suggested a while ago by Dmitry Baryshkov .
Signed-off-by: Paul Walmsley
Cc: Dmitry Baryshkov
---
arch/arm/mach-omap2/clockdomain.c | 118 ++---
arch/arm/mach-omap2/powerdomain.c | 178 ++---
arch/arm/plat-omap/include/plat/clockdomain.h |2
arch/arm/plat-omap/include/plat/powerdomain.h |2
4 files changed, 85 insertions(+), 215 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index a70ba29..2af9996 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -39,9 +39,6 @@
/* clkdm_list contains all registered struct clockdomains */
static LIST_HEAD(clkdm_list);
-/* clkdm_mutex protects clkdm_list add and del ops */
-static DEFINE_MUTEX(clkdm_mutex);
-
/* array of clockdomain deps to be added/removed when clkdm in hwsup mode */
static struct clkdm_autodep *autodeps;
@@ -67,6 +64,45 @@ static struct clockdomain *_clkdm_lookup(const char *name)
return clkdm;
}
+/**
+ * _clkdm_register - register a clockdomain
+ * @clkdm: struct clockdomain * to register
+ *
+ * Adds a clockdomain to the internal clockdomain list.
+ * Returns -EINVAL if given a null pointer, -EEXIST if a clockdomain is
+ * already registered by the provided name, or 0 upon success.
+ */
+static int _clkdm_register(struct clockdomain *clkdm)
+{
+ struct powerdomain *pwrdm;
+
+ if (!clkdm || !clkdm->name)
+ return -EINVAL;
+
+ if (!omap_chip_is(clkdm->omap_chip))
+ return -EINVAL;
+
+ pwrdm = pwrdm_lookup(clkdm->pwrdm.name);
+ if (!pwrdm) {
+ pr_err("clockdomain: %s: powerdomain %s does not exist\n",
+ clkdm->name, clkdm->pwrdm.name);
+ return -EINVAL;
+ }
+ clkdm->pwrdm.ptr = pwrdm;
+
+ /* Verify that the clockdomain is not already registered */
+ if (_clkdm_lookup(clkdm->name))
+ return -EEXIST;
+
+ list_add(&clkdm->node, &clkdm_list);
+
+ pwrdm_add_clkdm(pwrdm, clkdm);
+
+ pr_debug("clockdomain: registered %s\n", clkdm->name);
+
+ return 0;
+}
+
/* _clkdm_deps_lookup - look up the specified clockdomain in a clkdm list */
static struct clkdm_dep *_clkdm_deps_lookup(struct clockdomain *clkdm,
struct clkdm_dep *deps)
@@ -240,7 +276,7 @@ void clkdm_init(struct clockdomain **clkdms,
if (clkdms)
for (c = clkdms; *c; c++)
- clkdm_register(*c);
+ _clkdm_register(*c);
autodeps = init_autodeps;
if (autodeps)
@@ -249,76 +285,6 @@ void clkdm_init(struct clockdomain **clkdms,
}
/**
- * clkdm_register - register a clockdomain
- * @clkdm: struct clockdomain * to register
- *
- * Adds a clockdomain to the internal clockdomain list.
- * Returns -EINVAL if given a null pointer, -EEXIST if a clockdomain is
- * already registered by the provided name, or 0 upon success.
- */
-int clkdm_register(struct clockdomain *clkdm)
-{
- int ret = -EINVAL;
- struct powerdomain *pwrdm;
-
- if (!clkdm || !clkdm->name)
- return -EINVAL;
-
- if (!omap_chip_is(clkdm->omap_chip))
- return -EINVAL;
-
- pwrdm = pwrdm_lookup(clkdm->pwrdm.name);
- if (!pwrdm) {
- pr_err("clockdomain: %s: powerdomain %s does not exist\n",
- clkdm->name, clkdm->pwrdm.name);
- return -EINVAL;
- }
- clkdm->pwrdm.ptr = pwrdm;
-
- mutex_lock(&clkdm_mutex);
- /* Verify that the clockdomain is not already registered */
- if (_clkdm_lookup(clkdm->name)) {
- ret = -EEXIST;
- goto cr_unlock;
- }
-
- list_add(&clkdm->node, &clkdm_list);
-
- pwrdm_add_clkdm(pwrdm, clkdm);
-
- pr_debug("clockdomain: registered %s\n", clkdm->name);
- ret = 0;
-
-cr_unlock:
- mutex_unlock(&clkdm_mutex);
-
- return ret;
-}
-
-/**
- * clkdm_unregister - unregister a clockdomain
- * @clkdm: struct clockdomain * to unregister
- *
- * Removes a clockdomain from the internal clockdomain list. Returns
- * -EINVAL if clkdm argument is NULL.
- */
-int clkdm_unregister(struct clockdomain *clkdm)
-{
- if (!clkdm)
- return -EINVAL;
-
- pwrdm_del_clkdm(clkdm->pwrdm.ptr, clkdm);
-
- mutex_lock(&clkdm_mutex);
- list_del(&clkdm->node);
- mutex_unlock(&clkdm_mutex);
-
- pr_debug("clockdomain: unregistered %s\n", clkdm->name);
-
- return 0;
-}
-
-/**
* clkdm_lookup - look up a clockdomain by name, return a pointer
* @name: name of clockdomain
*
@@ -334,14 +300,12 @@ struct clockdomain *clkdm_lookup(con
[PATCH 10/10] OMAP clockdomain/powerdomain: improve documentation
This patch only affects documentation; no functional changes are
included.
Clean up comments in the current clockdomain, powerdomain code and
header files. This mostly involves conversion to kerneldoc format,
although some clarifications are also included.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomain.c | 65 ++-
arch/arm/mach-omap2/powerdomain.c | 149 +
arch/arm/plat-omap/include/plat/clockdomain.h | 87 +++
arch/arm/plat-omap/include/plat/powerdomain.h | 40 +++
4 files changed, 167 insertions(+), 174 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index f44d9ea..2f68c10 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -351,10 +351,10 @@ static void _init_sleepdep_usecount(struct clockdomain
*clkdm)
* @init_autodeps: optional pointer to an array of autodeps to register
*
* Set up internal state. If a pointer to an array of clockdomains
- * was supplied, loop through the list of clockdomains, register all
- * that are available on the current platform. Similarly, if a pointer
- * to an array of clockdomain autodependencies was provided, register
- * those. No return value.
+ * @clkdms was supplied, loop through the list of clockdomains,
+ * register all that are available on the current platform. Similarly,
+ * if a pointer to an array of clockdomain autodependencies
+ * @init_autodeps was provided, register those. No return value.
*/
void clkdm_init(struct clockdomain **clkdms,
struct clkdm_autodep *init_autodeps)
@@ -386,8 +386,8 @@ void clkdm_init(struct clockdomain **clkdms,
* clkdm_lookup - look up a clockdomain by name, return a pointer
* @name: name of clockdomain
*
- * Find a registered clockdomain by its name. Returns a pointer to the
- * struct clockdomain if found, or NULL otherwise.
+ * Find a registered clockdomain by its name @name. Returns a pointer
+ * to the struct clockdomain if found, or NULL otherwise.
*/
struct clockdomain *clkdm_lookup(const char *name)
{
@@ -412,8 +412,8 @@ struct clockdomain *clkdm_lookup(const char *name)
* clkdm_for_each - call function on each registered clockdomain
* @fn: callback function *
*
- * Call the supplied function for each registered clockdomain.
- * The callback function can return anything but 0 to bail
+ * Call the supplied function @fn for each registered clockdomain.
+ * The callback function @fn can return anything but 0 to bail
* out early from the iterator. The callback function is called with
* the clkdm_mutex held, so no clockdomain structure manipulation
* functions should be called from the callback, although hardware
@@ -446,7 +446,7 @@ int clkdm_for_each(int (*fn)(struct clockdomain *clkdm,
void *user),
* @clkdm: struct clockdomain *
*
* Return a pointer to the struct powerdomain that the specified clockdomain
- * 'clkdm' exists in, or returns NULL if clkdm argument is NULL.
+ * @clkdm exists in, or returns NULL if @clkdm is NULL.
*/
struct powerdomain *clkdm_get_pwrdm(struct clockdomain *clkdm)
{
@@ -759,10 +759,10 @@ int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
/**
* omap2_clkdm_clktrctrl_read - read the clkdm's current state transition mode
- * @clk: struct clk * of a clockdomain
+ * @clkdm: struct clkdm * of a clockdomain
*
- * Return the clockdomain's current state transition mode from the
- * corresponding domain OMAP2_CM_CLKSTCTRL register. Returns -EINVAL if clk
+ * Return the clockdomain @clkdm current state transition mode from the
+ * corresponding domain CM_CLKSTCTRL register. Returns -EINVAL if @clkdm
* is NULL or the current mode upon success.
*/
static int omap2_clkdm_clktrctrl_read(struct clockdomain *clkdm)
@@ -784,7 +784,7 @@ static int omap2_clkdm_clktrctrl_read(struct clockdomain
*clkdm)
* @clkdm: struct clockdomain *
*
* Instruct the CM to force a sleep transition on the specified
- * clockdomain 'clkdm'. Returns -EINVAL if clk is NULL or if
+ * clockdomain @clkdm. Returns -EINVAL if @clkdm is NULL or if
* clockdomain does not support software-initiated sleep; 0 upon
* success.
*/
@@ -828,7 +828,7 @@ int omap2_clkdm_sleep(struct clockdomain *clkdm)
* @clkdm: struct clockdomain *
*
* Instruct the CM to force a wakeup transition on the specified
- * clockdomain 'clkdm'. Returns -EINVAL if clkdm is NULL or if the
+ * clockdomain @clkdm. Returns -EINVAL if @clkdm is NULL or if the
* clockdomain does not support software-controlled wakeup; 0 upon
* success.
*/
@@ -871,7 +871,7 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
* omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
*
- * Allow the hardware to automatically switch the clockdomain into
+ * Allow the hardware to automatically switch the clockdomain @clkdm into
* active or idle states, as needed by
[PATCH 07/10] OMAP powerdomain/PM: use symbolic constants for the max number of power states
Replace some bare constants with symbolic constants. Signed-off-by: Paul Walmsley Cc: Kevin Hilman --- arch/arm/mach-omap2/powerdomain.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 411361f..df6446a 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -122,7 +122,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm) list_add(&pwrdm->node, &pwrdm_list); /* Initialize the powerdomain's state counter */ - for (i = 0; i < 4; i++) + for (i = 0; i < PWRDM_MAX_PWRSTS; i++) pwrdm->state_counter[i] = 0; pwrdm_wait_transition(pwrdm); -- 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 03/10] OMAP2 clockdomain: modem clockdomain is only present on OMAP2430
For some reason, previously, we included the MDM clockdomain on all 24xx,
but the stacked die-on-die modem configuration (chassis mode) is only
available on OMAP2430.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomains.h | 49
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index 9629ef1..fb026da 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -110,10 +110,10 @@ static struct clkdm_dep dsp_24xx_wkdeps[] = {
};
/*
- * 2420/2430 PM_WKDEP_MDM: CORE, MPU, WKUP
- * XXX This is probably 2430-only; 2420 did not have a stacked modem config.
+ * 2420 PM_WKDEP_MPU: CORE, DSP, WKUP
+ * 2430 adds MDM
*/
-static struct clkdm_dep mdm_24xx_wkdeps[] = {
+static struct clkdm_dep mpu_24xx_wkdeps[] = {
{
.clkdm_name = "core_l3_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
@@ -123,31 +123,35 @@ static struct clkdm_dep mdm_24xx_wkdeps[] = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = "mpu_clkdm",
+ .clkdm_name = "dsp_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
.clkdm_name = "wkup_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
+ {
+ .clkdm_name = "mdm_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ },
{ NULL },
};
/*
- * 2420 PM_WKDEP_MPU: CORE, DSP, WKUP
+ * 2420 PM_WKDEP_CORE: DSP, GFX, MPU, WKUP
* 2430 adds MDM
*/
-static struct clkdm_dep mpu_24xx_wkdeps[] = {
+static struct clkdm_dep core_24xx_wkdeps[] = {
{
- .clkdm_name = "core_l3_clkdm",
+ .clkdm_name = "dsp_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = "core_l4_clkdm",
+ .clkdm_name = "gfx_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = "dsp_clkdm",
+ .clkdm_name = "mpu_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
@@ -161,17 +165,21 @@ static struct clkdm_dep mpu_24xx_wkdeps[] = {
{ NULL },
};
-/*
- * 2420 PM_WKDEP_CORE: DSP, GFX, MPU, WKUP
- * 2430 adds MDM
- */
-static struct clkdm_dep core_24xx_wkdeps[] = {
+#endif
+
+
+/* 2430-specific possible wakeup dependencies */
+
+#ifdef CONFIG_ARCH_OMAP2430
+
+/* 2430 PM_WKDEP_MDM: CORE, MPU, WKUP */
+static struct clkdm_dep mdm_2430_wkdeps[] = {
{
- .clkdm_name = "dsp_clkdm",
+ .clkdm_name = "core_l3_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = "gfx_clkdm",
+ .clkdm_name = "core_l4_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
@@ -182,14 +190,11 @@ static struct clkdm_dep core_24xx_wkdeps[] = {
.clkdm_name = "wkup_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
- {
- .clkdm_name = "mdm_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
- },
{ NULL },
};
-#endif
+#endif /* CONFIG_ARCH_OMAP2430 */
+
/* 34XX-specific possible dependencies */
@@ -549,7 +554,7 @@ static struct clockdomain mdm_clkdm = {
.clkstctrl_reg = OMAP2430_CM_REGADDR(OMAP2430_MDM_MOD,
OMAP2_CM_CLKSTCTRL),
.dep_bit= OMAP2430_PM_WKDEP_MPU_EN_MDM_SHIFT,
- .wkdep_srcs = mdm_24xx_wkdeps,
+ .wkdep_srcs = mdm_2430_wkdeps,
.clktrctrl_mask = OMAP2430_AUTOSTATE_MDM_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] OMAP powerdomain: remove pwrdm_clk_state_switch
Nothing calls pwrdm_clk_state_switch(), and the function that seems to be
its ideal use case calls pwrdm_clkdm_state_switch(clk->clkdm), so remove it.
Signed-off-by: Paul Walmsley
Cc: Tero Kristo
Cc: Kevin Hilman
---
arch/arm/mach-omap2/powerdomain.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index df6446a..9d4b8f5 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -928,12 +928,6 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
return -EINVAL;
}
-int pwrdm_clk_state_switch(struct clk *clk)
-{
- if (clk != NULL && clk->clkdm != NULL)
- return pwrdm_clkdm_state_switch(clk->clkdm);
- return -EINVAL;
-}
int pwrdm_pre_transition(void)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] OMAP2/3 clockdomains: split shared structures so usecounting works
Previously some of the clockdomain wakeup/sleep dependency structures
were shared between several domains. For the subsequent wakeup and sleep
dependency usecounting patch to work, these can no longer be
shared. This patch splits the shared structures apart.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomains.h | 163
1 files changed, 127 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index ff216f2..9629ef1 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -52,6 +52,8 @@
* 2420/2430 PM_WKDEP_GFX: CORE, MPU, WKUP
* 3430ES1 PM_WKDEP_GFX: adds IVA2, removes CORE
* 3430ES2 PM_WKDEP_SGX: adds IVA2, removes CORE
+ * These can share data since they will never be present simultaneously
+ * on the same device.
*/
static struct clkdm_dep gfx_sgx_wkdeps[] = {
{
@@ -86,11 +88,32 @@ static struct clkdm_dep gfx_sgx_wkdeps[] = {
/* Wakeup dependency source arrays */
+/* 2420/2430 PM_WKDEP_DSP: CORE, MPU, WKUP */
+static struct clkdm_dep dsp_24xx_wkdeps[] = {
+ {
+ .clkdm_name = "core_l3_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ {
+ .clkdm_name = "core_l4_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ {
+ .clkdm_name = "mpu_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ {
+ .clkdm_name = "wkup_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ { NULL },
+};
+
/*
- * 2420/2430 PM_WKDEP_DSP: CORE, MPU, WKUP
- * 2420/2430 PM_WKDEP_MDM: same as DSP
+ * 2420/2430 PM_WKDEP_MDM: CORE, MPU, WKUP
+ * XXX This is probably 2430-only; 2420 did not have a stacked modem config.
*/
-static struct clkdm_dep dsp_mdm_24xx_wkdeps[] = {
+static struct clkdm_dep mdm_24xx_wkdeps[] = {
{
.clkdm_name = "core_l3_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
@@ -172,11 +195,8 @@ static struct clkdm_dep core_24xx_wkdeps[] = {
#ifdef CONFIG_ARCH_OMAP34XX
-/*
- * 3430: PM_WKDEP_{PER,USBHOST}: CORE, IVA2, MPU, WKUP
- * (USBHOST is ES2 only)
- */
-static struct clkdm_dep per_usbhost_wkdeps[] = {
+/* 3430: PM_WKDEP_PER: CORE, IVA2, MPU, WKUP */
+static struct clkdm_dep per_wkdeps[] = {
{
.clkdm_name = "core_l3_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
@@ -200,9 +220,32 @@ static struct clkdm_dep per_usbhost_wkdeps[] = {
{ NULL },
};
-/*
- * 3430 PM_WKDEP_MPU: CORE, IVA2, DSS, PER
- */
+/* 3430ES2: PM_WKDEP_USBHOST: CORE, IVA2, MPU, WKUP */
+static struct clkdm_dep usbhost_wkdeps[] = {
+ {
+ .clkdm_name = "core_l3_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = "core_l4_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = "iva2_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = "mpu_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = "wkup_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ { NULL },
+};
+
+/* 3430 PM_WKDEP_MPU: CORE, IVA2, DSS, PER */
static struct clkdm_dep mpu_34xx_wkdeps[] = {
{
.clkdm_name = "core_l3_clkdm",
@@ -227,9 +270,7 @@ static struct clkdm_dep mpu_34xx_wkdeps[] = {
{ NULL },
};
-/*
- * 3430 PM_WKDEP_IVA2: CORE, MPU, WKUP, DSS, PER
- */
+/* 3430 PM_WKDEP_IVA2: CORE, MPU, WKUP, DSS, PER */
static struct clkdm_dep iva2_wkdeps[] = {
{
.clkdm_name = "core_l3_clkdm",
@@ -259,8 +300,25 @@ static struct clkdm_dep iva2_wkdeps[] = {
};
-/* 3430 PM_WKDEP_{CAM,DSS}: IVA2, MPU, WKUP */
-static struct clkdm_dep cam_dss_wkdeps[] = {
+/* 3430 PM_WKDEP_CAM: IVA2, MPU, WKUP */
+static struct clkdm_dep cam_wkdeps[] = {
+ {
+ .clkdm_name = "iva2_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = "mpu_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = "wkup_clkdm",
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ { NULL },
+};
+
+/* 3430 PM_WKDEP_DSS: IVA2, MPU, WKUP */
+static struct clkdm_dep dss_wkdeps[] = {
{
.clkdm_name = "iva2_clkdm",
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
@@ -288,11 +346,8 @@ static struct clkdm_dep neon_wkdeps[] = {
/* Sleep dependency source arrays for 34xx-specific clkdms - 34XX only */
-/*
- * 3430: CM_SLEEPDEP_{DSS,PER}: MPU, IVA
- * 3430ES2: CM_SLEEP
[PATCH 00/10] OMAP2/3/4 clockdomains/powerdomains: split shared dependencies and clean up - for 2.6.34
Hello,
this series has already been posted on linux-omap, but is being
reposted here on linux-arm-kernel in case others wish to comment
before sending upstream to the for-next tree for 2.6.34 merging.
- Paul
---
Hi,
This series moves wakeup and sleep dependencies on the OMAP2/3 chips from
the powerdomain layer to the clockdomain layer, where they belong. It also
adds usecounting for clockdomain dependency usecounting, which fixes the
obvious problem that occurs when several different pieces of code need
to add clockdomain dependencies, and then one removes the dependency.
(To add usecounting, the dependencies that were shared between
clockdomains have been split into separate records.) These changes should
prepare the clockdomain code for OMAP4 clockdomain dependencies.
The series also does some cleanup. struct powerdomain is packed, the
dead function pwrdm_clk_state_switch() is removed, documentation is improved,
the nonexistent MDM clockdomain is removed from OMAP2420.
Boot-tested on N800, 2430SDP, and OMAP3 Beagle. Compile-tested with
omap_osk_5912_defconfig.
Applies on the 'for_2.6.34' branch of git://git.pwsan.com/linux-2.6
- Paul
---
textdata bss dec hex filename
3622921 198528 102984 3924433 3be1d1 vmlinux.beagle.orig
3623325 199168 102984 3925477 3be5e5 vmlinux.beagle
Paul Walmsley (10):
OMAP2/3 clkdm/pwrdm: move wkdep/sleepdep handling from pwrdm to clkdm
OMAP2/3 clockdomains: split shared structures so usecounting works
OMAP2 clockdomain: modem clockdomain is only present on OMAP2430
OMAP clockdomain/powerdomain: remove runtime register/unregister
OMAP clockdomains: add usecounting for wakeup and sleep dependencies
OMAP2/3/4 clockdomain: add clkdm_clear_all_{wkdep,sleepdep}s()
OMAP powerdomain/PM: use symbolic constants for the max number of power
states
OMAP powerdomain: rearrange struct powerdomain to save some memory
OMAP powerdomain: remove pwrdm_clk_state_switch
OMAP clockdomain/powerdomain: improve documentation
arch/arm/mach-omap2/clockdomain.c | 691 +++--
arch/arm/mach-omap2/clockdomains.h| 474 +
arch/arm/mach-omap2/io.c |2
arch/arm/mach-omap2/omap_hwmod.c | 10
arch/arm/mach-omap2/pm34xx.c | 10
arch/arm/mach-omap2/powerdomain.c | 570 -
arch/arm/mach-omap2/powerdomains.h| 88 ---
arch/arm/mach-omap2/powerdomains24xx.h| 87 ---
arch/arm/mach-omap2/powerdomains34xx.h| 145 -
arch/arm/mach-omap2/prcm.c| 12
arch/arm/plat-omap/include/plat/clockdomain.h | 99 ++--
arch/arm/plat-omap/include/plat/powerdomain.h | 78 +--
arch/arm/plat-omap/include/plat/prcm.h|8
13 files changed, 1241 insertions(+), 1033 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH v3 6/7] DSPBRIDGE: Use _IOxx macro to define ioctls
Resending with u8 instead of short for size_cmd array
>From: Ramirez Luna, Omar
>
>- Use standard convention to define ioctls.
>
>Currently 0xDB is used as identifier for dspbridge.
>
>Discussion:
>http://marc.info/?l=linux-omap&m=126297631603035&w=2
>
>WARNING:
>An update in api ioctl definitions is required, usually replacing
>to a new libbridge (with ioctl patch) should be enough. Other
>clients (not using libbridge) need to update their ioctl numbers
>manually.
>
>Signed-off-by: Omar Ramirez Luna
>CC: Nishanth Menon
>CC: Hiroshi Doyu
>CC: Ameya Palande
>CC: Felipe Contreras
>---
> arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 181 -
> drivers/dsp/bridge/pmgr/wcd.c | 200 +++
> drivers/dsp/bridge/rmgr/drv_interface.c |3 -
> 3 files changed, 237 insertions(+), 147 deletions(-)
>
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index 4b9dd0a..656d56b 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -437,86 +437,109 @@ union Trapped_Args {
} ARGS_UTIL_TESTDLL;
} ;
-#define CMD_BASE 1
+/*
+ * Dspbridge Ioctl numbering scheme
+ *
+ *7 0
+ * -
+ * | Module | Ioctl Number|
+ * -
+ * | x | x | x | 0 | 0 | 0 | 0 | 0 |
+ * -
+ */
+
+/* Ioctl driver identifier */
+#define DB 0xDB
+
+/*
+ * Following are used to distinguish between module ioctls, this is needed
+ * in case new ioctls are introduced.
+ */
+#define DB_MODULE_MASK 0xE0
+#define DB_IOC_MASK0x1F
+
+/* Ioctl module masks */
+#define DB_MGR 0x0
+#define DB_PROC0x20
+#define DB_NODE0x40
+#define DB_STRM0x60
+#define DB_CMM 0x80
+
+#define DB_MODULE_SHIFT5
+
+/* Used to calculate the ioctl per dspbridge module */
+#define DB_IOC(module, num) \
+ (((module) & DB_MODULE_MASK) | ((num) & DB_IOC_MASK))
+/* Used to get dspbridge ioctl module */
+#define DB_GET_MODULE(cmd) ((cmd) & DB_MODULE_MASK)
+/* Used to get dspbridge ioctl number */
+#define DB_GET_IOC(cmd)((cmd) & DB_IOC_MASK)
/* TODO: Remove deprecated and not implemented */
-/* MGR module offsets */
-#define CMD_MGR_BASE_OFFSET CMD_BASE
-#define CMD_MGR_ENUMNODE_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 0)
-#define CMD_MGR_ENUMPROC_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 1)
-#define CMD_MGR_REGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 2)
-#define CMD_MGR_UNREGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 3)
-#define CMD_MGR_WAIT_OFFSET (CMD_MGR_BASE_OFFSET + 4)
-
-#ifndef RES_CLEANUP_DISABLE
-#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)/*
Deprecated */
-#define CMD_MGR_END_OFFSET CMD_MGR_RESOUCES_OFFSET
-#else
-#define CMD_MGR_END_OFFSET CMD_MGR_WAIT_OFFSET
-#endif
-
-#define CMD_PROC_BASE_OFFSET (CMD_MGR_END_OFFSET + 1)
-#define CMD_PROC_ATTACH_OFFSET (CMD_PROC_BASE_OFFSET + 0)
-#define CMD_PROC_CTRL_OFFSET (CMD_PROC_BASE_OFFSET + 1)
-#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2) /* Deprecated */
-#define CMD_PROC_ENUMNODE_OFFSET (CMD_PROC_BASE_OFFSET + 3)
-#define CMD_PROC_ENUMRESOURCES_OFFSET (CMD_PROC_BASE_OFFSET + 4)
-#define CMD_PROC_GETSTATE_OFFSET (CMD_PROC_BASE_OFFSET + 5)
-#define CMD_PROC_GETTRACE_OFFSET (CMD_PROC_BASE_OFFSET + 6)
-#define CMD_PROC_LOAD_OFFSET (CMD_PROC_BASE_OFFSET + 7)
-#define CMD_PROC_REGISTERNOTIFY_OFFSET (CMD_PROC_BASE_OFFSET + 8)
-#define CMD_PROC_START_OFFSET (CMD_PROC_BASE_OFFSET + 9)
-#define CMD_PROC_RSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 10)
-#define CMD_PROC_UNRSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 11)
-#define CMD_PROC_MAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 12)
-#define CMD_PROC_UNMAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 13)
-#define CMD_PROC_FLUSHMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 14)
-#define CMD_PROC_STOP_OFFSET (CMD_PROC_BASE_OFFSET + 15)
-#define CMD_PROC_INVALIDATEMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 16)
-#define CMD_PROC_END_OFFSET CMD_PROC_INVALIDATEMEMORY_OFFSET
-
-
-#define CMD_NODE_BASE_OFFSET (CMD_PROC_END_OFFSET + 1)
-#define CMD_NODE_ALLOCATE_OFFSET (CMD_NODE_BASE_OFFSET + 0)
-#define CMD_NODE_ALLOCMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 1)
-#define CMD_NODE_CHANGEPRIORITY_OFFSET (CMD_NODE_BASE_OFFSET + 2)
-#define CMD_NODE_CONNECT_OFFSET (CMD_NODE_BASE_OFFSET + 3)
-#define CMD_NODE_CREATE_OFFSET (CMD_NODE_BASE_OFFSET + 4)
-#define CMD_NODE_DELETE_OFFSET (CMD_NODE_BASE_OFFSET + 5)
-#define CMD_NODE_FREEMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 6)
-#define CMD_NODE_GETATTR_OFFSET (CMD_NODE_BASE_OFFSET + 7)
-#define CMD_NODE_GETMESSAGE_OFFSET
Re: [PATCH v3 7/7] DSPBRIDGE: remove WCD_Cmd structure
Ramirez Luna, Omar had written, on 01/11/2010 07:00 PM, the following:
Remove WCD_Cmd structure given that only one member is being
used (fxn call), this structure is replaced for a definition
of an array of function pointers for each dspbridge ioctl
module.
Signed-off-by: Omar Ramirez Luna
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/pmgr/wcd.c | 134 +++-
1 files changed, 64 insertions(+), 70 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 27e8e8e..37d1f8a 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -147,12 +147,6 @@
/* Used to get dspbridge ioctl table */
#define DB_GET_IOC_TABLE(cmd) (DB_GET_MODULE(cmd) >> DB_MODULE_SHIFT)
-/* Device IOCtl function pointer */
-struct WCD_Cmd {
- u32(*fxn)(union Trapped_Args *args, void *pr_ctxt);
- u32 dwIndex;
-} ;
-
/* --- Globals */
#if GT_TRACE
static struct GT_Mask WCD_debugMask = { NULL, NULL }; /* Core VxD Mask */
@@ -167,80 +161,80 @@ static u32 WCD_cRefs;
*/
/* MGR wrapper functions */
-static struct WCD_Cmd mgr_cmd[] = {
- {MGRWRAP_EnumNode_Info},/* MGR_ENUMNODE_INFO */
- {MGRWRAP_EnumProc_Info},/* MGR_ENUMPROC_INFO */
- {MGRWRAP_RegisterObject}, /* MGR_REGISTEROBJECT */
- {MGRWRAP_UnregisterObject}, /* MGR_UNREGISTEROBJECT */
- {MGRWRAP_WaitForBridgeEvents}, /* MGR_WAIT */
+static u32 (*mgr_cmd[])(union Trapped_Args *args, void *pr_ctxt) = {
agreed that we dont need dwIndex anymore and struct wrapper is an
overhead, but, just being a nitpick again, but is'nt typedef a necessary
evil at this point to ensure that all cmd_ function pointers are of the
same style for each of the arrays?
--
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 1/3] OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies
Nishanth Menon writes:
[...]
>>> nitpick: I think you need {} for the else part too now a days..
>>
>> you mean as a CodingStyle issue, or a compiler issue?
>> do you have a reference for this requirement?
>>
>> do you mean if the 'if' part has {}, the else part should too, even if
>> it's a single line?
>>
>> I don't really care one way or the other, just want to know more about
>> what you're suggesting.
> Apologies on the obscure comment. I meant Coding style.
> Documentation/CodingStyle says:
>
> 171 This does not apply if one branch of a conditional statement is a
> single
> 172 statement. Use braces in both branches.
> 173
> 174 if (condition) {
> 175 do_this();
> 176 do_that();
> 177 } else {
> 178 otherwise();
> 179 }
doh, looks like I should've RTFM.
Thanks for the pointer.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies
Kevin Hilman had written, on 01/11/2010 06:50 PM, the following:
Nishanth Menon writes:
Kevin Hilman said the following on 01/08/2010 05:26 PM:
First, this patch adds new worst-case latency values to the
omap_device_pm_latency struct. Here the worst-case measured latencies
for the activate and deactivate hooks are stored.
In addition, add an option to auto-adjust the latency values used for
device activate/deactivate.
By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the
omap_device_pm_latency struct, the omap_device layer automatically
adjusts the activate/deactivate latencies to the worst-case measured
values.
Anytime a new worst-case value is found, it is printed to the console.
Here is an example log during boot using UART2 s an example. After
boot, the OPP is manually changed to the 125MHz OPP:
[...]
Freeing init memory: 128K
omap_device: serial8250.2: new worst case deactivate latency 0: 30517
omap_device: serial8250.2: new worst case activate latency 0: 30517
omap_device: serial8250.2: new worst case activate latency 0: 218139648
omap_device: serial8250.2: new worst case deactivate latency 0: 61035
omap_device: serial8250.2: new worst case activate latency 0: 278076171
omap_device: serial8250.2: new worst case activate latency 0: 298614501
omap_device: serial8250.2: new worst case activate latency 0: 327331542
/ # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
omap_device: serial8250.2: new worst case deactivate latency 0: 91552
Motivation: this can be used as a technique to automatically determine
the worst case latency values. The current method of printing a
warning on every violation is too noisy to actually interact the
console in order to set low OPP to discover latencies.
Another motivation for this patch is that the activate/deactivate
latenices can vary depending on the idlemode of the device. While
working on the UARTs, I noticed that when using no-idle, the activate
latencies were as high as several hundred msecs as shown above. When
the UARTs are in smart-idle, the max latency is well under 100 usecs.
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |4 ++
arch/arm/plat-omap/omap_device.c | 41 -
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index dc1fac1..76d4917 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -131,11 +131,15 @@ int omap_device_enable_clocks(struct omap_device *od);
*/
struct omap_device_pm_latency {
u32 deactivate_lat;
+ u32 deactivate_lat_worst;
int (*deactivate_func)(struct omap_device *od);
u32 activate_lat;
+ u32 activate_lat_worst;
int (*activate_func)(struct omap_device *od);
+ u32 flags;
};
+#define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
/* Get omap_device pointer from platform_device pointer */
#define to_omap_device(x) container_of((x), struct omap_device, pdev)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 1e5648d..d8c75c8 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -148,10 +148,22 @@ static int _omap_device_activate(struct omap_device *od,
u8 ignore_lat)
"%llu nsec\n", od->pdev.name, od->pm_lat_level,
act_lat);
- WARN(act_lat > odpl->activate_lat, "omap_device:
%s.%d: "
-"activate step %d took longer than expected (%llu > %d)\n",
-od->pdev.name, od->pdev.id, od->pm_lat_level,
-act_lat, odpl->activate_lat);
+ if (act_lat > odpl->activate_lat) {
+ odpl->activate_lat_worst = act_lat;
+ if (odpl->flags & OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
+ odpl->activate_lat = act_lat;
+ pr_warning("omap_device: %s.%d: new worst case "
+ "activate latency %d: %llu\n",
+ od->pdev.name, od->pdev.id,
+ od->pm_lat_level, act_lat);
nitpicky dumb comment: since the flags say auto adjust, do you care to
make this just a pr_info instead of a warning. it is not the same
severity as latency>activate_latency without AUTO_ADJUST right?
Agreed, will change to pr_info()
Thanks.
+ } else
+ pr_warning("omap_device: %s.%d: activate "
+ "latency %d higher than exptected. "
+ "(%llu > %d)\n",
+ od->pdev.name, od->pdev.id,
+ od->pm_lat_level, act_lat,
+
Re: [PATCH v3]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Hi,
Few more comments below.
* Vimal Singh [100111 02:47]:
> On Mon, Jan 11, 2010 at 4:10 PM, Vimal Singh wrote:
> > Re-summiting this patch. After re-basing on LO master.
> >
> > -vimal
> >
> >
> > From a7ea8851fe96690c9322393eb35a344853992166 Mon Sep 17 00:00:00 2001
> > From: Vimal Singh
> > Date: Mon, 11 Jan 2010 16:01:29 +0530
> > Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
> >
> > Introducing 'gpmc-nand.c' for GPMC specific NAND init.
> > For example: GPMC timing parameters and all.
> > This patch also migrates gpmc related calls from 'nand/omap2.c'
> > to 'gpmc-nand.c'.
> >
> > Signed-off-by: Vimal Singh
> > ---
> > arch/arm/mach-omap2/Makefile | 3 +
> > arch/arm/mach-omap2/gpmc-nand.c | 136
> >
> > arch/arm/plat-omap/include/plat/nand.h | 6 ++
> > drivers/mtd/nand/omap2.c | 26 +--
> > 4 files changed, 148 insertions(+), 23 deletions(-)
> > create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
>
>
> Patch got line wrapped. Corrected it below.
>
> From a7ea8851fe96690c9322393eb35a344853992166 Mon Sep 17 00:00:00 2001
> From: Vimal Singh
> Date: Mon, 11 Jan 2010 16:01:29 +0530
> Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
>
> Introducing 'gpmc-nand.c' for GPMC specific NAND init.
> For example: GPMC timing parameters and all.
> This patch also migrates gpmc related calls from 'nand/omap2.c'
> to 'gpmc-nand.c'.
>
> Signed-off-by: Vimal Singh
> ---
> arch/arm/mach-omap2/Makefile |3 +
> arch/arm/mach-omap2/gpmc-nand.c| 136
>
> arch/arm/plat-omap/include/plat/nand.h |6 ++
> drivers/mtd/nand/omap2.c | 26 +--
> 4 files changed, 148 insertions(+), 23 deletions(-)
> create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index b32678b..247438b 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -119,5 +119,8 @@ obj-y += usb-ehci.o
> onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
> obj-y+= $(onenand-m) $(onenand-y)
>
> +nand-$(CONFIG_MTD_NAND_OMAP2):= gpmc-nand.o
> +obj-y+= $(nand-m) $(nand-y)
> +
> smc91x-$(CONFIG_SMC91X) := gpmc-smc91x.o
> obj-y+= $(smc91x-m) $(smc91x-y)
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> new file mode 100644
> index 000..822ba82
> --- /dev/null
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -0,0 +1,136 @@
> +/*
> + * gpmc-nand.c
> + *
> + * Copyright (C) 2009 Texas Instruments
> + * Vimal Singh
> + *
> + * 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
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define WR_RD_PIN_MONITORING 0x0060
> +
> +static struct omap_nand_platform_data *gpmc_nand_data;
> +
> +static struct resource gpmc_nand_resource = {
> + .flags = IORESOURCE_MEM,
> +};
> +
> +static struct platform_device gpmc_nand_device = {
> + .name = "omap2-nand",
> + .id = 0,
> + .num_resources = 1,
> + .resource = &gpmc_nand_resource,
> +};
> +
> +static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
> +{
> + struct gpmc_timings t;
> + int err;
> +
> + const int cs_rd_off = 36;
> + const int cs_wr_off = 36;
> + const int adv_on = 6;
> + const int adv_rd_off = 24;
> + const int adv_wr_off = 36;
> + const int oe_off = 48;
> + const int we_off = 30;
> + const int rd_cycle = 72;
> + const int wr_cycle = 72;
> + const int access = 54;
> + const int wr_data_mux_bus = 0;
> + const int wr_access = 30;
> +
> + memset(&t, 0, sizeof(t));
> + t.sync_clk = 0;
> + t.cs_on = 0;
> + t.adv_on = gpmc_round_ns_to_ticks(adv_on);
> +
> + /* Read */
> + t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
> + t.oe_on = t.adv_on;
> + t.access = gpmc_round_ns_to_ticks(access);
> + t.oe_off = gpmc_round_ns_to_ticks(oe_off);
> + t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
> + t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
> +
> + /* Write */
> + t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
> + t.we_on = t.oe_on;
> + if (cpu_is_omap34xx()) {
> + t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
> + t.wr_access = gpmc_round_ns_to_ticks(wr_access);
> + }
> + t.we_off = gpmc_round_ns_to_ticks(we_off);
> + t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
> + t.wr_cycle =
[PATCH v3 0/7] misc patches (for ioctl and ssi)
Ioctl numbers has changed, this will require an update on libbridge and clients accesing directly to the driver - IO_ADDRESS is replaced for ioremap. *v3 - modified: DSPBRIDGE: replace IO_ADDRESS with ioremap, checking the result of ioremap (http://marc.info/?l=linux-omap&m=126324914710445&w=2). DSPBRIDGE: Use _IOxx macro to define ioctls (as per Nishanth comments) - new patch: DSPBRIDGE: remove WCD_Cmd structure *v2 - dropped from the series: DSPBRIDGE: Increased DMM size to 256MB DSPBRIDGE: sysfs entry for global driver state - will be kept in bridge-pm DSPBRIDGE: Use dspbridge to initialize platform data DSPBRIDGE: change to cpufreq_register_notifier for OPP changes DSPBRIDGE: Fix header locations mach to plat - previously acked DSPBRIDGE: Remove unused hDrvObject in bridge_[open|release] Omar Ramirez Luna (7): DSPBRIDGE: replace IO_ADDRESS with ioremap DSPBRIDGE: Replace magic numbers in SSI configuration DSPBRIDGE: Mark unused ioctls as deprecated DSPBRIDGE: remove ioctl runtime check DSPBRIDGE: Rename pResult to result for WCD_CallDevIOCtl DSPBRIDGE: Use _IOxx macro to define ioctls DSPBRIDGE: remove WCD_Cmd structure arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 184 ++--- drivers/dsp/bridge/pmgr/wcd.c | 250 ++- drivers/dsp/bridge/rmgr/drv_interface.c |3 - drivers/dsp/bridge/services/clk.c | 27 ++- 4 files changed, 274 insertions(+), 190 deletions(-) CC: Nishanth Menon CC: Hiroshi Doyu CC: Ameya Palande CC: 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
[PATCH v3 2/7] DSPBRIDGE: Replace magic numbers in SSI configuration
Rename ssi_sysconfig variable and replace the usage of magic
numbers while updating SSI configuration.
Signed-off-by: Omar Ramirez Luna
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/services/clk.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 21a61d8..d6b2259 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -58,6 +58,10 @@ typedef volatile unsigned long REG_UWORD32;
#define OMAP_SSI_SIZE 0x1000
#define OMAP_SSI_SYSCONFIG_OFFSET 0x10
+#define SSI_AUTOIDLE (1 << 0)
+#define SSI_SIDLE_SMARTIDLE(2 << 3)
+#define SSI_MIDLE_NOIDLE (1 << 12)
+
struct SERVICES_Clk_t {
struct clk *clk_handle;
const char *clk_name;
@@ -353,8 +357,8 @@ s32 CLK_Get_UseCnt(IN enum SERVICES_ClkId clk_id)
void SSI_Clk_Prepare(bool FLAG)
{
- u32 ssi_sysconfig;
void __iomem *ssi_base;
+ unsigned int value;
ssi_base = ioremap(L4_34XX_BASE + OMAP_SSI_OFFSET, OMAP_SSI_SIZE);
if (!ssi_base) {
@@ -366,14 +370,14 @@ void SSI_Clk_Prepare(bool FLAG)
/* Set Autoidle, SIDLEMode to smart idle, and MIDLEmode to
* no idle
*/
- ssi_sysconfig = 0x1011;
+ value = SSI_AUTOIDLE | SSI_SIDLE_SMARTIDLE | SSI_MIDLE_NOIDLE;
} else {
/* Set Autoidle, SIDLEMode to forced idle, and MIDLEmode to
* forced idle
*/
- ssi_sysconfig = 0x1;
+ value = SSI_AUTOIDLE;
}
- __raw_writel(ssi_sysconfig, ssi_base + OMAP_SSI_SYSCONFIG_OFFSET);
+ __raw_writel(value, ssi_base + OMAP_SSI_SYSCONFIG_OFFSET);
iounmap(ssi_base);
}
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] DSPBRIDGE: Rename pResult to result for WCD_CallDevIOCtl
Trivial cleanup, rename pResult to result for WCD_CallDevIOCtl
Signed-off-by: Omar Ramirez Luna
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/pmgr/wcd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 960b3cb..02def74 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -271,11 +271,11 @@ static inline void __cp_to_usr(void __user *to, const
void *from,
* Call the (wrapper) function for the corresponding WCD IOCTL.
*/
inline DSP_STATUS WCD_CallDevIOCtl(u32 cmd, union Trapped_Args *args,
- u32 *pResult, void *pr_ctxt)
+ u32 *result, void *pr_ctxt)
{
if (cmd < ARRAY_SIZE(WCD_cmdTable)) {
/* make the fxn call via the cmd table */
- *pResult = (*WCD_cmdTable[cmd].fxn) (args, pr_ctxt);
+ *result = (*WCD_cmdTable[cmd].fxn) (args, pr_ctxt);
return DSP_SOK;
}
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] DSPBRIDGE: Use _IOxx macro to define ioctls
- Use standard convention to define ioctls.
Currently 0xDB is used as identifier for dspbridge.
Discussion:
http://marc.info/?l=linux-omap&m=126297631603035&w=2
WARNING:
An update in api ioctl definitions is required, usually replacing
to a new libbridge (with ioctl patch) should be enough. Other
clients (not using libbridge) need to update their ioctl numbers
manually.
Signed-off-by: Omar Ramirez Luna
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 181 -
drivers/dsp/bridge/pmgr/wcd.c | 200 +++
drivers/dsp/bridge/rmgr/drv_interface.c |3 -
3 files changed, 237 insertions(+), 147 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index 4b9dd0a..656d56b 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -437,86 +437,109 @@ union Trapped_Args {
} ARGS_UTIL_TESTDLL;
} ;
-#define CMD_BASE 1
+/*
+ * Dspbridge Ioctl numbering scheme
+ *
+ *7 0
+ * -
+ * | Module | Ioctl Number|
+ * -
+ * | x | x | x | 0 | 0 | 0 | 0 | 0 |
+ * -
+ */
+
+/* Ioctl driver identifier */
+#define DB 0xDB
+
+/*
+ * Following are used to distinguish between module ioctls, this is needed
+ * in case new ioctls are introduced.
+ */
+#define DB_MODULE_MASK 0xE0
+#define DB_IOC_MASK0x1F
+
+/* Ioctl module masks */
+#define DB_MGR 0x0
+#define DB_PROC0x20
+#define DB_NODE0x40
+#define DB_STRM0x60
+#define DB_CMM 0x80
+
+#define DB_MODULE_SHIFT5
+
+/* Used to calculate the ioctl per dspbridge module */
+#define DB_IOC(module, num) \
+ (((module) & DB_MODULE_MASK) | ((num) & DB_IOC_MASK))
+/* Used to get dspbridge ioctl module */
+#define DB_GET_MODULE(cmd) ((cmd) & DB_MODULE_MASK)
+/* Used to get dspbridge ioctl number */
+#define DB_GET_IOC(cmd)((cmd) & DB_IOC_MASK)
/* TODO: Remove deprecated and not implemented */
-/* MGR module offsets */
-#define CMD_MGR_BASE_OFFSET CMD_BASE
-#define CMD_MGR_ENUMNODE_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 0)
-#define CMD_MGR_ENUMPROC_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 1)
-#define CMD_MGR_REGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 2)
-#define CMD_MGR_UNREGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 3)
-#define CMD_MGR_WAIT_OFFSET (CMD_MGR_BASE_OFFSET + 4)
-
-#ifndef RES_CLEANUP_DISABLE
-#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)/*
Deprecated */
-#define CMD_MGR_END_OFFSET CMD_MGR_RESOUCES_OFFSET
-#else
-#define CMD_MGR_END_OFFSET CMD_MGR_WAIT_OFFSET
-#endif
-
-#define CMD_PROC_BASE_OFFSET (CMD_MGR_END_OFFSET + 1)
-#define CMD_PROC_ATTACH_OFFSET (CMD_PROC_BASE_OFFSET + 0)
-#define CMD_PROC_CTRL_OFFSET (CMD_PROC_BASE_OFFSET + 1)
-#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2) /* Deprecated */
-#define CMD_PROC_ENUMNODE_OFFSET (CMD_PROC_BASE_OFFSET + 3)
-#define CMD_PROC_ENUMRESOURCES_OFFSET (CMD_PROC_BASE_OFFSET + 4)
-#define CMD_PROC_GETSTATE_OFFSET (CMD_PROC_BASE_OFFSET + 5)
-#define CMD_PROC_GETTRACE_OFFSET (CMD_PROC_BASE_OFFSET + 6)
-#define CMD_PROC_LOAD_OFFSET (CMD_PROC_BASE_OFFSET + 7)
-#define CMD_PROC_REGISTERNOTIFY_OFFSET (CMD_PROC_BASE_OFFSET + 8)
-#define CMD_PROC_START_OFFSET (CMD_PROC_BASE_OFFSET + 9)
-#define CMD_PROC_RSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 10)
-#define CMD_PROC_UNRSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 11)
-#define CMD_PROC_MAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 12)
-#define CMD_PROC_UNMAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 13)
-#define CMD_PROC_FLUSHMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 14)
-#define CMD_PROC_STOP_OFFSET (CMD_PROC_BASE_OFFSET + 15)
-#define CMD_PROC_INVALIDATEMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 16)
-#define CMD_PROC_END_OFFSET CMD_PROC_INVALIDATEMEMORY_OFFSET
-
-
-#define CMD_NODE_BASE_OFFSET (CMD_PROC_END_OFFSET + 1)
-#define CMD_NODE_ALLOCATE_OFFSET (CMD_NODE_BASE_OFFSET + 0)
-#define CMD_NODE_ALLOCMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 1)
-#define CMD_NODE_CHANGEPRIORITY_OFFSET (CMD_NODE_BASE_OFFSET + 2)
-#define CMD_NODE_CONNECT_OFFSET (CMD_NODE_BASE_OFFSET + 3)
-#define CMD_NODE_CREATE_OFFSET (CMD_NODE_BASE_OFFSET + 4)
-#define CMD_NODE_DELETE_OFFSET (CMD_NODE_BASE_OFFSET + 5)
-#define CMD_NODE_FREEMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 6)
-#define CMD_NODE_GETATTR_OFFSET (CMD_NODE_BASE_OFFSET + 7)
-#define CMD_NODE_GETMESSAGE_OFFSET (CMD_NODE_BASE_OFFSET + 8)
-#define CMD_NODE_PAUSE_OFFSET (CMD_NODE_BASE_OFFSET + 9)
-#define CMD_
[PATCH v3 7/7] DSPBRIDGE: remove WCD_Cmd structure
Remove WCD_Cmd structure given that only one member is being
used (fxn call), this structure is replaced for a definition
of an array of function pointers for each dspbridge ioctl
module.
Signed-off-by: Omar Ramirez Luna
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/pmgr/wcd.c | 134 +++-
1 files changed, 64 insertions(+), 70 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 27e8e8e..37d1f8a 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -147,12 +147,6 @@
/* Used to get dspbridge ioctl table */
#define DB_GET_IOC_TABLE(cmd) (DB_GET_MODULE(cmd) >> DB_MODULE_SHIFT)
-/* Device IOCtl function pointer */
-struct WCD_Cmd {
- u32(*fxn)(union Trapped_Args *args, void *pr_ctxt);
- u32 dwIndex;
-} ;
-
/* --- Globals */
#if GT_TRACE
static struct GT_Mask WCD_debugMask = { NULL, NULL }; /* Core VxD Mask */
@@ -167,80 +161,80 @@ static u32 WCD_cRefs;
*/
/* MGR wrapper functions */
-static struct WCD_Cmd mgr_cmd[] = {
- {MGRWRAP_EnumNode_Info},/* MGR_ENUMNODE_INFO */
- {MGRWRAP_EnumProc_Info},/* MGR_ENUMPROC_INFO */
- {MGRWRAP_RegisterObject}, /* MGR_REGISTEROBJECT */
- {MGRWRAP_UnregisterObject}, /* MGR_UNREGISTEROBJECT */
- {MGRWRAP_WaitForBridgeEvents}, /* MGR_WAIT */
+static u32 (*mgr_cmd[])(union Trapped_Args *args, void *pr_ctxt) = {
+ MGRWRAP_EnumNode_Info, /* MGR_ENUMNODE_INFO */
+ MGRWRAP_EnumProc_Info, /* MGR_ENUMPROC_INFO */
+ MGRWRAP_RegisterObject, /* MGR_REGISTEROBJECT */
+ MGRWRAP_UnregisterObject, /* MGR_UNREGISTEROBJECT */
+ MGRWRAP_WaitForBridgeEvents,/* MGR_WAIT */
#ifndef RES_CLEANUP_DISABLE
- {MGRWRAP_GetProcessResourcesInfo}, /* MGR_GET_PROC_RES */
+ MGRWRAP_GetProcessResourcesInfo,/* MGR_GET_PROC_RES */
#else
- {NULL},
+ NULL,
#endif
};
/* PROC wrapper functions */
-static struct WCD_Cmd proc_cmd[] = {
- {PROCWRAP_Attach}, /* PROC_ATTACH */
- {PROCWRAP_Ctrl},/* PROC_CTRL */
- {PROCWRAP_Detach}, /* PROC_DETACH */
- {PROCWRAP_EnumNode_Info}, /* PROC_ENUMNODE */
- {PROCWRAP_EnumResources}, /* PROC_ENUMRESOURCES */
- {PROCWRAP_GetState},/* PROC_GET_STATE */
- {PROCWRAP_GetTrace},/* PROC_GET_TRACE */
- {PROCWRAP_Load},/* PROC_LOAD */
- {PROCWRAP_RegisterNotify}, /* PROC_REGISTERNOTIFY */
- {PROCWRAP_Start}, /* PROC_START */
- {PROCWRAP_ReserveMemory}, /* PROC_RSVMEM */
- {PROCWRAP_UnReserveMemory}, /* PROC_UNRSVMEM */
- {PROCWRAP_Map}, /* PROC_MAPMEM */
- {PROCWRAP_UnMap}, /* PROC_UNMAPMEM */
- {PROCWRAP_FlushMemory}, /* PROC_FLUSHMEMORY */
- {PROCWRAP_Stop},/* PROC_STOP */
- {PROCWRAP_InvalidateMemory},/* PROC_INVALIDATEMEMORY */
+static u32 (*proc_cmd[])(union Trapped_Args *args, void *pr_ctxt) = {
+ PROCWRAP_Attach,/* PROC_ATTACH */
+ PROCWRAP_Ctrl, /* PROC_CTRL */
+ PROCWRAP_Detach,/* PROC_DETACH */
+ PROCWRAP_EnumNode_Info, /* PROC_ENUMNODE */
+ PROCWRAP_EnumResources, /* PROC_ENUMRESOURCES */
+ PROCWRAP_GetState, /* PROC_GET_STATE */
+ PROCWRAP_GetTrace, /* PROC_GET_TRACE */
+ PROCWRAP_Load, /* PROC_LOAD */
+ PROCWRAP_RegisterNotify,/* PROC_REGISTERNOTIFY */
+ PROCWRAP_Start, /* PROC_START */
+ PROCWRAP_ReserveMemory, /* PROC_RSVMEM */
+ PROCWRAP_UnReserveMemory, /* PROC_UNRSVMEM */
+ PROCWRAP_Map, /* PROC_MAPMEM */
+ PROCWRAP_UnMap, /* PROC_UNMAPMEM */
+ PROCWRAP_FlushMemory, /* PROC_FLUSHMEMORY */
+ PROCWRAP_Stop, /* PROC_STOP */
+ PROCWRAP_InvalidateMemory, /* PROC_INVALIDATEMEMORY */
};
/* NODE wrapper functions */
-static struct WCD_Cmd node_cmd[] = {
- {NODEWRAP_Allocate},/* NODE_ALLOCATE */
- {NODEWRAP_AllocMsgBuf}, /* NODE_ALLOCMSGBUF */
- {NODEWRAP_ChangePriority}, /* NODE_CHANGEPRIORITY */
- {NODEWRAP_Connect}, /* NODE_CONNECT */
- {NODEWRAP_Create},
[PATCH v3 1/7] DSPBRIDGE: replace IO_ADDRESS with ioremap
Use ioremap() instead of using IO_ADDRESS macro to make it generic.
Signed-off-by: Omar Ramirez Luna
CC: Tony Lindgren
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/services/clk.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index d1c68fc..21a61d8 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -54,10 +54,9 @@
typedef volatile unsigned long REG_UWORD32;
-#define SSI_Base0x48058000
-
-#define SSI_BASE IO_ADDRESS(SSI_Base)
-
+#define OMAP_SSI_OFFSET0x58000
+#define OMAP_SSI_SIZE 0x1000
+#define OMAP_SSI_SYSCONFIG_OFFSET 0x10
struct SERVICES_Clk_t {
struct clk *clk_handle;
@@ -355,7 +354,13 @@ s32 CLK_Get_UseCnt(IN enum SERVICES_ClkId clk_id)
void SSI_Clk_Prepare(bool FLAG)
{
u32 ssi_sysconfig;
- ssi_sysconfig = __raw_readl((SSI_BASE) + 0x10);
+ void __iomem *ssi_base;
+
+ ssi_base = ioremap(L4_34XX_BASE + OMAP_SSI_OFFSET, OMAP_SSI_SIZE);
+ if (!ssi_base) {
+ pr_err("%s: error, SSI not configured\n", __func__);
+ return;
+ }
if (FLAG) {
/* Set Autoidle, SIDLEMode to smart idle, and MIDLEmode to
@@ -368,5 +373,7 @@ void SSI_Clk_Prepare(bool FLAG)
*/
ssi_sysconfig = 0x1;
}
- __raw_writel((u32)ssi_sysconfig, SSI_BASE + 0x10);
+
+ __raw_writel(ssi_sysconfig, ssi_base + OMAP_SSI_SYSCONFIG_OFFSET);
+ iounmap(ssi_base);
}
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] DSPBRIDGE: Mark unused ioctls as deprecated
Mark unused ioctls as deprecated for future removal
and print an error message whenever they are used.
Signed-off-by: Omar Ramirez Luna
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 11 --
drivers/dsp/bridge/pmgr/wcd.c | 38 +--
2 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index 04b13ab..4b9dd0a 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -439,6 +439,8 @@ union Trapped_Args {
#define CMD_BASE 1
+/* TODO: Remove deprecated and not implemented */
+
/* MGR module offsets */
#define CMD_MGR_BASE_OFFSET CMD_BASE
#define CMD_MGR_ENUMNODE_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 0)
@@ -448,7 +450,7 @@ union Trapped_Args {
#define CMD_MGR_WAIT_OFFSET (CMD_MGR_BASE_OFFSET + 4)
#ifndef RES_CLEANUP_DISABLE
-#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)
+#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)/*
Deprecated */
#define CMD_MGR_END_OFFSET CMD_MGR_RESOUCES_OFFSET
#else
#define CMD_MGR_END_OFFSET CMD_MGR_WAIT_OFFSET
@@ -457,7 +459,7 @@ union Trapped_Args {
#define CMD_PROC_BASE_OFFSET (CMD_MGR_END_OFFSET + 1)
#define CMD_PROC_ATTACH_OFFSET (CMD_PROC_BASE_OFFSET + 0)
#define CMD_PROC_CTRL_OFFSET (CMD_PROC_BASE_OFFSET + 1)
-#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2)
+#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2) /* Deprecated */
#define CMD_PROC_ENUMNODE_OFFSET (CMD_PROC_BASE_OFFSET + 3)
#define CMD_PROC_ENUMRESOURCES_OFFSET (CMD_PROC_BASE_OFFSET + 4)
#define CMD_PROC_GETSTATE_OFFSET (CMD_PROC_BASE_OFFSET + 5)
@@ -497,6 +499,7 @@ union Trapped_Args {
#define CMD_STRM_ALLOCATEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 0)
#define CMD_STRM_CLOSE_OFFSET (CMD_STRM_BASE_OFFSET + 1)
#define CMD_STRM_FREEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 2)
+/* Not Impl'd */
#define CMD_STRM_GETEVENTHANDLE_OFFSET (CMD_STRM_BASE_OFFSET + 3)
#define CMD_STRM_GETINFO_OFFSET (CMD_STRM_BASE_OFFSET + 4)
#define CMD_STRM_IDLE_OFFSET (CMD_STRM_BASE_OFFSET + 5)
@@ -509,8 +512,8 @@ union Trapped_Args {
/* Communication Memory Manager (UCMM) */
#define CMD_CMM_BASE_OFFSET (CMD_STRM_END_OFFSET + 1)
-#define CMD_CMM_ALLOCBUF_OFFSET (CMD_CMM_BASE_OFFSET + 0)
-#define CMD_CMM_FREEBUF_OFFSET (CMD_CMM_BASE_OFFSET + 1)
+#define CMD_CMM_ALLOCBUF_OFFSET (CMD_CMM_BASE_OFFSET + 0)/* Not
Impl'd */
+#define CMD_CMM_FREEBUF_OFFSET (CMD_CMM_BASE_OFFSET + 1) /* Not Impl'd */
#define CMD_CMM_GETHANDLE_OFFSET (CMD_CMM_BASE_OFFSET + 2)
#define CMD_CMM_GETINFO_OFFSET (CMD_CMM_BASE_OFFSET + 3)
#define CMD_CMM_END_OFFSET CMD_CMM_GETINFO_OFFSET
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 7226b5a..f95980b 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -456,6 +456,8 @@ DSP_STATUS WCD_InitComplete2(void)
return status;
}
+/* TODO: Remove deprecated and not implemented ioctl wrappers */
+
/*
* MGRWRAP_EnumNode_Info
*/
@@ -634,21 +636,11 @@ u32 MGRWRAP_WaitForBridgeEvents(union Trapped_Args *args,
void *pr_ctxt)
/*
* MGRWRAP_GetProcessResourceInfo
*/
-u32 MGRWRAP_GetProcessResourcesInfo(union Trapped_Args *args, void *pr_ctxt)
+u32 __deprecated MGRWRAP_GetProcessResourcesInfo(union Trapped_Args *args,
+ void *pr_ctxt)
{
-DSP_STATUS status = DSP_SOK;
-u32 uSize = 0;
-u8 *pBuf = MEM_Alloc(8092, MEM_NONPAGED);
-GT_1trace(WCD_debugMask, GT_ENTER,
-"MGRWRAP_GetProcessResourcesInfo:uSize=%d :\n", uSize);
-cp_to_usr(args->ARGS_PROC_GETTRACE.pBuf, pBuf, status, uSize);
-GT_0trace(WCD_debugMask, GT_ENTER, "\n***"
-"123MGRWRAP_GetProcessResourcesInfo:**\n");
-GT_0trace(WCD_debugMask, GT_ENTER, "\n***"
-"456MGRWRAP_GetProcessResourcesInfo:**\n");
-cp_to_usr(args->ARGS_PROC_GETTRACE.pSize, &uSize, status, 1);
-MEM_Free(pBuf);
-return status;
+ pr_err("%s: deprecated dspbridge ioctl\n", __func__);
+ return DSP_SOK;
}
#endif
@@ -732,14 +724,10 @@ func_end:
/*
* PROCWRAP_Detach
*/
-u32 PROCWRAP_Detach(union Trapped_Args *args, void *pr_ctxt)
+u32 __deprecated PROCWRAP_Detach(union Trapped_Args *args, void *pr_ctxt)
{
- GT_1trace(WCD_debugMask, GT_ENTER,
-"PROCWRAP_Detach: entered args\n0x%x "
-"hProceesor \n", args->ARGS_PROC_DETACH.hProcessor);
-
/* PROC_Detach called at bridge_release only */
-
+ pr_err("%s: deprecated dspbridge ioc
[PATCH v3 4/7] DSPBRIDGE: remove ioctl runtime check
This patch removes the runtime check of device
ioctl array.
Signed-off-by: Omar Ramirez Luna
CC: Nishanth Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/pmgr/wcd.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index f95980b..960b3cb 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -321,13 +321,7 @@ bool WCD_Init(void)
bool fInit = true;
bool fDRV, fDEV, fCOD, fSERVICES, fCHNL, fMSG, fIO;
bool fMGR, fPROC, fNODE, fDISP, fNTFY, fSTRM, fRMM;
-#ifdef DEBUG
- /* runtime check of Device IOCtl array. */
- u32 i;
- for (i = 1; i < ARRAY_SIZE(WCD_cmdTable); i++)
- DBC_Assert(WCD_cmdTable[i - 1].dwIndex == i);
-#endif
if (WCD_cRefs == 0) {
/* initialize all SERVICES modules */
fSERVICES = SERVICES_Init();
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies
Nishanth Menon writes:
> Kevin Hilman said the following on 01/08/2010 05:26 PM:
>> First, this patch adds new worst-case latency values to the
>> omap_device_pm_latency struct. Here the worst-case measured latencies
>> for the activate and deactivate hooks are stored.
>>
>> In addition, add an option to auto-adjust the latency values used for
>> device activate/deactivate.
>>
>> By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the
>> omap_device_pm_latency struct, the omap_device layer automatically
>> adjusts the activate/deactivate latencies to the worst-case measured
>> values.
>>
>> Anytime a new worst-case value is found, it is printed to the console.
>> Here is an example log during boot using UART2 s an example. After
>> boot, the OPP is manually changed to the 125MHz OPP:
>>
>> [...]
>> Freeing init memory: 128K
>> omap_device: serial8250.2: new worst case deactivate latency 0: 30517
>> omap_device: serial8250.2: new worst case activate latency 0: 30517
>> omap_device: serial8250.2: new worst case activate latency 0: 218139648
>> omap_device: serial8250.2: new worst case deactivate latency 0: 61035
>> omap_device: serial8250.2: new worst case activate latency 0: 278076171
>> omap_device: serial8250.2: new worst case activate latency 0: 298614501
>> omap_device: serial8250.2: new worst case activate latency 0: 327331542
>>
>> / # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
>>
>> omap_device: serial8250.2: new worst case deactivate latency 0: 91552
>>
>> Motivation: this can be used as a technique to automatically determine
>> the worst case latency values. The current method of printing a
>> warning on every violation is too noisy to actually interact the
>> console in order to set low OPP to discover latencies.
>>
>> Another motivation for this patch is that the activate/deactivate
>> latenices can vary depending on the idlemode of the device. While
>> working on the UARTs, I noticed that when using no-idle, the activate
>> latencies were as high as several hundred msecs as shown above. When
>> the UARTs are in smart-idle, the max latency is well under 100 usecs.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>> arch/arm/plat-omap/include/plat/omap_device.h |4 ++
>> arch/arm/plat-omap/omap_device.c | 41
>> -
>> 2 files changed, 37 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
>> b/arch/arm/plat-omap/include/plat/omap_device.h
>> index dc1fac1..76d4917 100644
>> --- a/arch/arm/plat-omap/include/plat/omap_device.h
>> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
>> @@ -131,11 +131,15 @@ int omap_device_enable_clocks(struct omap_device *od);
>> */
>> struct omap_device_pm_latency {
>> u32 deactivate_lat;
>> +u32 deactivate_lat_worst;
>> int (*deactivate_func)(struct omap_device *od);
>> u32 activate_lat;
>> +u32 activate_lat_worst;
>> int (*activate_func)(struct omap_device *od);
>> +u32 flags;
>> };
>> +#define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
>> /* Get omap_device pointer from platform_device pointer */
>> #define to_omap_device(x) container_of((x), struct omap_device, pdev)
>> diff --git a/arch/arm/plat-omap/omap_device.c
>> b/arch/arm/plat-omap/omap_device.c
>> index 1e5648d..d8c75c8 100644
>> --- a/arch/arm/plat-omap/omap_device.c
>> +++ b/arch/arm/plat-omap/omap_device.c
>> @@ -148,10 +148,22 @@ static int _omap_device_activate(struct omap_device
>> *od, u8 ignore_lat)
>> "%llu nsec\n", od->pdev.name, od->pm_lat_level,
>> act_lat);
>> - WARN(act_lat > odpl->activate_lat, "omap_device:
>> %s.%d: "
>> - "activate step %d took longer than expected (%llu > %d)\n",
>> - od->pdev.name, od->pdev.id, od->pm_lat_level,
>> - act_lat, odpl->activate_lat);
>> +if (act_lat > odpl->activate_lat) {
>> +odpl->activate_lat_worst = act_lat;
>> +if (odpl->flags & OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
>> +odpl->activate_lat = act_lat;
>> +pr_warning("omap_device: %s.%d: new worst case "
>> + "activate latency %d: %llu\n",
>> + od->pdev.name, od->pdev.id,
>> + od->pm_lat_level, act_lat);
>>
> nitpicky dumb comment: since the flags say auto adjust, do you care to
> make this just a pr_info instead of a warning. it is not the same
> severity as latency>activate_latency without AUTO_ADJUST right?
Agreed, will change to pr_info()
>> +} else
>> +pr_warning("omap_device: %s.%d: activate "
>> + "latency %d higher than exptected. "
>> + "(%llu > %d)\n",
>> + o
[PATCH 3/5] AM35xx: Clock table updates for AM3505/17
From: Ranjith Lohithakshan
AM3505/17 though a OMAP3530 derivative have the following
main differences
- Removal of the following OMAP3 modules
- IVA
- ISP/CAM
- Modem and D2D components (MAD2D, SAD2D)
- USIM
- SSI
- Mailboxes
- USB OTG
- ICR
- MSPRO
- SmartReflex
- SDRC replaced with EMIF4 Controller in the SDRC subsystem
thus adding support for DDR2 memory devices
- Addition of the following new modules
- Ethernet MAC (CPGMAC)
- CAN Controller (HECC)
- New USB OTG Controller with integrated Phy
- Video Processing Front End (VPFE)
- Additional UART (UART4)
- All security accelerators disabled on GP devices and not to
be accessed or configured
This patch defines CPU flags for AM3505/17 and update the clock table.
Clock support for new modules will be added by subsequent patches.
Signed-off-by: Ranjith Lohithakshan
[p...@pwsan.com: updated for 2.6.34 clock layout]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock34xx_data.c | 353 +-
1 files changed, 180 insertions(+), 173 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 59b0903..409d445 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -2992,139 +2992,140 @@ static struct clk wdt1_fck = {
* clkdev
*/
-static struct omap_clk omap34xx_clks[] = {
- CLK(NULL, "omap_32k_fck", &omap_32k_fck, CK_343X),
- CLK(NULL, "virt_12m_ck", &virt_12m_ck, CK_343X),
- CLK(NULL, "virt_13m_ck", &virt_13m_ck, CK_343X),
- CLK(NULL, "virt_16_8m_ck", &virt_16_8m_ck, CK_3430ES2),
- CLK(NULL, "virt_19_2m_ck", &virt_19_2m_ck, CK_343X),
- CLK(NULL, "virt_26m_ck", &virt_26m_ck, CK_343X),
- CLK(NULL, "virt_38_4m_ck", &virt_38_4m_ck, CK_343X),
- CLK(NULL, "osc_sys_ck", &osc_sys_ck,CK_343X),
- CLK(NULL, "sys_ck", &sys_ck,CK_343X),
- CLK(NULL, "sys_altclk", &sys_altclk,CK_343X),
- CLK(NULL, "mcbsp_clks", &mcbsp_clks,CK_343X),
- CLK(NULL, "sys_clkout1", &sys_clkout1, CK_343X),
- CLK(NULL, "dpll1_ck", &dpll1_ck, CK_343X),
- CLK(NULL, "dpll1_x2_ck", &dpll1_x2_ck, CK_343X),
- CLK(NULL, "dpll1_x2m2_ck", &dpll1_x2m2_ck, CK_343X),
+/* XXX At some point we should rename this file to clock3xxx_data.c */
+static struct omap_clk omap3xxx_clks[] = {
+ CLK(NULL, "omap_32k_fck", &omap_32k_fck, CK_3XXX),
+ CLK(NULL, "virt_12m_ck", &virt_12m_ck, CK_3XXX),
+ CLK(NULL, "virt_13m_ck", &virt_13m_ck, CK_3XXX),
+ CLK(NULL, "virt_16_8m_ck", &virt_16_8m_ck, CK_3430ES2 |
CK_AM35XX),
+ CLK(NULL, "virt_19_2m_ck", &virt_19_2m_ck, CK_3XXX),
+ CLK(NULL, "virt_26m_ck", &virt_26m_ck, CK_3XXX),
+ CLK(NULL, "virt_38_4m_ck", &virt_38_4m_ck, CK_3XXX),
+ CLK(NULL, "osc_sys_ck", &osc_sys_ck,CK_3XXX),
+ CLK(NULL, "sys_ck", &sys_ck,CK_3XXX),
+ CLK(NULL, "sys_altclk", &sys_altclk,CK_3XXX),
+ CLK(NULL, "mcbsp_clks", &mcbsp_clks,CK_3XXX),
+ CLK(NULL, "sys_clkout1", &sys_clkout1, CK_3XXX),
+ CLK(NULL, "dpll1_ck", &dpll1_ck, CK_3XXX),
+ CLK(NULL, "dpll1_x2_ck", &dpll1_x2_ck, CK_3XXX),
+ CLK(NULL, "dpll1_x2m2_ck", &dpll1_x2m2_ck, CK_3XXX),
CLK(NULL, "dpll2_ck", &dpll2_ck, CK_343X),
CLK(NULL, "dpll2_m2_ck", &dpll2_m2_ck, CK_343X),
- CLK(NULL, "dpll3_ck", &dpll3_ck, CK_343X),
- CLK(NULL, "core_ck", &core_ck, CK_343X),
- CLK(NULL, "dpll3_x2_ck", &dpll3_x2_ck, CK_343X),
- CLK(NULL, "dpll3_m2_ck", &dpll3_m2_ck, CK_343X),
- CLK(NULL, "dpll3_m2x2_ck", &dpll3_m2x2_ck, CK_343X),
- CLK(NULL, "dpll3_m3_ck", &dpll3_m3_ck, CK_343X),
- CLK(NULL, "dpll3_m3x2_ck", &dpll3_m3x2_ck, CK_343X),
- CLK("etb", "emu_core_alwon_ck", &emu_core_alwon_ck, CK_343X),
- CLK(NULL, "dpll4_ck", &dpll4_ck, CK_343X),
- CLK(NULL, "dpll4_x2_ck", &dpll4_x2_ck, CK_343X),
- CLK(NULL, "omap_96m_alwon_fck", &omap_96m_alwon_fck, CK_343X),
- CLK(NULL, "omap_96m_fck", &omap_96m_fck, CK_343X),
- CLK(NULL, "cm_96m_fck", &cm_96m_fck,CK_343X),
- CLK(NULL, "omap_54m_fck", &omap_54m_fck, CK_343X),
- CLK(NULL, "omap_48m_fck", &omap_48m_fck, CK_343X),
- CLK(NULL, "omap_12m_fck", &omap_12m_fck, CK_343X),
[PATCH 4/5] OMAP clock: make the fixed divisor clock code available for all OMAPs
One of the OMAP1 clocks can use the fixed divisor recalculation code
introduced in the OMAP2 clock code, so rename the
omap2_fixed_divisor_recalc() function to omap_fixed_divisor_recalc()
and make it available to all OMAPs. A followup patch converts the OMAP1
clock.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock.c | 11 ---
arch/arm/mach-omap2/clock.h |1 -
arch/arm/mach-omap2/clock2xxx_data.c|4 ++--
arch/arm/mach-omap2/clock34xx_data.c|6 +++---
arch/arm/plat-omap/clock.c | 11 +++
arch/arm/plat-omap/include/plat/clock.h |3 ++-
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 759c72a..7565f8e 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -300,17 +300,6 @@ u32 omap2_get_dpll_rate(struct clk *clk)
return dpll_clk;
}
-/*
- * Used for clocks that have the same value as the parent clock,
- * divided by some factor
- */
-unsigned long omap2_fixed_divisor_recalc(struct clk *clk)
-{
- WARN_ON(!clk->fixed_div);
-
- return clk->parent->rate / clk->fixed_div;
-}
-
/**
* omap2_clk_dflt_find_companion - find companion clock to @clk
* @clk: struct clk * to find the companion clock of
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 93c48df..0d70dc0 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -78,7 +78,6 @@ u32 omap2_clksel_round_rate_div(struct clk *clk, unsigned
long target_rate,
u32 *new_div);
u32 omap2_clksel_to_divisor(struct clk *clk, u32 field_val);
u32 omap2_divisor_to_clksel(struct clk *clk, u32 div);
-unsigned long omap2_fixed_divisor_recalc(struct clk *clk);
long omap2_clksel_round_rate(struct clk *clk, unsigned long target_rate);
int omap2_clksel_set_rate(struct clk *clk, unsigned long rate);
u32 omap2_get_dpll_rate(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock2xxx_data.c
b/arch/arm/mach-omap2/clock2xxx_data.c
index 97dc7cf..402115f 100644
--- a/arch/arm/mach-omap2/clock2xxx_data.c
+++ b/arch/arm/mach-omap2/clock2xxx_data.c
@@ -261,7 +261,7 @@ static struct clk func_12m_ck = {
.parent = &func_48m_ck,
.fixed_div = 4,
.clkdm_name = "wkup_clkdm",
- .recalc = &omap2_fixed_divisor_recalc,
+ .recalc = &omap_fixed_divisor_recalc,
};
/* Secure timer, only available in secure mode */
@@ -557,7 +557,7 @@ static struct clk iva1_mpu_int_ifck = {
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP2420_EN_IVA_MPU_SHIFT,
.fixed_div = 2,
- .recalc = &omap2_fixed_divisor_recalc,
+ .recalc = &omap_fixed_divisor_recalc,
};
/*
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 409d445..856b44c 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -736,7 +736,7 @@ static struct clk omap_12m_fck = {
.ops= &clkops_null,
.parent = &omap_48m_fck,
.fixed_div = 4,
- .recalc = &omap2_fixed_divisor_recalc,
+ .recalc = &omap_fixed_divisor_recalc,
};
/* This virstual clock is the source for dpll4_m4x2_ck */
@@ -1592,7 +1592,7 @@ static struct clk ssi_sst_fck_3430es1 = {
.ops= &clkops_null,
.parent = &ssi_ssr_fck_3430es1,
.fixed_div = 2,
- .recalc = &omap2_fixed_divisor_recalc,
+ .recalc = &omap_fixed_divisor_recalc,
};
static struct clk ssi_sst_fck_3430es2 = {
@@ -1600,7 +1600,7 @@ static struct clk ssi_sst_fck_3430es2 = {
.ops= &clkops_null,
.parent = &ssi_ssr_fck_3430es2,
.fixed_div = 2,
- .recalc = &omap2_fixed_divisor_recalc,
+ .recalc = &omap_fixed_divisor_recalc,
};
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index d9f8c84..e0f72f4 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -199,6 +199,17 @@ unsigned long followparent_recalc(struct clk *clk)
return clk->parent->rate;
}
+/*
+ * Used for clocks that have the same value as the parent clock,
+ * divided by some factor
+ */
+unsigned long omap_fixed_divisor_recalc(struct clk *clk)
+{
+ WARN_ON(!clk->fixed_div);
+
+ return clk->parent->rate / clk->fixed_div;
+}
+
void clk_reparent(struct clk *child, struct clk *parent)
{
list_del_init(&child->sibling);
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 94fe2a0..896cedc 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -88,9 +88,9 @@ struct clk {
void(*init)(struct clk *);
__u8
[PATCH 5/5] OMAP1 clock: convert armwdt_ck to use the fixed divisor recalc function
The armwdt_ck clock uses a fixed divisor, so it can use the OMAP clock
fixed divisor recalculation code, rather than a custom function.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap1/clock.c |6 --
arch/arm/mach-omap1/clock_data.c |3 ++-
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 2ba9ab9..5b735b2 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -52,12 +52,6 @@ const struct clkops clkops_dummy = {
.disable= clk_omap1_dummy_disable,
};
-/* XXX can be replaced with a fixed_divisor_recalc */
-unsigned long omap1_watchdog_recalc(struct clk *clk)
-{
- return clk->parent->rate / 14;
-}
-
unsigned long omap1_uart_recalc(struct clk *clk)
{
unsigned int val = __raw_readl(clk->enable_reg);
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 65e7b5b..edefb34 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -149,7 +149,8 @@ static struct arm_idlect1_clk armwdt_ck = {
.flags = CLOCK_IDLE_CONTROL,
.enable_reg = OMAP1_IO_ADDRESS(ARM_IDLECT2),
.enable_bit = EN_WDTCK,
- .recalc = &omap1_watchdog_recalc,
+ .fixed_div = 14,
+ .recalc = &omap_fixed_divisor_recalc,
},
.idlect_shift = 0,
};
--
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] Some OMAP clock/SCM patches for 2.6.34
Hi, these patches have been posted on the linux-omap mailing list and are part of the planned queue for 2.6.34, but are being posted here in the event that anyone else wishes to comment. These patches include clock support for the Sitara platform (AM35xx) and some minor clock code improvements. - Paul --- Paul Walmsley (3): OMAP3 clock: reorganize CK_* platform flags OMAP clock: make the fixed divisor clock code available for all OMAPs OMAP1 clock: convert armwdt_ck to use the fixed divisor recalc function Ranjith Lohithakshan (2): AM35xx: Add AM35xx specific control module registers AM35xx: Clock table updates for AM3505/17 arch/arm/mach-omap1/clock.c |6 arch/arm/mach-omap1/clock_data.c |3 arch/arm/mach-omap2/clock.c | 11 - arch/arm/mach-omap2/clock.h |1 arch/arm/mach-omap2/clock2xxx_data.c |4 arch/arm/mach-omap2/clock34xx_data.c | 365 + arch/arm/plat-omap/clock.c| 11 + arch/arm/plat-omap/include/plat/clkdev_omap.h | 26 +- arch/arm/plat-omap/include/plat/clock.h |3 arch/arm/plat-omap/include/plat/control.h | 17 + 10 files changed, 237 insertions(+), 210 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP3 clock: reorganize CK_* platform flags
Add CK_* flags for the two new Sitara chips, AM3505 and AM3517, and
the OMAP34xx die shrink, OMAP36xx/OMAP37xx. Introduce a new CK_*
flag, CK_3XXX, that marks all clocks that are common to OMAP3 family
chips. CK_343X now refers to clocks that are available only on
OMAP34{1,2,3,4}0 (WTBU) and OMAP35{03,15,25,30} (any version).
At some point, the RATE_IN_* flags should be updated also.
While here, add some documentation describing the chip families
covered by these clock flags.
This patch is partially based on patches from Ranjith Lohithakshan
and Vishwanath Sripathy .
Signed-off-by: Paul Walmsley
Cc: Ranjith Lohithakshan
Cc: Vishwanath Sripathy
---
arch/arm/mach-omap2/clock34xx_data.c |4 ++--
arch/arm/plat-omap/include/plat/clkdev_omap.h | 26 -
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index c6031d7..59b0903 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3220,11 +3220,11 @@ int __init omap2_clk_init(void)
/* struct prcm_config *prcm; */
struct omap_clk *c;
/* u32 clkrate; */
- u32 cpu_clkflg;
+ u32 cpu_clkflg = CK_3XXX;
if (cpu_is_omap34xx()) {
cpu_mask = RATE_IN_343X;
- cpu_clkflg = CK_343X;
+ cpu_clkflg |= CK_343X;
/*
* Update this if there are further clock changes between ES2
diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h
b/arch/arm/plat-omap/include/plat/clkdev_omap.h
index 35b36ca..bb937f3 100644
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -25,17 +25,25 @@ struct omap_clk {
}, \
}
-
+/* Platform flags for the clkdev-OMAP integration code */
#define CK_310 (1 << 0)
-#define CK_7XX (1 << 1)
+#define CK_7XX (1 << 1)/* 7xx, 850 */
#define CK_1510(1 << 2)
-#define CK_16XX(1 << 3)
-#define CK_243X(1 << 4)
-#define CK_242X(1 << 5)
-#define CK_343X(1 << 6)
-#define CK_3430ES1 (1 << 7)
-#define CK_3430ES2 (1 << 8)
-#define CK_443X(1 << 9)
+#define CK_16XX(1 << 3)/* 16xx, 17xx, 5912 */
+#define CK_242X(1 << 4)
+#define CK_243X(1 << 5)
+#define CK_3XXX(1 << 6)/* OMAP3 + AM3 common clocks*/
+#define CK_343X(1 << 7)/* OMAP34xx common clocks */
+#define CK_3430ES1 (1 << 8)/* 34xxES1 only */
+#define CK_3430ES2 (1 << 9)/* 34xxES2, ES3, non-Sitara 35xx only */
+#define CK_3505(1 << 10)
+#define CK_3517(1 << 11)
+#define CK_36XX(1 << 12) /* OMAP36xx/37xx-specific
clocks */
+#define CK_443X(1 << 13)
+
+#define CK_AM35XX (CK_3505 | CK_3517) /* all Sitara AM35xx */
+
+
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] AM35xx: Add AM35xx specific control module registers
From: Ranjith Lohithakshan AM3517/05 has a few additional control module registers defined mainly to control the new IP's. This patch adds support for those new registers. Signed-off-by: Ranjith Lohithakshan Signed-off-by: Paul Walmsley --- arch/arm/plat-omap/include/plat/control.h | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h index a745d62..61e7b8a 100644 --- a/arch/arm/plat-omap/include/plat/control.h +++ b/arch/arm/plat-omap/include/plat/control.h @@ -160,6 +160,14 @@ #define OMAP343X_CONTROL_SRAMLDO5 (OMAP2_CONTROL_GENERAL + 0x02C0) #define OMAP343X_CONTROL_CSI (OMAP2_CONTROL_GENERAL + 0x02C4) +/* AM35XX only CONTROL_GENERAL register offsets */ +#define AM35XX_CONTROL_MSUSPENDMUX_6(OMAP2_CONTROL_GENERAL + 0x0038) +#define AM35XX_CONTROL_DEVCONF2 (OMAP2_CONTROL_GENERAL + 0x0310) +#define AM35XX_CONTROL_DEVCONF3 (OMAP2_CONTROL_GENERAL + 0x0314) +#define AM35XX_CONTROL_CBA_PRIORITY (OMAP2_CONTROL_GENERAL + 0x0320) +#define AM35XX_CONTROL_LVL_INTR_CLEAR (OMAP2_CONTROL_GENERAL + 0x0324) +#define AM35XX_CONTROL_IP_SW_RESET (OMAP2_CONTROL_GENERAL + 0x0328) +#define AM35XX_CONTROL_IPSS_CLK_CTRL(OMAP2_CONTROL_GENERAL + 0x032C) /* 34xx PADCONF register offsets */ #define OMAP343X_PADCONF_ETK(i)(OMAP2_CONTROL_PADCONFS + 0x5a8 + \ @@ -257,6 +265,15 @@ #define OMAP343X_SCRATCHPAD(OMAP343X_CTRL_BASE + 0x910) #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C +/* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ +#define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 +#define AM35XX_CPGMAC_VBUSP_CLK_SHIFT 1 +#define AM35XX_VPFE_VBUSP_CLK_SHIFT 2 +#define AM35XX_HECC_VBUSP_CLK_SHIFT 3 +#define AM35XX_USBOTG_FCLK_SHIFT8 +#define AM35XX_CPGMAC_FCLK_SHIFT9 +#define AM35XX_VPFE_FCLK_SHIFT 10 + /* * CONTROL OMAP STATUS register to identify OMAP3 features */ -- 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] Remove unnecessarily .init initializers from OMAP3 clocks
On Sun, 10 Jan 2010, Russell King - ARM Linux wrote: > The first thing that omap2_init_clksel_parent() does is check for > a non-zero .clksel field in the struct clk. Therefore, it is > pointless calling this function on clocks where the clksel field > is unset. > > Remove init calls to omap2_init_clksel_parent() on clocks without > a clksel field. > > Signed-off-by: Russell King Thanks, queuing for .33-rc. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Power Domains: Remove the return as power domain framework is in place
* Pagare, Abhijit [100110 21:57]:
> Sergio,
> I have taken care of that in my other patches, which I had posted
> earlier. They are not in mainline yet but are lined up for the next release.
> You can find the same here.
>
> http://marc.info/?l=linux-omap&m=126088474831309&w=2
>
> Do let me know if you have any further questions.
Please update your other patch to include this change.
Regards,
Tony
>
> Best Regards,
> Abhijit Pagare
>
> > -Original Message-
> > From: Aguirre, Sergio
> > Sent: Friday, January 08, 2010 7:31 PM
> > To: Pagare, Abhijit; linux-omap@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org
> > Cc: Paul Walmsley
> > Subject: RE: [PATCH] ARM: OMAP4: Power Domains: Remove the return as power
> > domain framework is in place
> >
> > Abhijit,
> >
> > > -Original Message-
> > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > ow...@vger.kernel.org] On Behalf Of Pagare, Abhijit
> > > Sent: Friday, January 08, 2010 5:59 AM
> > > To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > > Cc: Pagare, Abhijit; Paul Walmsley
> > > Subject: [PATCH] ARM: OMAP4: Power Domains: Remove the return as power
> > > domain framework is in place
> > >
> > > The return prevents the power domains from getting registered.
> > > Hence removing it to allow the frameworks model to work.
> > >
> > > Signed-off-by: Abhijit Pagare
> > > Cc: Paul Walmsley
> > > ---
> > >
> > > Compiled and Boot Tested on OMAP4430 simulator and ES1 Chip
> > > Compiled and Boot Tested on OMAP3430 SDP
> > > Compiled for OMAP2430 and OMAP2420
> > >
> > > arch/arm/mach-omap2/id.c |1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > > index a779240..6d1e97b 100644
> > > --- a/arch/arm/mach-omap2/id.c
> > > +++ b/arch/arm/mach-omap2/id.c
> > > @@ -362,7 +362,6 @@ void __init omap2_check_revision(void)
> > > omap3_cpuinfo();
> > > } else if (cpu_is_omap44xx()) {
> > > omap4_check_revision();
> > > - return;
> > > } else {
> > > pr_err("OMAP revision unknown, please fix!\n");
> > > }
> >
> > I don't have an OMAP4 with me, but I found something weird in your
> > reported behaviour...
> >
> > The code that was being skipped is:
> >
> > /*
> > * OK, now we know the exact revision. Initialize omap_chip bits
> > * for powerdowmain and clockdomain code.
> > */
> > if (cpu_is_omap243x()) {
> > /* Currently only supports 2430ES2.1 and 2430-all */
> > omap_chip.oc |= CHIP_IS_OMAP2430;
> > } else if (cpu_is_omap242x()) {
> > /* Currently only supports 2420ES2.1.1 and 2420-all */
> > omap_chip.oc |= CHIP_IS_OMAP2420;
> > } else if (cpu_is_omap3505() || cpu_is_omap3517()) {
> > omap_chip.oc = CHIP_IS_OMAP3430 | CHIP_IS_OMAP3430ES3_1;
> > } else if (cpu_is_omap343x()) {
> > omap_chip.oc = CHIP_IS_OMAP3430;
> > if (omap_rev() == OMAP3430_REV_ES1_0)
> > omap_chip.oc |= CHIP_IS_OMAP3430ES1;
> > else if (omap_rev() >= OMAP3430_REV_ES2_0 &&
> > omap_rev() <= OMAP3430_REV_ES2_1)
> > omap_chip.oc |= CHIP_IS_OMAP3430ES2;
> > else if (omap_rev() == OMAP3430_REV_ES3_0)
> > omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
> > else if (omap_rev() == OMAP3430_REV_ES3_1)
> > omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
> > else if (omap_rev() == OMAP3630_REV_ES1_0)
> > omap_chip.oc |= CHIP_IS_OMAP3630ES1;
> > } else {
> > pr_err("Uninitialized omap_chip, please fix!\n");
> > }
> >
> > And, in theory, in OMAP4 case, you SHOULDN'T be doing anything here, as
> > there's no case for cpu_is_omap443x or similar. So you should be _only_
> > seeing a print in console saying: "Uninitialized omap_chip, please fix!",
> > right?
> >
> > Is OMAP4 chip giving positive on cpu_is_omap343x() test then??
> >
> > Regards,
> > Sergio
> > > --
> > > 1.5.4.7
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [APPLIED] [PATCH v2] omap: zoom3: enable ehci support
* Tony Lindgren [100111 15:35]:
> This patch has been applied to the linux-omap
> by youw fwiendly patch wobot.
>
> Branch in linux-omap: for-next
>
> Initial commit ID (Likely to change): 426d2accc2b9c0392b2be9b8daed5699a08d8822
>
> PatchWorks
> http://patchwork.kernel.org/patch/71641/
>
> Git (Likely to change, and takes a while to get mirrored)
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=426d2accc2b9c0392b2be9b8daed5699a08d8822
I've updated the patch with following cosmetic clean-up:
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index b691340..6512b21 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -53,14 +53,13 @@ static struct omap_board_mux board_mux[] __initdata = {
#endif
static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
- .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
- .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 64,
- .reset_gpio_port[2] = -EINVAL
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .phy_reset = true,
+ .reset_gpio_port[0] = -EINVAL,
+ .reset_gpio_port[1] = 64,
+ .reset_gpio_port[2] = -EINVAL,
};
static void __init omap_zoom_init(void)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH v2] omap: zoom3: enable ehci support
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 426d2accc2b9c0392b2be9b8daed5699a08d8822 PatchWorks http://patchwork.kernel.org/patch/71641/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=426d2accc2b9c0392b2be9b8daed5699a08d8822 -- 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
[APPLIED] [PATCH v2] omap: serial: fix coding style indentaion
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): cc802321b5288be27cebf9afec66d1d5e73fad2a PatchWorks http://patchwork.kernel.org/patch/71639/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=cc802321b5288be27cebf9afec66d1d5e73fad2a -- 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
[APPLIED] [RFC/PATCH 2/2] fix compile for tahvo-usb.c
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: cbus Initial commit ID (Likely to change): df01abf99660f3077315a1f69a462a8e46bacccb PatchWorks http://patchwork.kernel.org/patch/71704/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=df01abf99660f3077315a1f69a462a8e46bacccb -- 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 resubmit] mmc-omap: Add support for 16-bit and 32-bit registers
* Cory Maccarrone [100111 11:13]: > On Mon, Jan 11, 2010 at 2:44 AM, Ladislav Michl > wrote: > > > > This patch differs from v5 you sent earlier: > > Subject: [PATCH v5] mmc-omap: Add support for 16-bit and 32-bit registers > > Date: Mon, 23 Nov 2009 10:37:28 -0800 > > Message-Id: <1259001448-9574-1-git-send-email-darkstar6...@gmail.com> > > > > Patch below is not going to work with 32-bit wide registers. Whoever is > > going > > to apply it, please don't. Use original version referred above. > > > > > > > > This is not going to work > > Ah, right, good catch. I thought I got the same one submitted -- this > is an older one. Sorry about that. I'll add the working v5 into omap-testing so we can make sure it works with other omaps. Will not merge it further, it still needs to get to mainline via linux-mmc list. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH v2] [I2C-OMAP] Add support for 16-bit registers
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-testing Initial commit ID (Likely to change): acc580d61f84565baec4a2fdf9b9d9e88e7bf373 PatchWorks http://patchwork.kernel.org/patch/66948/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=acc580d61f84565baec4a2fdf9b9d9e88e7bf373 -- 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
[APPLIED] [PATCH] OMAP: dma_chan[lch_head].flag & OMAP_DMA_ACTIVE tested twice
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): bf9e6367f80b285100f5fecd59ec11b643d4dcf1 PatchWorks http://patchwork.kernel.org/patch/71928/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=bf9e6367f80b285100f5fecd59ec11b643d4dcf1 -- 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: dma_chan[lch_head].flag & OMAP_DMA_ACTIVE tested twice in omap_dma_unlink_lch()
* Roel Kluin [100109 05:49]:
> The same flag and bits were tested twice.
>
> Signed-off-by: Roel Kluin
> ---
> arch/arm/plat-omap/dma.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Is this what was intended? please review.
Thanks, nice catch. Will queue into omap-fixes.
Regards,
Tony
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 09d82b3..728c642 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -1183,7 +1183,7 @@ void omap_dma_unlink_lch(int lch_head, int lch_queue)
> }
>
> if ((dma_chan[lch_head].flags & OMAP_DMA_ACTIVE) ||
> - (dma_chan[lch_head].flags & OMAP_DMA_ACTIVE)) {
> + (dma_chan[lch_queue].flags & OMAP_DMA_ACTIVE)) {
> printk(KERN_ERR "omap_dma: You need to stop the DMA channels "
> "before unlinking\n");
> dump_stack();
--
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
[APPLIED] [PATCH] omap3: pm: Add T2 Keypad as a wakeup source
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 586fdb82ddef6e96ed6c21e1e13d299b99227d19 PatchWorks http://patchwork.kernel.org/patch/71563/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=586fdb82ddef6e96ed6c21e1e13d299b99227d19 -- 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
[APPLIED] > [PATCH] ARCH OMAP : enable ARCH_HAS_HOLES_MEMORYMODEL for
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 0824be87f0fea5f4be0c5fd9effc337c0741a9d6 PatchWorks http://patchwork.kernel.org/patch/71579/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0824be87f0fea5f4be0c5fd9effc337c0741a9d6 -- 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] ARCH OMAP : enable ARCH_HAS_HOLES_MEMORYMODEL for OMAP
* Govindarajan, Sriramakrishnan [100111 04:11]: > From: Menon, Nishanth > > Sent: Friday, January 08, 2010 8:33 PM > > To: Govindarajan, Sriramakrishnan > > Cc: linux-omap@vger.kernel.org; Syed Mohammed, Khasim; Nori, Sekhar > > Subject: Re: [PATCH] ARCH OMAP : enable ARCH_HAS_HOLES_MEMORYMODEL for > > OMAP > > > > Govindarajan, Sriramakrishnan had written, on 01/08/2010 02:15 AM, the > > following: > > > > > >> From: Menon, Nishanth > > >> Govindarajan, Sriramakrishnan had written, on 01/07/2010 06:30 AM, the > > >> following: > > >>> From: Sriram > > >>> > > >>> OMAP platforms(like OMAP3530) include DSP or other co-processors > > >>> for media acceleration. when carving out memory for the > > >>> accelerators we can end up creating a hole in the memory map > > >>> of sort: > > >>> > > >>> > > >>> To handle such a memory configuration ARCH_HAS_HOLES_MEMORYMODEL > > >>> has to be enabled. For further information refer discussion at: > > >>> http://www.mail-archive.com/linux-o...@vger.kernl.org/msg15262.html. > > >> pls check the link: I see "The document you were looking for was not > > >> found." > > > > > > The URL is spelt incorrectly. Here is the correct URL: > > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15262.html > > > > > >>> select GENERIC_TIME > > >>> select GENERIC_CLOCKEVENTS > > >>> + select ARCH_HAS_HOLES_MEMORYMODEL > > >> why enable this for all OMAPs? > > > > > > I have tested this on several OMAP3 platforms and this feature is > > required > > > Wherever some memory needs to be reserved for media accelerators - hence > > it > > > Would be handy for earlier OMAP platforms as well > > I understand that you have tested with OMAP3. my question is you have > > handled this as per the diff > > @@ -699,6 +699,7 @@ config ARCH_OMAP > > to ARCH_OMAP > > > > is this good for OMAP1510, 1610, 1710, 2420,2430, 770 etc..? > > I do not have other OMAP platforms for me to validate this patch on. > I believe the nature of change is generic and benefit other OMAP > Platforms as well. Sounds like the issue is a slight performance penalty when not used. But considering all the coprocessors, I'd say let's apply this so the checks are in place when using the coprocessors. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] n8x0_defconfig: active cbus, retu-wd and omap-wd
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: cbus Initial commit ID (Likely to change): 11e11147915637c01577f3a3efb6f430660a04b4 PatchWorks http://patchwork.kernel.org/patch/71532/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=11e11147915637c01577f3a3efb6f430660a04b4 -- 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] Regulator: Kconfig modified to select TWL4030 for OMAP3 based platforms
* Anuj Aggarwal [100108 09:57]: > Kconfig is modified so that PMIC TWL4030 is automatically selected for > platforms using it. It is required to compile board-omap35x-twl4030-pmic.c > in the build. Please group the patches in a way that compile works for each patch in the series. Otherwise git bisect will break. Regards, Tony > Signed-off-by: Anuj Aggarwal > --- > arch/arm/mach-omap2/Kconfig | 11 +++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 95b8eb2..ab3abc9 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -66,16 +66,19 @@ config MACH_OMAP3_BEAGLE > bool "OMAP3 BEAGLE board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select PMIC_TWL4030 > > config MACH_OMAP_LDP > bool "OMAP3 LDP board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select PMIC_TWL4030 > > config MACH_OVERO > bool "Gumstix Overo board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select PMIC_TWL4030 > > config MACH_OMAP3EVM > bool "OMAP 3530 EVM board" > @@ -100,16 +103,19 @@ config MACH_OMAP3_PANDORA > bool "OMAP3 Pandora" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select PMIC_TWL4030 > > config MACH_OMAP3_TOUCHBOOK > bool "OMAP3 Touch Book" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select BACKLIGHT_CLASS_DEVICE > + select PMIC_TWL4030 > > config MACH_OMAP_3430SDP > bool "OMAP 3430 SDP board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select PMIC_TWL4030 > > config MACH_NOKIA_N800 > bool > @@ -136,27 +142,32 @@ config MACH_OMAP_ZOOM2 > bool "OMAP3 Zoom2 board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select PMIC_TWL4030 > > config MACH_OMAP_ZOOM3 > bool "OMAP3630 Zoom3 board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBP > + select PMIC_TWL4030 > > config MACH_CM_T35 > bool "CompuLab CM-T35 module" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CUS > select OMAP_MUX > + select PMIC_TWL4030 > > config MACH_IGEP0020 > bool "IGEP0020" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select PMIC_TWL4030 > > config MACH_OMAP_3630SDP > bool "OMAP3630 SDP board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBP > + select PMIC_TWL4030 > > config MACH_OMAP_4430SDP > bool "OMAP 4430 SDP board" > -- > 1.6.2.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] DSPBRIDGE: replace IO_ADDRESS with ioremap
* Omar Ramirez Luna [100111 12:02]:
> Use ioremap() instead of using IO_ADDRESS macro to make it generic.
>
> Signed-off-by: Omar Ramirez Luna
> CC: Nishant Menon
> CC: Hiroshi Doyu
> CC: Ameya Palande
> CC: Felipe Contreras
> ---
> drivers/dsp/bridge/services/clk.c | 15 +--
> 1 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dsp/bridge/services/clk.c
> b/drivers/dsp/bridge/services/clk.c
> index d1c68fc..116e10e 100644
> --- a/drivers/dsp/bridge/services/clk.c
> +++ b/drivers/dsp/bridge/services/clk.c
> @@ -54,10 +54,9 @@
>
> typedef volatile unsigned long REG_UWORD32;
>
> -#define SSI_Base0x48058000
> -
> -#define SSI_BASE IO_ADDRESS(SSI_Base)
> -
> +#define OMAP_SSI_OFFSET 0x58000
> +#define OMAP_SSI_SIZE0x1000
> +#define OMAP_SSI_SYSCONFIG_OFFSET0x10
>
> struct SERVICES_Clk_t {
> struct clk *clk_handle;
> @@ -355,7 +354,9 @@ s32 CLK_Get_UseCnt(IN enum SERVICES_ClkId clk_id)
> void SSI_Clk_Prepare(bool FLAG)
> {
> u32 ssi_sysconfig;
> - ssi_sysconfig = __raw_readl((SSI_BASE) + 0x10);
> + void __iomem *ssi_base;
> +
> + ssi_base = ioremap(L4_34XX_BASE + OMAP_SSI_OFFSET, OMAP_SSI_SIZE);
Please check the results from ioremap. Currently we're using static mapping,
but that may not always be the case in the future.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of sysconfig register.
On Mon, 11 Jan 2010, Paul Walmsley wrote:
> Queued for .33-rc (fixes).
By the way, the patch had to be slightly tweaked to apply it since the
original was based on the configurable clockactivity offset patch - here's
what is queued in the 'for_2.6.33rc_d' branch of
git://git.pwsan.com/linux-2.6
- Paul
>From 5d121735372f9983cca1747bc0332a045151d4a8 Mon Sep 17 00:00:00 2001
From: Thara Gopinath
Date: Mon, 11 Jan 2010 15:25:05 -0700
Subject: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of sysconfig
register.
In the current implementation the sysconfig value is read into
_sysc_cache once and an actual update to the sysconfig register
happens only if the new value paased is differnt from the one in _sysc_cache.
_sysc_cache is updated only if _HWMOD_SYSCONFIG_LOADED is not set.
This can lead to the follwing issue if off mode is enabled in modules
which employs "always-retore" mechanism of context save and restore.
a. The module sets the sysconfig register through omap_device_enable.
Here _sysc_cache is updated with the value written to the sysconfig
register and left.
b. The power domain containig the module enters off mode and the
module context is lost.
c. The module in use becomes active and calls omap_device_enable to
enable itself. Here a read of sysconfig register does not happen
as _HWMOD_SYSCONFIG_LOADED flag is set. The value to be written
to the sysconfig register will be same as the one written in step a.
Since _sysc_cache reflects the previous written value an update
of the sysconfig register does not happen.
This means in modules which employs "always-restore" mechanism
after off , the sysconfig regsiters will never get updated.
This patch introduces a flag SYSC_NO_CACHE which if set ensures that the
sysconfig register is always read into _sysc_cache before an update is
attempted.
This flags need to be set only by modules which does not do a context save
but re-initializes the registers every time the module is accessed. This
includes modules like i2c, smartreflex etc.
Signed-off-by: Thara Gopinath
[p...@pwsan.com: tweaked to apply on a different head]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c |3 ++-
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d8c8545..478ae58 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -94,7 +94,8 @@ static int _update_sysc_cache(struct omap_hwmod *oh)
oh->_sysc_cache = omap_hwmod_readl(oh, oh->sysconfig->sysc_offs);
- oh->_int_flags |= _HWMOD_SYSCONFIG_LOADED;
+ if (!(oh->sysconfig->sysc_flags & SYSC_NO_CACHE))
+ oh->_int_flags |= _HWMOD_SYSCONFIG_LOADED;
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 007935a..c110c8a 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -227,6 +227,7 @@ struct omap_hwmod_ocp_if {
#define SYSC_HAS_SIDLEMODE (1 << 5)
#define SYSC_HAS_MIDLEMODE (1 << 6)
#define SYSS_MISSING (1 << 7)
+#define SYSC_NO_CACHE (1 << 8)
/* omap_hwmod_sysconfig.clockact flags */
#define CLOCKACT_TEST_BOTH 0x0
--
1.6.6.rc2.5.g49666
--
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-WIP-OPP] [PATCH] cleaner ceil function for uv to vsel conversion
Romit Dasgupta writes:
> Cleaner ceil function.
Needs better subject and better changelog.
Subject should probably be something like: OMAP:
[PATCH] OPP: TWL/TPS: optimize uv to vsel function
And changelog should describe the motiviation for the patch or a
description of the problem you're trying to solve. IOW, is this a
correctness fix, or an optimization, etc. Looks to me like it's tring
to compensate for some rounding issues, but please describe in detail
in the changelog.
Thanks,
Kevin
> Signed-off-by: Romit Dasgupta
> ---
> diff --git a/arch/arm/plat-omap/opp_twl_tps.c
> b/arch/arm/plat-omap/opp_twl_tps.c
> index e0db39b..1caa414 100644
> --- a/arch/arm/plat-omap/opp_twl_tps.c
> +++ b/arch/arm/plat-omap/opp_twl_tps.c
> @@ -36,14 +36,7 @@ unsigned long omap_twl_vsel_to_uv(const u8 vsel)
> */
> u8 omap_twl_uv_to_vsel(unsigned long uv)
> {
> - u8 vsel;
>
> - vsel = ((uv / 100) - 6000) / 125;
> + return (((uv + 99) / 100 - 6000) + 124) / 125;
>
> - /* round off to higher voltage */
> - /* XXX Surely not the best way to handle this. */
> - if (uv > omap_twl_vsel_to_uv(vsel))
> - vsel++;
> -
> - return vsel;
> }
--
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] OMAP3: hwmod: Adding flag to prevent caching of sysconfig register.
On Thu, 7 Jan 2010, Gopinath, Thara wrote: > >>-Original Message- > >>From: Paul Walmsley [mailto:p...@pwsan.com] > >>Sent: Wednesday, January 06, 2010 6:02 AM > >>To: Gopinath, Thara > >>Cc: linux-omap@vger.kernel.org > >>Subject: RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of > >>sysconfig register. > >> > >>On Wed, 23 Dec 2009, Gopinath, Thara wrote: > >> > >>> Hi Paul,Kevin.. Does this patch look ok? > >> > >>Hello Thara, > >> > >>looking over this patch. Nice job on the descriptive patch comment; > >>it explains the problem well. What do you think about a slightly > >>different approach -- that is, to add a hook to the hwmod code to > >>invalidate the cache if the module's powerdomain has lost context? > > It should be possible but I feel it is a bit cumbersome. Couple of > reasons I have. > a. Some modules like smartreflex does not have any power domain > associated with it. Aren't the SmartReflex modules in their own powerdomain that changes with the CORE powerdomain? > b. Invalidating the cache is not needed for all modules even if the > module powerdomain context is lost. This is needed only for modules > which employ always restore mechanism. All other modules will do > explicit context save and restore of its registers I think we'll want to move all SYSCONFIG manipulation into the hwmod layer, once it is in place. > c. Getting whether power domain context is lost or not is not very > straight forward. If I am not mistaken the only way is to keep tab of > the powerdomain counters through omap_pm_get_dev_context_loss_count. I > might be mistaken. Yeah. Getting the hook in will take a little bit of work. Anyway, for the time being, we can take this patch. But the other reason that this approach doesn't appeal is that this new flag doesn't have anything to do with the hardware -- it's just a software workaround for device driver code. Ideally, all of these flags should be generatable based on hardware data only. Flags that pertain to how the device driver works belong in a different place. Perhaps they should still be connected to the hwmod code, but they should exist separately from the hwmod data. Queued for .33-rc (fixes). - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits.
Hi Thara,
this mostly looks good, but there are a few things to fix:
On Mon, 11 Jan 2010, Thara Gopinath wrote:
> In OMAP3 Some modules like Smartreflex do not have the regular sysconfig
> register.Instead clockactivity bits are part of another register at a
> different bit position than the usual bit positions 8 and 9.
>
> In OMAP4, a new scheme is available due to the new protocol
> between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG
> bitfields position will be different.
> The IP_REVISION register should be at offset 0x00.
> It should contain a SCHEME field From this we can determine legacy or HL.
>
> 31:30 SCHEME Used to distinguish between old scheme and current.
> Read 0x0: Legacy ASP or WTBU scheme
> Read 0x1: Highlander 0.8 scheme
>
> For legacy IP
> 13:12 MIDLEMODE
> 11:8 CLOCKACTIVITY
> 6 EMUSOFT
> 5 EMUFREE
> 4:3 SIDLEMODE
> 2 ENAWAKEUP
> 1 SOFTRESET
> 0 AUTOIDLE
>
> For Highlander IP, the bit position in SYSCONFIG is (for simple target):
> 5:4 STANDBYMODE (Ex MIDLEMODE)
> 3:2 IDLEMODE (Ex SIDLEMODE)
> 1 FREEEMU (Ex EMUFREE)
> 0 SOFTRESET
>
> Unfortunately In OMAP4 also some IPs will not follow any of these
> two schemes. This is the case at least for McASP, SmartReflex
> and some security IPs.
>
> This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which
> can be used by the hwmod structures to specify the offsets for the
> sysconfig register of the IP.Also two static structures
> omap_hwmod_sysc_fields and omap_hwmod_sysc_highlander are defined
> which can be used directly to populate the sysc_fields if the IP follows
> legacy or highlander scheme. If the IP follows none of these two schemes
> a new omap_hwmod_sysc_fields structure has to be defined and
> passed as part of omap_hwmod_sysconfig.
>
> Signed-off-by: Thara Gopinath
> Signed-off-by: Benoit Cousson
> Signed-off-by: Paul Walmsley
I haven't signed off on this one yet :-)
> ---
>
> This patch is based off Kevin's tree origin/pm-wip/omap_device branch
>
> arch/arm/mach-omap2/omap_hwmod.c | 14 --
> arch/arm/plat-omap/include/plat/omap_hwmod.h | 26
> +-
> 2 files changed, 29 insertions(+), 11 deletions(-)
>
> Index: linux-omap-pm/arch/arm/mach-omap2/omap_hwmod.c
> ===
> --- linux-omap-pm.orig/arch/arm/mach-omap2/omap_hwmod.c
> +++ linux-omap-pm/arch/arm/mach-omap2/omap_hwmod.c
> @@ -135,12 +135,23 @@ static void _write_sysconfig(u32 v, stru
> static int _set_master_standbymode(struct omap_hwmod *oh, u8 standbymode,
> u32 *v)
> {
> + u32 mstandby_mask = 0;
> + u8 mstandby_shift = 0;
There's no reason these variables, or the similar variables below, need to
be pre-initialized to zero. Hopefully the compiler would optimize these
assignments out, but in any case, please remove them, unless they are
absolutely needed.
> +
> if (!oh->sysconfig ||
> !(oh->sysconfig->sysc_flags & SYSC_HAS_MIDLEMODE))
> return -EINVAL;
>
> - *v &= ~SYSC_MIDLEMODE_MASK;
> - *v |= __ffs(standbymode) << SYSC_MIDLEMODE_SHIFT;
> + if (!oh->sysconfig->sysc_fields) {
> + pr_warning("offset struct for sysconfig not provided\n");
Maybe consider WARN() instead? That way, the user can see a stack dump
and know what the offending function is.
> + return -EINVAL;
> + }
> +
> + mstandby_shift = oh->sysconfig->sysc_fields->midle_shift;
> + mstandby_mask = (0x3 << mstandby_shift);
> +
> + *v &= ~mstandby_mask;
> + *v |= __ffs(standbymode) << mstandby_shift;
>
> return 0;
> }
> @@ -157,12 +168,22 @@ static int _set_master_standbymode(struc
> */
> static int _set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode, u32 *v)
> {
> + u32 sidle_mask = 0;
> + u8 sidle_shift = 0;
See above re: unnecessary assignment
> +
> if (!oh->sysconfig ||
> !(oh->sysconfig->sysc_flags & SYSC_HAS_SIDLEMODE))
> return -EINVAL;
>
> - *v &= ~SYSC_SIDLEMODE_MASK;
> - *v |= __ffs(idlemode) << SYSC_SIDLEMODE_SHIFT;
> + if (!oh->sysconfig->sysc_fields) {
> + pr_warning("offset struct for sysconfig not provided\n");
> + return -EINVAL;
> + }
Please add a blank line after closing this code block, as you did above
> + sidle_shift = oh->sysconfig->sysc_fields->sidle_shift;
> + sidle_mask = (0x3 << sidle_shift);
> +
> + *v &= ~sidle_mask;
> + *v |= __ffs(idlemode) << sidle_shift;
>
> return 0;
> }
> @@ -180,12 +201,22 @@ static int _set_slave_idlemode(struct om
> */
> static int _set_clockactivity(struct omap_hwmod *oh, u8 clockact, u32 *v)
> {
> + u32 clkact_mask = 0;
> + u8 clkact_shift = 0;
See above re: unnecessary assignment
> +
> if (!oh->sysconfig ||
> !(oh->sysconfig->sysc_flags & SY
RE: [PATCH 3/3] omap iommu: fix incorrect address for supersection 1st entry
Hi Hiroshi,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU
> Sent: Monday, January 11, 2010 1:47 AM
> To: linux-omap@vger.kernel.org
> Cc: Nagalla, Hari; Hiroshi DOYU
> Subject: [PATCH 3/3] omap iommu: fix incorrect address for supersection
> 1st entry
>
> From: Hiroshi DOYU
... and description missing here too.
Regards,
Sergio
>
> Signed-off-by: Hiroshi DOYU
> Signed-off-by: Hari Nagalla
> ---
> arch/arm/plat-omap/iommu.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index ccf25b3..ce0072a 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -667,7 +667,7 @@ static size_t iopgtable_clear_entry_core(struct iommu
> *obj, u32 da)
> if ((*iopgd & IOPGD_SUPER) == IOPGD_SUPER) {
> nent *= 16;
> /* rewind to the 1st entry */
> - iopgd = (u32 *)((u32)iopgd & IOSUPER_MASK);
> + iopgd = iopgd_offset(obj, (da & IOSUPER_MASK));
> }
> bytes *= nent;
> }
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] omap iommu: fix incorrect address for large page 1st entry
Hi Hiroshi,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU
> Sent: Monday, January 11, 2010 1:47 AM
> To: linux-omap@vger.kernel.org
> Cc: Nagalla, Hari; Hiroshi DOYU
> Subject: [PATCH 2/3] omap iommu: fix incorrect address for large page 1st
> entry
>
> From: Hiroshi DOYU
Description missing here aswell.
Regards,
Sergio
>
> Reported-by: Hari Nagalla
> Signed-off-by: Hiroshi DOYU
> Signed-off-by: Hari Nagalla
> ---
> arch/arm/plat-omap/iommu.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index c0ff1e3..ccf25b3 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -1,7 +1,7 @@
> /*
> * omap iommu: tlb and pagetable primitives
> *
> - * Copyright (C) 2008-2009 Nokia Corporation
> + * Copyright (C) 2008-2010 Nokia Corporation
> *
> * Written by Hiroshi DOYU ,
> * Paul Mundt and Toshihiro Kobayashi
> @@ -646,7 +646,7 @@ static size_t iopgtable_clear_entry_core(struct iommu
> *obj, u32 da)
> if (*iopte & IOPTE_LARGE) {
> nent *= 16;
> /* rewind to the 1st entry */
> - iopte = (u32 *)((u32)iopte & IOLARGE_MASK);
> + iopte = iopte_offset(iopgd, (da & IOLARGE_MASK));
> }
> bytes *= nent;
> memset(iopte, 0, nent * sizeof(*iopte));
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] omap iommu: cleanup iommu page address mask and definitions
Hi Hiroshi, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU > Sent: Monday, January 11, 2010 1:47 AM > To: linux-omap@vger.kernel.org > Cc: Nagalla, Hari; Hiroshi DOYU > Subject: [PATCH 1/3] omap iommu: cleanup iommu page address mask and > definitions > > From: Hiroshi DOYU Maybe a small description would help here... Are you just reshuffling defines, or are you also adding new ones? Is this just a cleanup or is it fixing a hidden bug? Regards, Sergio > > Signed-off-by: Hiroshi DOYU > --- > arch/arm/plat-omap/iopgtable.h | 50 +++ > > 1 files changed, 39 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/plat-omap/iopgtable.h b/arch/arm/plat- > omap/iopgtable.h > index 37dac43..ab23b6a 100644 > --- a/arch/arm/plat-omap/iopgtable.h > +++ b/arch/arm/plat-omap/iopgtable.h > @@ -1,7 +1,7 @@ > /* > * omap iommu: pagetable definitions > * > - * Copyright (C) 2008-2009 Nokia Corporation > + * Copyright (C) 2008-2010 Nokia Corporation > * > * Written by Hiroshi DOYU > * > @@ -13,26 +13,52 @@ > #ifndef __PLAT_OMAP_IOMMU_H > #define __PLAT_OMAP_IOMMU_H > > +/* > + * "L2 table" address mask and size definitions. > + */ > #define IOPGD_SHIFT 20 > -#define IOPGD_SIZE (1 << IOPGD_SHIFT) > +#define IOPGD_SIZE (1UL << IOPGD_SHIFT) > #define IOPGD_MASK (~(IOPGD_SIZE - 1)) > -#define IOSECTION_MASK IOPGD_MASK > -#define PTRS_PER_IOPGD (1 << (32 - IOPGD_SHIFT)) > -#define IOPGD_TABLE_SIZE (PTRS_PER_IOPGD * sizeof(u32)) > > -#define IOSUPER_SIZE (IOPGD_SIZE << 4) > +/* > + * "section" address mask and size definitions. > + */ > +#define IOSECTION_SHIFT 20 > +#define IOSECTION_SIZE (1UL << IOSECTION_SHIFT) > +#define IOSECTION_MASK (~(IOSECTION_SIZE - 1)) > + > +/* > + * "supersection" address mask and size definitions. > + */ > +#define IOSUPER_SHIFT24 > +#define IOSUPER_SIZE (1UL << IOSUPER_SHIFT) > #define IOSUPER_MASK (~(IOSUPER_SIZE - 1)) > > +#define PTRS_PER_IOPGD (1UL << (32 - IOPGD_SHIFT)) > +#define IOPGD_TABLE_SIZE (PTRS_PER_IOPGD * sizeof(u32)) > + > +/* > + * "small page" address mask and size definitions. > + */ > #define IOPTE_SHIFT 12 > -#define IOPTE_SIZE (1 << IOPTE_SHIFT) > +#define IOPTE_SIZE (1UL << IOPTE_SHIFT) > #define IOPTE_MASK (~(IOPTE_SIZE - 1)) > -#define IOPAGE_MASK IOPTE_MASK > -#define PTRS_PER_IOPTE (1 << (IOPGD_SHIFT - IOPTE_SHIFT)) > -#define IOPTE_TABLE_SIZE (PTRS_PER_IOPTE * sizeof(u32)) > > -#define IOLARGE_SIZE (IOPTE_SIZE << 4) > +/* > + * "large page" address mask and size definitions. > + */ > +#define IOLARGE_SHIFT16 > +#define IOLARGE_SIZE (1UL << IOLARGE_SHIFT) > #define IOLARGE_MASK (~(IOLARGE_SIZE - 1)) > > +#define PTRS_PER_IOPTE (1UL << (IOPGD_SHIFT - IOPTE_SHIFT)) > +#define IOPTE_TABLE_SIZE (PTRS_PER_IOPTE * sizeof(u32)) > + > +#define IOPAGE_MASK IOPTE_MASK > + > +/* > + * some descriptor attributes. > + */ > #define IOPGD_TABLE (1 << 0) > #define IOPGD_SECTION(2 << 0) > #define IOPGD_SUPER (1 << 18 | 2 << 0) > @@ -40,12 +66,14 @@ > #define IOPTE_SMALL (2 << 0) > #define IOPTE_LARGE (1 << 0) > > +/* to find an entry in a page-table-directory */ > #define iopgd_index(da) (((da) >> IOPGD_SHIFT) & > (PTRS_PER_IOPGD - 1)) > #define iopgd_offset(obj, da)((obj)->iopgd + iopgd_index(da)) > > #define iopte_paddr(iopgd) (*iopgd & ~((1 << 10) - 1)) > #define iopte_vaddr(iopgd) ((u32 *)phys_to_virt(iopte_paddr(iopgd))) > > +/* to find an entry in the second-level page table. */ > #define iopte_index(da) (((da) >> IOPTE_SHIFT) & > (PTRS_PER_IOPTE - 1)) > #define iopte_offset(iopgd, da) (iopte_vaddr(iopgd) + iopte_index(da)) > > -- > 1.6.0.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] DSPBRIDGE: Use _IOxx macro to define ioctls
Ramirez Luna, Omar had written, on 01/11/2010 02:12 PM, the following:
[...]
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 02def74..f52b7b8 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
[...]
static inline void __cp_fm_usr(void *to, const void __user *from,
@@ -273,13 +286,48 @@ static inline void __cp_to_usr(void __user *to, const
void *from,
inline DSP_STATUS WCD_CallDevIOCtl(u32 cmd, union Trapped_Args *args,
u32 *result, void *pr_ctxt)
{
- if (cmd < ARRAY_SIZE(WCD_cmdTable)) {
- /* make the fxn call via the cmd table */
- *result = (*WCD_cmdTable[cmd].fxn) (args, pr_ctxt);
- return DSP_SOK;
+ u32(*ioctl_cmd)(union Trapped_Args *args, void *pr_ctxt);
+ int i;
+
+ if (_IOC_TYPE(cmd) != DB) {
+ pr_err("%s: Incompatible dspbridge ioctl number\n", __func__);
+ goto err;
}
- return DSP_EINVALIDARG;
+ /* Retrieve the fxn via the cmd table */
+ i = cmd & DB_IOC_MASK;
+ switch (cmd & DB_MODULE_MASK) {
+ case DB_MGR:
+ ioctl_cmd = mgr_cmd[i].fxn;
just realized we have a risk here. if i > sizeof(mgr_cmd), then we will
not catch the out of range error.
[...]
--
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
[PATCH 6/6] DSPBRIDGE: Use _IOxx macro to define ioctls
- Use standard convention to define ioctls.
Currently 0xDB is used as identifier for dspbridge.
Discussion:
http://marc.info/?l=linux-omap&m=126297631603035&w=2
WARNING:
An update in api ioctl definitions is required, usually replacing
to a new libbridge (with ioctl patch) should be enough. Other
clients (not using libbridge) need to update their ioctl numbers
manually.
Signed-off-by: Omar Ramirez Luna
CC: Nishant Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 164 +++--
drivers/dsp/bridge/pmgr/wcd.c | 182 ++-
drivers/dsp/bridge/rmgr/drv_interface.c |3 -
3 files changed, 200 insertions(+), 149 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index 4b9dd0a..452be83 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -437,86 +437,92 @@ union Trapped_Args {
} ARGS_UTIL_TESTDLL;
} ;
-#define CMD_BASE 1
+/* Ioctl driver name */
+#define DB 0xDB
+
+/* Ioctl module masks */
+#define DB_MGR 0x0
+#define DB_PROC0x20
+#define DB_NODE0x40
+#define DB_STRM0x60
+#define DB_CMM 0x80
+
+/*
+ * Following are used to distinguish between module ioctls, this is needed
+ * in case new ioctls are introduced.
+ */
+#define DB_MODULE_MASK 0xE0
+#define DB_IOC_MASK0x1F
+
+/* Macro used to calculate the ioctl per dspbridge module */
+#define DB_IOC(module, num) \
+ (((module) & DB_MODULE_MASK) | ((num) & DB_IOC_MASK))
/* TODO: Remove deprecated and not implemented */
-/* MGR module offsets */
-#define CMD_MGR_BASE_OFFSET CMD_BASE
-#define CMD_MGR_ENUMNODE_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 0)
-#define CMD_MGR_ENUMPROC_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 1)
-#define CMD_MGR_REGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 2)
-#define CMD_MGR_UNREGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 3)
-#define CMD_MGR_WAIT_OFFSET (CMD_MGR_BASE_OFFSET + 4)
-
-#ifndef RES_CLEANUP_DISABLE
-#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)/*
Deprecated */
-#define CMD_MGR_END_OFFSET CMD_MGR_RESOUCES_OFFSET
-#else
-#define CMD_MGR_END_OFFSET CMD_MGR_WAIT_OFFSET
-#endif
-
-#define CMD_PROC_BASE_OFFSET (CMD_MGR_END_OFFSET + 1)
-#define CMD_PROC_ATTACH_OFFSET (CMD_PROC_BASE_OFFSET + 0)
-#define CMD_PROC_CTRL_OFFSET (CMD_PROC_BASE_OFFSET + 1)
-#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2) /* Deprecated */
-#define CMD_PROC_ENUMNODE_OFFSET (CMD_PROC_BASE_OFFSET + 3)
-#define CMD_PROC_ENUMRESOURCES_OFFSET (CMD_PROC_BASE_OFFSET + 4)
-#define CMD_PROC_GETSTATE_OFFSET (CMD_PROC_BASE_OFFSET + 5)
-#define CMD_PROC_GETTRACE_OFFSET (CMD_PROC_BASE_OFFSET + 6)
-#define CMD_PROC_LOAD_OFFSET (CMD_PROC_BASE_OFFSET + 7)
-#define CMD_PROC_REGISTERNOTIFY_OFFSET (CMD_PROC_BASE_OFFSET + 8)
-#define CMD_PROC_START_OFFSET (CMD_PROC_BASE_OFFSET + 9)
-#define CMD_PROC_RSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 10)
-#define CMD_PROC_UNRSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 11)
-#define CMD_PROC_MAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 12)
-#define CMD_PROC_UNMAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 13)
-#define CMD_PROC_FLUSHMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 14)
-#define CMD_PROC_STOP_OFFSET (CMD_PROC_BASE_OFFSET + 15)
-#define CMD_PROC_INVALIDATEMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 16)
-#define CMD_PROC_END_OFFSET CMD_PROC_INVALIDATEMEMORY_OFFSET
-
-
-#define CMD_NODE_BASE_OFFSET (CMD_PROC_END_OFFSET + 1)
-#define CMD_NODE_ALLOCATE_OFFSET (CMD_NODE_BASE_OFFSET + 0)
-#define CMD_NODE_ALLOCMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 1)
-#define CMD_NODE_CHANGEPRIORITY_OFFSET (CMD_NODE_BASE_OFFSET + 2)
-#define CMD_NODE_CONNECT_OFFSET (CMD_NODE_BASE_OFFSET + 3)
-#define CMD_NODE_CREATE_OFFSET (CMD_NODE_BASE_OFFSET + 4)
-#define CMD_NODE_DELETE_OFFSET (CMD_NODE_BASE_OFFSET + 5)
-#define CMD_NODE_FREEMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 6)
-#define CMD_NODE_GETATTR_OFFSET (CMD_NODE_BASE_OFFSET + 7)
-#define CMD_NODE_GETMESSAGE_OFFSET (CMD_NODE_BASE_OFFSET + 8)
-#define CMD_NODE_PAUSE_OFFSET (CMD_NODE_BASE_OFFSET + 9)
-#define CMD_NODE_PUTMESSAGE_OFFSET (CMD_NODE_BASE_OFFSET + 10)
-#define CMD_NODE_REGISTERNOTIFY_OFFSET (CMD_NODE_BASE_OFFSET + 11)
-#define CMD_NODE_RUN_OFFSET (CMD_NODE_BASE_OFFSET + 12)
-#define CMD_NODE_TERMINATE_OFFSET (CMD_NODE_BASE_OFFSET + 13)
-#define CMD_NODE_GETUUIDPROPS_OFFSET(CMD_NODE_BASE_OFFSET + 14)
-#define CMD_NODE_END_OFFSET CMD_NODE_GETUUIDPROPS_OFFSET
-
-#define CMD_STRM_BASE_OFFSET (CMD_NODE_END_OFFSET + 1)
-#define CMD_STRM_ALLOCATEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 0)
-#defin
[PATCH 2/6] DSPBRIDGE: Replace magic numbers in SSI configuration
Rename ssi_sysconfig variable and replace the usage of magic
numbers while updating SSI configuration.
Signed-off-by: Omar Ramirez Luna
CC: Nishant Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/services/clk.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 116e10e..0537487 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -58,6 +58,10 @@ typedef volatile unsigned long REG_UWORD32;
#define OMAP_SSI_SIZE 0x1000
#define OMAP_SSI_SYSCONFIG_OFFSET 0x10
+#define SSI_AUTOIDLE (1 << 0)
+#define SSI_SIDLE_SMARTIDLE(2 << 3)
+#define SSI_MIDLE_NOIDLE (1 << 12)
+
struct SERVICES_Clk_t {
struct clk *clk_handle;
const char *clk_name;
@@ -353,8 +357,8 @@ s32 CLK_Get_UseCnt(IN enum SERVICES_ClkId clk_id)
void SSI_Clk_Prepare(bool FLAG)
{
- u32 ssi_sysconfig;
void __iomem *ssi_base;
+ unsigned int value;
ssi_base = ioremap(L4_34XX_BASE + OMAP_SSI_OFFSET, OMAP_SSI_SIZE);
@@ -362,14 +366,14 @@ void SSI_Clk_Prepare(bool FLAG)
/* Set Autoidle, SIDLEMode to smart idle, and MIDLEmode to
* no idle
*/
- ssi_sysconfig = 0x1011;
+ value = SSI_AUTOIDLE | SSI_SIDLE_SMARTIDLE | SSI_MIDLE_NOIDLE;
} else {
/* Set Autoidle, SIDLEMode to forced idle, and MIDLEmode to
* forced idle
*/
- ssi_sysconfig = 0x1;
+ value = SSI_AUTOIDLE;
}
- __raw_writel(ssi_sysconfig, ssi_base + OMAP_SSI_SYSCONFIG_OFFSET);
+ __raw_writel(value, ssi_base + OMAP_SSI_SYSCONFIG_OFFSET);
iounmap(ssi_base);
}
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] DSPBRIDGE: replace IO_ADDRESS with ioremap
Use ioremap() instead of using IO_ADDRESS macro to make it generic.
Signed-off-by: Omar Ramirez Luna
CC: Nishant Menon
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Felipe Contreras
---
drivers/dsp/bridge/services/clk.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index d1c68fc..116e10e 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -54,10 +54,9 @@
typedef volatile unsigned long REG_UWORD32;
-#define SSI_Base0x48058000
-
-#define SSI_BASE IO_ADDRESS(SSI_Base)
-
+#define OMAP_SSI_OFFSET0x58000
+#define OMAP_SSI_SIZE 0x1000
+#define OMAP_SSI_SYSCONFIG_OFFSET 0x10
struct SERVICES_Clk_t {
struct clk *clk_handle;
@@ -355,7 +354,9 @@ s32 CLK_Get_UseCnt(IN enum SERVICES_ClkId clk_id)
void SSI_Clk_Prepare(bool FLAG)
{
u32 ssi_sysconfig;
- ssi_sysconfig = __raw_readl((SSI_BASE) + 0x10);
+ void __iomem *ssi_base;
+
+ ssi_base = ioremap(L4_34XX_BASE + OMAP_SSI_OFFSET, OMAP_SSI_SIZE);
if (FLAG) {
/* Set Autoidle, SIDLEMode to smart idle, and MIDLEmode to
@@ -368,5 +369,7 @@ void SSI_Clk_Prepare(bool FLAG)
*/
ssi_sysconfig = 0x1;
}
- __raw_writel((u32)ssi_sysconfig, SSI_BASE + 0x10);
+
+ __raw_writel(ssi_sysconfig, ssi_base + OMAP_SSI_SYSCONFIG_OFFSET);
+ iounmap(ssi_base);
}
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] DSPBRIDGE: remove ioctl runtime check
This patch removes the runtime check of device
ioctl array.
Signed-off-by: Omar Ramirez Luna
CC: Nishant Menon
CC: Felipe Contreras
---
drivers/dsp/bridge/pmgr/wcd.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index f95980b..960b3cb 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -321,13 +321,7 @@ bool WCD_Init(void)
bool fInit = true;
bool fDRV, fDEV, fCOD, fSERVICES, fCHNL, fMSG, fIO;
bool fMGR, fPROC, fNODE, fDISP, fNTFY, fSTRM, fRMM;
-#ifdef DEBUG
- /* runtime check of Device IOCtl array. */
- u32 i;
- for (i = 1; i < ARRAY_SIZE(WCD_cmdTable); i++)
- DBC_Assert(WCD_cmdTable[i - 1].dwIndex == i);
-#endif
if (WCD_cRefs == 0) {
/* initialize all SERVICES modules */
fSERVICES = SERVICES_Init();
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] misc patches
Ioctl numbers has changed, this will require an update on libbridge and clients accesing directly to the driver - IO_ADDRESS is replaced for ioremap. *v2 - dropped from the series: DSPBRIDGE: Increased DMM size to 256MB DSPBRIDGE: sysfs entry for global driver state - will be kept in bridge-pm DSPBRIDGE: Use dspbridge to initialize platform data DSPBRIDGE: change to cpufreq_register_notifier for OPP changes DSPBRIDGE: Fix header locations mach to plat - previously acked DSPBRIDGE: Remove unused hDrvObject in bridge_[open|release] Omar Ramirez Luna (6): DSPBRIDGE: replace IO_ADDRESS with ioremap DSPBRIDGE: Replace magic numbers in SSI configuration DSPBRIDGE: Mark unused ioctls as deprecated DSPBRIDGE: remove ioctl runtime check DSPBRIDGE: Rename pResult to result for WCD_CallDevIOCtl DSPBRIDGE: Use _IOxx macro to define ioctls arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 167 + drivers/dsp/bridge/pmgr/wcd.c | 228 +-- drivers/dsp/bridge/rmgr/drv_interface.c |3 - drivers/dsp/bridge/services/clk.c | 23 ++- 4 files changed, 234 insertions(+), 187 deletions(-) CC: Nishant Menon CC: Hiroshi Doyu CC: Ameya Palande CC: 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
[PATCH 5/6] DSPBRIDGE: Rename pResult to result for WCD_CallDevIOCtl
Trivial cleanup, rename pResult to result for WCD_CallDevIOCtl
Signed-off-by: Omar Ramirez Luna
CC: Nishant Menon
---
drivers/dsp/bridge/pmgr/wcd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 960b3cb..02def74 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -271,11 +271,11 @@ static inline void __cp_to_usr(void __user *to, const
void *from,
* Call the (wrapper) function for the corresponding WCD IOCTL.
*/
inline DSP_STATUS WCD_CallDevIOCtl(u32 cmd, union Trapped_Args *args,
- u32 *pResult, void *pr_ctxt)
+ u32 *result, void *pr_ctxt)
{
if (cmd < ARRAY_SIZE(WCD_cmdTable)) {
/* make the fxn call via the cmd table */
- *pResult = (*WCD_cmdTable[cmd].fxn) (args, pr_ctxt);
+ *result = (*WCD_cmdTable[cmd].fxn) (args, pr_ctxt);
return DSP_SOK;
}
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] DSPBRIDGE: Mark unused ioctls as deprecated
Mark unused ioctls as deprecated for future removal.
Signed-off-by: Omar Ramirez Luna
CC: Nishant Menon
CC: Felipe Contreras
---
arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 11 --
drivers/dsp/bridge/pmgr/wcd.c | 38 +--
2 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index 04b13ab..4b9dd0a 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -439,6 +439,8 @@ union Trapped_Args {
#define CMD_BASE 1
+/* TODO: Remove deprecated and not implemented */
+
/* MGR module offsets */
#define CMD_MGR_BASE_OFFSET CMD_BASE
#define CMD_MGR_ENUMNODE_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 0)
@@ -448,7 +450,7 @@ union Trapped_Args {
#define CMD_MGR_WAIT_OFFSET (CMD_MGR_BASE_OFFSET + 4)
#ifndef RES_CLEANUP_DISABLE
-#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)
+#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)/*
Deprecated */
#define CMD_MGR_END_OFFSET CMD_MGR_RESOUCES_OFFSET
#else
#define CMD_MGR_END_OFFSET CMD_MGR_WAIT_OFFSET
@@ -457,7 +459,7 @@ union Trapped_Args {
#define CMD_PROC_BASE_OFFSET (CMD_MGR_END_OFFSET + 1)
#define CMD_PROC_ATTACH_OFFSET (CMD_PROC_BASE_OFFSET + 0)
#define CMD_PROC_CTRL_OFFSET (CMD_PROC_BASE_OFFSET + 1)
-#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2)
+#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2) /* Deprecated */
#define CMD_PROC_ENUMNODE_OFFSET (CMD_PROC_BASE_OFFSET + 3)
#define CMD_PROC_ENUMRESOURCES_OFFSET (CMD_PROC_BASE_OFFSET + 4)
#define CMD_PROC_GETSTATE_OFFSET (CMD_PROC_BASE_OFFSET + 5)
@@ -497,6 +499,7 @@ union Trapped_Args {
#define CMD_STRM_ALLOCATEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 0)
#define CMD_STRM_CLOSE_OFFSET (CMD_STRM_BASE_OFFSET + 1)
#define CMD_STRM_FREEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 2)
+/* Not Impl'd */
#define CMD_STRM_GETEVENTHANDLE_OFFSET (CMD_STRM_BASE_OFFSET + 3)
#define CMD_STRM_GETINFO_OFFSET (CMD_STRM_BASE_OFFSET + 4)
#define CMD_STRM_IDLE_OFFSET (CMD_STRM_BASE_OFFSET + 5)
@@ -509,8 +512,8 @@ union Trapped_Args {
/* Communication Memory Manager (UCMM) */
#define CMD_CMM_BASE_OFFSET (CMD_STRM_END_OFFSET + 1)
-#define CMD_CMM_ALLOCBUF_OFFSET (CMD_CMM_BASE_OFFSET + 0)
-#define CMD_CMM_FREEBUF_OFFSET (CMD_CMM_BASE_OFFSET + 1)
+#define CMD_CMM_ALLOCBUF_OFFSET (CMD_CMM_BASE_OFFSET + 0)/* Not
Impl'd */
+#define CMD_CMM_FREEBUF_OFFSET (CMD_CMM_BASE_OFFSET + 1) /* Not Impl'd */
#define CMD_CMM_GETHANDLE_OFFSET (CMD_CMM_BASE_OFFSET + 2)
#define CMD_CMM_GETINFO_OFFSET (CMD_CMM_BASE_OFFSET + 3)
#define CMD_CMM_END_OFFSET CMD_CMM_GETINFO_OFFSET
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 7226b5a..f95980b 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -456,6 +456,8 @@ DSP_STATUS WCD_InitComplete2(void)
return status;
}
+/* TODO: Remove deprecated and not implemented ioctl wrappers */
+
/*
* MGRWRAP_EnumNode_Info
*/
@@ -634,21 +636,11 @@ u32 MGRWRAP_WaitForBridgeEvents(union Trapped_Args *args,
void *pr_ctxt)
/*
* MGRWRAP_GetProcessResourceInfo
*/
-u32 MGRWRAP_GetProcessResourcesInfo(union Trapped_Args *args, void *pr_ctxt)
+u32 __deprecated MGRWRAP_GetProcessResourcesInfo(union Trapped_Args *args,
+ void *pr_ctxt)
{
-DSP_STATUS status = DSP_SOK;
-u32 uSize = 0;
-u8 *pBuf = MEM_Alloc(8092, MEM_NONPAGED);
-GT_1trace(WCD_debugMask, GT_ENTER,
-"MGRWRAP_GetProcessResourcesInfo:uSize=%d :\n", uSize);
-cp_to_usr(args->ARGS_PROC_GETTRACE.pBuf, pBuf, status, uSize);
-GT_0trace(WCD_debugMask, GT_ENTER, "\n***"
-"123MGRWRAP_GetProcessResourcesInfo:**\n");
-GT_0trace(WCD_debugMask, GT_ENTER, "\n***"
-"456MGRWRAP_GetProcessResourcesInfo:**\n");
-cp_to_usr(args->ARGS_PROC_GETTRACE.pSize, &uSize, status, 1);
-MEM_Free(pBuf);
-return status;
+ pr_err("%s: deprecated dspbridge ioctl\n", __func__);
+ return DSP_SOK;
}
#endif
@@ -732,14 +724,10 @@ func_end:
/*
* PROCWRAP_Detach
*/
-u32 PROCWRAP_Detach(union Trapped_Args *args, void *pr_ctxt)
+u32 __deprecated PROCWRAP_Detach(union Trapped_Args *args, void *pr_ctxt)
{
- GT_1trace(WCD_debugMask, GT_ENTER,
-"PROCWRAP_Detach: entered args\n0x%x "
-"hProceesor \n", args->ARGS_PROC_DETACH.hProcessor);
-
/* PROC_Detach called at bridge_release only */
-
+ pr_err("%s: deprecated dspbridge ioctl\n", __func__);
return DSP_SOK;
}
@@ -1540,8 +1528,10 @@ u32 STRMWRAP_FreeB
RE: [PATCH] DSPBRIDGE: driver version 0.1
>From: Menon, Nishanth
>
>Ramirez Luna, Omar had written, on 01/11/2010 12:46 PM, the following:
>>> From: Menon, Nishanth
>>>
>>> Ramirez Luna, Omar had written, on 01/11/2010 11:50 AM, the following:
This is the official 0.1 dspbridge version.
CC: Felipe Contreras
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Nishant Menon
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/rmgr/drv_interface.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index c853854..efce35d 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -101,6 +101,7 @@
#define BRIDGE_NAME "C6410"
/* --- Globals */
#define DRIVER_NAME "DspBridge"
+#define DSPBRIDGE_VERSION "0.1"
s32 dsp_debug;
struct platform_device *omap_dspbridge_dev;
@@ -177,6 +178,7 @@ MODULE_PARM_DESC(tc_wordswapon, "TC Word Swap Option.
default = 0");
MODULE_AUTHOR("Texas Instruments");
MODULE_LICENSE("GPL");
+MODULE_VERSION(DSPBRIDGE_VERSION);
static char *driver_name = DRIVER_NAME;
>>> is the IOCTL patch before or after the 0.1?
>>
>> IOCTL patch is after 0.1
>>
>> I'll be resending v2 of IOCTL patch but should be applied after this patch.
>sounds reasonable. I wonder what happened to
>http://marc.info/?l=linux-omap&m=125729526105560&w=2
To the change: currently is on hold given the amount of changes but
scheduled for this month (hopefully ;))
To the request: I have a patch queue to be applied after 0.1 patch and v2 of
ioctl, the patches have already been sent to this mailing list but changes
didn't fit prior to 0.1 alignment
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 v5 resubmit] mmc-omap: Add support for 16-bit and 32-bit registers
On Mon, Jan 11, 2010 at 2:44 AM, Ladislav Michl wrote: > > This patch differs from v5 you sent earlier: > Subject: [PATCH v5] mmc-omap: Add support for 16-bit and 32-bit registers > Date: Mon, 23 Nov 2009 10:37:28 -0800 > Message-Id: <1259001448-9574-1-git-send-email-darkstar6...@gmail.com> > > Patch below is not going to work with 32-bit wide registers. Whoever is going > to apply it, please don't. Use original version referred above. > > > > This is not going to work Ah, right, good catch. I thought I got the same one submitted -- this is an older one. Sorry about that. - Cory -- 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
PM: Device usb1 failed to suspend: error -16
Hi All, I tried to suspend the system, and got the following messages: PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) musb_bus_suspend 2261: trying to suspend as a_host while active pm_op(): usb_dev_suspend+0x0/0x8 returns -16 PM: Device usb1 failed to suspend: error -16 PM: Some devices failed to suspend Restarting tasks ... Segmentation fault done. I use linux-omap-2.6.git, should I use the branch linux-omap-pm? Thanks. Wending Weng Software Engineer at Rheinmetall -- 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] DSPBRIDGE: driver version 0.1
Ramirez Luna, Omar had written, on 01/11/2010 12:46 PM, the following:
From: Menon, Nishanth
Ramirez Luna, Omar had written, on 01/11/2010 11:50 AM, the following:
This is the official 0.1 dspbridge version.
CC: Felipe Contreras
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Nishant Menon
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/rmgr/drv_interface.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index c853854..efce35d 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -101,6 +101,7 @@
#define BRIDGE_NAME "C6410"
/* --- Globals */
#define DRIVER_NAME "DspBridge"
+#define DSPBRIDGE_VERSION "0.1"
s32 dsp_debug;
struct platform_device *omap_dspbridge_dev;
@@ -177,6 +178,7 @@ MODULE_PARM_DESC(tc_wordswapon, "TC Word Swap Option. default =
0");
MODULE_AUTHOR("Texas Instruments");
MODULE_LICENSE("GPL");
+MODULE_VERSION(DSPBRIDGE_VERSION);
static char *driver_name = DRIVER_NAME;
is the IOCTL patch before or after the 0.1?
IOCTL patch is after 0.1
I'll be resending v2 of IOCTL patch but should be applied after this patch.
sounds reasonable. I wonder what happened to
http://marc.info/?l=linux-omap&m=125729526105560&w=2
--
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] DSPBRIDGE: driver version 0.1
>From: Menon, Nishanth
>
>Ramirez Luna, Omar had written, on 01/11/2010 11:50 AM, the following:
>> This is the official 0.1 dspbridge version.
>>
>> CC: Felipe Contreras
>> CC: Hiroshi Doyu
>> CC: Ameya Palande
>> CC: Nishant Menon
>>
>> Signed-off-by: Omar Ramirez Luna
>> ---
>> drivers/dsp/bridge/rmgr/drv_interface.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
>> b/drivers/dsp/bridge/rmgr/drv_interface.c
>> index c853854..efce35d 100644
>> --- a/drivers/dsp/bridge/rmgr/drv_interface.c
>> +++ b/drivers/dsp/bridge/rmgr/drv_interface.c
>> @@ -101,6 +101,7 @@
>> #define BRIDGE_NAME "C6410"
>> /* --- Globals */
>> #define DRIVER_NAME "DspBridge"
>> +#define DSPBRIDGE_VERSION "0.1"
>> s32 dsp_debug;
>>
>> struct platform_device *omap_dspbridge_dev;
>> @@ -177,6 +178,7 @@ MODULE_PARM_DESC(tc_wordswapon, "TC Word Swap Option.
>> default = 0");
>>
>> MODULE_AUTHOR("Texas Instruments");
>> MODULE_LICENSE("GPL");
>> +MODULE_VERSION(DSPBRIDGE_VERSION);
>>
>> static char *driver_name = DRIVER_NAME;
>>
>is the IOCTL patch before or after the 0.1?
IOCTL patch is after 0.1
I'll be resending v2 of IOCTL patch but should be applied after this patch.
- 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] DSPBRIDGE: driver version 0.1
Ramirez Luna, Omar had written, on 01/11/2010 11:50 AM, the following:
This is the official 0.1 dspbridge version.
CC: Felipe Contreras
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Nishant Menon
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/rmgr/drv_interface.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index c853854..efce35d 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -101,6 +101,7 @@
#define BRIDGE_NAME "C6410"
/* --- Globals */
#define DRIVER_NAME "DspBridge"
+#define DSPBRIDGE_VERSION "0.1"
s32 dsp_debug;
struct platform_device *omap_dspbridge_dev;
@@ -177,6 +178,7 @@ MODULE_PARM_DESC(tc_wordswapon, "TC Word Swap Option. default =
0");
MODULE_AUTHOR("Texas Instruments");
MODULE_LICENSE("GPL");
+MODULE_VERSION(DSPBRIDGE_VERSION);
static char *driver_name = DRIVER_NAME;
is the IOCTL patch before or after the 0.1?
--
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] AM35xx: Add clock support for new modules on AM35xx
Hi Paul, On Sat, 09-Jan-10 4:37 AM +0530, Paul Walmsley wrote: > Hello Ranjith, > > On Fri, 8 Jan 2010, Ranjith Lohithakshan wrote: > >> These ACK bits are for the target IdleAck status. I will add a custom >> find_companion code for AM35xx. > > ... > >> OK. I will extend the existing find_idlest to pass back what value needs >> to be checked as you suggested. I will make this change as a separate patch. > > Both of the above sound good. > >> All the VBUSP (interface) clocks are derived from core_l3_clk and I am >> making them as part of core_l3_clk domain. The rmii_ck/emac_fck and >> vpfe_fck are sourced from external clock sources. (AM35XX TRM section >> 4.7.7.12) > > ... > >> rmii_ck and vpfe_fck are from off-chip sources. These are fixed rate >> clocks being fed to the chip. Do we need to associate a dummy or virtual >> clock domain for these clocks or is it OK if we treat it similar to the >> way we currently treat 32K timer clock (RATE_FIXED, clockops_null, no >> clock domain and having no parent)? > > I guess it will be fine to add these with no clockdomain until we add an > external clockdomain. One last question - do you know if these external > clocks require the CORE powerdomain to be powered for them to be routed? > I believe this is the case for some of the external clocks that are routed > through the CM on OMAP3. These external clocks are routed directly from IO to the respective modules. They are not controlled by CM. - Ranjith -- 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] DSPBRIDGE: driver version 0.1
This is the official 0.1 dspbridge version.
CC: Felipe Contreras
CC: Hiroshi Doyu
CC: Ameya Palande
CC: Nishant Menon
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/rmgr/drv_interface.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index c853854..efce35d 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -101,6 +101,7 @@
#define BRIDGE_NAME "C6410"
/* --- Globals */
#define DRIVER_NAME "DspBridge"
+#define DSPBRIDGE_VERSION "0.1"
s32 dsp_debug;
struct platform_device *omap_dspbridge_dev;
@@ -177,6 +178,7 @@ MODULE_PARM_DESC(tc_wordswapon, "TC Word Swap Option.
default = 0");
MODULE_AUTHOR("Texas Instruments");
MODULE_LICENSE("GPL");
+MODULE_VERSION(DSPBRIDGE_VERSION);
static char *driver_name = DRIVER_NAME;
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/13] OMAP2/3: DMTIMER: Clear pending interrupts when stopping a timer
Hello Santosh,
On Sun, 10 Jan 2010, Shilimkar, Santosh wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org
> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
> > Hilman
> > Sent: Friday, January 08, 2010 11:29 PM
> > To: linux-omap@vger.kernel.org
> > Cc: Tero Kristo
> > Subject: [PATCH 01/13] OMAP2/3: DMTIMER: Clear pending interrupts when
> > stopping a timer
> >
> > From: Tero Kristo
> >
> > OMAP GP timers keep running for a few cycles after they are stopped,
> > which can cause the timer to expire and generate an interrupt. The pending
> > interrupt will prevent e.g. OMAP from entering suspend, thus we ack it
> > manually.
> >
> > Signed-off-by: Tero Kristo
> > Signed-off-by: Kevin Hilman
> > ---
> > arch/arm/plat-omap/dmtimer.c | 10 ++
> > 1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> > index 64f407e..5502ce8 100644
> > --- a/arch/arm/plat-omap/dmtimer.c
> > +++ b/arch/arm/plat-omap/dmtimer.c
> > @@ -551,6 +551,16 @@ void omap_dm_timer_stop(struct omap_dm_timer *timer)
> > if (l & OMAP_TIMER_CTRL_ST) {
> > l &= ~0x1;
> > omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
> > + /* Readback to make sure write has completed */
> > + omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
> Hopefully compiler don't optimize your readback.
It can't - if it does, it is a gcc bug. omap_dm_timer_read_reg()
ultimately calls __raw_readl() which uses the 'volatile' keyword:
http://en.wikipedia.org/wiki/Volatile_variable
...
Separately from the compiler, one must also ensure that the ARM core
itself does not cache the readback. This is handled by mapping the
GPTIMER memory space as MT_DEVICE in mach-omap2/io.c. See also the
MT_DEVICE section in arch/arm/mm/mmu.c. Further details are in the ARMv7
Architecture Reference Manual, section A3.5.5, "Device Memory".
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] driver version 0.1
Given the on going efforts to review bridge patches, a branch has been published with all of the comments received a few weeks ago, the current dspbridge which is meant to be 0.1 can be found at: Branch: dspbridge @ http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=shortlog;h=refs/heads/dspbridge Special thanks to: - Felipe Contreras: for his comments and time during this sync up. - Hiroshi Doyu and Ameya Palande for their time reviewing patches. - And all who also have provided their comments. Omar Ramirez Luna (1): DSPBRIDGE: driver version 0.1 drivers/dsp/bridge/rmgr/drv_interface.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) CC: Felipe Contreras CC: Hiroshi Doyu CC: Ameya Palande CC: Nishant 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 1/1] omap3: Add macros for comparing si revision
> -Original Message-
> From: Premi, Sanjeev
> Sent: Friday, January 08, 2010 8:56 PM
> To: linux-omap@vger.kernel.org
> Cc: Premi, Sanjeev
> Subject: [PATCH 1/1] omap3: Add macros for comparing si revision
>
> This patch adds verbose macros for comparing silicon
> revision bits. Current mechanism of comparing complete
> 'omap_revision' does not work/ represent the multiple
> processors, and their revisions.
>
> Existing instances of comparison via omap_rev() have
> been replaced with new macros.
>
> Signed-off-by: Sanjeev Premi
> ---
> arch/arm/mach-omap2/clock34xx.c |2 +-
> arch/arm/mach-omap2/clock34xx_data.c |6 ++-
> arch/arm/mach-omap2/control.c |7 ++--
> arch/arm/mach-omap2/id.c | 13 +++
> arch/arm/mach-omap2/pm34xx.c | 35 -
> arch/arm/plat-omap/include/plat/cpu.h | 55
> +
> 6 files changed, 97 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock34xx.c
> b/arch/arm/mach-omap2/clock34xx.c
> index d4217b9..6cef2f1 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -154,7 +154,7 @@ int omap3_dpll4_set_rate(struct clk *clk,
> unsigned long rate)
>* on 3430ES1 prevents us from changing DPLL
> multipliers or dividers
>* on DPLL4.
>*/
> - if (omap_rev() == OMAP3430_REV_ES1_0) {
> + if (cpu_is_omap34xx() && omap_rev_is_1_0()) {
> printk(KERN_ERR "clock: DPLL4 cannot change
> rate due to "
> "silicon 'Limitation 2.5' on 3430ES1.\n");
> return -EINVAL;
> diff --git a/arch/arm/mach-omap2/clock34xx_data.c
> b/arch/arm/mach-omap2/clock34xx_data.c
> index c6031d7..0a00a49 100644
> --- a/arch/arm/mach-omap2/clock34xx_data.c
> +++ b/arch/arm/mach-omap2/clock34xx_data.c
> @@ -3230,7 +3230,7 @@ int __init omap2_clk_init(void)
>* Update this if there are further clock
> changes between ES2
>* and production parts
>*/
> - if (omap_rev() == OMAP3430_REV_ES1_0) {
> + if (cpu_is_omap34xx() && omap_rev_is_1_0()) {
> /* No 3430ES1-only rates exist, so no
> RATE_IN_3430ES1 */
> cpu_clkflg |= CK_3430ES1;
> } else {
> @@ -3282,7 +3282,9 @@ int __init omap2_clk_init(void)
> /*
>* Lock DPLL5 and put it in autoidle.
>*/
> - if (omap_rev() >= OMAP3430_REV_ES2_0)
> + if ((cpu_is_omap34xx() && omap_rev_ge_2_0())
> + || cpu_is_omap3505() || cpu_is_omap3517()
> + || cpu_is_omap3630())
> omap3_clk_lock_dpll5();
>
> /* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
> diff --git a/arch/arm/mach-omap2/control.c
> b/arch/arm/mach-omap2/control.c
> index cdd1f35..55e9b0a 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -209,8 +209,7 @@ void omap3_save_scratchpad_contents(void)
>
> /* Populate the Scratchpad contents */
> scratchpad_contents.boot_config_ptr = 0x0;
> - if (omap_rev() != OMAP3430_REV_ES3_0 &&
> - omap_rev() !=
> OMAP3430_REV_ES3_1)
> + if (cpu_is_omap34xx() && omap_rev_le_3_0())
> scratchpad_contents.public_restore_ptr =
> virt_to_phys(get_restore_pointer());
> else
> @@ -271,7 +270,9 @@ void omap3_save_scratchpad_contents(void)
>* of AUTO_CNT = 1 prior to any transition to OFF mode.
>*/
> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
> - && (omap_rev() >= OMAP3430_REV_ES3_0))
> + && ((cpu_is_omap34xx() && omap_rev_ge_3_0())
> + || cpu_is_omap3505() || cpu_is_omap3517()
> + || cpu_is_omap3630()))
> sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) &
> ~(SDRC_POWER_AUTOCOUNT_MASK|
> SDRC_POWER_CLKCTRL_MASK)) |
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index a091b53..2d4c246 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -379,19 +379,18 @@ void __init omap2_check_revision(void)
> omap_chip.oc |= CHIP_IS_OMAP2420;
> } else if (cpu_is_omap3505() || cpu_is_omap3517()) {
> omap_chip.oc = CHIP_IS_OMAP3430 | CHIP_IS_OMAP3430ES3_1;
> + } else if (cpu_is_omap3630()) {
> + omap_chip.oc = CHIP_IS_OMAP3430 | CHIP_IS_OMAP3630ES1;
> } else if (cpu_is_omap343x()) {
> omap_chip.oc = CHIP_IS_OMAP3430;
> - if (omap_rev() == OMAP3430_REV_ES1_0)
> + if (omap_rev_is_1_0())
> omap_chip.oc |= CHIP_IS_OMAP3430ES1;
> - else if (omap_rev() >= OMAP3430_REV_ES2_0 &&
> - omap_rev() <= OMAP3430_REV_ES2_1)
> + else if (omap_rev_is_2_0() || omap_rev_is_2_1())
>
Re: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do notinvalidate clean lines
On Mon, Jan 11, 2010 at 04:26:30PM +, Catalin Marinas wrote: > On Mon, 2010-01-11 at 15:23 +, Russell King - ARM Linux wrote: > > On Mon, Jan 11, 2010 at 08:48:37PM +0530, Shilimkar, Santosh wrote: > > > > Do you need to specify "r12" as well? What about "cc", are they > > > > preserved by the secure monitor? > > > > > > r12 and reset of the registers are preserved. Lr needs to be saved but > > > because of function call, the compiler saves/restores it. > > > > That's not guaranteed; the compiler can re-use lr for its own purposes > > within a function. You need to add lr to the list of clobbered registers. > > Do we need to specify "r12" in the list of clobbered registers as the > inline asm explicitly modifies it? Or the compiler doesn't touch it. Yes - again, the compiler should be told about everything that potentially could change in an asm statement. The compiler could decide to inline debug_writel, and use things like r12 and lr to store temporary values within the parent function across these calls. -- 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] ARM: L2 : Errata 588369: Clean & Invalidate do notinvalidate clean lines
On Mon, 2010-01-11 at 15:23 +, Russell King - ARM Linux wrote: > On Mon, Jan 11, 2010 at 08:48:37PM +0530, Shilimkar, Santosh wrote: > > > Do you need to specify "r12" as well? What about "cc", are they > > > preserved by the secure monitor? > > > > r12 and reset of the registers are preserved. Lr needs to be saved but > > because of function call, the compiler saves/restores it. > > That's not guaranteed; the compiler can re-use lr for its own purposes > within a function. You need to add lr to the list of clobbered registers. Do we need to specify "r12" in the list of clobbered registers as the inline asm explicitly modifies it? Or the compiler doesn't touch it. -- Catalin -- 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] ARM: L2 : Errata 588369: Clean & Invalidate do not invalidate clean lines
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Monday, January 11, 2010 8:54 PM > To: Shilimkar, Santosh > Cc: Catalin Marinas; linux-arm-ker...@lists.infradead.org; > linux-omap@vger.kernel.org; > t...@atomide.com; Woodruff, Richard > Subject: Re: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do not > invalidate clean lines > > On Mon, Jan 11, 2010 at 08:48:37PM +0530, Shilimkar, Santosh wrote: > > Thanks for cooments !! > > > -Original Message- > > > From: Catalin Marinas [mailto:catalin.mari...@arm.com] > > > Sent: Monday, January 11, 2010 8:07 PM > > > To: Shilimkar, Santosh > > > Cc: li...@arm.linux.org.uk; linux-arm-ker...@lists.infradead.org; > > > linux-omap@vger.kernel.org; > > > t...@atomide.com; Woodruff, Richard > > > Subject: Re: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do > > > not invalidate clean lines > > > > > > Does your secure monitor corrupt r4-r8? Maybe you could add a comment > > > with a few words on this API. > > > > Yes they are corrupted. I will add some comments on the API. > > > > > Do you need to specify "r12" as well? What about "cc", are they > > > preserved by the secure monitor? > > > > r12 and reset of the registers are preserved. Lr needs to be saved but > > because of function call, the compiler saves/restores it. > > That's not guaranteed; the compiler can re-use lr for its own purposes > within a function. You need to add lr to the list of clobbered registers. Ok will add that. > > I didn't get your this comment "What about "cc", are they preserved > > by the secure monitor ? Do you mean rest of the register. If yes then > > the secure monitor don't tamper those registers. > > No - Catalin means are the NZCV flags changed by the secure monitor, or > are they preserved? If they're preserved, you don't need a "cc" clobber. > If they're not preserved, you do. I will double check this but IIRC the flags are preserved. Regards, Santosh -- 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] ARM: L2 : Errata 588369: Clean & Invalidate do not invalidate clean lines
On Mon, Jan 11, 2010 at 08:48:37PM +0530, Shilimkar, Santosh wrote: > Thanks for cooments !! > > -Original Message- > > From: Catalin Marinas [mailto:catalin.mari...@arm.com] > > Sent: Monday, January 11, 2010 8:07 PM > > To: Shilimkar, Santosh > > Cc: li...@arm.linux.org.uk; linux-arm-ker...@lists.infradead.org; > > linux-omap@vger.kernel.org; > > t...@atomide.com; Woodruff, Richard > > Subject: Re: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do not > > invalidate clean lines > > > > Does your secure monitor corrupt r4-r8? Maybe you could add a comment > > with a few words on this API. > > Yes they are corrupted. I will add some comments on the API. > > > Do you need to specify "r12" as well? What about "cc", are they > > preserved by the secure monitor? > > r12 and reset of the registers are preserved. Lr needs to be saved but > because of function call, the compiler saves/restores it. That's not guaranteed; the compiler can re-use lr for its own purposes within a function. You need to add lr to the list of clobbered registers. > I didn't get your this comment "What about "cc", are they preserved > by the secure monitor ? Do you mean rest of the register. If yes then > the secure monitor don't tamper those registers. No - Catalin means are the NZCV flags changed by the secure monitor, or are they preserved? If they're preserved, you don't need a "cc" clobber. If they're not preserved, you do. -- 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] ARM: L2 : Errata 588369: Clean & Invalidate do not invalidate clean lines
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Monday, January 11, 2010 8:15 PM > To: Catalin Marinas > Cc: Shilimkar, Santosh; linux-arm-ker...@lists.infradead.org; > linux-omap@vger.kernel.org; > t...@atomide.com; Woodruff, Richard > Subject: Re: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do not > invalidate clean lines > > On Mon, Jan 11, 2010 at 02:37:08PM +, Catalin Marinas wrote: > > On Mon, 2009-12-21 at 10:09 +, Santosh Shilimkar wrote: > > > @@ -139,7 +184,12 @@ static void l2x0_flush_range(unsigned long start, > > > unsigned long end) > > > spin_lock_irqsave(&l2x0_lock, flags); > > > } > > > } > > > +#ifdef CONFIG_PL310_ERRATA_588369 > > > + cache_wait(base + L2X0_CLEAN_LINE_PA, 1); > > > + cache_wait(base + L2X0_INV_LINE_PA, 1); > > > +#else > > > cache_wait(base + L2X0_CLEAN_INV_LINE_PA, 1); > > > +#endif > > > > I don't think we need to way on two separate registers here. AFAICT, bit > > 1 of those registers is shared for all the operations. > > > > As a general comment, maybe an inline function called something like > > wait_writel(before/after) would be better than a lot of ifdefs in the > > code, especially if one has a different workaround other than using TI's > > secure monitor. > > Since the bit is shared between all 'R7' registers, the ifdef above makes > no sense. We can just wait on any R7 register - I suggest that bit of > code is left as-is. Ok. will update the patch. -- 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] ARM: L2 : Errata 588369: Clean & Invalidate do not invalidate clean lines
Thanks for cooments !!
> -Original Message-
> From: Catalin Marinas [mailto:catalin.mari...@arm.com]
> Sent: Monday, January 11, 2010 8:07 PM
> To: Shilimkar, Santosh
> Cc: li...@arm.linux.org.uk; linux-arm-ker...@lists.infradead.org;
> linux-omap@vger.kernel.org;
> t...@atomide.com; Woodruff, Richard
> Subject: Re: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do not
> invalidate clean lines
>
> On Mon, 2009-12-21 at 10:09 +, Santosh Shilimkar wrote:
> > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> > index cb8fc65..5443c0d 100644
> > --- a/arch/arm/mm/cache-l2x0.c
> > +++ b/arch/arm/mm/cache-l2x0.c
> > @@ -28,6 +28,24 @@
> > static void __iomem *l2x0_base;
> > static DEFINE_SPINLOCK(l2x0_lock);
> >
> > +#ifdef CONFIG_PL310_ERRATA_588369
> > +static void debug_writel(unsigned long val)
> > +{
> > + register unsigned long r0 asm("r0") = val;
> > + /*
> > +* Texas Instrument secure monitor api to modify the PL310
> > +* Debug Control Register.
> > +*/
> > + __asm__ __volatile__(
> > + __asmeq("%0", "r0")
> > + "ldr r12, =0x100\n"
> > + "dsb\n"
> > + "smc\n"
> > + : : "r" (r0)
> > + : "r4", "r5", "r6", "r7", "r8");
>
> Does your secure monitor corrupt r4-r8? Maybe you could add a comment
> with a few words on this API.
Yes they are corrupted. I will add some comments on the API.
> Do you need to specify "r12" as well? What about "cc", are they
> preserved by the secure monitor?
r12 and reset of the registers are preserved. Lr needs to be saved but
because of function call, the compiler saves/restores it.
I didn't get your this comment "What about "cc", are they preserved
by the secure monitor ? Do you mean rest of the register. If yes then
the secure monitor don't tamper those registers.
> > @@ -139,7 +184,12 @@ static void l2x0_flush_range(unsigned long start,
> > unsigned long end)
> > spin_lock_irqsave(&l2x0_lock, flags);
> > }
> > }
> > +#ifdef CONFIG_PL310_ERRATA_588369
> > + cache_wait(base + L2X0_CLEAN_LINE_PA, 1);
> > + cache_wait(base + L2X0_INV_LINE_PA, 1);
> > +#else
> > cache_wait(base + L2X0_CLEAN_INV_LINE_PA, 1);
> > +#endif
>
> I don't think we need to way on two separate registers here. AFAICT, bit
> 1 of those registers is shared for all the operations.
>
> As a general comment, maybe an inline function called something like
> wait_writel(before/after) would be better than a lot of ifdefs in the
> code, especially if one has a different workaround other than using TI's
> secure monitor.
I agree. As suggested by Russell, we don't need above #ifdef and can
be removed
Regards,
Santosh
--
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] Feature enhancement of VPFE/CCDC Capture driver
Vaibhav, Hans already merged my dm365 patches. So you have rebase this to that before merging. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: Hiremath, Vaibhav >Sent: Monday, January 11, 2010 1:29 AM >To: Hiremath, Vaibhav; linux-me...@vger.kernel.org >Cc: linux-omap@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- >sou...@linux.davincidsp.com; Karicheri, Muralidharan >Subject: RE: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver > > >> -Original Message- >> From: Hiremath, Vaibhav >> Sent: Monday, January 04, 2010 7:33 PM >> To: linux-me...@vger.kernel.org >> Cc: linux-omap@vger.kernel.org; hverk...@xs4all.nl; davinci-linux- >> open-sou...@linux.davincidsp.com; Karicheri, Muralidharan; Hiremath, >> Vaibhav >> Subject: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver >> >> From: Vaibhav Hiremath >> >> While adding support for AM3517/05 devices I have implemented/came- >> across >> these features/enhancement/bug-fixes for VPFE-Capture driver. >> >> Also the important change added is, to introduced "ti-media" >> directory for all TI devices. >> >> Vaibhav Hiremath (9): >> Makfile:Removed duplicate entry of davinci >> TVP514x:Switch to automode for querystd >> tvp514x: add YUYV format support >> Introducing ti-media directory >> DMx:Update board files for ti-media directory change >> Davinci VPFE Capture:Return 0 from suspend/resume >> DM644x CCDC : Add Suspend/Resume Support >> VPFE Capture: Add call back function for interrupt clear to >> vpfe_cfg >> DM644x CCDC: Add 10bit BT support >> >> arch/arm/mach-davinci/include/mach/dm355.h |2 +- >> arch/arm/mach-davinci/include/mach/dm644x.h |2 +- >> drivers/media/video/Kconfig | 84 +- >> drivers/media/video/Makefile|4 +- >> drivers/media/video/davinci/Makefile| 17 - >> drivers/media/video/davinci/ccdc_hw_device.h| 110 -- >> drivers/media/video/davinci/dm355_ccdc.c| 1081 --- >> drivers/media/video/davinci/dm355_ccdc_regs.h | 310 >> drivers/media/video/davinci/dm644x_ccdc.c | 966 -- >> drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- >> drivers/media/video/davinci/vpfe_capture.c | 2055 >> - >> drivers/media/video/davinci/vpif.c | 296 --- >> drivers/media/video/davinci/vpif.h | 642 --- >> drivers/media/video/davinci/vpif_capture.c | 2168 >> --- >> drivers/media/video/davinci/vpif_capture.h | 165 -- >> drivers/media/video/davinci/vpif_display.c | 1654 >> - >> drivers/media/video/davinci/vpif_display.h | 175 -- >> drivers/media/video/davinci/vpss.c | 301 >> drivers/media/video/ti-media/Kconfig| 88 + >> drivers/media/video/ti-media/Makefile | 17 + >> drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ >> drivers/media/video/ti-media/dm355_ccdc.c | 1081 +++ >> drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 >> drivers/media/video/ti-media/dm644x_ccdc.c | 1090 >> drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ >> drivers/media/video/ti-media/vpfe_capture.c | 2067 >> + >> drivers/media/video/ti-media/vpif.c | 296 +++ >> drivers/media/video/ti-media/vpif.h | 642 +++ >> drivers/media/video/ti-media/vpif_capture.c | 2168 >> +++ >> drivers/media/video/ti-media/vpif_capture.h | 165 ++ >> drivers/media/video/ti-media/vpif_display.c | 1654 >> + >> drivers/media/video/ti-media/vpif_display.h | 175 ++ >> drivers/media/video/ti-media/vpss.c | 301 >> drivers/media/video/tvp514x.c | 15 + >> include/media/davinci/ccdc_types.h | 43 - >> include/media/davinci/dm355_ccdc.h | 321 >> include/media/davinci/dm644x_ccdc.h | 184 -- >> include/media/davinci/vpfe_capture.h| 200 --- >> include/media/davinci/vpfe_types.h | 51 - >> include/media/davinci/vpss.h| 69 - >> include/media/ti-media/ccdc_types.h | 43 + >> include/media/ti-media/dm355_ccdc.h | 321 >> include/media/ti-media/dm644x_ccdc.h| 184 ++ >> include/media/ti-media/vpfe_capture.h | 202 +++ >> include/media/ti-media/vpfe_types.h | 51 + >> include/media/ti-media/vpss.h | 69 + >> 46 files changed, 11207 insertions(+), 11040 deletions(-) >> delete mode 100644 drivers/media/video/davinci/Makefile >> delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h >> delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c >> delete mode 10
Re: [PATCH v3] ARM: L2 : Errata 588369: Clean & Invalidate do not invalidate clean lines
On Mon, Jan 11, 2010 at 02:37:08PM +, Catalin Marinas wrote: > On Mon, 2009-12-21 at 10:09 +, Santosh Shilimkar wrote: > > @@ -139,7 +184,12 @@ static void l2x0_flush_range(unsigned long start, > > unsigned long end) > > spin_lock_irqsave(&l2x0_lock, flags); > > } > > } > > +#ifdef CONFIG_PL310_ERRATA_588369 > > + cache_wait(base + L2X0_CLEAN_LINE_PA, 1); > > + cache_wait(base + L2X0_INV_LINE_PA, 1); > > +#else > > cache_wait(base + L2X0_CLEAN_INV_LINE_PA, 1); > > +#endif > > I don't think we need to way on two separate registers here. AFAICT, bit > 1 of those registers is shared for all the operations. > > As a general comment, maybe an inline function called something like > wait_writel(before/after) would be better than a lot of ifdefs in the > code, especially if one has a different workaround other than using TI's > secure monitor. Since the bit is shared between all 'R7' registers, the ifdef above makes no sense. We can just wait on any R7 register - I suggest that bit of code is left as-is. -- 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] ARM: L2 : Errata 588369: Clean & Invalidate do not invalidate clean lines
On Mon, 2009-12-21 at 10:09 +, Santosh Shilimkar wrote:
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index cb8fc65..5443c0d 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -28,6 +28,24 @@
> static void __iomem *l2x0_base;
> static DEFINE_SPINLOCK(l2x0_lock);
>
> +#ifdef CONFIG_PL310_ERRATA_588369
> +static void debug_writel(unsigned long val)
> +{
> + register unsigned long r0 asm("r0") = val;
> + /*
> +* Texas Instrument secure monitor api to modify the PL310
> +* Debug Control Register.
> +*/
> + __asm__ __volatile__(
> + __asmeq("%0", "r0")
> + "ldr r12, =0x100\n"
> + "dsb\n"
> + "smc\n"
> + : : "r" (r0)
> + : "r4", "r5", "r6", "r7", "r8");
Does your secure monitor corrupt r4-r8? Maybe you could add a comment
with a few words on this API.
Do you need to specify "r12" as well? What about "cc", are they
preserved by the secure monitor?
> @@ -139,7 +184,12 @@ static void l2x0_flush_range(unsigned long start,
> unsigned long end)
> spin_lock_irqsave(&l2x0_lock, flags);
> }
> }
> +#ifdef CONFIG_PL310_ERRATA_588369
> + cache_wait(base + L2X0_CLEAN_LINE_PA, 1);
> + cache_wait(base + L2X0_INV_LINE_PA, 1);
> +#else
> cache_wait(base + L2X0_CLEAN_INV_LINE_PA, 1);
> +#endif
I don't think we need to way on two separate registers here. AFAICT, bit
1 of those registers is shared for all the operations.
As a general comment, maybe an inline function called something like
wait_writel(before/after) would be better than a lot of ifdefs in the
code, especially if one has a different workaround other than using TI's
secure monitor.
--
Catalin
--
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] Regulator: Use common regulator supplies and init data structs
On Fri, Jan 8, 2010 at 7:57 PM, Anuj Aggarwal wrote:
> Common TWL4030 specific regulator supplies and init data structs are
> used instead of platform specific ones. Only one copy of the common
> structs will be included in the image, built for multiple OMAP3 based
> platforms.
>
> Signed-off-by: Anuj Aggarwal
> ---
> arch/arm/mach-omap2/board-3430sdp.c | 32 +
> arch/arm/mach-omap2/board-cm-t35.c | 14 ---
> arch/arm/mach-omap2/board-igep0020.c | 7 -
> arch/arm/mach-omap2/board-ldp.c | 7 -
> arch/arm/mach-omap2/board-omap3beagle.c | 14 ---
> arch/arm/mach-omap2/board-omap3evm.c | 25 +---
> arch/arm/mach-omap2/board-omap3pandora.c | 14 ---
> arch/arm/mach-omap2/board-omap3touchbook.c | 14 ---
> arch/arm/mach-omap2/board-overo.c | 8 +-
> arch/arm/mach-omap2/board-zoom-peripherals.c | 21 +++-
> 10 files changed, 108 insertions(+), 48 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index 2951029..b1267eb 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -55,6 +55,18 @@
>
> #define TWL4030_MSECURE_GPIO 22
>
> +extern struct regulator_consumer_supply twl4030_vmmc1_supply;
> +extern struct regulator_consumer_supply twl4030_vmmc2_supply;
> +extern struct regulator_consumer_supply twl4030_vsim_supply;
> +
> +extern struct regulator_init_data vaux1_data;
> +extern struct regulator_init_data vaux2_data;
> +extern struct regulator_init_data vaux3_data;
> +extern struct regulator_init_data vaux4_data;
> +extern struct regulator_init_data vmmc1_data;
> +extern struct regulator_init_data vmmc2_data;
> +extern struct regulator_init_data vsim_data;
Have you tried running your patches through ./scripts/checkpatch.pl?
WARNING: externs should be avoided in .c files
#75: FILE: arch/arm/mach-omap2/board-3430sdp.c:58:
+extern struct regulator_consumer_supply twl4030_vmmc1_supply;
> diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
> b/arch/arm/mach-omap2/board-omap3pandora.c
> index 4a24d94..98b46ef 100644
> --- a/arch/arm/mach-omap2/board-omap3pandora.c
> +++ b/arch/arm/mach-omap2/board-omap3pandora.c
> @@ -258,8 +264,8 @@ static struct twl4030_platform_data omap3pandora_twldata
> = {
> .gpio = &omap3pandora_gpio_data,
> .usb = &omap3pandora_usb_data,
> .codec = &omap3pandora_codec_data,
> - .vmmc1 = &pandora_vmmc1,
> - .vmmc2 = &pandora_vmmc2,
> + .vmmc1 = &vmmc1_data,
> + .vmmc2 = &vmmc2_data,
Your common supply file has VMMC2 supply configured for 1.8V which is
wrong for pandora (it uses 3.1V because it has a transceiver attached
to MMC2 that handles level shifting transparently).
I think you should leave pandora board file alone, because it uses
many supplies differently than your common file configures them
(VAUX1-VAUX4, VSIM differ, only VMMC1, VDAC and VPLL2 match, which is
not that much duplication).
--
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] ARCH OMAP : enable ARCH_HAS_HOLES_MEMORYMODEL for OMAP
From: Menon, Nishanth > Sent: Friday, January 08, 2010 8:33 PM > To: Govindarajan, Sriramakrishnan > Cc: linux-omap@vger.kernel.org; Syed Mohammed, Khasim; Nori, Sekhar > Subject: Re: [PATCH] ARCH OMAP : enable ARCH_HAS_HOLES_MEMORYMODEL for > OMAP > > Govindarajan, Sriramakrishnan had written, on 01/08/2010 02:15 AM, the > following: > > > >> From: Menon, Nishanth > >> Govindarajan, Sriramakrishnan had written, on 01/07/2010 06:30 AM, the > >> following: > >>> From: Sriram > >>> > >>> OMAP platforms(like OMAP3530) include DSP or other co-processors > >>> for media acceleration. when carving out memory for the > >>> accelerators we can end up creating a hole in the memory map > >>> of sort: > >>> > >>> > >>> To handle such a memory configuration ARCH_HAS_HOLES_MEMORYMODEL > >>> has to be enabled. For further information refer discussion at: > >>> http://www.mail-archive.com/linux-o...@vger.kernl.org/msg15262.html. > >> pls check the link: I see "The document you were looking for was not > >> found." > > > > The URL is spelt incorrectly. Here is the correct URL: > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15262.html > > > >>> select GENERIC_TIME > >>> select GENERIC_CLOCKEVENTS > >>> + select ARCH_HAS_HOLES_MEMORYMODEL > >> why enable this for all OMAPs? > > > > I have tested this on several OMAP3 platforms and this feature is > required > > Wherever some memory needs to be reserved for media accelerators - hence > it > > Would be handy for earlier OMAP platforms as well > I understand that you have tested with OMAP3. my question is you have > handled this as per the diff > @@ -699,6 +699,7 @@ config ARCH_OMAP > to ARCH_OMAP > > is this good for OMAP1510, 1610, 1710, 2420,2430, 770 etc..? I do not have other OMAP platforms for me to validate this patch on. I believe the nature of change is generic and benefit other OMAP Platforms as well. Regards Sriram -- 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 09/15] MAINTAINERS: Combine DSS2 and OMAPFB2 into one entry
On Fri, Jan 8, 2010 at 3:22 PM, Tomi Valkeinen wrote: > There isn't really any reason to divide those. > > Signed-off-by: Tomi Valkeinen > --- > MAINTAINERS | 13 ++--- > 1 files changed, 2 insertions(+), 11 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8d2fcee..d370787 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3955,23 +3955,14 @@ L: linux-o...@vger.kernel.org > S: Maintained > F: drivers/video/omap/ > > -OMAP DISPLAY SUBSYSTEM SUPPORT (DSS2) > +OMAP DISPLAY SUBSYSTEM and FRAMEBUFFER SUPPORT (DSS2) > M: Tomi Valkeinen > L: linux-omap@vger.kernel.org > L: linux-fb...@vger.kernel.org (moderated for non-subscribers) Not that it's very important, but linux-fbdev is not really moderated (see other entries in this file), this is probably leftover from the old list (linux-fbdev-de...@lists.sourceforge.net). > S: Maintained > -F: drivers/video/omap2/dss/ > -F: drivers/video/omap2/vrfb.c > -F: drivers/video/omap2/vram.c > +F: drivers/video/omap2/ > F: Documentation/arm/OMAP/DSS > > -OMAP FRAMEBUFFER SUPPORT (FOR DSS2) > -M: Tomi Valkeinen > -L: linux-omap@vger.kernel.org > -L: linux-fb...@vger.kernel.org (moderated for non-subscribers) > -S: Maintained > -F: drivers/video/omap2/omapfb/ > - > OMAP MMC SUPPORT > M: Jarkko Lavinen > L: linux-omap@vger.kernel.org > -- > 1.6.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 > -- 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] Regulator: Makefile modified to include TWL4030-PMIC specific file
Anuj Aggarwal wrote: > Makefile is modified so that board-omap35x-twl4030-pmic.c gets compiled > for the platforms having TWL4030 as the PMIC. > > Signed-off-by: Anuj Aggarwal > --- > arch/arm/mach-omap2/Makefile |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Can you combine this patch with "Modifying Kconfig to choose from the available PMICs" patch? Moreover, I think the patches should be reordered so that kernel build won't be broken. Maybe something like: 1 - Creating TWL4030 specific file having supplies & init data 2 - Modifying Kconfig and Makefile to choose from the available PMICs 3 - Kconfig modified to select TWL4030 for OMAP3 based platforms 4 - Use common regulator supplies and init data structs > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index b32678b..181be39 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -107,6 +107,7 @@ obj-$(CONFIG_MACH_IGEP0020) += > board-igep0020.o \ > mmc-twl4030.o > obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \ > mmc-twl4030.o > +obj-$(CONFIG_PMIC_TWL4030) += board-omap35x-twl4030-pmic.o > obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o > > obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o -- Sincerely yours, Mike. -- 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] Regulator: Modifying Kconfig to choose from the available PMICs
Anuj Aggarwal wrote: > Kconfig is modified for OMAP3 EVM so that user can choose the appropriate > PMIC (currently only TWL4030). Config options for other PMICs will be > added later on. > > Signed-off-by: Anuj Aggarwal > --- > arch/arm/mach-omap2/Kconfig |9 + > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 606bf04..95b8eb2 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -82,6 +82,15 @@ config MACH_OMAP3EVM > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > > +config PMIC_TWL4030 > + bool "TWL4030/TPS65950 Power Module" > + default y > + depends on TWL4030_CORE && MACH_OMAP3EVM I don't think PMIC_TWL4030 should depend on MACH_OMAP3EVM > + select REGULATOR_TWL4030 if REGULATOR > + help > + Say yes here if you are using the TWL4030/TPS65950 based power module > + for the EVM boards. > + > config MACH_OMAP3517EVM > bool "OMAP3517/ AM3517 EVM board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX -- Sincerely yours, Mike. -- 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] Regulator: Creating TWL4030 specific file having supplies & init data
Anuj Aggarwal wrote:
> A new file for TWL4030/TPS65950 is created which has common supplies
> and regulator init data structures. They will be referenced from the
> various board-evm files depending upon the EVM requirements.
>
> Signed-off-by: Anuj Aggarwal
> ---
> arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c | 175
> ++
> 1 files changed, 175 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
>
> diff --git a/arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
> b/arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
> new file mode 100644
> index 000..0b7cd74
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
[ snip ]
> +/* Regulator initialization data */
> +/* VAUX1 */
> +struct regulator_init_data vaux1_data = {
The reulator_init_data structs are now global, so I think they should
have twl4030_ prefix
> + .constraints = {
> + .min_uV = 280,
> + .max_uV = 280,
> + .apply_uV = true,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> +};
> +
> +/* VAUX2 */
> +struct regulator_init_data vaux2_data = {
> + .constraints = {
> + .min_uV = 280,
> + .max_uV = 280,
> + .apply_uV = true,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> +};
> +
> +/* VAUX3 */
> +struct regulator_init_data vaux3_data = {
> + .constraints = {
> + .min_uV = 280,
> + .max_uV = 280,
> + .apply_uV = true,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> +};
> +
> +/* VAUX4 */
> +struct regulator_init_data vaux4_data = {
> + .constraints = {
> + .min_uV = 180,
> + .max_uV = 180,
> + .apply_uV = true,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> +};
> +
> +/* VMMC1 */
> +struct regulator_init_data vmmc1_data = {
> + .constraints = {
> + .min_uV = 185,
> + .max_uV = 315,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
> + | REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &twl4030_vmmc1_supply,
> +};
> +
> +/* VMMC2 */
> +struct regulator_init_data vmmc2_data = {
> + .constraints = {
> + .min_uV = 185,
> + .max_uV = 185,
> + .apply_uV = true,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &twl4030_vmmc2_supply,
> +};
> +
> +/* VSIM */
> +struct regulator_init_data vsim_data = {
> + .constraints = {
> + .min_uV = 180,
> + .max_uV = 300,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
> + | REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &twl4030_vsim_supply,
> +};
> +
> +/* VDAC */
> +struct regulator_init_data vdac_data = {
> + .constraints = {
> + .min_uV = 180,
> + .max_uV = 180,
> +
Re: [PATCH 4/6] Regulator: Modifying Kconfig to choose from the available PMICs
On Fri, Jan 08, 2010 at 11:28:06PM +0530, Anuj Aggarwal wrote: > +config PMIC_TWL4030 > + bool "TWL4030/TPS65950 Power Module" > + default y > + depends on TWL4030_CORE && MACH_OMAP3EVM > + select REGULATOR_TWL4030 if REGULATOR > + help > + Say yes here if you are using the TWL4030/TPS65950 based power module > + for the EVM boards. > + Perhaps this should select the TWL4030 driver rather than depending on it? Configuration variables that require selection over different menus can be a bit obscure for users since (in this case) they need to know to go to the MFD menu, enable the TWL4030 then go back down into the OMAP menu to enable the board-specific support. -- 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] Regulator: Creating TWL4030 specific file having supplies & init data
On Fri, Jan 08, 2010 at 11:27:43PM +0530, Anuj Aggarwal wrote: > A new file for TWL4030/TPS65950 is created which has common supplies > and regulator init data structures. They will be referenced from the > various board-evm files depending upon the EVM requirements. > > Signed-off-by: Anuj Aggarwal > --- > arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c | 175 > ++ > 1 files changed, 175 insertions(+), 0 deletions(-) Shouldn't there be a header file as well? -- 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] Regulator: Removing the common supplies and regulator init data structs
On Fri, Jan 08, 2010 at 11:27:53PM +0530, Anuj Aggarwal wrote: > Removing the common supplies and regulator init data structs for various > OMAP3 platforms. They all have been moved to a common TWL4030 specific file > and will be referenced from there. > Signed-off-by: Anuj Aggarwal I'd expect this to be combined with the patch adding the usage of the shared definitions so that the substitution that's being done is a bit clearer. -- 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] Regulator: Removing common code for TWL4030 PMIC from various OMAP3 board-evms
On Fri, Jan 08, 2010 at 11:27:28PM +0530, Anuj Aggarwal wrote: > Based on the discussions and feedback received, this patch set is > created which cleans up various OMAP3-board-evm files and removes > common TWL4030 specific regulator suuplies and init data structs. Please use an OMAP-specific subject line for this patch series - there's no generic regulator changes in here, it's all OMAP-specific. This helps with scanning inboxes and mailing list folders. -- 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/1] Regulator: Registering USB internal LDOs for TWL4030
On Mon, Jan 11, 2010 at 02:55:18PM +0530, Anuj Aggarwal wrote: > Adding member variables for USB internal LDOs in twl4030_platform_data > and registering them in twl-core.c if the variables are populated > from board-evm file. > Signed-off-by: Anuj Aggarwal Acked-by: Mark Brown -- 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
