Re: [PATCH E 11/14] OMAP clock: track child clocks
Hello Russell,
On Sat, 14 Feb 2009, Russell King - ARM Linux wrote:
On Sat, Feb 14, 2009 at 11:23:25AM +, Russell King - ARM Linux wrote:
There's also a second issue - the comments before omap2_divisor_to_clksel()
indicate that this function returns 0x on error. Unfortunately,
this is not so, it actually returns zero on error. Moreover, we test
the result of the function against ~0, so we'll never deal with the error
case. This really should be fixed so that we return the right value for
the error case. (Further comments on this in a follow up.)
The thing I don't like about this is that we have several functions looking
up clksel_rate entries, some of which return 0 on error and others ~0 on
error.
This is very prone to mistakes - and is probably why the original problem
has occurred. I'd much prefer to fix the underlying confusion rather
than letting it persist, by making all these lookup functions return the
clksel_rate pointer or NULL.
Not only does that avoid the question about whether the function returns
0 or ~0 on error, but it also gets rid of the horrible return-through-pointer
style of _omap2_clksel_get_src_field() which itself is error prone.
(The kernel has had a few cases where this kind of thing has lead to
uninitialized use, so avoiding this where it's easy to do so makes
sense.)
One final point:
if (parent_div 0)
clk-rate /= parent_div;
seems to be impossible to be false - the old code used div == 0 in the
tables as the end of table sentinel, and if it is encountered,
_omap2_clksel_get_src_field (and the newer omap2_clksel_lookup_parent)
causes failure to occur. Also, since parent_div is unsigned, the only
case where the above statement is false is when div == 0. So, the code
can be further simplified to:
/* CLKSEL clocks follow their parents' rates, divided by a divisor */
clk-rate = new_parent-rate / clkr-div;
Agreed?
Agreed on both points -- a few comments on the patch:
diff -u a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -596,23 +596,24 @@
}
/**
- * omap2_clksel_to_divisor() - turn clksel field value into integer divider
+ * omap2_clksel_lookup_field() - lookup clksel_rate for clksel field value
* @clk: OMAP struct clk to use
* @field_val: register field value to find
*
* Given a struct clk of a rate-selectable clksel clock, and a register field
- * value to search for, find the corresponding clock divisor. The register
+ * value to search for, find the corresponding clksel_rate entry. The
register
* field value should be pre-masked and shifted down so the LSB is at bit 0
- * before calling. Returns 0 on error
+ * before calling. Returns NULL on error.
*/
-u32 omap2_clksel_to_divisor(struct clk *clk, u32 field_val)
+static const
+struct clksel_rate *omap2_clksel_lookup_field(struct clk *clk, u32 field_val)
{
const struct clksel *clks;
const struct clksel_rate *clkr;
clks = omap2_get_clksel_by_parent(clk, clk-parent);
if (!clks)
- return 0;
+ return NULL;
for (clkr = clks-rates; clkr-div; clkr++) {
if ((clkr-flags cpu_mask) (clkr-val == field_val))
@@ -623,22 +624,22 @@
printk(KERN_ERR clock: Could not find fieldval %d for
clock %s parent %s\n, field_val, clk-name,
clk-parent-name);
- return 0;
+ return NULL;
}
- return clkr-div;
+ return clkr;
}
/**
- * omap2_divisor_to_clksel() - turn clksel integer divisor into a field value
+ * omap2_clksel_lookup_divisor() - lookup clksel_rate for integer divisor
* @clk: OMAP struct clk to use
* @div: integer divisor to search for
*
- * Given a struct clk of a rate-selectable clksel clock, and a clock divisor,
- * find the corresponding register field value. The return register value is
- * the value before left-shifting. Returns ~0 on error
+ * Given a struct clk of a rate-selectable clksel clock and a clock divisor,
+ * find the corresponding clksel_rate entry. Returns NULL on error.
*/
-u32 omap2_divisor_to_clksel(struct clk *clk, u32 div)
+static const
+struct clksel_rate *omap2_clksel_lookup_divisor(struct clk *clk, u32 div)
{
const struct clksel *clks;
const struct clksel_rate *clkr;
@@ -648,7 +649,7 @@
clks = omap2_get_clksel_by_parent(clk, clk-parent);
if (!clks)
- return ~0;
+ return NULL;
for (clkr = clks-rates; clkr-div; clkr++) {
if ((clkr-flags cpu_mask) (clkr-div == div))
@@ -659,10 +660,10 @@
printk(KERN_ERR clock: Could not find divisor %d for
clock %s parent %s\n, div, clk-name,
clk-parent-name);
- return ~0;
+
Re: [patch 2.6.29-rc5-omap-git] mach-omap2/mmc-twl4030: fix for vmmc = 0
David Brownell wrote: On Tuesday 24 February 2009, Adrian Hunter wrote: David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Resolve longstanding issue noted by Adrian Hunter: confusion between settting VSEL=0 (which is 1.8V on MMC1) and poweroff. Also, leave VSEL alone if we're just powering the regulator off. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- Looks fine to me, but I wonder if you know why the regulator is turned on (DEV_GRP) and then the voltage is selected (DEDICATED). History, I'd guess. I seem to remember some sequencing constraint, but couldn't find it when last I sought it out in the reference manual. What about section 5.5.1 item 6? Wouldn't it make more sense the other way around? I had the same thought. Eventually I'd like this code to mostly wither away ... using the regulator framework for the hsmmc driver will eliminate most of the remaining bits of twl4030-specific code. So I'd just leave it be for the moment. Doesn't the new regulator framework do it that way? No; setting voltage and enabling are distinct operations. Perhaps, but there are features like regulator constraints, or the Virtual regulator that do set the voltage and then enable. -- 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.29-rc5-omap-git] mach-omap2/mmc-twl4030: fix for vmmc = 0
Looks fine to me, but I wonder if you know why the regulator is turned on (DEV_GRP) and then the voltage is selected (DEDICATED). History, I'd guess. I seem to remember some sequencing constraint, but couldn't find it when last I sought it out in the reference manual. What about section 5.5.1 item 6? That's an example. I'm thinking the constraint had to do with one or more of the USB regulators. It just doesn't make sense to have a *general* rule that the resource needs to be enabled before tweaking. Maybe it was an erratum or something. Wouldn't it make more sense the other way around? I had the same thought. Eventually I'd like this code to mostly wither away ... using the regulator framework for the hsmmc driver will eliminate most of the remaining bits of twl4030-specific code. So I'd just leave it be for the moment. Doesn't the new regulator framework do it that way? No; setting voltage and enabling are distinct operations. Perhaps, but there are features like regulator constraints, or the Virtual regulator that do set the voltage and then enable. Right, and I have most certainly configured regulators with regulator_init_data.constraints.apply_uV so that the VSEL gets set to a sane value as Linux sets up, since u-boot wasn't touching it. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] MUSB and TWL4030-USB fixes
Hi, These fixes are the replacement of [ARM: OMAP: Disable USB interrupt in the musb_resume() function] and trying to following David Brownell's recommendation. Thanks, especially David. -- Kyuwon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: musb: fix the possible panic while resuming
From: Kim Kyuwon chamm...@gmail.com
While waking up, musb can cause a kernel panic. This patch is fixing
it by enabling the clock in the resume_early method.
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/musb/musb_core.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..ae76ad7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2141,16 +2141,13 @@ static int __devexit musb_remove(struct
platform_device *pdev)
#ifdef CONFIG_PM
-static int musb_suspend(struct platform_device *pdev, pm_message_t message)
+static int musb_suspend_late(struct platform_device *pdev, pm_message_t state)
{
- unsigned long flags;
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct musb *musb = dev_to_musb(pdev-dev);
if (!musb-clock)
return 0;
- spin_lock_irqsave(musb-lock, flags);
-
if (is_peripheral_active(musb)) {
/* FIXME force disconnect unless we know USB will wake
* the system up quickly enough to respond ...
@@ -2165,20 +2162,17 @@ static int musb_suspend(struct platform_device
*pdev, pm_message_t message)
musb-set_clock(musb-clock, 0);
else
clk_disable(musb-clock);
- spin_unlock_irqrestore(musb-lock, flags);
+
return 0;
}
-static int musb_resume(struct platform_device *pdev)
+static int musb_resume_early(struct platform_device *pdev)
{
- unsigned long flags;
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct musb *musb = dev_to_musb(pdev-dev);
if (!musb-clock)
return 0;
- spin_lock_irqsave(musb-lock, flags);
-
if (musb-set_clock)
musb-set_clock(musb-clock, 1);
else
@@ -2188,7 +2182,6 @@ static int musb_resume(struct platform_device *pdev)
* unless for some reason the whole soc powered down and we're
* not treating that as a whole-system restart (e.g. swsusp)
*/
- spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
@@ -2205,8 +2198,8 @@ static struct platform_driver musb_driver = {
},
.remove = __devexit_p(musb_remove),
.shutdown = musb_shutdown,
- .suspend= musb_suspend,
- .resume = musb_resume,
+ .suspend_late = musb_suspend_late,
+ .resume_early = musb_resume_early,
};
/*-*/
--
1.5.2.5
--
Kyuwon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] twl: usb: Add the resume() and suspend() methods to twl4030-usb.c
From: Minkyu Kang mk7.k...@samsung.com
The MPU module can be waked up by the unexpected USB
interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
peripheral mode and connected to a host PC, it can never enter the low
power mode due to interrupts from the host PC. This patch added the
feature that a board specific file can determines that TWL4030
supplies the USB power or not in the low power mode. Disabling the USB
power may save the power consumption.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 25 +
include/linux/i2c/twl4030.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 416e441..0d65a8d 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -256,6 +256,7 @@ struct twl4030_usb {
u8 linkstat;
u8 asleep;
boolirq_enabled;
+ boolsuspend_enabled;
};
/* internal define on top of container_of */
@@ -618,6 +619,7 @@ static int __init twl4030_usb_probe(struct
platform_device *pdev)
twl-otg.set_suspend= twl4030_set_suspend;
twl-usb_mode = pdata-usb_mode;
twl-asleep = 1;
+ twl-suspend_enabled= pdata-suspend_enabled;
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -694,9 +696,32 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+int twl4030_usb_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ if (!twl-suspend_enabled)
+ return 0;
+
+ twl-otg.set_suspend(twl-otg, 1);
+
+ return 0;
+}
+
+int twl4030_usb_resume(struct platform_device *pdev)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ twl-otg.set_suspend(twl-otg, 0);
+
+ return 0;
+}
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index c89d33b..0b12509 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -325,6 +325,7 @@ enum twl4030_usb_mode {
struct twl4030_usb_data {
enum twl4030_usb_mode usb_mode;
+ bool suspend_enabled;
};
struct twl4030_ins {
--
1.5.2.5
--
Kyuwon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] twl: usb: Add the resume() and suspend() methods to twl4030-usb.c
On Wed, Feb 25, 2009 at 12:55:41PM +0100, ext Kim Kyuwon wrote:
+int twl4030_usb_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ if (!twl-suspend_enabled)
+ return 0;
+
+ twl-otg.set_suspend(twl-otg, 1);
otg_set_suspend(otg, 1);
+
+ return 0;
+}
+
+int twl4030_usb_resume(struct platform_device *pdev)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ twl-otg.set_suspend(twl-otg, 0);
otg_set_suspend(otg, 0);
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap2: off by 1
with while (i++ MAX_CLOCK_ENABLE_WAIT); i can reach MAX_CLOCK_ENABLE_WAIT + 1
after the loop, so if (i == MAX_CLOCK_ENABLE_WAIT) that's still success.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/mach-omap2/powerdomain.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index ce4d46a..da185ff 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -202,7 +202,7 @@ int omap2_wait_clock_ready(void __iomem *reg, u32 mask,
const char *name)
udelay(1);
}
- if (i MAX_CLOCK_ENABLE_WAIT)
+ if (i = MAX_CLOCK_ENABLE_WAIT)
pr_debug(Clock %s stable after %d loops\n, name, i);
else
printk(KERN_ERR Clock %s didn't enable in %d tries\n,
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 73e2971..983f1cb 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1099,7 +1099,7 @@ int pwrdm_wait_transition(struct powerdomain *pwrdm)
(c++ PWRDM_TRANSITION_BAILOUT))
udelay(1);
- if (c = PWRDM_TRANSITION_BAILOUT) {
+ if (c PWRDM_TRANSITION_BAILOUT) {
printk(KERN_ERR powerdomain: waited too long for
powerdomain %s to complete transition\n, pwrdm-name);
return -EAGAIN;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to pass camera Orientation to userspace
Actually, this happens and is happening! I got OT. I just needed to vent! Sorry for the spam. For the sensor mounting, I think the cam knows how the sensor is mounted and therefor the driver knows (driver - first abstraction layer between software and hardware). Therefor the drive has to report the sensor orientation to user space (read only). Thomas PS: May be, I am OT all ready. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch/rfc 2.6.29-rc6 1/2] regulator: enumerate voltages
On Tue, Feb 24, 2009 at 04:17:22PM -0800, David Brownell wrote: On Tuesday 24 February 2009, Mark Brown wrote: + /* maybe force machine-wide voltage constraints to match the + * voltages supported by this regulator. use the regulator's + * entire range for boards with no particular constraints. + */ I'd really rather the second bit weren't here. I'd like to see a warning for the first part. Fixable in an update. I still think it's better to require less manual configuration, not more ... manual configuration is by definition error prone; requiring more manual configuration makes This whole interface is structured around the idea that the consequences of getting this wrong include things like lasting hardware damage. This hardware damage may not be immediately obvious but may develop over time if components are kept running out of spec, either way it's not likely to make users happy. systems be more fragile. Which is why I wouldn't naturally want to see a warning: it implies manual configuration is desirable. If we weren't so reliant on the machine driver getting things right I'd agree with you. My thought here is that because there is room for human error here it'd be good to use the information we do have to flag potential problems to people, helping catch any mistakes that they make. I'm having a hard time loving this interface for the driver. It feels fairly cumbersome to have to provide two functions to look up what I'd expect to be static data - I'd be fairly surprised to see it change at runtime. It can be a function of configuration, and I didn't want to force such seldom-used data into wasteful standardized-format tables. Notice that with the twl4030 code, a functional interface takes less space ... and is more flexible, since it copes with the voltage options that are defined as not supported. Yeah, TWL4030 is pretty special here :/ . The only gotcha I can see is having to have a second table with only supported values in it for the case where you're not allowing the out of spec values but TBH I don't see that as a big deal. Consider also the TPS6235x regulators: the voltages they support are a simple linear function of an index 0..63, and that driver handles seven such chips. 64 values * 4 bytes * 7 chips == about 2KB of table data ... vs a few dozen bytes of function code. That's actually the most common case in the regulators I'd seen and is why I'd suggested doing something like the ALSA dB scales which handle this nicely - you don't need to actually have a table with all the values, you just provide parmeters that expresses each sub range. You say things like DECLARE_TLV_DB_SCALE(mix_tlv, -1500, 300, 0); As far as hardware requirements go I've seen regulators which provide: - A set of irregularly distributed values (usually fairly small). - A range of regularly distributed values. - A large range of values with several regular ranges in it (usually you get higher resolution at the low end). Either way can be made to work for all of these, the concerns I have are that the fact that it's a function based interface makes it look like this might be dynamic data and that it's exposing a bit too much of the implementation details (see below) which made that suggestion seem even stronger. [ALSA dB scale style] Another virtue of functional interfaces for enumeration is they avoid the need for callers to see and handle a variety of different models, like that!! I'd expect the core to deal with unrolling the data rather than the consumers, this is why... This mostly applies to the driver interface - on the consumer side it feels a bit cumbersome to use but I can't think of anything that's particularly better. There's a LONG history of functional iterator models, such as the one I used. I think they are clearly better, and don't understand why you'd prefer that more cumbersome approach. ...I am, as I say, reasonably OK with it on the consumer side. The only issue I have with it on the consumer side is that the invalid slots in the array are visible to users since it feels icky to have error conditions be part of the normal iteration process for what should be well known constant data. I worry that it's going to catch people out since relatively few regulator drivers do that (the fact that it's there is an implementation detail for drivers which have holes in the range of register values they can set). Thinking about it that could be hidden by mapping the invalid values to zero or some value that is actually valid instead of returning an error - not entirely nice but it keeps the pain away from the consumers. An interface that also allows consumers to ask if particular ranges can be satisfied might help here - it'd be nice for things like MMC that want to check for a relatively small set of voltages or voltage ranges (which I'd expect is the common case). Umm, did you look at the MMC patch I
Re: leds-gpio broken with current git?
On Feb 23, 2009, at 4:08 PM, David Brownell wrote:
On Monday 23 February 2009, David Brownell wrote:
Perhaps something broke with Tony's RC1 merge?
The LEDs are broken for me as well.
Still works for me. Did you maybe not enable the twl4030
GPIO support in Kconfig?
Oh, and if you did *not*, please give this patch a try.
I've been meaning to test it.
Thanks, the patch works. Not enabling the TWL4030 GPIO was the issue
and this patch provides a good method of not having all the GPIOs fail
due to the failure of just one. Diego assisted in the test, as I had
first taken the approach of removing the failing GPIO.
- Dave
==
Sometimes it's awkward to make sure that the array in the
platform_data handed to the leds-gpio driver has only valid
data ... some leds may not be always available, and coping
with that currently requires patching or rebuilding the array.
This patch fixes that by making it be OK to pass an invalid
GPIO (such as -EINVAL) ... such table entries are skipped.
---
drivers/leds/leds-gpio.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -90,13 +90,19 @@ static int gpio_led_probe(struct platfor
cur_led = pdata-leds[i];
led_dat = leds_data[i];
+ /* skip leds that aren't available */
+ led_dat-gpio = cur_led-gpio;
+ if (!gpio_is_valid(led_dat-gpio)) {
+ dev_dbg(pdev-dev, skipping %s\n, cur_led-name);
+ continue;
+ }
+
ret = gpio_request(cur_led-gpio, cur_led-name);
if (ret 0)
goto err;
led_dat-cdev.name = cur_led-name;
led_dat-cdev.default_trigger = cur_led-default_trigger;
- led_dat-gpio = cur_led-gpio;
led_dat-can_sleep = gpio_cansleep(cur_led-gpio);
led_dat-active_low = cur_led-active_low;
if (pdata-gpio_blink_set) {
@@ -125,6 +131,8 @@ static int gpio_led_probe(struct platfor
err:
if (i 0) {
for (i = i - 1; i = 0; i--) {
+ if (!gpio_is_valid(leds_data[i].gpio))
+ continue;
led_classdev_unregister(leds_data[i].cdev);
cancel_work_sync(leds_data[i].work);
gpio_free(leds_data[i].gpio);
@@ -145,6 +153,8 @@ static int __devexit gpio_led_remove(str
leds_data = platform_get_drvdata(pdev);
for (i = 0; i pdata-num_leds; i++) {
+ if (!gpio_is_valid(leds_data[i].gpio))
+ continue;
led_classdev_unregister(leds_data[i].cdev);
cancel_work_sync(leds_data[i].work);
gpio_free(leds_data[i].gpio);
--
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
[PATCH][OMAPZOOM] DSPBRIDGE: Remove variables not used in cfgdefs.h
From d3aeedc4677ebe6fdfb7f9f68b72ad5dc96463f0 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 25 Feb 2009 10:19:12 -0600
Subject: [PATCH] DSPBRIDGE: Remove variables not used in cfgdefs.h
This patch removes some variable that are not used.
Signed-off-by: Guzman Lugo Fernando x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/cfgdefs.h | 10 --
drivers/dsp/bridge/rmgr/drv.c |2 --
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
index e7633b5..34a28f8
--- a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
@@ -77,15 +77,6 @@
u8 bIRQAttrib; /* IRQ Attribute */
u32 dwOffsetForMonitor; /* The Shared memory starts from
* dwMemBase + this offset */
- u32 dwBusType; /* Bus type for this device */
- u32 dwProgBase; /* DSP ProgBase */
- u32 dwProgLength; /* DSP ProgBase Length */
- u32 dwRegBase; /* DSP memory mapped register base */
- u32 dwRegLength;/* DSP Register Base Length */
- u32 ClientHandle; /* Client Handle */
- u32 SocketHandle; /* Socket and Function Pair */
- u32 CardInfo; /* This will be used as a context data in
-* in the CardRequestIRQ */
/*
* Info needed by NODE for allocating channels to communicate with RMS:
* dwChnlOffset: Offset of RMS channels. Lower channels are
@@ -102,7 +93,6 @@
void __iomem *dwWdTimerDspBase;
void __iomem *dwMboxBase;
void __iomem *dwDmmuBase;
- u32 *dwDipiBase;
void __iomem *dwSysCtrlBase;
} ;
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 2241f48..160d730
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1733,7 +1733,6 @@ static DSP_STATUS RequestBridgeResources(u32 dwContext,
s32 bRequest)
/* Second window is for DSP external memory shared with MPU */
if (DSP_SUCCEEDED(status)) {
/* for Linux, these are hard-coded values */
- pResources-dwBusType = 0;
pResources-bIRQRegisters = 0;
pResources-bIRQAttrib = 0;
pResources-dwOffsetForMonitor = 0;
@@ -1856,7 +1855,6 @@ static DSP_STATUS RequestBridgeResourcesDSP(u32
dwContext, s32 bRequest)
}
if (DSP_SUCCEEDED(status)) {
/* for Linux, these are hard-coded values */
- pResources-dwBusType = 0;
pResources-bIRQRegisters = 0;
pResources-bIRQAttrib = 0;
pResources-dwOffsetForMonitor = 0;
--
1.5.6.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
GPMC address signals gpmc_a11 to gpmc_a26
Hi, Can someone tell me why gpmc_a11 to gpmc_a26 signals are missing from initial pages for the CBB package specification, in the OMAP3515/03 Applications Processor document (Rev. C)? If you go down to page 91 of the same document, it lists gpmc_a11 to gpmc_a26. Are the address lines multiplexed somehow for the TI OMAP GPMC, because if you look at the following table, the pin numbers are the same for a couple of them, e.g AC16 for gpmc_a3, gpmc_a19. I can't seem to find a pattern here. Best regards, Elvis -- 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: GPMC address signals gpmc_a11 to gpmc_a26
Hi, Can someone tell me why gpmc_a11 to gpmc_a26 signals are missing from initial pages for the CBB package specification, in the OMAP3515/03 Applications Processor document (Rev. C)? If you go down to page 91 of the same document, it lists gpmc_a11 to gpmc_a26. Are the address lines multiplexed somehow for the TI OMAP GPMC, because if you look at the following table, the pin numbers are the same for a couple of them, e.g AC16 for gpmc_a3, gpmc_a19. I can't seem to find a pattern here. Best regards, Elvis Hi Elvis, The GPMC is an address/data-multiplexed bus sharing the lower 16 address lines between address and data. I admit, that the naming in the Datasheet might be a bit misleading, but the way it should be read is like: GPMC_dxx is the 16 data lines for data GPMC_dxx is the lower 16 address lines for address GPMC_a1 is address line 17 GPMC_a2 address line 18 GPMC_a3 address line 19 - and so forth This as well explains why you though that address lines 3 and 19 could be multiplexed :-) Best regards Søren -- 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: GPMC address signals gpmc_a11 to gpmc_a26
Thanks Soren! I would have never figured this out, if you hadn't explained it!! :-) Best regards, Elvis On Feb 25, 2009, at 10:46 PM, Søren Steen Christensen wrote: Hi, Can someone tell me why gpmc_a11 to gpmc_a26 signals are missing from initial pages for the CBB package specification, in the OMAP3515/03 Applications Processor document (Rev. C)? If you go down to page 91 of the same document, it lists gpmc_a11 to gpmc_a26. Are the address lines multiplexed somehow for the TI OMAP GPMC, because if you look at the following table, the pin numbers are the same for a couple of them, e.g AC16 for gpmc_a3, gpmc_a19. I can't seem to find a pattern here. Best regards, Elvis Hi Elvis, The GPMC is an address/data-multiplexed bus sharing the lower 16 address lines between address and data. I admit, that the naming in the Datasheet might be a bit misleading, but the way it should be read is like: GPMC_dxx is the 16 data lines for data GPMC_dxx is the lower 16 address lines for address GPMC_a1 is address line 17 GPMC_a2 address line 18 GPMC_a3 address line 19 - and so forth This as well explains why you though that address lines 3 and 19 could be multiplexed :-) Best regards Søren -- 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: [alsa-devel] [PATCH] ASoC: Add support for OMAP3 EVM
Hi, On Tue, Nov 25, 2008 at 02:52:58PM +, Mark Brown wrote: On Tue, Nov 25, 2008 at 01:21:20PM +0200, Jarkko Nikula wrote: Or if those EVM's SDP's can route TWL4030 audio connections more flexible than Beagle but somewhat similar manner, then probably have one single machine driver for all EVM's? Otherwise it doesn't make very much sense to have n similar machine drivers where only functions and variable names differ. Yes, it looks like a lot of these drivers could be redone along the lines of s3c24xx_uda134x.c with platform data specifying the differences between the boards. Is someone working on updating ASoC drivers for OMAP TWL4030 based boards as recommended above? Just curious since I already made the mistake of creating my own OMAP3 EVM ASoC driver w/o checking the list first. : / -- Regards, George -- 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: [alsa-devel] [PATCH] ASoC: Add support for OMAP3 EVM
On Wed, Feb 25, 2009 at 03:25:59PM -0500, George G. Davis wrote: Is someone working on updating ASoC drivers for OMAP TWL4030 based boards as recommended above? Just curious since I already made the mistake of creating my own OMAP3 EVM ASoC driver w/o checking the list first. : / Not to my knowledge. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] twl4030: move twl4030-pwrbutton to drivers/input/misc
On Thu, Feb 19, 2009 at 10:30:30PM +0200, Felipe Balbi wrote: On Thu, Feb 19, 2009 at 12:08:45PM -0800, David Brownell wrote: On Thursday 19 February 2009, Felipe Balbi wrote: Take it out of drivers/i2c/chips as requested by Jean Delvare that all drivers move out of there. Cc: David Brownell dbrown...@users.sourceforge.net Cc: Samuel Ortiz sa...@openedhand.com Signed-off-by: Felipe Balbi m...@felipebalbi.com You're cc'ing Sam on these patches to the OMAP tree ... are you suggesting this code merge to mainline? Just so he knows I'm willing to add a few more changes to twl4030-core.c, If you're ok with these patches, I'll send the final version to Sam, mainline and linux-input. If so, you'll need to send the input driver to the input list as a patch against mainline, for review. The snippet from your patch 1/2 affecting the twl4030 MFD core might reasonably be merged with that, assuming Sam's OK with that going though the input tree. I could also make them separate. Send the final drivers/input/misc/twl4030-pwrbutton.c to linux-input and the twl4030-core.c to be merged via Sam. Does anyone have anything against this patch ? If not, I guess it should be applied and I'll generate the patch against mainline for input + mfd maintainers. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd behavior in musb_hdrc OTG if gadget drivers are modules
On Thu, Jan 22, 2009 at 03:46:28PM -0600, david.hag...@gmail.com wrote: I've spend the day tracking down a weird behavior on a Beagleboard with 2.6.29-rc2-omap1. If you select the mode for the musb to operate in OnTheGo mode (CONFIG_USB_MUSB_OTG), and if you compile the gadget drivers as modules, the the USB port will NOT be brought up at system boot, even if it has a USB mini-A cable plugged in (and thus should be in host mode, not gadget mode). If you then modprobe an appropriate gadget driver, then the interface will be brought up in host mode. that's expected. When you have otg selected, you can only let musb work when it's fully functional on both roles ;-) If you DON'T modprobe a gadget driver, AND you attempt to force the port to host mode by echo host /sys/devices/platform/musb_hdrc/mode Then we get a kernel page fault trying to change modes, even though we are changing to host mode, which should be valid. It seems to me that either the port should be brought up in host mode if no gadget drivers are loaded, and an attempt to switch to gadget mode should fail if no driver is loaded, OR there should be a config options to set what the default gadget driver is in the absence of one being loaded by the system. not really, imagine what would happen, for example, if when you don't have a gadget driver loaded, the other side tries HNP... -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3430SDP: Fix checkpatch.pl warnings
From bd4df7db454add3f679456a1e7f4c814f297cc71 Mon Sep 17 00:00:00 2001 From: Sergio Aguirre saagui...@ti.com Date: Wed, 25 Feb 2009 16:01:04 -0600 Subject: [PATCH 0/2] OMAP3430SDP: Fix checkpatch.pl warnings This 2 small patches fixes 3 warnings seen when running checkpatch.pl script on latest 3430sdp boardfile. Sergio Aguirre (2): OMAP3430SDP: Remove unneded extern line OMAP3430SDP: Get rid of checkpatch.pl warnings with includes arch/arm/mach-omap2/board-3430sdp.c |5 + 1 files changed, 1 insertions(+), 4 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 1/2] OMAP3430SDP: Remove unneded extern line
From 9ec9fef55a7fbfc9f813a521bed6158db1aad46f Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 25 Feb 2009 15:26:35 -0600
Subject: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
This patch removes a duplicate extern on board-3430sdp.c
file, as it is present already on
arch/arm/plat-omap/include/mach/board-3430sdp.h
Found by doing a checkpatch.pl run with board-3430sdp.c
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 758183c..ab0aa7d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -623,8 +623,6 @@ static int __init omap3430_i2c_init(void)
return 0;
}
-extern void __init sdp3430_flash_init(void);
-
static void __init omap_3430sdp_init(void)
{
omap3430_i2c_init();
--
1.5.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
[PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes
From bd4df7db454add3f679456a1e7f4c814f297cc71 Mon Sep 17 00:00:00 2001 From: Sergio Aguirre saagui...@ti.com Date: Wed, 25 Feb 2009 15:55:56 -0600 Subject: [PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index ab0aa7d..867f5f6 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -24,6 +24,7 @@ #include linux/spi/ads7846.h #include linux/i2c/twl4030.h #include linux/regulator/machine.h +#include linux/io.h #include mach/hardware.h #include asm/mach-types.h @@ -39,8 +40,6 @@ #include mach/dma.h #include mach/gpmc.h -#include asm/io.h -#include asm/delay.h #include mach/control.h #include sdram-qimonda-hyb18m512160af-6.h -- 1.5.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
Re: [patch/rfc 2.6.29-rc6 1/2] regulator: enumerate voltages
On Wednesday 25 February 2009, Mark Brown wrote:
On Tue, Feb 24, 2009 at 04:17:22PM -0800, David Brownell wrote:
Fixable in an update. I still think it's better to require less
manual configuration, not more ... manual configuration is by
definition error prone; requiring more manual configuration makes
This whole interface is structured around the idea that the consequences
of getting this wrong include things like lasting hardware damage. This
hardware damage may not be immediately obvious but may develop over time
if components are kept running out of spec, either way it's not likely
to make users happy.
And as I noted: *hardware* designers don't like to make
such goofage possible. So that's not a common scenario.
I'll update the patch to be noisier about such situations,
since you insist. And since braindamaged hardware designers
have actually been observed in the wild. ;)
It feels
fairly cumbersome to have to provide two functions to look up what I'd
expect to be static data - I'd be fairly surprised to see it change at
runtime.
It can be a function of configuration, and I didn't want to force
such seldom-used data into wasteful standardized-format tables.
Notice that with the twl4030 code, a functional interface takes
less space ... and is more flexible, since it copes with the
voltage options that are defined as not supported.
Yeah, TWL4030 is pretty special here :/ .
Those not supported cases seem to be mostly fallout from using
four bit voltage selectors, and wanting future family members to
be able to add new supported cases. A slightly more typical
model would be to have those bit values be undefined.
Part of the space savings comes of course from tables being able
to use milliVolts, not microVolts ... two bytes for each entry
instead of four. :)
Consider also the TPS6235x regulators: the voltages they support are
a simple linear function of an index 0..63, and that driver handles
seven such chips. 64 values * 4 bytes * 7 chips == about 2KB of
table data ... vs a few dozen bytes of function code.
That's actually the most common case in the regulators I'd seen
Not for me. I had seen two and three bit voltage selector fields,
defining fairly irregular sets of voltages.
I think the rationale has to do with getting better system-wide
efficiency, to stretch battery life. Circuits generating the
reference voltages can be more efficient if they don't need to
be continually adjustable over some range(s).
As far as hardware requirements go I've seen regulators which provide:
- A set of irregularly distributed values (usually fairly small).
- A range of regularly distributed values.
- A large range of values with several regular ranges in it (usually
you get higher resolution at the low end).
All of which model nicely as a mapping { selector -- voltage }.
Hardware probably even has a register bitfield holding selector
values. Maybe in that third case there's a second bitfield to
hold selector bits which specify the range.
Either way can be made to work for all of these, the concerns I have are
that the fact that it's a function based interface makes it look like
this might be dynamic data and that it's exposing a bit too much of the
implementation details (see below) which made that suggestion seem even
stronger.
That still doesn't make sense to me. It doesn't say a thing
about what it *is* ... just how to find the voltage associated
with a given index/selector.
[ALSA dB scale style]
Another virtue of functional interfaces for enumeration is
they avoid the need for callers to see and handle a variety
of different models, like that!!
I'd expect the core to deal with unrolling the data rather than the
consumers, this is why...
I don't see why the core should unroll anything at all!
The regulator driver is already doing that for get_voltage:
get_voltage() {
read selector from hardware
map selector to voltage
return that voltage
}
So it's trivial for similar code to take the selector as
a function parameter, and do the same thing. Repackage
the existing code a bit; bzzt, done!
This mostly applies to the driver interface - on the consumer side it
feels a bit cumbersome to use but I can't think of anything that's
particularly better.
There's a LONG history of functional iterator models, such as
the one I used. I think they are clearly better, and don't
understand why you'd prefer that more cumbersome approach.
...I am, as I say, reasonably OK with it on the consumer side.
The only issue I have with it on the consumer side is that the invalid
slots in the array are visible to users since it feels icky to have
error conditions be part of the normal iteration process for what should
be well known constant data.
They are fault conditions (like page fault), not errors. ;)
I worry that it's
RE: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
Sent: Wednesday, February 25, 2009 4:03 PM
To: linux-omap@vger.kernel.org
Cc: Syed Mohammed, Khasim
Subject: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
From 9ec9fef55a7fbfc9f813a521bed6158db1aad46f Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 25 Feb 2009 15:26:35 -0600
Subject: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
This patch removes a duplicate extern on board-3430sdp.c
file, as it is present already on
arch/arm/plat-omap/include/mach/board-3430sdp.h
Found by doing a checkpatch.pl run with board-3430sdp.c
Signed-off-by: Sergio Aguirre saagui...@ti.com
Acked-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-
3430sdp.c
index 758183c..ab0aa7d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -623,8 +623,6 @@ static int __init omap3430_i2c_init(void)
return 0;
}
-extern void __init sdp3430_flash_init(void);
-
static void __init omap_3430sdp_init(void)
{
omap3430_i2c_init();
--
1.5.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 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto Sent: Wednesday, February 25, 2009 4:03 PM To: linux-omap@vger.kernel.org Cc: Syed Mohammed, Khasim Subject: [PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes From bd4df7db454add3f679456a1e7f4c814f297cc71 Mon Sep 17 00:00:00 2001 From: Sergio Aguirre saagui...@ti.com Date: Wed, 25 Feb 2009 15:55:56 -0600 Subject: [PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes Signed-off-by: Sergio Aguirre saagui...@ti.com Acked-by: Dominic Curran dcur...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board- 3430sdp.c index ab0aa7d..867f5f6 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -24,6 +24,7 @@ #include linux/spi/ads7846.h #include linux/i2c/twl4030.h #include linux/regulator/machine.h +#include linux/io.h #include mach/hardware.h #include asm/mach-types.h @@ -39,8 +40,6 @@ #include mach/dma.h #include mach/gpmc.h -#include asm/io.h -#include asm/delay.h #include mach/control.h #include sdram-qimonda-hyb18m512160af-6.h -- 1.5.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/rfc 2.6.29-rc6 1/2] regulator: enumerate voltages
On Wed, Feb 25, 2009 at 02:12:26PM -0800, David Brownell wrote:
On Wednesday 25 February 2009, Mark Brown wrote:
This whole interface is structured around the idea that the consequences
of getting this wrong include things like lasting hardware damage. This
hardware damage may not be immediately obvious but may develop over time
if components are kept running out of spec, either way it's not likely
to make users happy.
And as I noted: *hardware* designers don't like to make
such goofage possible. So that's not a common scenario.
That's often not possible with software controllable regulators - it's
usually hard to stop them being set to any value they support and the
desire for any additional protection needs to be traded off against
power consumption and space and BoM costs.
Not for me. I had seen two and three bit voltage selector fields,
defining fairly irregular sets of voltages.
I think the rationale has to do with getting better system-wide
efficiency, to stretch battery life. Circuits generating the
reference voltages can be more efficient if they don't need to
be continually adjustable over some range(s).
It's certainly not the common case for regulators that people are
contributing to the kernel (most of which seem to be intended to be
primary PMICs). Make of that what you will :)
As far as hardware requirements go I've seen regulators which provide:
- A set of irregularly distributed values (usually fairly small).
- A range of regularly distributed values.
- A large range of values with several regular ranges in it (usually
you get higher resolution at the low end).
All of which model nicely as a mapping { selector -- voltage }.
Hardware probably even has a register bitfield holding selector
values. Maybe in that third case there's a second bitfield to
hold selector bits which specify the range.
Yes, you can clearly always do selector-voltage since there's going to
be a finite number of register bits that it'll be possible to set.
Either way can be made to work for all of these, the concerns I have are
that the fact that it's a function based interface makes it look like
this might be dynamic data and that it's exposing a bit too much of the
implementation details (see below) which made that suggestion seem even
stronger.
That still doesn't make sense to me. It doesn't say a thing
about what it *is* ... just how to find the voltage associated
with a given index/selector.
A function that return errors suggests something non-static to me.
I'd expect the core to deal with unrolling the data rather than the
consumers, this is why...
I don't see why the core should unroll anything at all!
The regulator driver is already doing that for get_voltage:
get_voltage() {
read selector from hardware
map selector to voltage
return that voltage
}
So it's trivial for similar code to take the selector as
a function parameter, and do the same thing. Repackage
the existing code a bit; bzzt, done!
Yes, that's a reasonable point (though I'd still like to see the maximum
turn into a static value now I think about it).
I worry that it's going to catch people
out since relatively few regulator drivers do that (the fact that it's
there is an implementation detail for drivers which have holes in the
range of register values they can set).
It will be fairly common for the regulator to support voltages
that are disallowed by the machine constraints, though. That
can produce holes too; and not necessarily only for the lowest
or highest selector codes.
At present only continous ranges are possible, though. I can't think of
any systems I've seen that'd want discontinous constraints, though I'm
sure there are some.
Thinking about it that could be hidden by mapping the invalid values to
zero or some value that is actually valid instead of returning an error
- not entirely nice but it keeps the pain away from the consumers.
The test for an invalid voltage is v = 0 regardless.
If you're looking for a bound you'd just check for things within that
bound anyway. It's if there's explicit this is an error return that
people start wanting to do something with it rather than silently ignore
it (we hope, anyway).
You can either write the loop the way you have by iterating over the
voltages offered or you can write it by asking for voltage ranges that
the device might want.
The MMC stack is written to work the way I described.
...
True, *other* stacks might want something else:
Indeed, I'm not talking about MMC in particular here - other things are
going to want to ask the same questions.
It seems like it'd be useful for driver authors
if the core allowed either method so they can use whichever idiom fits
more comfortably with their needs.
A patch could be added later, when some system needs
some other model. I'm not exactly sure what would
Re: [patch/rfc 2.6.29-rc6 1/2] regulator: enumerate voltages
On Wednesday 25 February 2009, Mark Brown wrote:
get_voltage() {
read selector from hardware
map selector to voltage
return that voltage
}
So it's trivial for similar code to take the selector as
a function parameter, and do the same thing. Repackage
the existing code a bit; bzzt, done!
Yes, that's a reasonable point (though I'd still like to see the maximum
turn into a static value now I think about it).
At the regulator_desc level, that's trivial; I'll do that
in the patch you'll see.
In terms of the consumer interface, not -- struct regulator
is opaque to consumers, and everything is a functional accessor.
So I'll leave that as-is.
It will be fairly common for the regulator to support voltages
that are disallowed by the machine constraints, though. That
can produce holes too; and not necessarily only for the lowest
or highest selector codes.
At present only continous ranges are possible, though. I can't think of
any systems I've seen that'd want discontinous constraints, though I'm
sure there are some.
Consider a regulator where voltage selectors 0..3 correspond to
voltages
{ 3.3V, 1.8V, 4.2V, 5.0V }
With machine constraints that say voltages go from 3V to 4.5V ...
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] twl: usb: Add the resume() and suspend() methods to twl4030-usb.c (re)
The MPU module can be waked up by the unexpected USB
interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
peripheral mode and connected to a host PC, it can never enter the low
power mode due to interrupts from the host PC. This patch added the
feature that a board specific file can determines that TWL4030
supplies the USB power or not in the low power mode. Disabling the USB
power may save the power consumption.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 25 +
include/linux/i2c/twl4030.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 416e441..b725be2 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -256,6 +256,7 @@ struct twl4030_usb {
u8 linkstat;
u8 asleep;
boolirq_enabled;
+ boolsuspend_enabled;
};
/* internal define on top of container_of */
@@ -618,6 +619,7 @@ static int __init twl4030_usb_probe(struct platform_device
*pdev)
twl-otg.set_suspend= twl4030_set_suspend;
twl-usb_mode = pdata-usb_mode;
twl-asleep = 1;
+ twl-suspend_enabled= pdata-suspend_enabled;
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -694,9 +696,32 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+int twl4030_usb_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ if (!twl-suspend_enabled)
+ return 0;
+
+ otg_set_suspend(twl-otg, 1);
+
+ return 0;
+}
+
+int twl4030_usb_resume(struct platform_device *pdev)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ otg_set_suspend(twl-otg, 0);
+
+ return 0;
+}
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index c89d33b..0b12509 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -325,6 +325,7 @@ enum twl4030_usb_mode {
struct twl4030_usb_data {
enum twl4030_usb_mode usb_mode;
+ bool suspend_enabled;
};
struct twl4030_ins {
--
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][OMAPZOOM] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull function
Hi,
This patch removes unncessary checks in HW_MBOX_IsFull this patch is
base on the previous patch that Felipe Contreras sent.
Regards,
Fernando.
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 25 Feb 2009 17:48:01 -0600
Subject: [PATCH] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull function
This patch removes some unnecessary checks in HW_MBOX_IsFull
function
Signed-off-by: Guzman Lugo Fernando x0095...@ti.com
---
drivers/dsp/bridge/hw/hw_mbox.c| 22 ++
drivers/dsp/bridge/hw/hw_mbox.h|6 ++
drivers/dsp/bridge/wmd/tiomap_sm.c |6 +++---
3 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c b/drivers/dsp/bridge/hw/hw_mbox.c
index bc61d64..0f9e5a7
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -105,28 +105,10 @@ HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress, const
HW_MBOX_Id_t mailBoxId,
}
/* Reads the full status register for mailbox. */
-HW_STATUS HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId,
- u32 *const pIsFull)
+bool HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId)
{
- HW_STATUS status = RET_OK;
- u32 fullStatus;
-
- /* Check input parameters */
- CHECK_INPUT_PARAM(baseAddress, 0, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_PARAM(pIsFull, NULL, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_RANGE_MIN0(mailBoxId, HW_MBOX_ID_MAX, RET_INVALID_ID,
- RES_MBOX_BASE + RES_INVALID_INPUT_PARAM);
-
- /* read the is full status parameter for Mailbox */
- fullStatus = MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
+ return MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
(u32)mailBoxId);
-
- /* fill in return parameter */
- *pIsFull = (fullStatus 0xFF);
-
- return status;
}
/* Gets number of messages in a specified mailbox. */
diff --git a/drivers/dsp/bridge/hw/hw_mbox.h b/drivers/dsp/bridge/hw/hw_mbox.h
index 225fb40..e70305d
--- a/drivers/dsp/bridge/hw/hw_mbox.h
+++ b/drivers/dsp/bridge/hw/hw_mbox.h
@@ -158,11 +158,9 @@ extern HW_STATUS HW_MBOX_MsgWrite(
*
* PURPOSE: : this function reads the full status register for mailbox.
*/
-extern HW_STATUS HW_MBOX_IsFull(
+extern bool HW_MBOX_IsFull(
const u32 baseAddress,
- const HW_MBOX_Id_t mailBoxId,
- u32 *constpIsFull
- );
+ const HW_MBOX_Id_t mailBoxId);
/*
* FUNCTION : HW_MBOX_NumMsgGet
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index edc3bcf..7acb4f8
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -178,7 +178,7 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
#endif
#endif
HW_STATUS hwStatus;
- u32 mbxFull;
+ bool mbxFull;
struct CFG_HOSTRES resources;
u16 cnt = 10;
u32 temp;
@@ -242,8 +242,8 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
pDevContext-dwBrdState = BRD_RUNNING;
}
while (--cnt) {
- hwStatus = HW_MBOX_IsFull(resources.dwMboxBase,
- MBOX_ARM2DSP, mbxFull);
+ mbxFull = HW_MBOX_IsFull(resources.dwMboxBase,
+ MBOX_ARM2DSP);
if (mbxFull)
UTIL_Wait(1000);/* wait for 1 ms) */
else
--
1.5.6.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][OMAPZOOM] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull function
Fernando,
I think you are missing the CHNLSM_InterruptDSP() function changes from Felipe
patch; ie. To wait less.
Thank you,
Best regards,
Hari
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando
Sent: Wednesday, February 25, 2009 5:58 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH][OMAPZOOM] DSPBRIDGE: Remove unnecessary checks in
HW_MBOX_IsFull function
Hi,
This patch removes unncessary checks in HW_MBOX_IsFull this patch is
base on the previous patch that Felipe Contreras sent.
Regards,
Fernando.
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 25 Feb 2009 17:48:01 -0600
Subject: [PATCH] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull
function
This patch removes some unnecessary checks in HW_MBOX_IsFull
function
Signed-off-by: Guzman Lugo Fernando x0095...@ti.com
---
drivers/dsp/bridge/hw/hw_mbox.c| 22 ++
drivers/dsp/bridge/hw/hw_mbox.h|6 ++
drivers/dsp/bridge/wmd/tiomap_sm.c |6 +++---
3 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c
b/drivers/dsp/bridge/hw/hw_mbox.c
index bc61d64..0f9e5a7
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -105,28 +105,10 @@ HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress,
const HW_MBOX_Id_t mailBoxId,
}
/* Reads the full status register for mailbox. */
-HW_STATUS HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t
mailBoxId,
- u32 *const pIsFull)
+bool HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId)
{
- HW_STATUS status = RET_OK;
- u32 fullStatus;
-
- /* Check input parameters */
- CHECK_INPUT_PARAM(baseAddress, 0, RET_BAD_NULL_PARAM, RES_MBOX_BASE
+
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_PARAM(pIsFull, NULL, RET_BAD_NULL_PARAM, RES_MBOX_BASE
+
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_RANGE_MIN0(mailBoxId, HW_MBOX_ID_MAX, RET_INVALID_ID,
- RES_MBOX_BASE + RES_INVALID_INPUT_PARAM);
-
- /* read the is full status parameter for Mailbox */
- fullStatus =
MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
+ return MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
(u32)mailBoxId);
-
- /* fill in return parameter */
- *pIsFull = (fullStatus 0xFF);
-
- return status;
}
/* Gets number of messages in a specified mailbox. */
diff --git a/drivers/dsp/bridge/hw/hw_mbox.h
b/drivers/dsp/bridge/hw/hw_mbox.h
index 225fb40..e70305d
--- a/drivers/dsp/bridge/hw/hw_mbox.h
+++ b/drivers/dsp/bridge/hw/hw_mbox.h
@@ -158,11 +158,9 @@ extern HW_STATUS HW_MBOX_MsgWrite(
*
* PURPOSE: : this function reads the full status register for
mailbox.
*/
-extern HW_STATUS HW_MBOX_IsFull(
+extern bool HW_MBOX_IsFull(
const u32 baseAddress,
- const HW_MBOX_Id_t mailBoxId,
- u32 *constpIsFull
- );
+ const HW_MBOX_Id_t mailBoxId);
/*
* FUNCTION : HW_MBOX_NumMsgGet
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index edc3bcf..7acb4f8
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -178,7 +178,7 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
#endif
#endif
HW_STATUS hwStatus;
- u32 mbxFull;
+ bool mbxFull;
struct CFG_HOSTRES resources;
u16 cnt = 10;
u32 temp;
@@ -242,8 +242,8 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
pDevContext-dwBrdState = BRD_RUNNING;
}
while (--cnt) {
- hwStatus = HW_MBOX_IsFull(resources.dwMboxBase,
-MBOX_ARM2DSP, mbxFull);
+ mbxFull = HW_MBOX_IsFull(resources.dwMboxBase,
+MBOX_ARM2DSP);
if (mbxFull)
UTIL_Wait(1000);/* wait for 1 ms) */
else
--
1.5.6.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/2] twl: usb: Add the resume() and suspend() methods to twl4030-usb.c (re)
On Thu, Feb 26, 2009 at 08:54:38AM +0900, Minkyu Kang wrote:
The MPU module can be waked up by the unexpected USB
interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
peripheral mode and connected to a host PC, it can never enter the low
power mode due to interrupts from the host PC. This patch added the
feature that a board specific file can determines that TWL4030
supplies the USB power or not in the low power mode. Disabling the USB
power may save the power consumption.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 25 +
include/linux/i2c/twl4030.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 416e441..b725be2 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -256,6 +256,7 @@ struct twl4030_usb {
u8 linkstat;
u8 asleep;
boolirq_enabled;
+ boolsuspend_enabled;
before we ack it and let it go through, could you please explain a bit
more the necessity of this ?
I mean, what you're doing here is that you would allow twl4030 to enter
low power mode even though we're connected to host side, meaning we
would never get awaken by the host side, right ?
Is that really wanted ? I mean, how would you then wake the device ?
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: musb: fix the possible panic while resuming
On Wed, Feb 25, 2009 at 08:53:00PM +0900, Kim Kyuwon wrote:
From: Kim Kyuwon chamm...@gmail.com
While waking up, musb can cause a kernel panic. This patch is fixing
it by enabling the clock in the resume_early method.
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/musb/musb_core.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..ae76ad7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2141,16 +2141,13 @@ static int __devexit musb_remove(struct
platform_device *pdev)
#ifdef CONFIG_PM
-static int musb_suspend(struct platform_device *pdev, pm_message_t message)
+static int musb_suspend_late(struct platform_device *pdev, pm_message_t
state)
{
- unsigned long flags;
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct musb *musb = dev_to_musb(pdev-dev);
this hunk is unecessary, please revert. I'll also take a closer look
tomorrow, it's already really late and need some nap (as suggested by
greg, hehe :-p)
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][OMAPZOOM] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull function
On Thu, Feb 26, 2009 at 1:58 AM, Guzman Lugo, Fernando x0095...@ti.com wrote:
Hi,
This patch removes unncessary checks in HW_MBOX_IsFull this patch is
base on the previous patch that Felipe Contreras sent.
Regards,
Fernando.
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 25 Feb 2009 17:48:01 -0600
Subject: [PATCH] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull
function
This patch removes some unnecessary checks in HW_MBOX_IsFull
function
Signed-off-by: Guzman Lugo Fernando x0095...@ti.com
---
drivers/dsp/bridge/hw/hw_mbox.c | 22 ++
drivers/dsp/bridge/hw/hw_mbox.h | 6 ++
drivers/dsp/bridge/wmd/tiomap_sm.c | 6 +++---
3 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c b/drivers/dsp/bridge/hw/hw_mbox.c
index bc61d64..0f9e5a7
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -105,28 +105,10 @@ HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress, const
HW_MBOX_Id_t mailBoxId,
}
/* Reads the full status register for mailbox. */
-HW_STATUS HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId,
- u32 *const pIsFull)
+bool HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId)
Why not 'static inline'?
{
- HW_STATUS status = RET_OK;
- u32 fullStatus;
-
- /* Check input parameters */
- CHECK_INPUT_PARAM(baseAddress, 0, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_PARAM(pIsFull, NULL, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_RANGE_MIN0(mailBoxId, HW_MBOX_ID_MAX, RET_INVALID_ID,
- RES_MBOX_BASE + RES_INVALID_INPUT_PARAM);
-
- /* read the is full status parameter for Mailbox */
- fullStatus =
MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
+ return MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
(u32)mailBoxId);
This would return an int, not a bool, right? The int would have only 0
and 1 and values, so that might be ok, I'm not sure.
-
- /* fill in return parameter */
- *pIsFull = (fullStatus 0xFF);
-
- return status;
}
/* Gets number of messages in a specified mailbox. */
diff --git a/drivers/dsp/bridge/hw/hw_mbox.h b/drivers/dsp/bridge/hw/hw_mbox.h
index 225fb40..e70305d
--- a/drivers/dsp/bridge/hw/hw_mbox.h
+++ b/drivers/dsp/bridge/hw/hw_mbox.h
@@ -158,11 +158,9 @@ extern HW_STATUS HW_MBOX_MsgWrite(
*
* PURPOSE: : this function reads the full status register for mailbox.
*/
-extern HW_STATUS HW_MBOX_IsFull(
+extern bool HW_MBOX_IsFull(
const u32 baseAddress,
- const HW_MBOX_Id_t mailBoxId,
- u32 *const pIsFull
- );
+ const HW_MBOX_Id_t mailBoxId);
/*
* FUNCTION : HW_MBOX_NumMsgGet
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index edc3bcf..7acb4f8
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -178,7 +178,7 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
#endif
#endif
HW_STATUS hwStatus;
- u32 mbxFull;
+ bool mbxFull;
struct CFG_HOSTRES resources;
u16 cnt = 10;
u32 temp;
@@ -242,8 +242,8 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
pDevContext-dwBrdState = BRD_RUNNING;
}
while (--cnt) {
- hwStatus = HW_MBOX_IsFull(resources.dwMboxBase,
- MBOX_ARM2DSP, mbxFull);
+ mbxFull = HW_MBOX_IsFull(resources.dwMboxBase,
+ MBOX_ARM2DSP);
if (mbxFull)
UTIL_Wait(1000); /* wait for 1 ms) */
else
--
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch/rfc 2.6.29-rc6 1/2] regulator: enumerate voltages
On Wednesday 25 February 2009, Mark Brown wrote: Fixable in an update. I still think it's better to require less manual configuration, not more ... manual configuration is by definition error prone; requiring more manual configuration makes This whole interface is structured around the idea that the consequences of getting this wrong include things like lasting hardware damage. Oh, one more comment. Requiring manual configuration of fixed-voltage regulators is pure time-wastage. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] twl: usb: Add the resume() and suspend() methods to twl4030-usb.c (re)
I mean, what you're doing here is that you would allow twl4030 to enter
low power mode even though we're connected to host side, meaning we
would never get awaken by the host side, right ?
Yes, right.
If usb is connected to host side, our system never sleep because of usb
interrupts by host.
We don't want this.
We want to enter sleep mode quietly without any disturbance even if usb is
connected to host side.(And we need to reduce power consumption)
This patch gives option for these reasons.
If you don't want this option, please set suspend_enabled = false in the
board specific configuration.
Is that really wanted ? I mean, how would you then wake the device ?
Our system is waked when get wake-up interrupts such as IO pad wake-up
events and other wake-up events from peripheral devices.
When it wakes up devices, usb device will be waked too.
---
Minkyu Kang.
-Original Message-
From: Felipe Balbi [mailto:m...@felipebalbi.com]
Sent: Thursday, February 26, 2009 9:12 AM
To: Minkyu Kang
Cc: Kim Kyuwon; m...@felipebalbi.com; linux-...@vger.kernel.org; OMAP; David
Brownell; q1@samsung.com
Subject: Re: [PATCH 2/2] twl: usb: Add the resume() and suspend() methods to
twl4030-usb.c (re)
On Thu, Feb 26, 2009 at 08:54:38AM +0900, Minkyu Kang wrote:
The MPU module can be waked up by the unexpected USB
interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
peripheral mode and connected to a host PC, it can never enter the low
power mode due to interrupts from the host PC. This patch added the
feature that a board specific file can determines that TWL4030
supplies the USB power or not in the low power mode. Disabling the USB
power may save the power consumption.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 25 +
include/linux/i2c/twl4030.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 416e441..b725be2 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -256,6 +256,7 @@ struct twl4030_usb {
u8 linkstat;
u8 asleep;
boolirq_enabled;
+ boolsuspend_enabled;
before we ack it and let it go through, could you please explain a bit
more the necessity of this ?
I mean, what you're doing here is that you would allow twl4030 to enter
low power mode even though we're connected to host side, meaning we
would never get awaken by the host side, right ?
Is that really wanted ? I mean, how would you then wake the device ?
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[UPDATE][PATCH][OMAPZOOM] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull function
Hi,
I have updated the patch base on Felipe's patches.
From db89674b7316d7490e71c131091758eb7ef0eca2 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 25 Feb 2009 19:27:41 -0600
Subject: [PATCH] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull function
This patch removes some unnecesarry checks in HW_MBOX_IsFull
function
Signed-off-by: Guzman Lugo Fernando x0095...@ti.com
---
drivers/dsp/bridge/hw/hw_mbox.c| 22 ++
drivers/dsp/bridge/hw/hw_mbox.h|6 ++
drivers/dsp/bridge/wmd/tiomap_sm.c | 14 --
3 files changed, 8 insertions(+), 34 deletions(-)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c b/drivers/dsp/bridge/hw/hw_mbox.c
index bc61d64..3a539f5
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -105,28 +105,10 @@ HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress, const
HW_MBOX_Id_t mailBoxId,
}
/* Reads the full status register for mailbox. */
-HW_STATUS HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId,
- u32 *const pIsFull)
+inline bool HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId)
{
- HW_STATUS status = RET_OK;
- u32 fullStatus;
-
- /* Check input parameters */
- CHECK_INPUT_PARAM(baseAddress, 0, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_PARAM(pIsFull, NULL, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_RANGE_MIN0(mailBoxId, HW_MBOX_ID_MAX, RET_INVALID_ID,
- RES_MBOX_BASE + RES_INVALID_INPUT_PARAM);
-
- /* read the is full status parameter for Mailbox */
- fullStatus = MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
+ return MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
(u32)mailBoxId);
-
- /* fill in return parameter */
- *pIsFull = (fullStatus 0xFF);
-
- return status;
}
/* Gets number of messages in a specified mailbox. */
diff --git a/drivers/dsp/bridge/hw/hw_mbox.h b/drivers/dsp/bridge/hw/hw_mbox.h
index 225fb40..50a3746
--- a/drivers/dsp/bridge/hw/hw_mbox.h
+++ b/drivers/dsp/bridge/hw/hw_mbox.h
@@ -158,11 +158,9 @@ extern HW_STATUS HW_MBOX_MsgWrite(
*
* PURPOSE: : this function reads the full status register for mailbox.
*/
-extern HW_STATUS HW_MBOX_IsFull(
+extern inline bool HW_MBOX_IsFull(
const u32 baseAddress,
- const HW_MBOX_Id_t mailBoxId,
- u32 *constpIsFull
- );
+ const HW_MBOX_Id_t mailBoxId);
/*
* FUNCTION : HW_MBOX_NumMsgGet
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index edc3bcf..2843788
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -178,9 +178,8 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
#endif
#endif
HW_STATUS hwStatus;
- u32 mbxFull;
struct CFG_HOSTRES resources;
- u16 cnt = 10;
+ u16 cnt = 1000;
u32 temp;
/* We are waiting indefinitely here. This needs to be fixed in the
* second phase */
@@ -241,14 +240,9 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
pDevContext-dwBrdState = BRD_RUNNING;
}
- while (--cnt) {
- hwStatus = HW_MBOX_IsFull(resources.dwMboxBase,
- MBOX_ARM2DSP, mbxFull);
- if (mbxFull)
- UTIL_Wait(1000);/* wait for 1 ms) */
- else
- break;
- }
+ while (--cnt HW_MBOX_IsFull(resources.dwMboxBase, MBOX_ARM2DSP))
+ udelay(1);
+
if (!cnt) {
DBG_Trace(DBG_LEVEL7, Timed out waiting for DSP mailbox \n);
status = WMD_E_TIMEOUT;
--
1.5.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: musb: fix the possible panic while resuming
On Thu, Feb 26, 2009 at 9:13 AM, Felipe Balbi m...@felipebalbi.com wrote:
On Wed, Feb 25, 2009 at 08:53:00PM +0900, Kim Kyuwon wrote:
From: Kim Kyuwon chamm...@gmail.com
While waking up, musb can cause a kernel panic. This patch is fixing
it by enabling the clock in the resume_early method.
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/musb/musb_core.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..ae76ad7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2141,16 +2141,13 @@ static int __devexit musb_remove(struct
platform_device *pdev)
#ifdef CONFIG_PM
-static int musb_suspend(struct platform_device *pdev, pm_message_t message)
+static int musb_suspend_late(struct platform_device *pdev, pm_message_t
state)
{
- unsigned long flags;
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct musb *musb = dev_to_musb(pdev-dev);
this hunk is unecessary, please revert. I'll also take a closer look
tomorrow, it's already really late and need some nap (as suggested by
greg, hehe :-p)
OK, but before I resend the patch, I have something to check again.
Now I know that, in addition to HSUSB_MC_NINT disabled by the previous
patch [ARM: OMAP: Disable USB interrupt in the musb_resume()
function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up
source events to PRMC module. Sorry I didn't know that time. The
remote wake uses these two SWAKEUP. David, is my previous patch is
still NAK?
--
balbi
--
Q1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] usb: musb: fix the possible panic while resuming
snip Now I know that, in addition to HSUSB_MC_NINT disabled by the previous patch [ARM: OMAP: Disable USB interrupt in the musb_resume() function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up source events to PRMC module. Sorry I didn't know that time. The remote wake uses these two SWAKEUP. David, is my previous patch is still NAK? USBTLL_SWAKEUP and USBHOST_SWAKEUP are not for MUSB. - Anand-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: musb: fix the possible panic while resuming
Hi, On Thu, Feb 26, 2009 at 3:37 PM, Gadiyar, Anand gadi...@ti.com wrote: snip Now I know that, in addition to HSUSB_MC_NINT disabled by the previous patch [ARM: OMAP: Disable USB interrupt in the musb_resume() function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up source events to PRMC module. Sorry I didn't know that time. The remote wake uses these two SWAKEUP. David, is my previous patch is still NAK? USBTLL_SWAKEUP and USBHOST_SWAKEUP are not for MUSB. But they are used to wake up request. Can I ask what they are for? - Anand -- Q1 -- 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: [alsa-devel] [PATCH] ASoC: Add support for OMAP3 EVM
On Wed, 25 Feb 2009 21:27:44 +0100 ext Mark Brown broo...@sirena.org.uk wrote: On Wed, Feb 25, 2009 at 03:25:59PM -0500, George G. Davis wrote: Is someone working on updating ASoC drivers for OMAP TWL4030 based boards as recommended above? Just curious since I already made the mistake of creating my own OMAP3 EVM ASoC driver w/o checking the list first. : / Not to my knowledge. Stanley Miao started to do some early development on this: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012946.html http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012995.html IRCC this work was let to aside to develop since there were some slight differencies between the boards and also TWL4030 didn't contain all the features. Stanley, do you remember better? Probably now there is a better change after tons of generic TWL4030 patches and TWL4030 codec updates from Peter Ujfalusi. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] usb: musb: fix the possible panic while resuming
-Original Message- From: Kim Kyuwon [mailto:chamm...@gmail.com] Sent: Thursday, February 26, 2009 12:28 PM To: Gadiyar, Anand Cc: m...@felipebalbi.com; linux-...@vger.kernel.org; OMAP; David Brownell; q1@samsung.com; Minkyu Kang Subject: Re: [PATCH 1/2] usb: musb: fix the possible panic while resuming Hi, On Thu, Feb 26, 2009 at 3:37 PM, Gadiyar, Anand gadi...@ti.com wrote: snip Now I know that, in addition to HSUSB_MC_NINT disabled by the previous patch [ARM: OMAP: Disable USB interrupt in the musb_resume() function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up source events to PRMC module. Sorry I didn't know that time. The remote wake uses these two SWAKEUP. David, is my previous patch is still NAK? USBTLL_SWAKEUP and USBHOST_SWAKEUP are not for MUSB. But they are used to wake up request. Can I ask what they are for? I'm not the PRCM expert, but USBHOST refers to EHCI/OHCI and USBTLL is needed for EHCI (except in PHY mode) and for OHCI (all modes). These wakeup sources are meant for wakeups initiated by these modules. MUSB is a different module altogether. -- 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: [alsa-devel] [PATCH] ASoC: Add support for OMAP3 EVM
On Wednesday 25 February 2009 22:25:59 ext George G. Davis wrote: Hi, On Tue, Nov 25, 2008 at 02:52:58PM +, Mark Brown wrote: On Tue, Nov 25, 2008 at 01:21:20PM +0200, Jarkko Nikula wrote: Or if those EVM's SDP's can route TWL4030 audio connections more flexible than Beagle but somewhat similar manner, then probably have one single machine driver for all EVM's? Otherwise it doesn't make very much sense to have n similar machine drivers where only functions and variable names differ. Yes, it looks like a lot of these drivers could be redone along the lines of s3c24xx_uda134x.c with platform data specifying the differences between the boards. Is someone working on updating ASoC drivers for OMAP TWL4030 based boards as recommended above? Just curious since I already made the mistake of creating my own OMAP3 EVM ASoC driver w/o checking the list first. : / Well, I have checked the s3c24xx_uda134x.c and the corresponding uda134x.c codec driver. In case of the uda134x codec - since it does not have DAPM implementation, the board file does not need to deal with the output/input pins. In case of boards using the TWL4030 codec it is not that simple IMHO. You see TWL4030 has nine output 'pins' and six (plus 2x stereo digital mic) input 'pins'. So, yes it is doable, but will it make things cleaner and more manageable? Few things came to my mind, which needs to be addressed: 1. Who is the master (OMAP McBSP or TWL4030)? 2. What is the reference clock in the given board 3. Connected pins (or not connected pins) 4. I2S or TDM mode (this is not implemented yet, but it is coming at some point) It easy to provide 1, 2 and 4. But when it comes to 3... One needs to build up the DAPM routes in the common board file for the supported boards, which again doable based on - for example - some model/board ID, but I think it will look ugly. Or I might over complicate things ;) -- Regards, George -- Péter -- 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/3] GPIO for jack reporting interface
The following patch set implements GPIO support for SoC jack reporting interface and uses it in SDP3430 machine driver. The jack detection interface is used in SDP3430 driver to handle headset events. That requires DAPM machine widgets to be added to the machine driver before the actual use of the interface. ASoC: Add GPIO support for jack reporting interface ASoC: Add DAPM machine widgets to SDP3430 driver ASoC: Add headset jack detection for SDP3430 machine driver-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ASoC: Add GPIO support for jack reporting interface
Add GPIO support for jack reporting framework in ASoC, by using
gpiolib calls. It's only required to append GPIO information (gpio
number, irq handler and flags) to standard jack_pin declaration.
GPIO request, data direction configuration and irq request are
handled by the utility.
The minimal GPIO information that can be provided is the gpio number,
in that case default handler/flags will be used. Default handler queues
a work that reads the current value in the gpio pin and informs to the
jack framework.
If the GPIO support is not required, the gpio field ot jack_pin
structure must be set to NO_JACK_PIN_GPIO.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
include/sound/soc.h | 15 ++
sound/soc/soc-jack.c | 70 -
2 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 68d8149..846e2c1 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/types.h
#include linux/workqueue.h
+#include linux/interrupt.h
+#include linux/kernel.h
#include sound/core.h
#include sound/pcm.h
#include sound/control.h
@@ -254,14 +256,27 @@ int snd_soc_put_volsw_s8(struct snd_kcontrol *kcontrol,
* @pin:name of the pin to update
* @mask: bits to check for in reported jack status
* @invert: if non-zero then pin is enabled when status is not reported
+ * @gpio: gpio number associated to the pin (gpiolib calls will be used)
+ * @irqflags IRQ flags
+ * @handler: handler for servicing interrupt events on gpio pin
*/
struct snd_soc_jack_pin {
+ struct snd_soc_jack *jack;
+ struct snd_soc_jack_gpio *gpio_pin;
struct list_head list;
const char *pin;
int mask;
bool invert;
+ /* GPIO */
+ unsigned int gpio;
+ unsigned int irq;
+ unsigned long irqflags;
+ irq_handler_t handler;
+ struct work_struct work;
};
+#define NO_JACK_PIN_GPIO UINT_MAX
+
struct snd_soc_jack {
struct snd_jack *jack;
struct snd_soc_card *card;
diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c
index 8cc00c3..0d048b2 100644
--- a/sound/soc/soc-jack.c
+++ b/sound/soc/soc-jack.c
@@ -14,6 +14,9 @@
#include sound/jack.h
#include sound/soc.h
#include sound/soc-dapm.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/workqueue.h
/**
* snd_soc_jack_new - Create a new jack
@@ -96,6 +99,32 @@ out:
}
EXPORT_SYMBOL_GPL(snd_soc_jack_report);
+/* Default IRQ handler for a GPIO jack pin, it will queue a
+ * work that reads current value in GPIO pin and reports it
+ * to the jack framework.
+ */
+static irqreturn_t gpio_interrupt(int irq, void *data)
+{
+ struct snd_soc_jack_pin *pin = data;
+
+ return IRQ_RETVAL(schedule_work(pin-work));
+}
+
+static void gpio_work(struct work_struct *work)
+{
+ struct snd_soc_jack_pin *pin;
+ int report;
+
+ pin = container_of(work, struct snd_soc_jack_pin, work);
+ report = pin-jack-status pin-mask;
+ if (gpio_get_value(pin-gpio))
+ report |= pin-mask;
+ else
+ report = ~pin-mask;
+
+ snd_soc_jack_report(pin-jack, report, pin-jack-jack-type);
+}
+
/**
* snd_soc_jack_add_pins - Associate DAPM pins with an ASoC jack
*
@@ -106,11 +135,18 @@ EXPORT_SYMBOL_GPL(snd_soc_jack_report);
* After this function has been called the DAPM pins specified in the
* pins array will have their status updated to reflect the current
* state of the jack whenever the jack status is updated.
+ *
+ * A GPIO pin (using gpiolib) can be used to detect events. It requieres
+ * an IRQ handler and flags to be set in jack_pin structure; if they are
+ * not provided, default handler/flags will be used instead. If this
+ * feature is not desired, gpio field of jack_pin structure must be
+ * set to NO_JACK_PIN_GPIO.
*/
int snd_soc_jack_add_pins(struct snd_soc_jack *jack, int count,
struct snd_soc_jack_pin *pins)
{
- int i;
+ unsigned int gpio = 0;
+ int i, ret = 0;
for (i = 0; i count; i++) {
if (!pins[i].pin) {
@@ -123,6 +159,32 @@ int snd_soc_jack_add_pins(struct snd_soc_jack *jack, int
count,
return -EINVAL;
}
+ if (pins[i].gpio != NO_JACK_PIN_GPIO) {
+ pins[i].jack = jack;
+ gpio = pins[i].gpio;
+ ret = gpio_request(gpio, pins[i].pin);
+ if (ret)
+ return ret;
+
+ ret = gpio_direction_input(gpio);
+ if (ret)
+ goto out;
+ pins[i].irq = gpio_to_irq(gpio);
+ /* If none set, use the default handler */
+ if (!pins[i].handler) {
+
[PATCH 2/3] ASoC: Add DAPM machine widgets to SDP3430 driver
Add DAPM machine domain widgets to SDP3430 machine driver.
Current interconection:
* Ext Mic: MAINMIC, SUBMIC
* Ext Spk: HFL, HFR
* Headset Jack: HSMIC, HSOL, HSOR
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/omap/sdp3430.c | 61 ++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
index e226fa7..7a996d9 100644
--- a/sound/soc/omap/sdp3430.c
+++ b/sound/soc/omap/sdp3430.c
@@ -81,12 +81,73 @@ static struct snd_soc_ops sdp3430_ops = {
.hw_params = sdp3430_hw_params,
};
+/* SDP3430 machine DAPM */
+static const struct snd_soc_dapm_widget sdp3430_twl4030_dapm_widgets[] = {
+ SND_SOC_DAPM_MIC(Ext Mic, NULL),
+ SND_SOC_DAPM_SPK(Ext Spk, NULL),
+ SND_SOC_DAPM_HP(Headset Jack, NULL),
+};
+
+static const struct snd_soc_dapm_route audio_map[] = {
+ /* External Mics: MAINMIC, SUBMIC */
+ {MAINMIC, NULL, Ext Mic},
+ {SUBMIC, NULL, Ext Mic},
+
+ /* External Speakers: HFL, HFR */
+ {Ext Spk, NULL, HFL},
+ {Ext Spk, NULL, HFR},
+
+ /* Headset: HSMIC, HSOL, HSOR */
+ {Headset Jack, NULL, HSOL},
+ {Headset Jack, NULL, HSOR},
+ {HSMIC, NULL, Headset Jack},
+};
+
+static int sdp3430_twl4030_init(struct snd_soc_codec *codec)
+{
+ int ret;
+
+ /* SDP3430 connected pins */
+ snd_soc_dapm_enable_pin(codec, Ext Mic);
+ snd_soc_dapm_enable_pin(codec, Ext Spk);
+ snd_soc_dapm_enable_pin(codec, Headset Jack);
+
+ /* TWL4030 not connected pins */
+ snd_soc_dapm_nc_pin(codec, AUXL);
+ snd_soc_dapm_nc_pin(codec, AUXR);
+ snd_soc_dapm_nc_pin(codec, CARKITMIC);
+ snd_soc_dapm_nc_pin(codec, DIGIMIC0);
+ snd_soc_dapm_nc_pin(codec, DIGIMIC1);
+
+ snd_soc_dapm_nc_pin(codec, OUTL);
+ snd_soc_dapm_nc_pin(codec, OUTR);
+ snd_soc_dapm_nc_pin(codec, EARPIECE);
+ snd_soc_dapm_nc_pin(codec, PREDRIVEL);
+ snd_soc_dapm_nc_pin(codec, PREDRIVER);
+ snd_soc_dapm_nc_pin(codec, CARKITL);
+ snd_soc_dapm_nc_pin(codec, CARKITR);
+
+ /* Add SDP3430 specific widgets */
+ ret = snd_soc_dapm_new_controls(codec, sdp3430_twl4030_dapm_widgets,
+ ARRAY_SIZE(sdp3430_twl4030_dapm_widgets));
+ if (ret)
+ return ret;
+
+ /* Set up SDP3430 specific audio path audio_map */
+ snd_soc_dapm_add_routes(codec, audio_map, ARRAY_SIZE(audio_map));
+
+ ret = snd_soc_dapm_sync(codec);
+
+ return ret;
+}
+
/* Digital audio interface glue - connects codec -- CPU */
static struct snd_soc_dai_link sdp3430_dai = {
.name = TWL4030,
.stream_name = TWL4030,
.cpu_dai = omap_mcbsp_dai[0],
.codec_dai = twl4030_dai,
+ .init = sdp3430_twl4030_init,
.ops = sdp3430_ops,
};
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ASoC: Add headset jack detection for SDP3430 machine driver
Add headset jack detection for SDP3430 boards using SoC jack
reporting interface. Headset detection on SDP3430 board is
achieved through TWL4030 GPIO_2 pin.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/omap/sdp3430.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
index 7a996d9..7695675 100644
--- a/sound/soc/omap/sdp3430.c
+++ b/sound/soc/omap/sdp3430.c
@@ -28,6 +28,7 @@
#include sound/pcm.h
#include sound/soc.h
#include sound/soc-dapm.h
+#include sound/jack.h
#include asm/mach-types.h
#include mach/hardware.h
@@ -141,6 +142,18 @@ static int sdp3430_twl4030_init(struct snd_soc_codec
*codec)
return ret;
}
+/* Jack detection */
+struct snd_soc_jack *sdp3430_jack;
+
+struct snd_soc_jack_pin sdp3430_jack_pins[] = {
+ {
+ .pin = Headset Jack,
+ .mask = SND_JACK_HEADSET,
+ .invert = 0,
+ .gpio = (OMAP_MAX_GPIO_LINES + 2),
+ },
+};
+
/* Digital audio interface glue - connects codec -- CPU */
static struct snd_soc_dai_link sdp3430_dai = {
.name = TWL4030,
@@ -191,7 +204,23 @@ static int __init sdp3430_soc_init(void)
if (ret)
goto err1;
- return 0;
+ /* Jack detection */
+ sdp3430_jack = kzalloc(sizeof(struct snd_soc_jack), GFP_KERNEL);
+ if (!sdp3430_jack) {
+ printk(KERN_ERR SDP3430 SoC Jack allocation failed\n);
+ return -ENOMEM;
+ }
+
+ snd_soc_jack_new(snd_soc_sdp3430, SDP3430 SoC Jack,
+ SND_JACK_HEADSET, sdp3430_jack);
+ if (ret)
+ return ret;
+
+ ret = snd_soc_jack_add_pins(sdp3430_jack,
+ ARRAY_SIZE(sdp3430_jack_pins),
+ sdp3430_jack_pins);
+
+ return ret;
err1:
printk(KERN_ERR Unable to add platform device\n);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
