Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Saturday 15 May 2010, Kevin Hilman wrote: > "Rafael J. Wysocki" writes: > > > On Friday 14 May 2010, Kevin Hilman wrote: > >> Kevin Hilman writes: > >> > >> > "Rafael J. Wysocki" writes: > >> > > >> >> On Thursday 13 May 2010, Tony Lindgren wrote: > >> >>> * Rafael J. Wysocki [100513 14:16]: > >> > > >> > [...] > >> > > >> >>> > >> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved > >> >>> > differently, while there's a growing number of out-of-tree drivers > >> >>> > depending > >> >>> > on this framework. We need those drivers in and because we don't > >> >>> > have any > >> >>> > viable alternative at hand, we have no good reason to reject it. > >> >>> > >> >>> Nothing is preventing merging the drivers can be merged without > >> >>> these calls. > >> >> > >> >> And yet, there _is_ a growing nuber of drivers that don't get merge > >> >> because > >> >> of that. That's _reality_. Are you going to discuss with facts, or > >> >> what? > >> > > >> > It may be reality, but IMO, "preventing other drivers" isn't a good > >> > *technical* argument for merging a feature. It feels like these "for > >> > the 'good' of the community" arguments are being used to trump the > >> > technical arguments. Maybe we need to keep the separate. > >> > >> To continue along the "for the good of the community" path... > >> > >> If it truly is the lack of a suspend blocker API that is preventing > >> the merge of these out of tree drivers, I second Mark's proposal[1] to > >> merge a noop version of the API while the technical issues continue to > >> be discussed. > > > > I'm against that, sorry. > > OK, I'll bite... Why? Because in that case the real feature will always be opposed as "unnecessary" and never merged. I very much prefer to decide whether to merge it or reject it right now. > >> Then we would see how many drivers get submitted and merged. > >> > >> Personally, I suspect that lack of this feature is not the real > >> obstacle to getting these out-of-tree drivers upstream. Having this > >> API upstream will not change the product schedules and corporate > >> cultures that have prevented code from making its way upstream. > > > > But apparently it is considered as a suitable excuse. > > No, it is not a _technical_ excuse. Just a healthy, experience-based > dose of skepticism. I didn't mean that, actually. What I wanted to say is that people use the lack of "wakelocks" in the mainline as an excuse not to push their drivers upstream (which is kind of understandable, because there's a zero benefit to them from mainlining their code, as they will have to maintain a separate "Android" version of it anyway). Sorry for the confusion. > It was expressed because I find the arguments above for merging > because it prevents out-of-tree drivers from merging quite > unconvincing. This is not just about opportunistic suspend + suspend > blockers specifically but comes from several years experience in the > embedded Linux world. In this particular case, the lack of the mainline's support for opportunistic suspend (in the form of "wakelocks" to be precise) has been given as a main obstacle against merging of several drivers at least. So, let's not just easily generalize, please. And this is not the only reason to push the opportunistic suspend feature upstream IMO. First, I think it is a legitimate approach to power management, whether you like it or not. I haven't seen anyone seriously arguing against that yet. Second, (as said above) there is a number of drivers _already_ depending on it and that number is only going to grow given the popularity of Android. They are not mainlined in part because their authors don't see a benefit from doing so (usually the benefit is that you don't have to maintain your code out of the tree, because the mainline does it for you to some extent, so if you need to maintain a separate version yourself, the benefit is zero). Next, the only thing the Arve's patches do is to give people an _option_ to use opportunistic suspend if they need it or want it. It's not mandatory and not even enabled by default, so I don't really see what the problem is. Quite on the contrary, I'd like people to be able to use the mainline on Android systems without major modifications, because potentially that can increase our tester base (and developer base too in consequence) and including opportunistic suspend in the mainline would be a step in that direction. Finally, it appears to address some issues that at the moment we don't seriously know how to address in a different way. Thanks, Rafael -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Brian Swetland wrote: > In tickless mode, the time until next timer is a signed int, so the > longest the kernel will ever sleep is ~2 seconds at a go. In > practice, userspace entities often have polling behavior that can > trigger more often than that, and I've observed some kernel periodic > timers (haven't cataloged them recently) that happen more often than > once a second. Paul and Kevin, how does the OMAP implementation handle these difficulties? Also, how does it handle the issue of ill-behaved apps? Alan Stern -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:34:55PM -0700, Tony Lindgren wrote: > * Matthew Garrett [100513 14:16]: > > What race-free mechanism do you use to ensure that? It's very easy to > > handwave these problems away. It's very difficult to actually write an > > implementation that works. > > Can you describe where do you see the race now? 1) Trusted app decides to suspend 2) Network packet that would otherwise wake the system is received 3) Trusted app sends SIGSTOP to untrusted userspace 4) Network packet sits waiting for stopped userspace to process it Unless the trusted userspace gets woken up on every event that would potentially cause a wakeup, you're racy. And the alternative involves an extra userspace wakeup for every network packet - which is expensive. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/5] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
Adds card detect callback function which gives the status of
the card .For MMC1 Controller, Card detect interrupt is provided
by twl6030 and card status is provided by MMCCTRL reg of twl6030.
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/board-4430sdp.c |9 +-
arch/arm/mach-omap2/hsmmc.c |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mfd/twl6030-irq.c | 23
drivers/mmc/host/omap_hsmmc.c | 31 ++---
include/linux/i2c/twl.h | 47 +
6 files changed, 105 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index e4a5d66..eb4545e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -144,6 +144,7 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires = 8,
+ .cd_type= NON_GPIO,
.gpio_wp= -EINVAL,
},
{
@@ -174,10 +175,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev->platform_data;
- /* Setting MMC1 Card detect Irq */
- if (pdev->id == 0)
+ /* MMC1 Card detect Configuration */
+ if (pdev->id == 0) {
+ ret = omap4_hsmmc1_card_detect_config();
+ if (ret < 0)
+ pr_err("Unable to configure Card detect for MMC1\n");
pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+ }
return ret;
}
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..8a8f7b1 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -265,6 +265,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc->get_context_loss_count = hsmmc_get_context_loss;
mmc->slots[0].switch_pin = c->gpio_cd;
+ mmc->slots[0].cd_type = c->cd_type;
mmc->slots[0].gpio_wp = c->gpio_wp;
mmc->slots[0].remux = c->remux;
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index ed60c0f..cd42c77 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..ca8b30b 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -223,6 +223,29 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect(int host_id, int slot)
+{
+ int ret = -ENOSYS;
+ u8 read_reg;
+
+ switch (host_id) {
+ case 0:
+ /*
+* BIT0 of REG_MMC_CTRL
+* 0 - Card not present ,1 - Card present
+*/
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0,
+ &read_reg, TWL6030_MMCCTRL);
+ if (ret >= 0)
+ ret = read_reg & STS_MMC;
+ break;
+ default:
+ pr_err("Unkown MMC controller %d in %s\n", host_id, __func__);
+ }
+ return ret;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect);
+
int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end)
{
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e9caf69..e25db63 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -190,9 +190,16 @@ struct omap_hsmmc_host {
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_mmc_platform_data *mmc = dev->platform_data;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ int ret = -ENOSYS;
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
+ if (mmc->slots[0].cd_type == GPIO)
+ /* NOTE: assumes card detect signal is active-low */
+ ret = !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
+ else
+ ret = twl6030_mmc_card_detect(pdev->id, slot);
+ return ret;
}
static int omap_hsmmc_get_wp(struct device *dev, int slot)
@@ -465,8 +472,6 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
int ret;
if (gpio_is_valid(pdata->slots[0].switch_pin)) {
- pdata->suspend = omap_hsmmc_suspend_cdirq;
- pdata->resume = omap_hsmmc_resume_cdirq;
if (pdata->slots[0].cover)
pdata->slots[0].get_cover_
[PATCH v4 4/5] OMAP HSMMC: Adding a flag to determine the card detect type
Adding a flag to determine the card detect type which can be
either GPIO or NON-GPIO.MMC1 Controller of OMAP4 have NON-GPIO
interrupt line from twl6030 for card detect.
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/board-2430sdp.c |2 ++
arch/arm/mach-omap2/board-3430sdp.c |3 +++
arch/arm/mach-omap2/board-cm-t35.c |3 +++
arch/arm/mach-omap2/board-devkit8000.c |2 ++
arch/arm/mach-omap2/board-igep0020.c |3 +++
arch/arm/mach-omap2/board-ldp.c |2 ++
arch/arm/mach-omap2/board-omap3beagle.c |2 ++
arch/arm/mach-omap2/board-omap3evm.c |2 ++
arch/arm/mach-omap2/board-omap3pandora.c |4
arch/arm/mach-omap2/board-omap3touchbook.c |2 ++
arch/arm/mach-omap2/board-overo.c|3 +++
arch/arm/mach-omap2/board-rx51-peripherals.c |3 +++
arch/arm/mach-omap2/board-zoom-peripherals.c |3 +++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h|4
15 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index a11a575..c7dec0e 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "hsmmc.h"
@@ -196,6 +197,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.mmc= 1,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
.ext_clock = 1,
},
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index e7d629b..cfb20a0 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
@@ -356,11 +357,13 @@ static struct omap2_hsmmc_info mmc[] = {
* so the SIM card isn't used; else 4 bits.
*/
.wires = 8,
+ .cd_type= GPIO,
.gpio_wp= 4,
},
{
.mmc= 2,
.wires = 8,
+ .cd_type= GPIO,
.gpio_wp= 7,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e679a2c..89cfd1a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
@@ -599,6 +600,7 @@ static struct omap2_hsmmc_info mmc[] = {
.mmc= 1,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
},
@@ -607,6 +609,7 @@ static struct omap2_hsmmc_info mmc[] = {
.wires = 4,
.transceiver= 1,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
.ocr_mask = 0x0010, /* 3.3V */
},
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 77022b5..114820f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -122,6 +123,7 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires = 8,
+ .cd_type= GPIO,
.gpio_wp= 29,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index d55c57b..3d5d506 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "mux.h"
#include "hsmmc.h"
@@ -250,12 +251,14 @@ static struct omap2_hsmmc_info mmc[] = {
.mmc= 1,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 5fcb52e..efe3b1b 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#inclu
[PATCH v4 3/5] OMAP4 HSMMC: Enable HSMMC support
Enables HSMMC support for OMAP4430 defconfig Signed-off-by: Kishore Kadiyala --- arch/arm/configs/omap_4430sdp_defconfig | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 25e8d04..1fb0456 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -810,7 +810,24 @@ CONFIG_DUMMY_CONSOLE=y # CONFIG_SOUND is not set # CONFIG_HID_SUPPORT is not set # CONFIG_USB_SUPPORT is not set -# CONFIG_MMC is not set +CONFIG_MMC=y +# CONFIG_MMC_DEBUG is not set +# CONFIG_MMC_UNSAFE_RESUME is not set + +# +# MMC/SD/SDIO Card Drivers +# +CONFIG_MMC_BLOCK=y +CONFIG_MMC_BLOCK_BOUNCE=y +# CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set + +# +# MMC/SD/SDIO Host Controller Drivers +# +# CONFIG_MMC_SDHCI is not set +# CONFIG_MMC_OMAP is not set +CONFIG_MMC_OMAP_HS=y # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set -- 1.6.3.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 v4 2/5] OMAP4 HSMMC: Adding PBIAS Configuration for MMC1 Controller
In OMAP4 , MMC1 PBIAS and its associated IO is software-controlled
by CONTROL_PBIAS and CONTROL_MMC1 registers. This patch adds PBIAS
configuration for MMC1 Controller during power-ON and power-OFF
of regulator.
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/hsmmc.c | 97 ++---
arch/arm/plat-omap/include/plat/control.h | 20 ++
2 files changed, 108 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 2d36f3a..1ef54b0 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -24,6 +24,7 @@
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
+static u16 control_mmc1;
#define HSMMC_NAME_LEN 9
@@ -42,7 +43,7 @@ static int hsmmc_get_context_loss(struct device *dev)
#define hsmmc_get_context_loss NULL
#endif
-static void hsmmc1_before_set_reg(struct device *dev, int slot,
+static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg, prog_io;
@@ -95,7 +96,7 @@ static void hsmmc1_before_set_reg(struct device *dev, int
slot,
}
}
-static void hsmmc1_after_set_reg(struct device *dev, int slot,
+static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg;
@@ -119,6 +120,60 @@ static void hsmmc1_after_set_reg(struct device *dev, int
slot,
}
}
+static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
+ int power_on, int vdd)
+{
+ u32 reg;
+
+ /*
+* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
+* card with Vcc regulator (from twl4030 or whatever). OMAP has both
+* 1.8V and 3.0V modes, controlled by the PBIAS register.
+*
+* In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
+* is most naturally TWL VSIM; those pins also use PBIAS.
+*
+* FIXME handle VMMC1A as needed ...
+*/
+ reg = omap_ctrl_readl(control_pbias_offset);
+ reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ |
+ OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+}
+
+static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
+int power_on, int vdd)
+{
+ u32 reg;
+
+ if (power_on) {
+ reg = omap_ctrl_readl(control_pbias_offset);
+ reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
+ if ((1 << vdd) <= MMC_VDD_165_195)
+ reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
+ else
+ reg |= OMAP4_MMC1_PBIASLITE_VMODE;
+ reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ |
+ OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ /* 4 microsec delay for comparator to generate an error*/
+ udelay(4);
+ reg = omap_ctrl_readl(control_pbias_offset);
+ if (reg & OMAP4_MMC1_PBIASLITE_VMODE_ERROR) {
+ pr_err("Pbias Voltage is not same as LDO\n");
+ /* Caution : On VMODE_ERROR Power Down MMC IO */
+ reg &= ~(OMAP4_MMC1_PWRDNZ | OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ }
+ } else {
+ reg = omap_ctrl_readl(control_pbias_offset);
+reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
+ OMAP4_MMC1_PBIASLITE_VMODE | OMAP4_MMC1_PWRDNZ |
+ OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ }
+}
+
static void hsmmc23_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
@@ -152,13 +207,28 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
struct omap2_hsmmc_info *c;
int nr_hsmmc = ARRAY_SIZE(hsmmc_data);
int i;
+ u32 reg;
- if (cpu_is_omap2430()) {
- control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
- control_devconf1_offset = OMAP243X_CONTROL_DEVCONF1;
+ if (!cpu_is_omap44xx()) {
+ if (cpu_is_omap2430()) {
+ control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
+ control_devconf1_offset = OMAP243X_CONTROL_DEVCONF1;
+ } else {
+ control_pbias_offset = OMAP343X_CONTROL_PBIAS_LITE;
+ control_devconf1_offset = OMAP343X_CONTROL_DEVCONF1;
+ }
} else {
- control_pbias_offset = OMAP343X_CONTROL_PBIAS_LITE;
- control_devconf1_offset = OMAP343X_CONTROL_DEVCONF1;
+ control
[PATCH v4 1/5] OMAP4 HSMMC: Adding hsmmc support to board file
Adding support for MMC1 & MMC2 controllers of OMAP4430 SDP
to board file.
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-4430sdp.c | 59 ++
2 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 203a414..a799453 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -137,7 +137,8 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
hsmmc.o
-obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
+obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \
+ hsmmc.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 921cde3..e4a5d66 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -33,6 +33,8 @@
#include
#include
#include
+#include
+#include "hsmmc.h"
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
@@ -137,24 +139,66 @@ static struct omap_musb_board_data musb_board_data = {
.mode = MUSB_PERIPHERAL,
.power = 100,
};
-static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
- {
- .supply = "vmmc",
- },
+
+static struct omap2_hsmmc_info mmc[] = {
{
- .supply = "vmmc",
+ .mmc= 1,
+ .wires = 8,
+ .gpio_wp= -EINVAL,
},
{
- .supply = "vmmc",
+ .mmc= 2,
+ .wires = 8,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .nonremovable = true,
},
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
{
.supply = "vmmc",
+ .dev_name = "mmci-omap-hs.0",
},
{
.supply = "vmmc",
+ .dev_name = "mmci-omap-hs.1",
},
};
+static int omap4_twl6030_hsmmc_late_init(struct device *dev)
+{
+ int ret = 0;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ struct omap_mmc_platform_data *pdata = dev->platform_data;
+
+ /* Setting MMC1 Card detect Irq */
+ if (pdev->id == 0)
+ pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
+ MMCDETECT_INTR_OFFSET;
+ return ret;
+}
+
+static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
+{
+ struct omap_mmc_platform_data *pdata = dev->platform_data;
+
+ pdata->init = omap4_twl6030_hsmmc_late_init;
+}
+
+static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
+{
+ struct omap2_hsmmc_info *c;
+
+ omap2_hsmmc_init(controllers);
+ for (c = controllers; c->mmc; c++)
+ omap4_twl6030_hsmmc_set_late_init(c->dev);
+
+ return 0;
+}
+
static struct regulator_init_data sdp4430_vaux1 = {
.constraints = {
.min_uV = 100,
@@ -206,7 +250,7 @@ static struct regulator_init_data sdp4430_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 5,
+ .num_consumer_supplies = 2,
.consumer_supplies = sdp4430_vmmc_supply,
};
@@ -329,6 +373,7 @@ static void __init omap_4430sdp_init(void)
omap4_i2c_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
+ omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
--
1.6.3.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 v4 0/5] Adding MMC Support on OMAP4430 SDP
Adding MMC1 and MMC2 controllers support for OMAP4 V4: - Rebased to "for_next" branch[LO]. - The first 3 patches [1,2,3] in the series are Minimal set of changes with which MMC1/MMC2 works [No card detect for MMC1]on OMAP4 but with dependencies on following patches [Not in "for_next" branch] [1] I2c patches a)https://patchwork.kernel.org/patch/98937/ b)https://patchwork.kernel.org/patch/98936/ c)https://patchwork.kernel.org/patch/98939/ d)https://patchwork.kernel.org/patch/79735/ [2] Regulator pacth a)https://patchwork.kernel.org/patch/94054/ [3] hsmmc-clk patch a)https://patchwork.kernel.org/patch/96821/ - The patches 4,5 adds card detect feature for MMC1 - Tested on both OMAP4430 SDP and OMAP3430 SDP [Also with omap_hsmmc.c as Kernel Module]. - Compile tested for rest of omap3 boards using omap3_defconfig. Could any one test on other boards V3: http://www.mail-archive.com/linux-...@vger.kernel.org/msg01908.html V2: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27612.html V1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26858.html Kishore Kadiyala (5): OMAP4 HSMMC :Adding hsmmc support to board file OMAP4 HSMMC :Adding PBIAS Configuration for MMC1 Controller OMAP4 HSMMC :Enable HSMMC support OMAP HSMMC :Adding a flag to determine the card detect type OMAP4 HSMMC :Adding card detect support for MMC1 Controller arch/arm/configs/omap_4430sdp_defconfig | 19 +- arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/board-2430sdp.c |2 + arch/arm/mach-omap2/board-3430sdp.c |3 + arch/arm/mach-omap2/board-4430sdp.c | 64 +++-- arch/arm/mach-omap2/board-cm-t35.c |3 + arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |3 + arch/arm/mach-omap2/board-ldp.c |2 + arch/arm/mach-omap2/board-omap3beagle.c |2 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |4 + arch/arm/mach-omap2/board-omap3touchbook.c |2 + arch/arm/mach-omap2/board-overo.c|3 + arch/arm/mach-omap2/board-rx51-peripherals.c |3 + arch/arm/mach-omap2/board-zoom-peripherals.c |3 + arch/arm/mach-omap2/hsmmc.c | 98 +++--- arch/arm/mach-omap2/hsmmc.h |1 + arch/arm/plat-omap/include/plat/control.h| 20 + arch/arm/plat-omap/include/plat/mmc.h|5 ++ drivers/mfd/twl6030-irq.c| 23 ++ drivers/mmc/host/omap_hsmmc.c| 31 +++-- include/linux/i2c/twl.h | 47 23 files changed, 322 insertions(+), 23 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
Re: [PATCH v3 2/5] OMAP4 HSMMC: Adding hsmmc support to board file
Tony,
On Sat, May 15, 2010 at 3:26 AM, Tony Lindgren wrote:
> * kishore kadiyala [100513 13:06]:
>> Support for MMC1 & MMC2 controllers is added to the board file.
>> Also includes configuration of MMC1 Card detect initially.
>
> This patch does not seem to apply, I don't know where you're getting
> the sdp4430_vmmc_supply in this patch?
I have mentioned that patch series has dependency on I2c/regulator
pacthes [with links] in the cover letter.
here is the link to exact patch where sdp4430_vmmc_supply is added
to board file which i had mentioned :
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26258.html
>
> I suggest you forget about the card detect patches for now and
> first produce a minimal set of patches to get the MMC working
> for board-4430sdp.c. The card detect patches should be applied
> only after board-4430sdp.c works for MMC. And we're running out
> of time for this merge window.
Agree.
Actually the patches I've sent has that minimal changes with which MMC
works but with card detect feature dependency [Thought that card detect is also
a basic feature which is much needed].
Will rework and post patches as below :
1)As Sanotsh suggested, will re-base on "for_next " branch
2)Cover letter having links to dependencies on patches [I2c/Regulator]
with latest re-based
3)patch series with
a) Minimal set of changes for MMC
b) later Card detect. [Can take a call on this]
Regards,
Kishore
>
> Regards,
>
> Tony
>
>> Signed-off-by: Kishore Kadiyala
>> ---
>> arch/arm/mach-omap2/Makefile | 3 +-
>> arch/arm/mach-omap2/board-4430sdp.c | 64
>> +++
>> include/linux/i2c/twl.h | 44
>> 3 files changed, 103 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
>> index ffe600a..65d8d11 100644
>> --- a/arch/arm/mach-omap2/Makefile
>> +++ b/arch/arm/mach-omap2/Makefile
>> @@ -140,7 +140,8 @@ obj-$(CONFIG_MACH_IGEP0020) +=
>> board-igep0020.o \
>> hsmmc.o
>> obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
>> hsmmc.o
>> -obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o
>> +obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o \
>> + hsmmc.o
>>
>> obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
>>
>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
>> b/arch/arm/mach-omap2/board-4430sdp.c
>> index d86e22d..70c8ab7 100644
>> --- a/arch/arm/mach-omap2/board-4430sdp.c
>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
>> @@ -32,6 +32,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include "hsmmc.h"
>>
>> static struct platform_device sdp4430_lcd_device = {
>> .name = "sdp4430_lcd",
>> @@ -68,24 +70,71 @@ static struct omap_musb_board_data musb_board_data = {
>> .power = 100,
>> };
>>
>> -static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
>> - {
>> - .supply = "vmmc",
>> - },
>> +static struct omap2_hsmmc_info mmc[] = {
>> {
>> - .supply = "vmmc",
>> + .mmc = 1,
>> + .wires = 8,
>> + .gpio_cd = TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET,
>> + .cd_type = NON_GPIO,
>> + .gpio_wp = -EINVAL,
>> },
>> {
>> - .supply = "vmmc",
>> + .mmc = 2,
>> + .wires = 8,
>> + .gpio_cd = -EINVAL,
>> + .gpio_wp = -EINVAL,
>> + .nonremovable = true,
>> },
>> + {} /* Terminator */
>> +};
>> +
>> +static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
>> {
>> .supply = "vmmc",
>> + .dev_name = "mmci-omap-hs.0",
>> },
>> {
>> .supply = "vmmc",
>> + .dev_name = "mmci-omap-hs.1",
>> },
>> };
>>
>> +static int omap4_twl6030_hsmmc_late_init(struct device *dev)
>> +{
>> + int ret = 0;
>> + struct platform_device *pdev = container_of(dev,
>> + struct platform_device, dev);
>> + struct omap_mmc_platform_data *pdata = dev->platform_data;
>> +
>> + /* MMC1 Card detect Configuration */
>> + if (pdev->id == 0) {
>> + ret = omap4_hsmmc1_card_detect_config();
>> + if (ret < 0)
>> + pr_err("Unable to configure Card detect for MMC1\n");
>> + pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
>> + MMCDETECT_INTR_OFFSET;
>> + }
>> + return ret;
>> +}
>> +
>> +static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
>> +{
>> + struct omap_mmc_platform_data *pdata = dev->platform_data;
>> +
>> + pdata->init
Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
On Sat, May 15, 2010 at 11:26 AM, Felipe Contreras wrote: > On Fri, May 14, 2010 at 10:49 PM, Omar Ramirez Luna > wrote: >> On 5/14/2010 2:27 PM, Felipe Contreras wrote: >> [...] >>> >>> So, I tried your patches, and a simple test app worked fine without >>> modification, but a real video decoding hanged the device >>> completely... some spinlock was stuck. I don't know if it's because of >>> your patches, or because of the state of the bridge at that point. >>> I'll try first to rebase to the latest to have a better idea of what's >>> happening. >> >> You may want to check if you have this patch "DSPBRIDGE: Fix declaration and >> initialization of sync objects"[1] > > I used what Ohad suggested: 13e2573. So no, that patch is not there. > >> This is the one I know fixes a spinlock issue and which description is not >> clear enough to state that. >> >> File fixed was: drivers/dsp/bridge/wmd/msg_sm.c >> >> [1]http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b3900e6df1f4e16b59d506a299cd5084c67a6ede > > I tried to cherry-pick that commit... didn't help: > > BUG: spinlock lockup on CPU#0, gst-launch-0.10/534, c6404304 > Backtrace: > [] (dump_backtrace+0x0/0xf8) from [] > (dump_stack+0x18/0x1c) > r6: r5:c644a000 r4:c6404304 r3: > [] (dump_stack+0x0/0x1c) from [] > (__spin_lock_debug+0xbc/0xd0) > [] (__spin_lock_debug+0x0/0xd0) from [] > (do_raw_spin_lock+0x84/0xb4) > r8:c644be54 r7:0064 r6:c005f178 r5:8013 r4:c6404304 > [] (do_raw_spin_lock+0x0/0xb4) from [] > (_raw_spin_lock_irqsave+0x5c/0x68) > r4:c6404304 r3:c7865a00 > [] (_raw_spin_lock_irqsave+0x0/0x68) from [] > (completion_done+0x1c/0x38) > r6:0001 r5:c6404304 r4:c6404300 > [] (completion_done+0x0/0x38) from [] > (sync_wait_on_multiple_events+0x58/0x14c [bridgedriver]) > r5:0002 r4:c644be4c > [] (sync_wait_on_multiple_events+0x0/0x14c [bridgedriver]) > from [] (bridge_msg_get+0x154/0x240 [bridgedriver]) > [] (bridge_msg_get+0x0/0x240 [bridgedriver]) from > [] (node_get_message+0x94/0x128 [bridgedriver]) > [] (node_get_message+0x0/0x128 [bridgedriver]) from > [] (nodewrap_get_message+0x28/0x8c [bridgedriver]) > r7:c004db48 r6:bf02e7d6 r5:c644bebc r4:c644bf04 > [] (nodewrap_get_message+0x0/0x8c [bridgedriver]) from > [] (wcd_call_dev_io_ctl+0xf8/0x120 [bridgedriver]) > r5:0040 r4:c644bf1c > [] (wcd_call_dev_io_ctl+0x0/0x120 [bridgedriver]) from > [] (bridge_ioctl+0xac/0xcc [bridgedriver]) > r6:421e7d64 r5:c004db48 r4:c6419f00 r3:c65bb500 > [] (bridge_ioctl+0x0/0xcc [bridgedriver]) from [] > (vfs_ioctl+0x34/0xb4) > r6:421e7d64 r5:bf029fac r4:c6419f00 > [] (vfs_ioctl+0x0/0xb4) from [] (do_vfs_ioctl+0x1c4/0x1e0) > r7:0005 r6:c004db48 r5:421e7d64 r4:421e7d64 > [] (do_vfs_ioctl+0x0/0x1e0) from [] (sys_ioctl+0x40/0x64) > r4:c6419f00 > [] (sys_ioctl+0x0/0x64) from [] > (ret_fast_syscall+0x0/0x38) > r7:0036 r6:0006ef10 r5:4055d860 r4:0006a000 > > I'll try to rebase the patches to the latest head. Nope, didn't help. I've put the updated patches here: http://people.freedesktop.org/~felipec/dspbridge/ -- 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 v3 2/5] OMAP4 HSMMC: Adding hsmmc support to board file
Kishore, > -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > Shilimkar, Santosh > Sent: Saturday, May 15, 2010 11:41 AM > To: Kadiyala, Kishore > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Chikkature > Rajashekar, Madhusudhan; > jarkko.lavi...@nokia.com; p...@pwsan.com; adrian.hun...@nokia.com; Russell > King; Tony Lindgren > Subject: RE: [PATCH v3 2/5] OMAP4 HSMMC: Adding hsmmc support to board file > > Kishore, > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org > > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > Russell > > King > > Sent: Saturday, May 15, 2010 3:35 AM > > To: Tony Lindgren > > Cc: Kadiyala, Kishore; linux-...@vger.kernel.org; > > linux-omap@vger.kernel.org; Chikkature > Rajashekar, > > Madhusudhan; jarkko.lavi...@nokia.com; p...@pwsan.com; > > adrian.hun...@nokia.com > > Subject: Re: [PATCH v3 2/5] OMAP4 HSMMC: Adding hsmmc support to board file > > > > On Fri, May 14, 2010 at 02:56:51PM -0700, Tony Lindgren wrote: > > > * kishore kadiyala [100513 13:06]: > > > > Support for MMC1 & MMC2 controllers is added to the board file. > > > > Also includes configuration of MMC1 Card detect initially. > > > > > > This patch does not seem to apply, I don't know where you're getting > > > the sdp4430_vmmc_supply in this patch? > > > > > > I suggest you forget about the card detect patches for now and > > > first produce a minimal set of patches to get the MMC working > > > for board-4430sdp.c. The card detect patches should be applied > > > only after board-4430sdp.c works for MMC. And we're running out > > > of time for this merge window. > > > > Absolutely - we _really_ _really_ _really_ need to get MMC usable > > on the 4430SDP for this merge window - don't care about the card > > detection provided the system can find a MMC card which is left > > plugged in. > > > > To do this makes the overall 4430SDP more usable than it currently > > is with mainline kernels. > > > Why is it taking so much time to get 4-5 patches in shape for mainline?? > What is expected is just basic MMC support and no advance features yet. > Please have a look at Tony's "for-next" branch where your i2c board depedancy is taken care. May be you can rebase your patches against this branch. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 3/6] DSPBRIDGE: remove mapping information in proc_unmap
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen wrote: > Clean up all mapping information resources whenever > a buffer is unmapped. If I understand correctly the previous patch doesn't make sense on it's own because it will leak memory. Therefore it should be squashed with this one. Otherwise a git bisect might land on a very bad place. It's good for reviewing though. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/17] omap: mailbox: reorganize init
Hi Felipe, On Fri, May 14, 2010 at 10:03 PM, Felipe Contreras wrote: > On Fri, May 14, 2010 at 6:09 PM, Ohad Ben-Cohen wrote: >> Hi Felipe, >> >> On Fri, May 14, 2010 at 6:01 PM, Felipe Contreras >> wrote: >>> The main purpose of this patch series is to be able to compile mach platform >>> data as built-in. Otherwise, client modules such as bridgedriver will load >>> the >>> platform code, but not the mach code when mailbox is built as a module. >>> >>> Unfortunately, there's no easy way to do that since plat and mach code are >>> deepely interrelated. So the first patches try to separate the mailbox >>> registering through a defined omap_mbox_platform_data. >> >> Have you considered converting mailbox to hwmod + omap_device ? > > I don't know what's that... so no. Is there any good source of > information, or a good example? A good example (that also demonstrates runtime PM conversion) would be the MMC conversion in Kevin's 'pm-wip/mmc' branch: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=log;h=pm-wip/mmc > I think there is further tidying up > possible after this patch series independent of that, but I would like > to concentrate on getting this in first. Sure thing. Thanks, Ohad. > > -- > 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
Recall: Android Suspend Blockers
Lohithakshan, Ranjith would like to recall the message, "Android Suspend Blockers".-- 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/PATCH 2/6] DSPBRIDGE: remember mapping and page info in proc_map
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen wrote: > Every time the MM application calls proc_map to map > a memory area, remember the details of that mapping, > together with the related page structures. > > Signed-off-by: Ohad Ben-Cohen > --- > If you want, you can also reach me at < ohadb at ti dot com >. > @@ -948,6 +949,7 @@ static dsp_status bridge_dev_create(OUT struct > wmd_dev_context **ppDevContext, > status = DSP_EMEMORY; > goto func_end; > } > + > status = cfg_get_host_resources((struct cfg_devnode *) > drv_get_first_dev_extension(), > &resources); Completely unrelated change. Moreover, this creates conflicts on future commits since that code is gone. -- 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
Android Suspend Blockers
Quite a lot of debate on linux-pm whether to accept he Android suspend blocker support (locally called wakelocks in Android) to the mainline. It appears that the linux-omap camp is not all for it. Android handles the PM slightly differently and they have used wakelocks all over. The Android power driver and wakelock support were two of the main features that I had to pull in from Android repo on top of our 2.6.29 release when I experimented with Android. You can go through the debate at (and sort by thread) https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025179.html Ranjith-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
On Fri, May 14, 2010 at 10:49 PM, Omar Ramirez Luna wrote: > On 5/14/2010 2:27 PM, Felipe Contreras wrote: > [...] >> >> So, I tried your patches, and a simple test app worked fine without >> modification, but a real video decoding hanged the device >> completely... some spinlock was stuck. I don't know if it's because of >> your patches, or because of the state of the bridge at that point. >> I'll try first to rebase to the latest to have a better idea of what's >> happening. > > You may want to check if you have this patch "DSPBRIDGE: Fix declaration and > initialization of sync objects"[1] I used what Ohad suggested: 13e2573. So no, that patch is not there. > This is the one I know fixes a spinlock issue and which description is not > clear enough to state that. > > File fixed was: drivers/dsp/bridge/wmd/msg_sm.c > > [1]http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b3900e6df1f4e16b59d506a299cd5084c67a6ede I tried to cherry-pick that commit... didn't help: BUG: spinlock lockup on CPU#0, gst-launch-0.10/534, c6404304 Backtrace: [] (dump_backtrace+0x0/0xf8) from [] (dump_stack+0x18/0x1c) r6: r5:c644a000 r4:c6404304 r3: [] (dump_stack+0x0/0x1c) from [] (__spin_lock_debug+0xbc/0xd0) [] (__spin_lock_debug+0x0/0xd0) from [] (do_raw_spin_lock+0x84/0xb4) r8:c644be54 r7:0064 r6:c005f178 r5:8013 r4:c6404304 [] (do_raw_spin_lock+0x0/0xb4) from [] (_raw_spin_lock_irqsave+0x5c/0x68) r4:c6404304 r3:c7865a00 [] (_raw_spin_lock_irqsave+0x0/0x68) from [] (completion_done+0x1c/0x38) r6:0001 r5:c6404304 r4:c6404300 [] (completion_done+0x0/0x38) from [] (sync_wait_on_multiple_events+0x58/0x14c [bridgedriver]) r5:0002 r4:c644be4c [] (sync_wait_on_multiple_events+0x0/0x14c [bridgedriver]) from [] (bridge_msg_get+0x154/0x240 [bridgedriver]) [] (bridge_msg_get+0x0/0x240 [bridgedriver]) from [] (node_get_message+0x94/0x128 [bridgedriver]) [] (node_get_message+0x0/0x128 [bridgedriver]) from [] (nodewrap_get_message+0x28/0x8c [bridgedriver]) r7:c004db48 r6:bf02e7d6 r5:c644bebc r4:c644bf04 [] (nodewrap_get_message+0x0/0x8c [bridgedriver]) from [] (wcd_call_dev_io_ctl+0xf8/0x120 [bridgedriver]) r5:0040 r4:c644bf1c [] (wcd_call_dev_io_ctl+0x0/0x120 [bridgedriver]) from [] (bridge_ioctl+0xac/0xcc [bridgedriver]) r6:421e7d64 r5:c004db48 r4:c6419f00 r3:c65bb500 [] (bridge_ioctl+0x0/0xcc [bridgedriver]) from [] (vfs_ioctl+0x34/0xb4) r6:421e7d64 r5:bf029fac r4:c6419f00 [] (vfs_ioctl+0x0/0xb4) from [] (do_vfs_ioctl+0x1c4/0x1e0) r7:0005 r6:c004db48 r5:421e7d64 r4:421e7d64 [] (do_vfs_ioctl+0x0/0x1e0) from [] (sys_ioctl+0x40/0x64) r4:c6419f00 [] (sys_ioctl+0x0/0x64) from [] (ret_fast_syscall+0x0/0x38) r7:0036 r6:0006ef10 r5:4055d860 r4:0006a000 I'll try to rebase the patches to the latest head. Cheer.s -- 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
