Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
On 13.10.2015 07:29, Heiko Schocher wrote:
On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.
E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.
Signed-off-by: Heiko Schocher <h...@denx.de>
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"
The last attempt I remember is from last year
http://www.spinics.net/lists/linux-mmc/msg26586.html
http://www.spinics.net/lists/linux-mmc/msg26588.html
I can't remember why this wasn't accepted, too. But maybe searching
the archives will help answering that.
Best regards
Dirk
I adapt this to the omap_hsmmc driver.
Is there another solution for this problem?
Or why was this patch not accepted to mainline?
drivers/mmc/card/block.c | 6 --
drivers/mmc/host/omap_hsmmc.c | 6 ++
include/linux/mmc/host.h | 3 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;
- devidx = find_first_zero_bit(dev_use, max_devices);
+ devidx = find_next_zero_bit(dev_use, max_devices,
+ card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
* index anymore so we keep track of a name index.
*/
if (!subname) {
- md->name_idx = find_first_zero_bit(name_use, max_devices);
+ md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;
+ if (pdev->dev.of_node) {
+ ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+ if (ret >= 0)
+ host->mmc->devidx = ret;
+ }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */
+ /* preferred mmc block device index (mmcblkX) */
+ unsigned intdevidx;
+
unsigned long private[0] cacheline_aligned;
};
--
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
Windows on OMAP
Sorry if this is off topic on a Linux mailing list, but maybe it's of some interest here, too: Windows on OMAP presented at Microsoft's CES keynote yesterday: http://www.youtube.com/watch?v=xKc_XGuvNIk#t=1m53s Best regards Dirk Btw.: Is anybody able to identify the OMAP board used there? And with this the OMAP? OMAP3? OMAP4? -- 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] OMAP35xx:SDIO IRQ Support for OMAP35xx
On 21.12.2009 17:46, Mike Rapoport wrote:
Hi,
Phaneendra Kumar Alapati wrote:
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Signed-off-by: Phaneendra Kumarph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
I've tried the patch on CM-T35 that has Marvell 88W8686 on-board and
surprisingly I get a lot of command timeouts from the libertas driver :(
---
libertas: requeueing command 0x0006 due to timeout (#1)
libertas: Received result 0 to command 6 after 1 retries
libertas: command 0x0006 timed out
---
I hope I'll find time to debug it in the next few days and provide more valuable
information...
There is a test report from Overo air that there it doesn't work, too:
http://old.nabble.com/Re%3A-Overo-wifi-speed-and-WPA2-connection-issue-p27231874.html
Any news on this patch?
Best regards
Dirk
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD (1 26)
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE(1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
int vdd;
int protect_card;
int reqs_blocked;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ }
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
spin_lock(host-irq_lock);
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO Card Interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+ host-sdio_int = enable;
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) (~CIRQ_ENABLE)));
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) (~CIRQ_ENABLE)));
+ }
+
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq
Re: bootloader compilation
On 14.12.2009 08:02, Niamathullah sharief wrote: Hello,i am newbie. i am having beagle board with me. now i want to compile bootloader. what is theprocedure to do that? where can i find the right tutorial to compile bootloader. i didnt find the right tutorial for newbie. please help me. http://elinux.org/BeagleBoard#U-Boot Best regards Dirk Btw.: Do you know Beagle mailing list http://groups.google.com/group/beagleboard ? -- 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: TFTP on beagle board
Mai Daftedar wrote: Hi all, I was wondering how can we configure the u-boot with the TFTP capability on the beagle board at runtime.. For this you will need ethernet support in U-Boot. There are two (?) options to achieve this: Add support for USB ethernet dongle in U-Boot or use a Beagle expansion card with ethernet. Regarding USB ethernet dongle, there are some basic USB patches for Beagle U-Boot on the list. But I'm not sure how much work it is to enable them to support USB ethernet. For ethernet on expansion board, there is TinCanTool's Zippy board [1]. To access ethernet on this board from U-Boot, an U-Boot OMAP3 SPI driver is missing. Both options are not ready, yet, and need some development work. Any help is greatly appreciated! Cheers Dirk Btw.: I added U-Boot list, it is the better place to discuss this. [1] http://www.tincantools.com/product.php?productid=16147cat=0page=1featured -- 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] OMAP35xx: Added SDIO IRQ support
Dirk Behme wrote:
Madhusudhan wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Phaneendra Kumar Alapati
Sent: Wednesday, October 28, 2009 8:19 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP35xx: Added SDIO IRQ support
This patch adds SDIO IRQ support for omap hsmmc driver.
Signed-off-by: Phaneendra Kumar Alapati ph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c |62 ++--
1 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 1cf9cfb..a540626 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -92,6 +92,10 @@
#define DUAL_VOLT_OCR_BIT7
#define SRC(1 25)
#define SRD(1 26)
+#define OMAP_HSMMC_CARD_INTBIT(8)
+#define SDIO_INT_ENBIT(8)
Why multiple defines of the same? One of them should be enough.
What I think meant here is
#define CIRQ(1 8)
#define CIRQ_ENABLE(1 8)
One is for the status register, the other is for the interrupt enable
registers. To be compatible with the TRM, I would use both in this way.
+#define CTPLBIT(11)
+#define CLKEXTFREEBIT(16)
Can we define them in the same way as other defines to maintain
uniformity?
Yes, ack.
/*
* FIXME: Most likely all the data using these _DEVID defines should
come
@@ -149,6 +153,7 @@ struct mmc_omap_host {
intslot_id;
intdbclk_enabled;
intresponse_busy;
+intsdio_int;
What purpose does this serve? IMHO, this is not needed.
Hmm. This is set to != 0 in omap_hsmmc_enable_sdio_irq() when IRQs are
enabled. Then in mmc_omap_start_command() these interrupts are enabled
again if sdio_int is != 0. Yes, looks unneeded, indeed. But maybe there
is some trick ;)
structomap_mmc_platform_data*pdata;
};
@@ -240,8 +245,13 @@ mmc_omap_start_command(struct mmc_omap_host
*host, struct mmc_command *cmd,
Patch is line wrapped by mailer.
* Clear status bits and enable interrupts
*/
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
-OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
-OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+if (host-sdio_int) {
+OMAP_HSMMC_WRITE(host-base, ISE, (INT_EN_MASK |
SDIO_INT_EN));
+OMAP_HSMMC_WRITE(host-base, IE, (INT_EN_MASK |
SDIO_INT_EN));
Why? It is being taken care in enable_sdio_irq.
Yes, why?
+} else {
+OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+}
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
@@ -430,17 +440,27 @@ static irqreturn_t mmc_omap_irq(int irq, void
*dev_id)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
+data = host-data;
+status = OMAP_HSMMC_READ(host-base, STAT);
+dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
Why are these moved up?
Yes, why? Why not move the block below down instead?
+
+if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+if (status OMAP_HSMMC_CARD_INT) {
+dev_dbg(mmc_dev(host-mmc),
+ SDIO CARD interrupt status %x\n,
+status);
+mmc_signal_sdio_irq(host-mmc);
+}
+}
- It makes no sense to print status in dev_dbg here again, as it is
already printed some lines above. Something like
dev_dbg(mmc_dev(host-mmc), SDIO interrupt\n);
would be sufficient here.
- Why isn't IRQ acknowledged here? I.e. why not doing something like
OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
~(CIRQ_ENABLE));
here?
- No return IRQ_HANDLED; here? Mmm, maybe this makes sense.
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
-OMAP_HSMMC_READ(host-base, STAT));
+OMAP_HSMMC_READ(host-base, STAT));
This just adds a tab space. Not needed.
Ack.
/* Flush posted write */
OMAP_HSMMC_READ(host-base, STAT);
return IRQ_HANDLED;
}
-data = host-data;
-status = OMAP_HSMMC_READ(host-base, STAT);
-dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
Check my comment above.
Yes, from theory it looks better to move the new code below this, instead.
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
@@ -932,6 +952,29 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return pdata-slots[0].get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
enable)
+{
+struct mmc_omap_host *host = mmc_priv(mmc);
+
+host-sdio_int = enable;
+if (enable) {
+OMAP_HSMMC_WRITE(host-base, ISE,
+(OMAP_HSMMC_READ(host-base, ISE) |
+ OMAP_HSMMC_CARD_INT));
+OMAP_HSMMC_WRITE(host-base, IE,
+(OMAP_HSMMC_READ(host-base, IE) |
+ OMAP_HSMMC_CARD_INT
Re: [PATCH] OMAP35xx: Added SDIO IRQ support
Comments below...
Phaneendra Kumar Alapati wrote:
Dirk and Madhu, Thanks for the review/comments. I have explained below
the reasons behind certain changes i made esp the interrupt enabling
and irq routine changes.
On Thu, Oct 29, 2009 at 2:22 AM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Wednesday, October 28, 2009 2:48 PM
To: Madhusudhan; 'Phaneendra Kumar Alapati'
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP35xx: Added SDIO IRQ support
Madhusudhan wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Phaneendra Kumar Alapati
Sent: Wednesday, October 28, 2009 8:19 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP35xx: Added SDIO IRQ support
This patch adds SDIO IRQ support for omap hsmmc driver.
Signed-off-by: Phaneendra Kumar Alapati ph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c |62 ++--
1 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 1cf9cfb..a540626 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -92,6 +92,10 @@
#define DUAL_VOLT_OCR_BIT 7
#define SRC (1 25)
#define SRD (1 26)
+#define OMAP_HSMMC_CARD_INT BIT(8)
+#define SDIO_INT_EN BIT(8)
Why multiple defines of the same? One of them should be enough.
What I think meant here is
#define CIRQ (1 8)
#define CIRQ_ENABLE (1 8)
One is for the status register, the other is for the interrupt enable
registers. To be compatible with the TRM, I would use both in this way.
+#define CTPL BIT(11)
+#define CLKEXTFREEBIT(16)
Can we define them in the same way as other defines to maintain
uniformity?
Yes, ack.
I have kept separate macros in reference to the TRM as they are for
different registers. To keep the code simpler they can be merged
/*
* FIXME: Most likely all the data using these _DEVID defines should
come
@@ -149,6 +153,7 @@ struct mmc_omap_host {
int slot_id;
int dbclk_enabled;
int response_busy;
+ int sdio_int;
What purpose does this serve? IMHO, this is not needed.
Hmm. This is set to != 0 in omap_hsmmc_enable_sdio_irq() when IRQs are
enabled. Then in mmc_omap_start_command() these interrupts are enabled
again if sdio_int is != 0. Yes, looks unneeded, indeed. But maybe
there is some trick ;)
struct omap_mmc_platform_data *pdata;
};
@@ -240,8 +245,13 @@ mmc_omap_start_command(struct mmc_omap_host
*host, struct mmc_command *cmd,
Patch is line wrapped by mailer.
* Clear status bits and enable interrupts
*/
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE, (INT_EN_MASK |
SDIO_INT_EN));
+ OMAP_HSMMC_WRITE(host-base, IE, (INT_EN_MASK |
SDIO_INT_EN));
Why? It is being taken care in enable_sdio_irq.
Yes, why?
Once sdio interrupts are enabled through enable_sdio_irq, commands
which are sent further disable the sdio interrupts by directly over
writing to the IE and ISE without preserving currently enabled
interrupts.
Best option is to read+modify+write the IE and ISE register as i did
in enable_sdio_irq. But the IE and ISE register seem to be modified in
other places too, so i made use of sdio_int flag to keep track of sdio
interrupt enabling/disabling.
+ } else {
+ OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ }
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
@@ -430,17 +440,27 @@ static irqreturn_t mmc_omap_irq(int irq, void
*dev_id)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
Why are these moved up?
Yes, why? Why not move the block below down instead?
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status OMAP_HSMMC_CARD_INT) {
+ dev_dbg(mmc_dev(host-mmc),
+ SDIO CARD interrupt status %x\n,
+ status);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
- It makes no sense to print status in dev_dbg here again, as it is
already printed some lines above. Something like
dev_dbg(mmc_dev(host-mmc), SDIO interrupt\n);
would be sufficient here.
- Why isn't IRQ acknowledged here? I.e. why not doing something like
OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
~(CIRQ_ENABLE));
here?
SDIO interrupts are generated asynchronously from the sdio
Re: [PATCH] OMAP35xx: Added SDIO IRQ support
-sdio_int = enable;
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) |
+OMAP_HSMMC_CARD_INT));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) |
+OMAP_HSMMC_CARD_INT));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE)
+(~OMAP_HSMMC_CARD_INT)));
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE)
+(~OMAP_HSMMC_CARD_INT)));
+ }
+
+}
+
static void omap_hsmmc_init(struct mmc_omap_host *host)
{
u32 hctl, capa, value;
@@ -964,7 +1007,7 @@ static struct mmc_host_ops mmc_omap_ops = {
.set_ios = omap_mmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static int __init omap_mmc_probe(struct platform_device *pdev)
@@ -1011,6 +1054,7 @@ static int __init omap_mmc_probe(struct
platform_device *pdev)
Greetings from the mailer again.
host-irq= irq;
host-id = pdev-id;
host-slot_id= 0;
+ host-sdio_int = 0;
Not needed.
host-mapbase= res-start;
host-base = ioremap(host-mapbase, SZ_4K);
@@ -1080,6 +1124,10 @@ static int __init omap_mmc_probe(struct
platform_device *pdev)
else if (pdata-slots[host-slot_id].wires = 4)
mmc-caps |= MMC_CAP_4_BIT_DATA;
+ mmc-caps |= MMC_CAP_SDIO_IRQ;
+ OMAP_HSMMC_WRITE(host-base, CON,
+ OMAP_HSMMC_READ(host-base, CON) | (CTPL |
CLKEXTFREE));
How about moving this to enable_sdio_irq so that these are done for SDIO
alone? Also can be disabled in the same fn.
Ack. But I think that mmc-caps |= MMC_CAP_SDIO_IRQ has to stay here.
Else enable_sdio_irq will never be called (?)
All in all, I wonder why IBG bit isn't used in this patch. Is this
tested with 1 or 4 bit (wire) SDIO?
Just for reference the slightly modified version of this patch for
testing in attachment (based on pure theory ;) ). I will come back
with testing results.
Best regards
Dirk
Regards,
Madhusudhan
+
omap_hsmmc_init(host);
/* Select DMA lines */
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Subject: [PATCH] OMAP35xx: Added SDIO IRQ support
From: Phaneendra Kumar Alapati ph...@embwise.com
Date: Wed, 28 Oct 2009 18:48:38 +0530
To: linux-omap@vger.kernel.org
This patch adds SDIO IRQ support for omap hsmmc driver.
Signed-off-by: Phaneendra Kumar Alapati ph...@embwise.com
---
Revised version of
http://marc.info/?l=linux-omapm=125673594321210w=2
based on comments and theory. Please test.
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
drivers/mmc/host/omap_hsmmc.c | 48 ++
1 file changed, 44 insertions(+), 4 deletions(-)
Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c
===
--- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-beagle/drivers/mmc/host/omap_hsmmc.c
@@ -92,6 +92,10 @@
#define DUAL_VOLT_OCR_BIT 7
#define SRC(1 25)
#define SRD(1 26)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE(1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -430,6 +434,15 @@ static irqreturn_t mmc_omap_irq(int irq,
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if ((status CIRQ) (host-mmc-caps MMC_CAP_SDIO_IRQ)) {
+ dev_dbg(mmc_dev(host-mmc), SDIO interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -438,9 +451,6 @@ static irqreturn_t mmc_omap_irq(int irq,
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
Re: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I don't think it is already ready for review. We are still in the find out how to get sdio irq working phase. Once we have found out what's needed for this, sure, I will send a patch for review inlined. Best regards Dirk I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote: In enable_sdio_irq if enable set ctpl else clear ctpl It would really help avoiding mails like this if you just would send your changes. We know that they are for an old kernel and just a dirty hack. Dirk On Tue, Oct 20, 2009 at 4:47 PM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
Woodruff, Richard wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Thanks! Do you have any idea about MMCHS_HCTL.IBG? This bit is valid only in 4-bit mode of SDIO card to enable interrupt detection in the interrupt cycle at block gap for a multiple block transfer. For MMC cards and for SD card this bit should be set to 0. 0x0: Disable interrupt detection at the block gap in 4-bit mode 0x1: Enable interrupt detection at the block gap in 4-bit mode I saw it neither in the exiting code I looked at, nor in your description above. But it sounds to me that it should be set for 4-bit mode? Best regards Dirk -- 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: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. Subject: [PATCH v2][RFC] OMAP HSMMC: Add SDIO interrupt support Form: Dirk Behme dirk.be...@googlemail.com At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor performance. Add support for SDIO interrupt handling. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Patch against recent omap-linux head Linux omap got rebuilt from scratch 274c94b29ee7c53609a756acca974e4742c59559 Compile tested only. Please comment and help testing. Changes in v2: - For testing only, hardcode IBG. This should be set only in SDIO and 4-bit mode. But how to detect this? mmc_card_sdio(host-mmc-card) doesn't seem to work here. - Additonally, set CTPL. Is this needed for 1-bit mode? drivers/mmc/host/omap_hsmmc.c | 44 -- 1 file changed, 38 insertions(+), 6 deletions(-) Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c === --- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c +++ linux-beagle/drivers/mmc/host/omap_hsmmc.c @@ -65,6 +65,7 @@ #define SDVSDET0x0400 #define AUTOIDLE 0x1 #define SDBP (1 8) +#define IBG(1 19) #define DTO0xe #define ICE0x1 #define ICS0x2 @@ -76,6 +77,7 @@ #define INT_EN_MASK0x307F0033 #define BWR_ENABLE (1 4) #define BRR_ENABLE (1 5) +#define CIRQ_ENABLE(1 8) #define INIT_STREAM(1 1) #define DP_SELECT (1 21) #define DDIR (1 4) @@ -84,9 +86,11 @@ #define BCE(1 1) #define FOUR_BIT (1 1) #define DW8(1 5) +#define CTPL (1 11) #define CC 0x1 #define TC 0x02 #define OD 0x1 +#define CIRQ (1 8) #define ERR(1 15) #define CMD_TIMEOUT(1 16) #define DATA_TIMEOUT (1 20) @@ -268,12 +272,12 @@ static int omap_hsmmc_context_restore(st OMAP_HSMMC_WRITE(host-base, CON, con | DW8); break; case MMC_BUS_WIDTH_4: - OMAP_HSMMC_WRITE(host-base, CON, con ~DW8); + OMAP_HSMMC_WRITE(host-base, CON, (con | CTPL) ~DW8); OMAP_HSMMC_WRITE(host-base, HCTL, OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT); break; case MMC_BUS_WIDTH_1: - OMAP_HSMMC_WRITE(host-base, CON, con ~DW8); + OMAP_HSMMC_WRITE(host-base, CON, (con | CTPL) ~DW8); OMAP_HSMMC_WRITE(host-base, HCTL, OMAP_HSMMC_READ(host-base, HCTL) ~FOUR_BIT); break; @@ -653,6 +657,15 @@ static
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote: All, Sorry for the delay, I have been without internet access until just now. I added the cptl bit and I don't get continuous cirqs anymore. Right now I have a hacked driver that still does timed polling in sdio_irq.c and also wakes up on cirq. With this config the libertas works well. A flood ping of 1000 packets loses 2. Previously it was dropping about 30% of the packets from a flood ping. Great!! :) Without the polling in sdio_irq.c I get timeouts in libertas driver so I suspect that we may need to add checks of the DAT1 line in other places like the davinci driver does. As I said before, my kernel is a few months old so my issues may not be the same as current head of tree. Do you like to send your changes anyway? Just for reference... Thanks to all who helped on this. Now, the job will be to do this with recent kernel, make it stable and in the mid term get it applied. Anybody likes to help with this? Many thanks and best regards Dirk On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan madhu...@ti.com wrote: Hi John, So does the SDIO card interrupt mode work fine now? Regards, Madhu -- *From:* John Rigby [mailto:jcri...@gmail.com] *Sent:* Sunday, October 18, 2009 7:24 PM *To:* Woodruff, Richard *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman *Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
Ok, in other words, this does mean that the card has no interrupt
asserted any more (i.e. it is acknowledged by upper layers, e.g.
libertas driver), but OMAP thinks there is still an interrupt. Right?
This would mean it is an OMAP/omap_hsmmc.c issue. Right?
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
Have you checked if
- IBG (and 4 bit mode) is correctly set before the first interrupt is
fired (just to make sure that we don't have a function calling order
issue)?
- your HW design has a pull up on DAT1 line (as required by the SD
physical spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@vger.kernel.org; John Rigby; linux-omap@vger.kernel.org;
Steve Sakoman
Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan Chikkature wrote:
Hi Dirk,
I am inlining the patch so that it helps review.
...
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+ if (mmc_card_sdio(host-mmc-card)) {
I wish it could be moved to enable_sdio_irq so that we can avoid
inclusion of
card.h and checking the type of card in the host controller driver.
Yes, this would be the real clean way. But ...
But the
dependancy on 4-bit seems to be a problem here.
... most probably we have to find a workaround until (if ever?) above
clean implementation is available.
What we need is after SDIO mode and bus width is known, and before the
first interrupt comes, to set IBG.
On the problems being discussed on testing is the interrupt source
geting
cleared at the SDIO card level upon genaration of the CIRQ? If not it
remains
asserted.
Yes, this seems to be exactly the problem John reports in his follow
up mail.
Any hint how to clear SDIO interrupt?
On the controller side I guess it is cleared when you pass disable in the
enable_sdio_irq fn. This happens when you call mmc_signal_sdio_irq.
I am not too sure about how it gets disabled from the card side. I see that
SDIO core has a function sdio_release_irq which is used by the sdio uart
driver. The usage of this could give a clue.
Regards,
Madhu
Many thanks
Dirk
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| IBG | FOUR_BIT);
+ } else {
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| FOUR_BIT);
+ }
break;
case MMC_BUS_WIDTH_1:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
@@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
return 0;
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 ie, ise;
+
+ ise = OMAP_HSMMC_READ(host-base, ISE);
+ ie = OMAP_HSMMC_READ(host-base, IE);
+
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE, ise | CIRQ_ENABLE);
+ OMAP_HSMMC_WRITE(host-base, IE, ie | CIRQ_ENABLE);
+ } else {
+ OMAP_HSMMC_WRITE(host-base, ISE, ise ~CIRQ_ENABLE);
+ OMAP_HSMMC_WRITE(host-base, IE, ie ~CIRQ_ENABLE);
+ }
+
+}
+
static const struct mmc_host_ops omap_hsmmc_ops = {
.enable = omap_hsmmc_enable_fclk,
.disable = omap_hsmmc_disable_fclk,
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hs
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
#ifdef CONFIG_DEBUG_FS
@@ -1734,7 +1772,7 @@ static int __init omap_hsmmc_probe(struc
mmc-max_seg_size = mmc-max_req_size;
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_WAIT_WHILE_BUSY;
+MMC_CAP_WAIT_WHILE_BUSY
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
First, answers to your questions:
The CIRQ bit in the STAT register is on if the CIRQ is enabled in the
IE register and clear when disabled in the IE. That is to say that
the IE register appears to be working.
Yes the card has no pending irqs.
IBG is set really early when the card is discovered. First interrupt
does not occur until much later when the libertas driver asks for
interrupts.
The lines have pull ups.
Ok. This all sounds fine. Thanks for testing/checking all this!
Now a thought.
Do we need to set DDIR in the CMD reg for CIRQ to work correctly?
Right now it is set at the beginning of data read commands, cleared on
data write commands and otherwise untouched. If DDIR is used
unconditionally to set the direction of the data line buffers then it
would make sense that we need to set the direction to in in order to
monitor the DAT1 line. I will try this Monday when I get back to
work.
Sounds like it's time to re-read TRM again.
If somebody has additionally ideas, this would be really helpful!
Madhu: Do you think it would be possible to check inside TI if
somebody has SDIO working on OMAP3 and maybe can provide some example
code?
Many thanks and best regards
Dirk
On Sat, Oct 17, 2009 at 12:30 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
Ok, in other words, this does mean that the card has no interrupt asserted
any more (i.e. it is acknowledged by upper layers, e.g. libertas driver),
but OMAP thinks there is still an interrupt. Right? This would mean it is an
OMAP/omap_hsmmc.c issue. Right?
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
Have you checked if
- IBG (and 4 bit mode) is correctly set before the first interrupt is fired
(just to make sure that we don't have a function calling order issue)?
- your HW design has a pull up on DAT1 line (as required by the SD physical
spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@vger.kernel.org; John Rigby; linux-omap@vger.kernel.org;
Steve Sakoman
Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan Chikkature wrote:
Hi Dirk,
I am inlining the patch so that it helps review.
...
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+ if (mmc_card_sdio(host-mmc-card)) {
I wish it could be moved to enable_sdio_irq so that we can avoid
inclusion of
card.h and checking the type of card in the host controller driver.
Yes, this would be the real clean way. But ...
But the
dependancy on 4-bit seems to be a problem here.
... most probably we have to find a workaround until (if ever?) above
clean implementation is available.
What we need is after SDIO mode and bus width is known, and before the
first interrupt comes, to set IBG.
On the problems being discussed on testing is the interrupt source
geting
cleared at the SDIO card level upon genaration of the CIRQ? If not it
remains
asserted.
Yes, this seems to be exactly the problem John reports in his follow
up mail.
Any hint how to clear SDIO interrupt?
On the controller side I guess it is cleared when you pass disable in
the
enable_sdio_irq fn. This happens when you call mmc_signal_sdio_irq.
I am not too sure about how it gets disabled from the card side. I see
that
SDIO core has a function sdio_release_irq which is used by the sdio
uart
driver. The usage of this could give a clue.
Regards,
Madhu
Many thanks
Dirk
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| IBG | FOUR_BIT);
+ } else {
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| FOUR_BIT);
+ }
break;
case MMC_BUS_WIDTH_1:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
@@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
return 0;
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 ie, ise;
+
+ ise = OMAP_HSMMC_READ(host-base, ISE);
+ ie = OMAP_HSMMC_READ(host
Re: MMC_CAP_SDIO_IRQ for omap 3430
Does anybody have access to omap_hsmmc driver of the SDK 1.0.2
kernel? Or has any hint where to get it from?
https://community.ti.com/forums/p/6290/23867.aspx#23873
talks about
For the SDIO solution, the SDK 1.0.2 kernel supports SDIO out of the
box ...
Thanks
Dirk
John Rigby wrote:
First, answers to your questions:
The CIRQ bit in the STAT register is on if the CIRQ is enabled in the
IE register and clear when disabled in the IE. That is to say that
the IE register appears to be working.
Yes the card has no pending irqs.
IBG is set really early when the card is discovered. First interrupt
does not occur until much later when the libertas driver asks for
interrupts.
The lines have pull ups.
Now a thought.
Do we need to set DDIR in the CMD reg for CIRQ to work correctly?
Right now it is set at the beginning of data read commands, cleared on
data write commands and otherwise untouched. If DDIR is used
unconditionally to set the direction of the data line buffers then it
would make sense that we need to set the direction to in in order to
monitor the DAT1 line. I will try this Monday when I get back to
work.
John
On Sat, Oct 17, 2009 at 12:30 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
Ok, in other words, this does mean that the card has no interrupt asserted
any more (i.e. it is acknowledged by upper layers, e.g. libertas driver),
but OMAP thinks there is still an interrupt. Right? This would mean it is an
OMAP/omap_hsmmc.c issue. Right?
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
Have you checked if
- IBG (and 4 bit mode) is correctly set before the first interrupt is fired
(just to make sure that we don't have a function calling order issue)?
- your HW design has a pull up on DAT1 line (as required by the SD physical
spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@vger.kernel.org; John Rigby; linux-omap@vger.kernel.org;
Steve Sakoman
Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan Chikkature wrote:
Hi Dirk,
I am inlining the patch so that it helps review.
...
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+ if (mmc_card_sdio(host-mmc-card)) {
I wish it could be moved to enable_sdio_irq so that we can avoid
inclusion of
card.h and checking the type of card in the host controller driver.
Yes, this would be the real clean way. But ...
But the
dependancy on 4-bit seems to be a problem here.
... most probably we have to find a workaround until (if ever?) above
clean implementation is available.
What we need is after SDIO mode and bus width is known, and before the
first interrupt comes, to set IBG.
On the problems being discussed on testing is the interrupt source
geting
cleared at the SDIO card level upon genaration of the CIRQ? If not it
remains
asserted.
Yes, this seems to be exactly the problem John reports in his follow
up mail.
Any hint how to clear SDIO interrupt?
On the controller side I guess it is cleared when you pass disable in
the
enable_sdio_irq fn. This happens when you call mmc_signal_sdio_irq.
I am not too sure about how it gets disabled from the card side. I see
that
SDIO core has a function sdio_release_irq which is used by the sdio
uart
driver. The usage of this could give a clue.
Regards,
Madhu
Many thanks
Dirk
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| IBG | FOUR_BIT);
+ } else {
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| FOUR_BIT);
+ }
break;
case MMC_BUS_WIDTH_1:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
@@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
return 0;
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 ie, ise;
+
+ ise = OMAP_HSMMC_READ(host-base, ISE);
+ ie = OMAP_HSMMC_READ(host-base, IE);
+
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches. Has anyone on this list implemented this
and/or can anyone point me to patches?
What a coincidence ;)
I'm currently working on this. See attachment what I currently have.
It is compile tested only against recent omap linux head. I don't have
a board using SDIO at the moment, so no real testing possible :(
Some background, maybe it helps people to step in:
Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by
MMC port 2 in 4 bit configuration [1]. The wifi performance is quite
bad (~100kB/s). There is some rumor that this might be SDIO irq
related [2]. There was an attempt to fix this [3] already, but this
doesn't work [4]. Having this, I started to look into it.
I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
Simplified Specification [6] and the OMAP35x TRM [7] as starting points.
Unfortunately, the Davinci MMC registers and irqs are different
(Davinci has a dedicated SDIO irq). But combining [3] and [5] helps to
get an idea what has to be done.
I think the main issues of [3] were that it doesn't enable IBG for 4
bit mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the
irq bits.
Topics I still open:
- Is it always necessary to deal with IE _and_ ISE register? I'm not
totally clear what the difference between these two registers are ;)
And in which order they have to be set.
- Davinci driver [5] in line 1115 checks for data line to call
mmc_signal_sdio_irq() for irq enable.
- Davinci driver deals with SDIO in xfer_done() (line 873)
- Davinci driver sets block size to 64 if SDIO in line 701
It would be quite nice if anybody likes to comment on attachment and
help testing.
Many thanks and best regards
Dirk
[1] http://gumstix.net/wiki/index.php?title=Overo_Wifi
[2] http://groups.google.com/group/beagleboard/msg/14e822778c5eeb56
[3] http://groups.google.com/group/beagleboard/msg/d0eb69f4c20673be
[4] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937
[5]
http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD
[6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/
[7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf
Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support
Form: Dirk Behme dirk.be...@googlemail.com
At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor
performance. Add support for SDIO interrupt handling.
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---
Patch against recent omap-linux head Linux omap got rebuilt from scratch
274c94b29ee7c53609a756acca974e4742c59559
Compile tested only. Please comment and help testing.
drivers/mmc/host/omap_hsmmc.c | 48 +-
1 file changed, 43 insertions(+), 5 deletions(-)
Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c
===
--- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-beagle/drivers/mmc/host/omap_hsmmc.c
@@ -27,6 +27,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/mmc/host.h
+#include linux/mmc/card.h
#include linux/mmc/core.h
#include linux/io.h
#include linux/semaphore.h
@@ -65,6 +66,7 @@
#define SDVSDET0x0400
#define AUTOIDLE 0x1
#define SDBP (1 8)
+#define IBG(1 19)
#define DTO0xe
#define ICE0x1
#define ICS0x2
@@ -76,6 +78,7 @@
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CIRQ_ENABLE(1 8)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -87,6 +90,7 @@
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 8)
#define ERR(1 15)
#define CMD_TIMEOUT(1 16)
#define DATA_TIMEOUT (1 20)
@@ -653,6 +657,15 @@ static irqreturn_t omap_hsmmc_irq(int ir
status = OMAP_HSMMC_READ(host-base, STAT);
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+ OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+ mmc_signal_sdio_irq(host-mmc);
+ spin_unlock(host-irq_lock);
+ return IRQ_HANDLED;
+ }
+
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break
Re: MMC_CAP_SDIO_IRQ for omap 3430
John, John Rigby wrote: Dirk, Many thanks, after sending the request yesterday I made my own attempt which failed miserably. My patch looks like a subset of yours so that is to be expected. I'll try yours out today and report back my experience. I got already some (private) feedback (thanks!): - Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null pointer :( Seems that mmc-card isn't set yet while calling omap_hsmmc_set_ios(). As workaround, for testing only, I hard coded setting IBG with something like case MMC_BUS_WIDTH_4: OMAP_HSMMC_WRITE(host-base, CON, con ~DW8); - OMAP_HSMMC_WRITE(host-base, HCTL, - OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT); + OMAP_HSMMC_WRITE(host-base, HCTL, +OMAP_HSMMC_READ(host-base, HCTL) | IBG | FOUR_BIT); break; If you test this, be careful that this doesn't hurt any other 4 bit cards except the SDIO you want to test. Later, we have to find a way how to detect that we are in SDIO mode. We want to set IBG only if in SDIO and 4 bit mode. - After this, I got the report that null pointer crash is gone. But SDIO doesn't seem to work any more: libertas_sdio: Libertas SDIO driver libertas_sdio: Copyright Pierre Ossman libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#1) libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#2) libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#3) libertas: command 0x0003 timed out libertas: Excessive timeouts submitting command 0x0003 libertas: PREP_CMD: command 0x0003 failed: -110 libertas_sdio: probe of mmc1:0001:1 failed with error -110 I now start to think about it ;) Again, any help would be appreciated! Best regards Dirk On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com wrote: John Rigby wrote: I have seen several discussions about lack of sdio irq support in the hsmmc driver but no patches. Has anyone on this list implemented this and/or can anyone point me to patches? What a coincidence ;) I'm currently working on this. See attachment what I currently have. It is compile tested only against recent omap linux head. I don't have a board using SDIO at the moment, so no real testing possible :( Some background, maybe it helps people to step in: Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by MMC port 2 in 4 bit configuration [1]. The wifi performance is quite bad (~100kB/s). There is some rumor that this might be SDIO irq related [2]. There was an attempt to fix this [3] already, but this doesn't work [4]. Having this, I started to look into it. I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO Simplified Specification [6] and the OMAP35x TRM [7] as starting points. Unfortunately, the Davinci MMC registers and irqs are different (Davinci has a dedicated SDIO irq). But combining [3] and [5] helps to get an idea what has to be done. I think the main issues of [3] were that it doesn't enable IBG for 4 bit mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the irq bits. Topics I still open: - Is it always necessary to deal with IE _and_ ISE register? I'm not totally clear what the difference between these two registers are ;) And in which order they have to be set. - Davinci driver [5] in line 1115 checks for data line to call mmc_signal_sdio_irq() for irq enable. - Davinci driver deals with SDIO in xfer_done() (line 873) - Davinci driver sets block size to 64 if SDIO in line 701 It would be quite nice if anybody likes to comment on attachment and help testing. Many thanks and best regards Dirk [1] http://gumstix.net/wiki/index.php?title=Overo_Wifi [2] http://groups.google.com/group/beagleboard/msg/14e822778c5eeb56 [3] http://groups.google.com/group/beagleboard/msg/d0eb69f4c20673be [4] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937 [5] http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD [6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/ [7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support Form: Dirk Behme dirk.be...@googlemail.com At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor performance. Add support for SDIO interrupt handling. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Patch against recent omap-linux head Linux omap got rebuilt from scratch 274c94b29ee7c53609a756acca974e4742c59559 Compile tested only. Please comment and help testing. drivers/mmc/host/omap_hsmmc.c | 48
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
Dirk,
Thanks for the update. After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.
On which board are you working? libertas does mean you are working on
wifi connected via SDIO?
The last thing i see is the firmware request
message.
Ok, you see a hang. Below we have a timeout.
I would vote for some interrupt issues. For timeouts I would vote for
missing interrupts, while system hang might be infinite interrupts
(something like this was reported in [1]).
Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace
if enable/disable is called in the correct order? And in
omap_hsmmc_irq() in if (status CIRQ) { to check if and how often it
is called?
Best regards
Dirk
[1] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937
On Fri, Oct 16, 2009 at 9:02 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John,
John Rigby wrote:
Dirk,
Many thanks, after sending the request yesterday I made my own attempt
which failed miserably. My patch looks like a subset of yours so that
is to be expected. I'll try yours out today and report back my
experience.
I got already some (private) feedback (thanks!):
- Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null
pointer :( Seems that mmc-card isn't set yet while calling
omap_hsmmc_set_ios().
As workaround, for testing only, I hard coded setting IBG with something
like
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL) |
IBG | FOUR_BIT);
break;
If you test this, be careful that this doesn't hurt any other 4 bit cards
except the SDIO you want to test.
Later, we have to find a way how to detect that we are in SDIO mode. We want
to set IBG only if in SDIO and 4 bit mode.
- After this, I got the report that null pointer crash is gone. But SDIO
doesn't seem to work any more:
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#1)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#2)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#3)
libertas: command 0x0003 timed out
libertas: Excessive timeouts submitting command 0x0003
libertas: PREP_CMD: command 0x0003 failed: -110
libertas_sdio: probe of mmc1:0001:1 failed with error -110
I now start to think about it ;)
Again, any help would be appreciated!
Best regards
Dirk
On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com
wrote:
John Rigby wrote:
I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches. Has anyone on this list implemented this
and/or can anyone point me to patches?
What a coincidence ;)
I'm currently working on this. See attachment what I currently have. It
is
compile tested only against recent omap linux head. I don't have a board
using SDIO at the moment, so no real testing possible :(
Some background, maybe it helps people to step in:
Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by MMC
port 2 in 4 bit configuration [1]. The wifi performance is quite bad
(~100kB/s). There is some rumor that this might be SDIO irq related [2].
There was an attempt to fix this [3] already, but this doesn't work [4].
Having this, I started to look into it.
I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
Simplified Specification [6] and the OMAP35x TRM [7] as starting points.
Unfortunately, the Davinci MMC registers and irqs are different (Davinci
has
a dedicated SDIO irq). But combining [3] and [5] helps to get an idea
what
has to be done.
I think the main issues of [3] were that it doesn't enable IBG for 4 bit
mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the irq
bits.
Topics I still open:
- Is it always necessary to deal with IE _and_ ISE register? I'm not
totally
clear what the difference between these two registers are ;) And in which
order they have to be set.
- Davinci driver [5] in line 1115 checks for data line to call
mmc_signal_sdio_irq() for irq enable.
- Davinci driver deals with SDIO in xfer_done() (line 873)
- Davinci driver sets block size to 64 if SDIO in line 701
It would be quite nice if anybody likes to comment on attachment and help
testing.
Many thanks and best regards
Dirk
[1] http://gumstix.net/wiki/index.php?title=Overo_Wifi
[2] http
Re: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan Chikkature wrote:
Hi Dirk,
I am inlining the patch so that it helps review.
...
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+ if (mmc_card_sdio(host-mmc-card)) {
I wish it could be moved to enable_sdio_irq so that we can avoid inclusion of
card.h and checking the type of card in the host controller driver.
Yes, this would be the real clean way. But ...
But the
dependancy on 4-bit seems to be a problem here.
... most probably we have to find a workaround until (if ever?) above
clean implementation is available.
What we need is after SDIO mode and bus width is known, and before the
first interrupt comes, to set IBG.
On the problems being discussed on testing is the interrupt source geting
cleared at the SDIO card level upon genaration of the CIRQ? If not it remains
asserted.
Yes, this seems to be exactly the problem John reports in his follow
up mail.
Any hint how to clear SDIO interrupt?
Many thanks
Dirk
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| IBG | FOUR_BIT);
+ } else {
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| FOUR_BIT);
+ }
break;
case MMC_BUS_WIDTH_1:
OMAP_HSMMC_WRITE(host-base, CON, con ~DW8);
@@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
return 0;
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 ie, ise;
+
+ ise = OMAP_HSMMC_READ(host-base, ISE);
+ ie = OMAP_HSMMC_READ(host-base, IE);
+
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE, ise | CIRQ_ENABLE);
+ OMAP_HSMMC_WRITE(host-base, IE, ie | CIRQ_ENABLE);
+ } else {
+ OMAP_HSMMC_WRITE(host-base, ISE, ise ~CIRQ_ENABLE);
+ OMAP_HSMMC_WRITE(host-base, IE, ie ~CIRQ_ENABLE);
+ }
+
+}
+
static const struct mmc_host_ops omap_hsmmc_ops = {
.enable = omap_hsmmc_enable_fclk,
.disable = omap_hsmmc_disable_fclk,
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hs
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
#ifdef CONFIG_DEBUG_FS
@@ -1734,7 +1772,7 @@ static int __init omap_hsmmc_probe(struc
mmc-max_seg_size = mmc-max_req_size;
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_WAIT_WHILE_BUSY;
+MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_SDIO_IRQ;
if (mmc_slot(host).wires = 8)
mmc-caps |= MMC_CAP_8_BIT_DATA;
John Rigby wrote:
I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches. Has anyone on this list implemented this
and/or can anyone point me to patches?
What a coincidence ;)
I'm currently working on this. See attachment what I currently have.
It is compile tested only against recent omap linux head. I don't have
a board using SDIO at the moment, so no real testing possible :(
Some background, maybe it helps people to step in:
Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by
MMC port 2 in 4 bit configuration [1]. The wifi performance is quite
bad (~100kB/s). There is some rumor that this might be SDIO irq
related [2]. There was an attempt to fix this [3] already, but this
doesn't work [4]. Having this, I started to look into it.
I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
Simplified Specification [6] and the OMAP35x TRM [7] as starting points.
Unfortunately, the Davinci MMC registers and irqs are different
(Davinci has a dedicated SDIO irq). But combining [3] and [5] helps to
get an idea what has to be done.
I think the main issues of [3] were that it doesn't enable IBG for 4
bit mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the
irq bits.
Topics I still open:
- Is it always necessary to deal with IE _and_ ISE register? I'm not
totally clear what the difference between these two
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
First the disclaimers:
The board is new board that has had hardware mmc/sdio problems before.
It is based closely on beagle but uses a different package which has
some package specific issues. We think we have found them all but who
knows.
My kernel is a few months old 2.6.29.
Then you can't apply my patch 1:1. Steve already found that there are
a lot of differences between recent git head and 2.6.31. A lot of
omap_hsmmc changes were done since 2.6.31.
Ok, given the above issues, it looks to me like I am getting
interrupted every time CIRQ is enabled.
Infinite interrupts. This is what I assumed :(
Nor sure if the libertas
driver is not disabling as it should or what.
I'm not sure if libertas has to do something with this.
So I end up in this
death spiral:
irq handler is called and status indicates CIRQ is pending
mmc_signal_sdio_irq is called which calls omap_hsmmc_enable_sdio_irq
with via mmc_host_ops, en is zero so CIRQ gets disabled
mmc_signal_sdio_irq then wakes up sdio_irq_thread which does its thing
then before going to sleep calls omap_hsmmc_enable_irq with en set to
1 so CIRC gets turned back on
Sounds ok. And thanks for giving the call stack. As mentioned, I did
only compile check ;)
with CIRC enabled the irq handler gets called and we are back where we started.
The issue then is not acknowledging the interrupt correctly. The TRM
(spruf98.c) tells us:
-- cut --
Card interrupt Enable
A clear of this bit also clears the corresponding status bit.
During 1-bit mode, if the interrupt routine does not remove the
source of a card interrupt in the SDIO card, the status bit is
reasserted when this bit is set to 1.
-- cut --
The clear card interrupt enable should be done by ~(CIRQ_ENABLE) in
+if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+ OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+ mmc_signal_sdio_irq(host-mmc);
+ spin_unlock(host-irq_lock);
+ return IRQ_HANDLED;
+}
Anybody sees anything wrong here? Maybe we missed something?
I assume that we are not in 1-bit mode. We should be in 4 bit mode. It
could be checked by some test code that we are in 4 bit mode and IBG
is set.
Additionally, what I wonder regarding this, is the davinci driver [1]
additionally checking for DAT1 level in enable_sdio_irq
1114 if (enable) {
1115 if (!((readl(host-base + DAVINCI_SDIOST0))
1116 SDIOST0_DAT1_HI)) {
1117 writel(SDIOIST_IOINT,
1118 host-base +
DAVINCI_SDIOIST);
1119 mmc_signal_sdio_irq(host-mmc);
1120 } else {
... enable int
1124 }
1125 } else {
... disable int
1129 }
And it does similar stuff in xfer_done
873 if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
874 if (host-sdio_int (!((readl(host-base +
DAVINCI_SDIOST0))
875 SDIOST0_DAT1_HI))) {
876 writel(SDIOIST_IOINT, host-base +
DAVINCI_SDIOIST);
877 mmc_signal_sdio_irq(host-mmc);
878 }
879 }
Most probably there is a reason for doing so?
Best regards
Dirk
[1]
http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD
Looks like either the libertas driver is not disabling the irq or the
CIRQ irq is somehow getting stuck or I have a hw problem.
One thing I did try was to have the sdio_irq_thread basically ignore
the MMC_CAP_SDIO_IRQ flag except for calling
host-ops-enable_sdio_irq(host, 1) and I changed mmc_signal_sdio_irq
to not reschedule sdio_irq_thread. In shows that the mere act of
enabling CIRQ does not break anything. In this mode I get one CIRQ
irq for each time around the sdio_irq_thread loop.
I guess I should try checking the CIRQ bit in the status register
after calling the libertas handler which should clear the irq?
John
On Fri, Oct 16, 2009 at 10:06 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
Dirk,
Thanks for the update. After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.
On which board are you working? libertas does mean you are working on wifi
connected via SDIO?
The last thing i see is the firmware request
message.
Ok, you see a hang. Below we have a timeout.
I would vote for some interrupt issues. For timeouts I would vote for
missing interrupts, while system hang might be infinite interrupts
(something like this was reported in [1]).
Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace if
enable/disable is called in the correct order
Re: X-loader / U-Boot query
Gary Thomas wrote: I have a new board - OMAP 3530 with 512MB DRAM NAND I've build X-loader and U-Boot for it and it mostly comes up. The sources I used (based on recommendations from the BeagleBoard pages) were: http://git.gitorious.org/x-load-omap3/mainline.git git://git.denx.de/u-boot.git I had to make a small change to get it to recognize the larger NAND FLASH device. The problem I have now is that it's only seeing 1/2 (256MB) of the available DRAM. * Does anyone know how to get it to see all 512MB? Not exactly on how to see all 512MB. But while we switched U-Boot Beagle to support 256MB instead of 128MB we did what is in http://git.mansr.com/?p=u-boot;a=shortlog;h=refs/heads/old Maybe the top ~10 commits from Mans there could help you. * Is there a better place to ask/discuss these questions? Yes. U-Boot list. It was already mentioned in this thread. Cheers Dirk -- 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: Gumstix Overo Low Power Standby?
Blazej Kot wrote: On May 20, 2009, at 1:55 PM, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: Blazej Kot bj...@cornell.edu writes: I have been working with the linux-pm kernel on the Gumstix Overo, seeing how low it's power consumption can go, both during the cpu on and especially while the CPU is suspended. Thus far, I've had some disappointing results, the best I could get is about 500mW while on, and 250mW while suspended (ie by running echo mem /sys/power/ state). I am led to believe that the OMAP processor is capable of much lower power consumption during standby. I am wondering if anybody in the gumstix community is looking into the software support for very-low-power modes on the overo. If so, I am wondering what the lowest power levels are which you have reached during standby are. I have seen this: http://markmail.org/message/ge5hec5f5asp7a67#query:omap%20linux %2080%20ma+page:1+mid:t2erlwweknakm767+state:results Which seems to indicate the lowest power reached is 80mA at 3.3V - 0.264 W, which is about what I'm seeing. Is it really true that the overo draws a quarter of a watt when doing absolutely nothing? There are lots of factors involved. The current OMAP PM branch is focused on minimizing power consumed by the OMAP SoC itself. However, there are lots of other things on-board (audio codecs, regulators, WiFi chipsets etc.) that can consume power that we may not be currently managing in the omap kernel. I don't have an Overo so am not familiar with all the on board peripherals, but you should probably do some experiments where you can put all the on-board devices into low-power/off states and run some experiments as well. In the case of the Beagle results you referenced, I'm pretty sure it is something on board that is drawing the ~80mA and not on-chip. I assume this because setting the OMAP to use OFF-mode in suspend or idle results in the drop of a few mA reflecting an expected drop in power consumed by OMAP itself, but still leaving lots of power consumed. For example, testing today's PM branch on Beagle gives me roughly the same numbers as the post you referenced, but slightly better: - boot idle: 323 mA - screen blank: 216 mA # echo 3 /sys/class/graphics/fb0/blank - suspend (OMAP retention): 75 mA # echo mem /sys/power/state - sleep-while-idle: 75 mA - this same power state as suspend, but happens in idle # echo 1 /sys/power/sleep_while_idle - suspend (OMAP off): 72 mA # echo 1 /sys/power/enable_off_mode # echo 1 /sys/power/voltage_off_while_idle Ultimitately the answer is that more work needs to be done with the using the regulator framework and/or the drivers for the on-chip peripherals to be sure they can be powered off when needed. After digging a little more in the beagle forums, someone has already done the work to confirm that it is indeed board level design and issues that are drawing the rest of the power on Beagle. There's a thread[1] in the beagleboard list about how to get down to 8mW power on Beagle, but it does require hardware changes. This should shed some light on the types of things you'd probably have to do for Overo. Kevin [1] http://groups.google.com/group/beagleboard/browse_thread/thread/197a8ef6b46cc828/6e98db4cbe2cebaa?# Thanks for that, it is an interesting link. I have now reached the new low of around 170mW (at 3.28V), but this is high. I basically used the TWL (PMC) scripts in the linked post, and also turned off the U6 chip on the gumstix, which is the USB PHY layer driver. Also, I noticed that my systems becomes unusable after suspending for more than abut a minute, and it will not wake from sleep. I will try to troubleshot and narrow this down. I think to remember there was some discussion about SDRAM self refresh. Look for thread OMAP3: PM: SDRC: ensure mux of SDRC clock enable pins for self-refresh and http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=4025cfbde3611b14c0d4831a5524e5e061128e30 Just guessing, though. Dirk I am wondering, is there anyone out there working on PM issues on the Gumstix? Perhaps if there are some gumstix company people here they can answer what their status is. I will ask around on the gumstix emailing list also. thanks, Blazej -- 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: Reading OMAP3 CONTROL_RAND_KEY_0 register hangs
Woodruff, Richard wrote: With OMAP3530 on BeagleBoard we like to read OMAP3's CONTROL_RAND_KEY_0 (0x4800 2318) register with something like printf (attempting cpu_uid read\n); u32 cpu_uid = *((u32 *) 0x48002318); /* u32 cpu_uid = readl(ctrl_base-randkey_0); */ printf (cpu_uid read done\n); This address is not accessible out side of secure mode along with some other qualifiers. Trying to access is futile and will result in an abort. The control register range is full of readable and aborting addresses. Is there any hint in TRM (spruf98b.pdf) identifying/marking which registers are readable in normal and which are only accessible in secure mode? Thanks Dirk -- 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: Old OMAP mailing list
Mark Brown wrote: Please don't CC any ASoC patches to the linux-omap-open-source list - my understanding is that it should no longer be used, having been replaced by [EMAIL PROTECTED] Any posts CCed to it result in backscatter like this: On Tue, Nov 18, 2008 at 07:57:55AM -0600, [EMAIL PROTECTED] wrote: You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at [EMAIL PROTECTED] which seems a bit hostile. It'd be nice if this bounce mentioned the new list, FWIW. We already tried several times to reach somebody with admin rights for old OMAP mailing list to change this, set list to e.g. read only, link new list at http://linux.omap.com/mailman/listinfo/linux-omap-open-source stop subscription system etc. Unfortunately without any luck :( Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Patch for proper Cortex-A8 cache configuration output
Recent ARM kernel doesn't detect and output Cortex-A8 cache configuration correctly. Result is something like this in kernel's boot messages: -- cut -- ... CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f ... CPU0: D VIPT write-through cache CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets ... -- cut -- Catalin sent a patch for this to linux-arm-kernel list: http://lists.arm.linux.org.uk/lurker/message/20080704.150532.983f01ca.en.html Result: -- cut -- ... CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3 CPU0: Level 1 cache is separate instruction and data CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, supports RA CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, supports RA WB WT CPU0: Level 2 cache is unified CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 sets, supports WA RA WB WT ... -- cut -- Some people really like this and this patch is used in some private trees, e.g. for BeagleBoard. Unfortunately, RMK doesn't like the patch. He prefers to completely remove 'broken' configuration output completely. What's about applying this patch locally to OMAP git until upstream ARM kernel has a fix/remove solution for this? Many thanks Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About to tag v2.6.26-omap1, patch queue deleted, please check and repost
Gadiyar, Anand wrote: Hi all, I've pushed all the patches I have in my omap inbox, except for the omap serial driver that I want to look more. I've tried to comment on the ones that did not get pushed, then erased everything from my omap inbox. Some drivers should get integrated via other mailing lists, and some debug patches can probably stay as debug patches, and some patches I probably have accidentally deleted :) And the PM patches I lost track of, so those should be reposted. So please check your patches, and repost your patches if something is left out. Also please check that things work for your board, let's try to tag v2.6.26-omap1 within next few days so we can move on again. Cheers, Tony Boot tested on 3430SDP with the defconfig. Things work okay so far. Same with BeagleBoard. Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3 v2] OMAP3 Beagle: Enable nand support
This series of patches adds NAND support to the BeagleBoard. The first patch in the series builds on work by Teerth Reddy [EMAIL PROTECTED] and Steve Sakoman [EMAIL PROTECTED] to extend the omap2 nand driver to work with both omap2 and omap3 architectures (as well as adding/clarifying comments). The second patch adds the beagle nand support, and the final patch enables the nand driver and jffs2 support in the beagle defconfig. The patch set was reviewed by Khasim Syed Mohammed [EMAIL PROTECTED] prior to this submission. It was tested on Rev A and B BeagleBoards. This v2 replaces http://marc.info/?l=linux-omapm=121230229625544w=2 Changes in v2: - Apply cleanly to recent git (defconfig, drivers/mtd/nand/omap2.c) - Beagle has only NAND. This results in small config. Move configuration to board-omap3beagle.c and don't create a new file board-omap3beagle-flash.c for it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3 v2] OMAP3 Beagle: add nand support
From: Steve Sakoman [EMAIL PROTECTED], Dirk Behme [EMAIL PROTECTED]
Add nand support to omap3beagle
Signed-off-by: Steve Sakoman [EMAIL PROTECTED]
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -20,11 +20,15 @@
#include linux/clk.h
#include linux/io.h
#include linux/leds.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
#include asm/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include asm/mach/flash.h
#include asm/arch/gpio.h
#include asm/arch/board.h
@@ -32,6 +36,64 @@
#include asm/arch/usb-ehci.h
#include asm/arch/hsmmc.h
#include asm/arch/common.h
+#include asm/arch/gpmc.h
+#include asm/arch/nand.h
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+static struct mtd_partition omap3beagle_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader,
+ .offset = 0,
+ .size = 4*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot Env,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1*(64 * 2048),
+ },
+ {
+ .name = Kernel,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32*(64 * 2048),
+ },
+ {
+ .name = File System,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data omap3beagle_nand_data = {
+ .parts = omap3beagle_nand_partitions,
+ .nr_parts = ARRAY_SIZE(omap3beagle_nand_partitions),
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .nand_setup = NULL,
+ .dev_ready = NULL,
+};
+
+static struct resource omap3beagle_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3beagle_nand_device = {
+ .name = omap2-nand,
+ .id = -1,
+ .dev= {
+ .platform_data = omap3beagle_nand_data,
+ },
+ .num_resources = 1,
+ .resource = omap3beagle_nand_resource,
+};
static struct omap_uart_config omap3_beagle_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
@@ -113,6 +175,44 @@ static struct platform_device *omap3_bea
leds_gpio,
};
+void __init omap3beagle_flash_init(void)
+{
+ u8 cs = 0;
+ u8 nandcs = GPMC_CS_NUM + 1;
+
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ /* find out the chip-select on which NAND exists */
+ while (cs GPMC_CS_NUM) {
+ u32 ret = 0;
+ ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ if ((ret 0xC00) == 0x800) {
+ printk(KERN_INFO Found NAND on CS%d\n, cs);
+ if (nandcs GPMC_CS_NUM)
+ nandcs = cs;
+ }
+ cs++;
+ }
+
+ if (nandcs GPMC_CS_NUM) {
+ printk(KERN_INFO NAND: Unable to find configuration
+in GPMC\n );
+ return;
+ }
+
+ if (nandcs GPMC_CS_NUM) {
+ omap3beagle_nand_data.cs = nandcs;
+ omap3beagle_nand_data.gpmc_cs_baseaddr = (void *)
+ (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
+ omap3beagle_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add);
+
+ printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
+ if (platform_device_register(omap3beagle_nand_device) 0)
+ printk(KERN_ERR Unable to register NAND device\n);
+ }
+}
+
static void __init omap3_beagle_init(void)
{
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
@@ -122,6 +222,7 @@ static void __init omap3_beagle_init(voi
hsmmc_init();
usb_musb_init();
usb_ehci_init();
+ omap3beagle_flash_init();
}
arch_initcall(omap3_beagle_i2c_init);
[PATCH 3/3 v2] OMAP3 Beagle: Enable nand and jffs2 support in defconfig
From: Steve Sakoman [EMAIL PROTECTED], Dirk Behme [EMAIL PROTECTED] Enable nand and jffs2 in defconfig Signed-off-by: Steve Sakoman [EMAIL PROTECTED] Signed-off-by: Dirk Behme [EMAIL PROTECTED] Index: linux-beagle/arch/arm/configs/omap3_beagle_defconfig === --- linux-beagle.orig/arch/arm/configs/omap3_beagle_defconfig +++ linux-beagle/arch/arm/configs/omap3_beagle_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.26-rc3-omap1 -# Tue May 27 22:23:14 2008 +# Linux kernel version: 2.6.26-rc8-omap1 +# Fri Jul 4 10:19:23 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -170,9 +170,9 @@ CONFIG_ARCH_OMAP3=y # # OMAP Feature Selections # -CONFIG_OMAP_DEBUG_SRAM_PATCH=y # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set +# CONFIG_OMAP_SMARTREFLEX is not set # CONFIG_OMAP_RESET_CLOCKS is not set CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y @@ -415,7 +415,83 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_CONCAT is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set +# CONFIG_MTD_AFS_PARTS is not set +# CONFIG_MTD_AR7_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set +# CONFIG_MTD_OOPS is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set +CONFIG_MTD_NAND=y +# CONFIG_MTD_NAND_VERIFY_WRITE is not set +# CONFIG_MTD_NAND_ECC_SMC is not set +# CONFIG_MTD_NAND_MUSEUM_IDS is not set +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_IDS=y +# CONFIG_MTD_NAND_DISKONCHIP is not set +# CONFIG_MTD_NAND_NANDSIM is not set +# CONFIG_MTD_NAND_PLATFORM is not set +# CONFIG_MTD_ALAUDA is not set +# CONFIG_MTD_ONENAND is not set + +# +# UBI - Unsorted block images +# +# CONFIG_MTD_UBI is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set @@ -791,6 +867,7 @@ CONFIG_USB_MUSB_LOGLEVEL=0 # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set +# CONFIG_USB_WDM is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' @@ -837,6 +914,7 @@ CONFIG_USB_MON=y # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set +# CONFIG_USB_ISIGHTFW is not set CONFIG_USB_GADGET=y # CONFIG_USB_GADGET_DEBUG is not set # CONFIG_USB_GADGET_DEBUG_FILES is not set @@ -873,6 +951,7 @@ CONFIG_MMC=y CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set # # MMC/SD Host Controller Drivers @@ -909,6 +988,7 @@ CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_DRV_M41T80 is not set CONFIG_RTC_DRV_TWL4030=y # CONFIG_RTC_DRV_S35390A is not set +# CONFIG_RTC_DRV_FM3130 is not set # # SPI RTC drivers @@ -1001,6 +1081,17 @@ CONFIG_TMPFS=y # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +# CONFIG_JFFS2_FS_WBUF_VERIFY is not set +# CONFIG_JFFS2_SUMMARY is not set +# CONFIG_JFFS2_FS_XATTR is not set +# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set +CONFIG_JFFS2_ZLIB=y +# CONFIG_JFFS2_LZO is not set +CONFIG_JFFS2_RTIME=y +# CONFIG_JFFS2_RUBIN is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set @@ -1235,6 +1326,8 @@ CONFIG_CRC_CCITT=y CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y
Re: Kernel hang on OMAP3 based Beagle board, RTC issue?
Koen Kooi wrote: Op 2 jul 2008, om 22:03 heeft Gadiyar, Anand het volgende geschreven: At Beagle IRC there was some discussion [1] [2] today about kernel hang on OMAP3 based Beagle board. I'll try to summarize discussion and Khasim's findings, maybe somebody here has an idea. Latest OMAP git kernel seems to hang on beagle board after some time. You don't see any crash, but after a while typing, anything doesn't work. SD stops as well, so you can only do stuff that's in ram, any IO will block. It can take 1 day to get there, but mostly it's ~30 minutes. Khasim found that it seems disabling RTC will remove the hang. When booting the git kernel after some time there are no timer or PRCM interrupts and the control resides in cpu_idle. We don't know where exactly the problem in RTC is, but while browsing the history of files related to RTC Khasim found that some changes were done to the files to handle T2 interrupts in a centralized way for USB, Battery and RTC. It seems even Battery broke with this patch set http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=68d7477caca19c0b52b5d4e85700cd3e6115577f May be this is the change that is affecting RTC. But it's unclear why it is affecting GP timer and PRCM interrupts. Any idea? Thanks and please correct if something is wrong in the summary Dirk Khasim also found that T2 RTC is not enabled by default in 3430sdp defconfig, but it appears to be enabled in the beagleboard defconfig. Maybe you can get by by simply disabling T2 RTC in menuconfig for now? Tried that and I get the same hang, so I don't think the RTC is to blame. Short update just in case anybody has an idea: Gadiyar spent some time with git-bisect (thanks!): It seems that the bad commit is probably between: # good: [3ffec4e18484c34838fa341de3848306c29ecd5d] 24XX: PM: Move pm.c to pm24xx.c and sleep.S to sleep24xx.S and # bad: [458776cfe389ff03bd6c56c47e059df0778cdfca] OMAP3430SDP: Enable config options CONFIG_OMAP_RESET_CLOCKS and CONFIG_SUSPEND This is a 9-patch series by Jouni Hogander related to suspend and power-management. Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
if nothing is connected to this connector. As internal OMAP3 pull up
resistors are not strong enough, enabled but unused I2C2 bus results
in error messages (e.g. I2C timeouts). I2C2 should be enabled only if
something is connected to I2C2 at board's expansion connector and this
extension has additional pull up resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- Ensure correct pin mux if I2C2 is enabled, independent of settings
done by bootloader
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Subject: ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
From: Dirk Behme [EMAIL PROTECTED]
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused if
nothing is connected to this connector. As internal OMAP3 pull up resistors
are not strong enough, enabled but unused I2C2 bus results in error messages
(e.g. I2C timeouts). I2C2 should be enabled only if something is connected to
I2C2 at board's expansion connector and this extension has additional pull up
resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- Ensure correct pin mux if I2C2 is enabled, independent of settings done
by bootloader.
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
---
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -40,7 +40,9 @@ static struct omap_uart_config omap3_bea
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, NULL, 0);
+#ifdef CONFIG_I2C2_OMAP_BEAGLE
omap_register_i2c_bus(2, 400, NULL, 0);
+#endif
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
}
Index: linux-beagle/arch/arm/mach-omap2/mux.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/mux.c
+++ linux-beagle/arch/arm/mach-omap2/mux.c
@@ -231,10 +231,12 @@ MUX_CFG_34XX(K21_34XX_I2C1_SCL, 0x1ba,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(J21_34XX_I2C1_SDA, 0x1bc,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+#ifdef CONFIG_I2C2_OMAP_BEAGLE
MUX_CFG_34XX(AF15_34XX_I2C2_SCL, 0x1be,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AE15_34XX_I2C2_SDA, 0x1c0,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+#endif
MUX_CFG_34XX(AF14_34XX_I2C3_SCL, 0x1c2,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AG14_34XX_I2C3_SDA, 0x1c4,
Index: linux-beagle/drivers/i2c/busses/Kconfig
===
--- linux-beagle.orig/drivers/i2c/busses/Kconfig
+++ linux-beagle/drivers/i2c/busses/Kconfig
@@ -332,10 +332,27 @@ config I2C_OMAP
default y if MACH_OMAP_H3 || MACH_OMAP_OSK
help
If you say yes to this option, support will be included for the
- I2C interface on the Texas Instruments OMAP1/2 family of processors.
- Like OMAP1510/1610/1710/5912 and OMAP242x.
+ I2C interface on the Texas Instruments OMAP1/2/3 family of
+ processors.
+ Like OMAP1510/1610/1710/5912, OMAP242x, OMAP34x and OMAP35x.
For details see http://www.ti.com/omap.
+config I2C2_OMAP_BEAGLE
+ bool Enable I2C2 for OMAP3 BeagleBoard
+ depends on ARCH_OMAP MACH_OMAP3_BEAGLE
+ select OMAP_MUX
+ default n
+ help
+ Say Y here if you want to enable I2C bus 2 at OMAP3 based
+ BeagleBoard.
+ I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
+ if nothing is connected to this connector. As internal OMAP3 pull up
+ resistors are not strong enough, enabled but unused I2C2 bus results
+ in error messages (e.g. I2C timeouts). Enable this only if you have
+ something connected to I2C2 at board's expansion connector and this
+ extension has additional pull up resistors for I2C2 bus.
+
+
config I2C_PARPORT
tristate Parallel port adapter
depends on PARPORT
Re: [PATCH] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
Jarkko Nikula wrote: On Fri, 04 Jul 2008 08:26:55 +0200 ext Dirk Behme [EMAIL PROTECTED] wrote: - Add configuration option for this - Use configuration option in board-omap3beagle - Ensure correct pin mux if I2C2 is enabled, independent of settings done by bootloader Why this CONFIG_I2C2_OMAP_BEAGLE in mux.c? Because bootloader, e.g. uboot, might have set other mux for these pins, e.g. GPIO168 and GPIO183. Then, if CONFIG_MUX is enabled but I2C2 isn't, don't touch the pin mux done by bootloader. But if I2C2 is enabled, make sure that the correct mux settings are done independent of bootloader. Do you think this is wrong? Thanks Dirk --- linux-beagle.orig/arch/arm/mach-omap2/mux.c +++ linux-beagle/arch/arm/mach-omap2/mux.c @@ -231,10 +231,12 @@ MUX_CFG_34XX(K21_34XX_I2C1_SCL, 0x1ba, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(J21_34XX_I2C1_SDA, 0x1bc, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) +#ifdef CONFIG_I2C2_OMAP_BEAGLE MUX_CFG_34XX(AF15_34XX_I2C2_SCL, 0x1be, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(AE15_34XX_I2C2_SDA, 0x1c0, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) +#endif MUX_CFG_34XX(AF14_34XX_I2C3_SCL, 0x1c2, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(AG14_34XX_I2C3_SDA, 0x1c4, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
if nothing is connected to this connector. As internal OMAP3 pull up
resistors are not strong enough, enabled but unused I2C2 bus results
in error messages (e.g. I2C timeouts). I2C2 should be enabled only if
something is connected to I2C2 at board's expansion connector and this
extension has additional pull up resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Subject: ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
From: Dirk Behme [EMAIL PROTECTED]
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused if
nothing is connected to this connector. As internal OMAP3 pull up resistors
are not strong enough, enabled but unused I2C2 bus results in error messages
(e.g. I2C timeouts). I2C2 should be enabled only if something is connected to
I2C2 at board's expansion connector and this extension has additional pull up
resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
---
Changes in v2: Incorporate Jarkko's comments. Pin mux is already done
depending on enabled busses in omap_i2c_mux_pins(int bus).
We don't have to do it manually here. Thanks!
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -40,7 +40,9 @@ static struct omap_uart_config omap3_bea
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, NULL, 0);
+#ifdef CONFIG_I2C2_OMAP_BEAGLE
omap_register_i2c_bus(2, 400, NULL, 0);
+#endif
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
}
Index: linux-beagle/drivers/i2c/busses/Kconfig
===
--- linux-beagle.orig/drivers/i2c/busses/Kconfig
+++ linux-beagle/drivers/i2c/busses/Kconfig
@@ -332,10 +332,27 @@ config I2C_OMAP
default y if MACH_OMAP_H3 || MACH_OMAP_OSK
help
If you say yes to this option, support will be included for the
- I2C interface on the Texas Instruments OMAP1/2 family of processors.
- Like OMAP1510/1610/1710/5912 and OMAP242x.
+ I2C interface on the Texas Instruments OMAP1/2/3 family of
+ processors.
+ Like OMAP1510/1610/1710/5912, OMAP242x, OMAP34x and OMAP35x.
For details see http://www.ti.com/omap.
+config I2C2_OMAP_BEAGLE
+ bool Enable I2C2 for OMAP3 BeagleBoard
+ depends on ARCH_OMAP MACH_OMAP3_BEAGLE
+ select OMAP_MUX
+ default n
+ help
+ Say Y here if you want to enable I2C bus 2 at OMAP3 based
+ BeagleBoard.
+ I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
+ if nothing is connected to this connector. As internal OMAP3 pull up
+ resistors are not strong enough, enabled but unused I2C2 bus results
+ in error messages (e.g. I2C timeouts). Enable this only if you have
+ something connected to I2C2 at board's expansion connector and this
+ extension has additional pull up resistors for I2C2 bus.
+
+
config I2C_PARPORT
tristate Parallel port adapter
depends on PARPORT
Kernel hang on OMAP3 based Beagle board, RTC issue?
At Beagle IRC there was some discussion [1] [2] today about kernel hang on OMAP3 based Beagle board. I'll try to summarize discussion and Khasim's findings, maybe somebody here has an idea. Latest OMAP git kernel seems to hang on beagle board after some time. You don't see any crash, but after a while typing, anything doesn't work. SD stops as well, so you can only do stuff that's in ram, any IO will block. It can take 1 day to get there, but mostly it's ~30 minutes. Khasim found that it seems disabling RTC will remove the hang. When booting the git kernel after some time there are no timer or PRCM interrupts and the control resides in cpu_idle. We don't know where exactly the problem in RTC is, but while browsing the history of files related to RTC Khasim found that some changes were done to the files to handle T2 interrupts in a centralized way for USB, Battery and RTC. It seems even Battery broke with this patch set http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=68d7477caca19c0b52b5d4e85700cd3e6115577f May be this is the change that is affecting RTC. But it's unclear why it is affecting GP timer and PRCM interrupts. Any idea? Thanks and please correct if something is wrong in the summary Dirk [1] http://www.beagleboard.org/irclogs/index.php?date=2008-07-02#T07:19:47 [2] http://www.beagleboard.org/irclogs/index.php?date=2008-07-02#T16:57:47 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: OMAP3: Fix warnings in clock34xx.h
Fix warnings arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes pointer from integer without a cast Signed-off-by: Dirk Behme [EMAIL PROTECTED] Subject: ARM: OMAP3: Fix warnings in clock34xx.h From: Dirk Behme [EMAIL PROTECTED] Fix warnings arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes pointer from integer without a cast Signed-off-by: Dirk Behme [EMAIL PROTECTED] --- Changes in V3: Update to recent git. Index: linux-beagle/arch/arm/mach-omap2/clock34xx.h === --- linux-beagle.orig/arch/arm/mach-omap2/clock34xx.h +++ linux-beagle/arch/arm/mach-omap2/clock34xx.h @@ -53,14 +53,17 @@ static int omap3_noncore_dpll_set_rate(s #define DPLL_LOW_POWER_BYPASS 0x5 #define DPLL_LOCKED0x7 +#define _OMAP34XX_PRM_REGADDR(module, reg) \ + ((__force void __iomem *)(OMAP34XX_PRM_REGADDR((module), (reg + #define OMAP3430_PRM_CLKSRC_CTRL \ - OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x0070) + _OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, OMAP3_PRM_CLKSRC_CTRL_OFFSET) #define OMAP3430_PRM_CLKSEL\ - OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET) + _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET) #define OMAP3430_PRM_CLKOUT_CTRL \ - OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET) + _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET) /* PRM CLOCKS */
Re: DSP BIOS Link support on OMAP3430
Anil S wrote: Hi, Is DSP/BIOS Link ported onto OMAP3430 (linux flavor), if yes from where can I download the sources/archive? I think there was some discussion about this yesterday at beagle IRC http://www.beagleboard.org/irclogs/index.php?date=2008-06-22 Maybe Koen or Philip have some more info about this. Cheers Dirk Btw, you used the wrong ml. [EMAIL PROTECTED] shouldn't be used any more. OMAP ML moved to http://vger.kernel.org/vger-lists.html#linux-omap Use linux-omap@vger.kernel.org instead. Looping it in. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP3: Fix warnings in clock34xx.h
Fix warnings
arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes
pointer from integer without a cast
arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes
pointer from integer without a cast
arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes
pointer from integer without a cast
arch/arm/mach-omap2/clock34xx.h:2238: warning: initialization makes
pointer from integer without a cast
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Subject: ARM: OMAP3: Fix warnings in clock34xx.h
From: Dirk Behme [EMAIL PROTECTED]
Fix warnings
arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes pointer from
integer without a cast
arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes pointer from
integer without a cast
arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes pointer from
integer without a cast
arch/arm/mach-omap2/clock34xx.h:2238: warning: initialization makes pointer
from integer without a cast
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
---
Changes in V2: Incorporating comments from Paul Walmsley. Thanks!
Index: linux-beagle/arch/arm/mach-omap2/clock34xx.h
===
--- linux-beagle.orig/arch/arm/mach-omap2/clock34xx.h
+++ linux-beagle/arch/arm/mach-omap2/clock34xx.h
@@ -53,14 +53,17 @@ static int omap3_noncore_dpll_set_rate(s
#define DPLL_LOW_POWER_BYPASS 0x5
#define DPLL_LOCKED0x7
+#define _OMAP34XX_PRM_REGADDR(module, reg) \
+ ((__force void __iomem *)(OMAP34XX_PRM_REGADDR((module), (reg
+
#define OMAP3430_PRM_CLKSRC_CTRL \
- OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x0070)
+ _OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, OMAP3_PRM_CLKSRC_CTRL_OFFSET)
#define OMAP3430_PRM_CLKSEL\
- OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET)
+ _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET)
#define OMAP3430_PRM_CLKOUT_CTRL \
- OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET)
+ _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET)
/* PRM CLOCKS */
@@ -2235,7 +2238,7 @@ static struct clk usbhost_sar_fck = {
.name = usbhost_sar_fck,
.parent = osc_sys_ck,
.init = omap2_init_clk_clkdm,
- .enable_reg = OMAP34XX_PRM_REGADDR(OMAP3430ES2_USBHOST_MOD,
PM_PWSTCTRL),
+ .enable_reg = _OMAP34XX_PRM_REGADDR(OMAP3430ES2_USBHOST_MOD,
PM_PWSTCTRL),
.enable_bit = OMAP3430ES2_SAVEANDRESTORE_SHIFT,
.flags = CLOCK_IN_OMAP3430ES2,
.clkdm_name = usbhost_clkdm,
Re: [PATCH] OMAP3 clock: fix omap2_clk_wait_ready for OMAP3430ES2 DSS
Paul Walmsley wrote:
On OMAP3430ES2, DSS has both an initiator standby CM_IDLEST bit, and a
target idle CM_IDLEST bit. This is a departure from previous silicon,
which only had an initiator standby bit.
This means we need to test the target idle bit after enabling
dss1_alwon_fclk. Previous clock code has done the wrong thing since ES2
came out: it's either tested the wrong bit, causing intermittent
Clock dss1_alwon_fck didn't enable in 10 tries
messages; or not tested anything at all, causing intermittent crashes
during DISPC initialization with:
Unhandled fault: external abort on non-linefetch (0x1028)
This patch modifies omap2_clk_wait_ready() to wait for the DSS to become
accessible after dss1_alwon_fclk is enabled.
Thanks to Anand Gadiyar [EMAIL PROTECTED] for identifying one of the
problem patches.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
Acked-by: Dirk Behme [EMAIL PROTECTED]
arch/arm/mach-omap2/clock.c | 30 --
arch/arm/mach-omap2/cm-regbits-34xx.h |4 +++-
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index ed15868..1820f75 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -244,18 +244,36 @@ static void omap2_clk_wait_ready(struct clk *clk)
}
/* REVISIT: What are the appropriate exclusions for 34XX? */
- /* OMAP3: ignore DSS-mod clocks */
- if (cpu_is_omap34xx()
- ((reg ~0xff) == (__force
u32)OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, 0) ||
-(((reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(CORE_MOD, 0))
- clk-enable_bit == OMAP3430_EN_SSI_SHIFT)))
- return;
+ if (cpu_is_omap34xx()) {
+
+ /* 3430ES1 DSS and SSI have no target idlest bits */
+ if (is_sil_rev_equal_to(OMAP3430_REV_ES1_0)
+ ((reg ~0xff) == (__force
u32)OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, 0) ||
+((reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(CORE_MOD, 0)
+ clk-enable_bit == OMAP3430_EN_SSI_SHIFT)))
+ return;
+
+ /* Even for 3430ES2 DSS, only wait for dss1_alwon_fclk */
+ if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)
+ (reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD,
0)
+ clk-enable_bit != OMAP3430_EN_DSS1_SHIFT)
+ return;
+
+ }
/* Check if both functional and interface clocks
* are running. */
bit = 1 clk-enable_bit;
if (!(__raw_readl((__force void __iomem *)other_reg) bit))
return;
+
+ /* OMAP3430ES2 DSS is an unusual case */
+ if (cpu_is_omap34xx()
+ (reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, 0)
+ clk-enable_bit == OMAP3430_EN_DSS1_SHIFT) {
+ bit = OMAP3430ES2_ST_DSS_IDLE;
+ }
+
st_reg = ((other_reg ~0xf0) | 0x20); /* CM_IDLEST* */
omap2_wait_clock_ready((__force void __iomem *)st_reg, bit, clk-name);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6ec66f4..946c552 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -500,7 +500,9 @@
#define OMAP3430_CM_ICLKEN_DSS_EN_DSS_SHIFT0
/* CM_IDLEST_DSS */
-#define OMAP3430_ST_DSS(1 0)
+#define OMAP3430ES2_ST_DSS_IDLE(1 1)
+#define OMAP3430ES2_ST_DSS_STDBY (1 0)
+#define OMAP3430ES1_ST_DSS (1 0)
/* CM_AUTOIDLE_DSS */
#define OMAP3430_AUTO_DSS (1 0)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Fix warnings in clock34xx.h
Fix warnings
arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes
pointer from integer without a cast
arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes
pointer from integer without a cast
arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes
pointer from integer without a cast
arch/arm/mach-omap2/clock34xx.h:2238: warning: initialization makes
pointer from integer without a cast
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Subject: ARM: OMAP3: Fix warnings in clock34xx.h
From: Dirk Behme [EMAIL PROTECTED]
Fix warnings
arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes pointer from
integer without a cast
arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes pointer from
integer without a cast
arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes pointer from
integer without a cast
arch/arm/mach-omap2/clock34xx.h:2238: warning: initialization makes pointer
from integer without a cast
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
---
Index: linux-beagle/arch/arm/mach-omap2/clock34xx.h
===
--- linux-beagle.orig/arch/arm/mach-omap2/clock34xx.h
+++ linux-beagle/arch/arm/mach-omap2/clock34xx.h
@@ -53,14 +53,20 @@ static int omap3_noncore_dpll_set_rate(s
#define DPLL_LOW_POWER_BYPASS 0x5
#define DPLL_LOCKED0x7
+#define _OMAP34XX_PRM_REGADDR(module, reg) \
+ ((__force void __iomem *)(OMAP34XX_PRM_REGADDR((module), (reg
+
#define OMAP3430_PRM_CLKSRC_CTRL \
- OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x0070)
+ _OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x0070)
#define OMAP3430_PRM_CLKSEL\
- OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET)
+ _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET)
#define OMAP3430_PRM_CLKOUT_CTRL \
- OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET)
+ _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET)
+
+#define OMAP3430_USBHOST_MOD \
+ _OMAP34XX_PRM_REGADDR(OMAP3430ES2_USBHOST_MOD, PM_PWSTCTRL)
/* PRM CLOCKS */
@@ -2235,7 +2241,7 @@ static struct clk usbhost_sar_fck = {
.name = usbhost_sar_fck,
.parent = osc_sys_ck,
.init = omap2_init_clk_clkdm,
- .enable_reg = OMAP34XX_PRM_REGADDR(OMAP3430ES2_USBHOST_MOD,
PM_PWSTCTRL),
+ .enable_reg = OMAP3430_USBHOST_MOD,
.enable_bit = OMAP3430ES2_SAVEANDRESTORE_SHIFT,
.flags = CLOCK_IN_OMAP3430ES2,
.clkdm_name = usbhost_clkdm,
Re: Boot failure on OMAP 3430 SDP
Gadiyar, Anand wrote: Hi all, Commit 5b36d70fa08f09de161487fe7f6e04200ffb8d71 breaks boot on OMAP3430 SDP. Reversing the patch allows the boot to work. Bootlog and the patch are shown below. Regards, Anand commit 5b36d70fa08f09de161487fe7f6e04200ffb8d71 Author: Jouni Hogander [EMAIL PROTECTED] Date: Mon Jun 9 12:32:40 2008 +0300 PRCM: OMAP3: Fix to wrongly modified omap2_clk_wait_ready omap2_clk_wait_ready was wrongly modified to check registers contents. This fix changes it back to check addresses. Signed-off-by: Jouni Hogander [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Signed-off-by: Tony Lindgren [EMAIL PROTECTED] diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c index d3ab537..ed15868 100644 --- a/arch/arm/mach-omap2/clock.c +++ b/arch/arm/mach-omap2/clock.c @@ -246,8 +246,8 @@ static void omap2_clk_wait_ready(struct clk *clk) /* REVISIT: What are the appropriate exclusions for 34XX? */ /* OMAP3: ignore DSS-mod clocks */ if (cpu_is_omap34xx() - ((reg ~0xff) == cm_read_mod_reg(OMAP3430_DSS_MOD, 0) || -(((reg ~0xff) == cm_read_mod_reg(CORE_MOD, 0)) + ((reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, 0) || +(((reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(CORE_MOD, 0)) clk- enable_bit == OMAP3430_EN_SSI_SHIFT))) return; Hmm, looking at recent git, we already have OMAP34XX_CM_REGADDR instead of cm_read_mod_reg there http://source.mvista.com/git/?p=linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/clock.c;h=ed1586847db4dd95cff8016e4259b533f1582737;hb=HEAD and it seems that this patch is already applied http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=5b36d70fa08f09de161487fe7f6e04200ffb8d71 ? *BUT*: I still see below Unhandled fault at OMAP3 based Beagle board! Any idea? Oops. Sorry for this confusion. The patch inlined in the mail was the commit that causes the boot failure - not the fix. I would rather have Jouni and Paul look at the commit. I haven't looked too deeply at the patch to see why it causes the crash. Until this is fixed, you might just want to apply the patch in reverse. Ah, yes, sorry for my misunderstanding! And many thanks for finding the cause of this issue. Hopefully we will have a fix for this soon now. Sorry and thanks Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mach-omap2/powerdomain.c: convert rwsem to rwlock
Paul Walmsley wrote:
The generic rwsem implementation of down_read() and down_write() does not
save and restore interrupt state. This causes powerdomain code to
inadvertently enable interrupts early in the boot process, causing
init/main.c to complain. This patch converts powerdomain locking to
r-w spinlocks instead.
I'm also curious to know if this fixes the BeagleBoard boot problem.
Yes! :)
Git head is now working on Beagle again.
Many thanks
Dirk
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mach-omap2/powerdomain.c | 46 ++---
1 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 939efe4..0a6caaf 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -18,7 +18,7 @@
#include linux/module.h
#include linux/types.h
#include linux/delay.h
-#include linux/rwsem.h
+#include linux/spinlock.h
#include linux/list.h
#include linux/errno.h
#include linux/err.h
@@ -38,10 +38,10 @@
static LIST_HEAD(pwrdm_list);
/*
- * pwrdm_rwsem protects pwrdm_list add and del ops - also reused to
+ * pwrdm_rwlock protects pwrdm_list add and del ops - also reused to
* protect pwrdm_clkdms[] during clkdm add/del ops
*/
-static DECLARE_RWSEM(pwrdm_rwsem);
+static DEFINE_RWLOCK(pwrdm_rwlock);
/* Private functions */
@@ -131,6 +131,7 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
*/
int pwrdm_register(struct powerdomain *pwrdm)
{
+ unsigned long flags;
int ret = -EINVAL;
if (!pwrdm)
@@ -139,7 +140,7 @@ int pwrdm_register(struct powerdomain *pwrdm)
if (!omap_chip_is(pwrdm-omap_chip))
return -EINVAL;
- down_write(pwrdm_rwsem);
+ write_lock_irqsave(pwrdm_rwlock, flags);
if (_pwrdm_lookup(pwrdm-name)) {
ret = -EEXIST;
goto pr_unlock;
@@ -151,7 +152,7 @@ int pwrdm_register(struct powerdomain *pwrdm)
ret = 0;
pr_unlock:
- up_write(pwrdm_rwsem);
+ write_unlock_irqrestore(pwrdm_rwlock, flags);
return ret;
}
@@ -165,12 +166,14 @@ pr_unlock:
*/
int pwrdm_unregister(struct powerdomain *pwrdm)
{
+ unsigned long flags;
+
if (!pwrdm)
return -EINVAL;
- down_write(pwrdm_rwsem);
+ write_lock_irqsave(pwrdm_rwlock, flags);
list_del(pwrdm-node);
- up_write(pwrdm_rwsem);
+ write_unlock_irqrestore(pwrdm_rwlock, flags);
pr_debug(powerdomain: unregistered %s\n, pwrdm-name);
@@ -187,13 +190,14 @@ int pwrdm_unregister(struct powerdomain *pwrdm)
struct powerdomain *pwrdm_lookup(const char *name)
{
struct powerdomain *pwrdm;
+ unsigned long flags;
if (!name)
return NULL;
- down_read(pwrdm_rwsem);
+ read_lock_irqsave(pwrdm_rwlock, flags);
pwrdm = _pwrdm_lookup(name);
- up_read(pwrdm_rwsem);
+ read_unlock_irqrestore(pwrdm_rwlock, flags);
return pwrdm;
}
@@ -204,7 +208,7 @@ struct powerdomain *pwrdm_lookup(const char *name)
*
* Call the supplied function for each registered powerdomain. The
* callback function can return anything but 0 to bail out early from
- * the iterator. The callback function is called with the pwrdm_rwsem
+ * the iterator. The callback function is called with the pwrdm_rwlock
* held for reading, so no powerdomain structure manipulation
* functions should be called from the callback, although hardware
* powerdomain control functions are fine. Returns the last return
@@ -215,18 +219,19 @@ struct powerdomain *pwrdm_lookup(const char *name)
int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm))
{
struct powerdomain *temp_pwrdm;
+ unsigned long flags;
int ret = 0;
if (!fn)
return -EINVAL;
- down_read(pwrdm_rwsem);
+ read_lock_irqsave(pwrdm_rwlock, flags);
list_for_each_entry(temp_pwrdm, pwrdm_list, node) {
ret = (*fn)(temp_pwrdm);
if (ret)
break;
}
- up_read(pwrdm_rwsem);
+ read_unlock_irqrestore(pwrdm_rwlock, flags);
return ret;
}
@@ -243,6 +248,7 @@ int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm))
*/
int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm)
{
+ unsigned long flags;
int i;
int ret = -EINVAL;
@@ -252,7 +258,7 @@ int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm)
pr_debug(powerdomain: associating clockdomain %s with powerdomain
%s\n, clkdm-name, pwrdm-name);
- down_write(pwrdm_rwsem);
+ write_lock_irqsave(pwrdm_rwlock, flags);
for (i = 0; i PWRDM_MAX_CLKDMS; i++) {
if (!pwrdm-pwrdm_clkdms[i])
@@ -278,7 +284,7 @@ int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct
clockdomain *clkdm)
ret = 0;
pac_exit:
- up_write(pwrdm_rwsem);
+
Re: Recent OMAP git broken on Beagle
Paul Walmsley wrote: Hello Dirk, On Sat, 10 May 2008, Dirk Behme wrote: -- cut -- git bisect bad 757f0b4ad6b0fd4377c2ee512fc595b5778aa3ac is first bad commit commit 757f0b4ad6b0fd4377c2ee512fc595b5778aa3ac Author: Paul Walmsley [EMAIL PROTECTED] Date: Fri May 9 14:45:24 2008 -0700 powerdomain: convert pwrdm_mutex to rwsem Curious, this boots fine on 3430sdp, and there's nothing in that patch that should affect Beagle in particular. Could you try building cdda2a9adbc5421f4857e0313afc6c189f422e25 and see if that also breaks? Hmm, I think cdda2a9a... was the first one working for me: http://marc.info/?l=linux-omapm=121040218707239w=2 I started with git bisect good cdda2a9a... If you like, I can recheck again. But would be better if anybody else could confirm this, just in case I missed anything. Hint, hint ;) Of the recent OMAP-specific patches, that's the one that I would suspect. And if that also breaks, maybe try the one before it, 352b2e24c5cd193a40ae376fec85665f2660aeb1 ? In a private mail I got: -- cut -- To add another data point: on the OMAP3 EVM warm boots fail as described, but cold boots complete successfully. -- cut -- Unfortunately, he couldn't confirm which commit is failing for him yet. On Beagle we currently boot using bootrom starting from MMC. Like with TWL, it seems that the pre-initialization by bootrom has some influence on kernel behaviour. Thanks Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
Brian Swetland wrote: [Tony Lindgren [EMAIL PROTECTED]] I've merged Jarkko's asoc patch to linux-omap for testing. Have not gotten any sound out of it on my n810 though.. Maybe some alsamixer settings issue? Kalle, do you have any tips on getting WLAN to work on n8x0? This was the show-stopper for me. When I last got things hobbling along on n8x0, the binary-only wlan module was incompatible with newer kernels than 2.6.21 (changes in some network data structures). The newer android builds expect 2.6.24 or more recent. I'm hoping that Nokia will release a newer build of the wlan module for 2.6.24 at some point. That'd be a big motivator for me to spend time hacking on the platform again. Have a look to the section -- cut -- ... In the end I think what would be realistically possible ... is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. ... -- cut -- of http://lists.maemo.org/pipermail//maemo-developers/2008-May/017556.html Maybe you as community should ask for updates on maemo-developers list? Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: OMAP3: Check for L2 cache enabled
Enabling L2 cache of Cortex-A8 based OMAP3 has to be done by
bootloader. Check if this is done and warn if not.
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Changes in v3: Remove braces. Thanks to Felipe for review!
Index: linux-beagle/arch/arm/mach-omap2/id.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/id.c
+++ linux-beagle/arch/arm/mach-omap2/id.c
@@ -267,3 +267,25 @@ void __init omap2_check_revision(void)
}
+#ifdef CONFIG_ARCH_OMAP3
+/*
+ * OMAP3 has L2 cache which has to be enabled by bootloader.
+ */
+static int __init omap3_check_l2cache(void)
+{
+ u32 val;
+
+ /* Get CP15 AUX register, bit 1 enabled indicates L2 cache is on */
+ asm volatile(mrc p15, 0, %0, c1, c0, 1:=r (val));
+
+ if ((val 0x2) == 0)
+ printk(KERN_WARNING Warning: L2 cache not enabled. Check
+ your bootloader. L2 off results in performance loss\n);
+ else
+ pr_info(OMAP3 L2 cache enabled\n);
+
+ return 0;
+}
+
+arch_initcall(omap3_check_l2cache);
+#endif /* CONFIG_ARCH_OMAP3 */
Recent OMAP git broken on Beagle
I tried latest OMAP git (2.6.26-rc1-omap1, git from today, HEAD == 42fa072e237427675752bb9da05bf406bff19719, OMAP3 EVM: enable ethernet support) on OMAP3 based BeagleBoard and it immediately stops after output of Kernel command line (with CONFIG_DEBUG_LL enabled): ... Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 5Kernel command line: console=ttyS2,115200n8 ... No later output or crash, nothing. On an older 2.6.25-omap1 kernel next output is ... Kernel command line: console=ttyS2,115200n8 ... Clocking rate (Crystal/DPLL/ARM core): 26.0/266/381 MHz GPMC revision 5.0 ... Assuming that it might be related to recent clock or powerdomain changes [1] I switched back to HEAD == Fix remaining sparse warnings in arch/arm/mach-omap2 (git-checkout cdda2a9adbc5421f4857e0313afc6c189f422e25) and system now boots again. Any idea? Many thanks Dirk [1] http://source.mvista.com/git/?p=linux-omap-2.6.git;a=summary -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Check for L2 cache enabled
Enabling L2 cache of Cortex-A8 based OMAP3 has to be done by
bootloader. Check if this is done and warn if not.
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Index: linux-beagle/arch/arm/mach-omap2/id.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/id.c
+++ linux-beagle/arch/arm/mach-omap2/id.c
@@ -267,3 +267,26 @@ void __init omap2_check_revision(void)
}
+#ifdef CONFIG_ARCH_OMAP3
+/*
+ * OMAP3 has L2 cache which has to be enabled by bootloader.
+ */
+static int __init omap3_check_l2cache(void)
+{
+ u32 val;
+
+ /* Get CP15 AUX register, bit 1 enabled indicates L2 cache is on */
+ asm volatile(mrc p15, 0, %0, c1, c0, 1:=r (val));
+
+ if ((val 0x2) == 0) {
+ printk(KERN_WARNING Warning: L2 cache not enabled. Check
+ your bootloader. L2 off results in performance loss\n);
+ } else {
+ pr_info(OMAP3 L2 cache enabled);
+ }
+
+ return 0;
+}
+
+arch_initcall(omap3_check_l2cache_on);
+#endif /* CONFIG_ARCH_OMAP3 */
Re: public git l2 cache off.
Richard, Woodruff, Richard wrote: Beagleboard (omap3530) I'll try the latest from here on SDP with this and see if it works. There is also a difference in CR handling. I had submitted long back a fix to Russell but let it get by me as I didn't have the time to fix per his comments. I think our version was more correct then the one in place but was still lacking a bit. [*] It seems possible you could have an issue depending on what your boot loader is or isn't doing for you. U-boot (both 1.1.4 and 1.3.2) calls l2disable() before booting linux, so linux needs to enable it. I vote for removing the l2disable() in u- boot, but I can see that people might be stuck with broken binary bootloaders... Yes, this 'might' help for some users if it works. Traditionally things usually have had some complications here at multiple levels in both hardware and software. And yes not everyone can upgrade a boot loader. However, with expanding boot from MMC/SD support things are getting safer. The bit I was more worried about was the boot loader may not be invalidating secure L2 tags correctly. The method to do this correctly is a little different between EMU/HS and GP devices. Also these base methods changed some between ES1 and ES2 of the chip. I hope no one is using an ES1 anymore but I'm sure code remnants exist. The working code variants did some work in u-boot and some in the kernel to handle these conditions. The current balance today in working variants today has u-boot doing more work. This probably merges with fewer conflicts with the arm-kernel. Last I checked u-boot on Beagle was a based on an older version of the code and probably even a wider range of versions exist in the community. As such it's a good bet some of this is at the root of the problems you are seeing. On Beagle, we use ES2 GP device. From discussion on ARM kernel list [1] we learned that it's the job of bootloader to initialize L2 cache correctly. Thanks to Khasim we have a patch to enable L2 cache in kernel [2], but this is only to work around broken bootloaders. So, we need fixed bootloader (e.g. U-Boot) doing L2 cache initialization correctly. Currently, in U-Boot used for Beagle we have the following (L2) cache handling (cleaned up for easier reading). Do you think this is correct? Can we simply add a l2cache_enable() at the end of following code or do we have to do/fix/change more to pass correctly configured caches from U-Boot to kernel? -- cut -- At U-Boot start: l2cache_enable() for CPU_3430_ES2: __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r (i)); __asm__ __volatile__(orr %0, %0, #0x2:=r(i)); __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r (i)); ... do U-Boot work ... then just before kernel is called: cleanup_before_linux(): /* turn off I/D-cache */ asm (mrc p15, 0, %0, c1, c0, 0:=r (i)); i = ~(C1_DC | C1_IC); asm (mcr p15, 0, %0, c1, c0, 0: :r (i)); /* invalidate I-cache */ mcr p15, 0, r1, c7, c5, 0 @ invalidate I cache /* turn off L2 cache */ __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r (i)); __asm__ __volatile__(bic %0, %0, #0x2:=r(i)); __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r (i)); /* invalidate L2 cache also */ v7_flush_dcache_all(get_device_type()): mov r7, r0 @ take a backup of device type cmp r0, #0x3@ check if the device type is GP moveq r12, #0x1 @ set up to invalide L2 smi:.word 0x01600070@ Call SMI monitor (smieq) cmp r7, #0x3@ compare again in case its lost beq finished_inval @ if GP device, inval done above mrc p15, 1, r0, c0, c0, 1 @ read clidr andsr3, r0, #0x700 @ extract loc from clidr mov r3, r3, lsr #23 @ left align loc bit field beq finished_inval @ if loc is 0, then no need to clean mov r10, #0 @ start clean at cache level 0 inval_loop1: add r2, r10, r10, lsr #1@ work out 3x current cache level mov r1, r0, lsr r2 @ extract cache type bits from clidr and r1, r1, #7 @ mask of the bits for current cache only cmp r1, #2 @ see what cache we have at this level blt skip_inval @ skip if no cache, or just i-cache mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr isb @ isb to sych the new cssrcsidr mrc p15, 1, r1, c0, c0, 0 @ read the new csidr and r2, r1, #7 @ extract the length of the cache lines add r2, r2, #4 @ add 4 (line length offset) ldr r4, =0x3ff
Re: [beagleboard] Re: TWL4030 intermittent freakout on boot
Tony Lindgren wrote: * Koen Kooi [EMAIL PROTECTED] [080508 11:22]: Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven: Hello everyone, occasionally the TWL4030 driver on the 3430SDP freaks out on boot. (This is either an ES2.0 or ES2.1, not sure.) Here's a partial console log with initcall debugging enabled. This probably happens every thirty or forty boots, I would guess. The board does boot to userspace when this happens. Perhaps the TWL4030 experts out there might know what's going on? 3i2c_omap i2c_omap.1: controller timed out 3i2c_omap i2c_omap.1: controller timed out 3twl4030_usb: i2c write failed, line 422 Looks suspiciously like the symptons in http://code.google.com/p/beagleboard/issues/detail?id=14 This also looks similar to the earlier twl4030 hangs where access to some domains caused twl4030 to hang. If twl4030 hangs, there's no way to reset it as all control is over I2C. When twl4030 hangs, bootloader won't be able to detect the chip either unless devices is power cycled (and USB cable detached). The reason earlier was that twl4030 internal clock was not being programmed properly, and was fixed by patch 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d. Link for this is http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d I don't know OMAP3 good enough yet, but which clock should we use on OMAP3 here? Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too? E.g something like ... if (cpu_is_omap2430() || cpu_is_omap34xx()) osc = clk_get(NULL, osc_ck); else osc = clk_get(NULL, osc_sys_ck); ... Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: public git l2 cache off.
Woodruff, Richard wrote: Enabling L2 cache was removed from proc-v7.S since was cortex specific instead of armv7 specific and u-boot explicitly turns of L2 before booting into linux. I made a reverse patch, but my omap3 board doesn't boot if I use it: Our 2.6.24 kernel does something close and boots fine on OMAP3-SDP and Labrador boards. Which platform did you try on? I think we are talking about BeagleBoard here. Dirk I'll try the latest from here on SDP with this and see if it works. There is also a difference in CR handling. I had submitted long back a fix to Russell but let it get by me as I didn't have the time to fix per his comments. I think our version was more correct then the one in place but was still lacking a bit. [*] It seems possible you could have an issue depending on what your boot loader is or isn't doing for you. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
Jonathan Herriott wrote:
I had it confirmed in another thread
Any pointer to this thread?
Thanks
Dirk
that the issue is that the local
filesystem for the N810 is jffs, which is unsupported and I need to
install it on an mini SD card with ext2/ext3 on it.
On 4/26/08, Dirk Behme [EMAIL PROTECTED] wrote:
Jonathan Herriott wrote:
I'm using vanilla Kernel 2.6.21.0 with the patch from
http://android-on-n8xx.googlecode.com/files/linux-2.6.21_rx-34_android-m5-rc14.bz2.
I was told in another thread that I need to use the m3 userspace
files, but when trying to use those, I have the same issue.
I'm assuming you want the strace when running init:
\h:\w\$ strace -f -ff -tt -s 200 /init
04:02:38.896362 execve(/init, [/init], [/* 59 vars */]) = 0
04:02:38.909790 gettid()= 1464
04:02:38.912689 syscall_983045(0xbea0d614, 0, 0x20, 0, 0xbe9ee000,
0xbea0d6d0, 0xbea0d720, 0xf0005, 0xbea0d720, 0, 0x80b8, 0x80b4, 0,
0xbea0d608, 0x17c77, 0x17f2c, 0x6010, 0xbea0d614, 0, 0, 0xc764, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
04:02:38.916168 socket(PF_FILE, SOCK_STREAM, 0) = 3
04:02:38.919250 connect(3, {sa_family=AF_FILE,
[EMAIL PROTECTED], 19) = -1 ECONNREFUSED (Connection refused)
04:02:38.923248 close(3)= 0
04:02:38.926208 sigaction(SIGCHLD, {0x8211, [], SA_NOCLDSTOP}, NULL,
0xc0fb8) = 0
04:02:38.929718 umask(0)= 022
04:02:38.932373 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost
isig icanon echo ...}) = 0
04:02:38.936523 dup(1) = 3
04:02:38.939422 write(3, init: HOW ARE YOU GENTLEMEN\n, 28init: HOW
ARE YOU GENTLEMEN
) = 28
04:02:38.943328 close(0)= 0
04:02:38.945983 close(1)= 0
04:02:38.948577 close(2)= 0
04:02:38.951202 open(/dev/null, O_RDWR|O_LARGEFILE) = 0
04:02:38.954345 dup2(0, 1) = 1
04:02:38.956939 dup2(0, 2) = 2
04:02:38.959625 write(3, init: reading config file\n, 26init:
reading config file
) = 26
04:02:38.963592 brk(0) = 0x2
04:02:38.966217 brk(0x2)= 0x2
04:02:38.968994 brk(0x21000)= 0x21000
04:02:38.971832 open(/etc/init.rc, O_RDONLY|O_LARGEFILE) = 4
04:02:38.975006 lseek(4, 0, SEEK_END) = 5746
04:02:38.991088 lseek(4, 0, SEEK_SET) = 0
04:02:38.993286 brk(0x22000)= 0x22000
04:02:38.998413 read(4, ## Global environment setup\n##\nenv {\n
PATH /sbin:/system/sbin:/system/bin\nLD_LIBRARY_PATH
/system/lib
\nANDROID_BOOTLOGO 1\nANDROID_ROOT /system\n
ANDROID_ASSETS /system/app\n ANDROID_..., 5746) = 5746
04:02:39.002288 close(4)= 0
04:02:39.003845 brk(0x23000)= 0x23000
04:02:39.005310 mkdir(/proc, 0755)= -1 EEXIST (File exists)
04:02:39.006622 mkdir(/dev, 0755) = -1 EEXIST (File exists)
04:02:39.007843 mkdir(/dev/pts, 0755) = -1 EEXIST (File exists)
04:02:39.009368 mkdir(/sys, 0755) = -1 EEXIST (File exists)
04:02:39.011230 mkdir(/d, 0755) = -1 EEXIST (File exists)
04:02:39.012451 mount(/dev/pts, /dev/pts, devpts, 0, NULL) = -1
EBUSY (Device or resource busy)
04:02:39.017883 mount(/proc, /proc, proc, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.026428 mount(/sys, /sys, sysfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.033416 mount(/d, /d, debugfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.038238 mount(/tmp, /tmp, tmpfs, 0, NULL) = 0
04:02:39.043457 open(/proc/cmdline, O_RDONLY|O_LARGEFILE) = 4
04:02:39.046417 read(4, root=1f03 rootfstype=jffs2 ro\n, 1023) = 30
04:02:39.048187 close(4)= 0
04:02:39.049346 chmod(/proc/cmdline, 0400) = 0
04:02:39.050689 open(/system_properties, O_RDWR|O_CREAT|O_EXCL|
O_LARGEFILE, 0600) = 4
04:02:39.052368 ftruncate(4, 32768) = 0
04:02:39.053588 open(/system_properties, O_RDONLY|O_LARGEFILE) = 5
04:02:39.056884 unlink(/system_properties) = 0
04:02:39.058624 mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED,
4, 0) = -1 EINVAL (Invalid argument)
04:02:39.059997 close(5)= 0
04:02:39.061096 close(4)= 0
04:02:39.063110 open(/etc/default.prop, O_RDONLY|O_LARGEFILE) = 4
04:02:39.064422 lseek(4, 0, SEEK_END) = 130
04:02:39.065521 lseek(4, 0, SEEK_SET) = 0
04:02:39.066619 read(4, # default system properties\n# these may be
overridden by /data/local.prop\n\nnet.bt.name = Android\n\n# end
default system properties\n, 130) = 130
04:02:39.069152 close(4)= 0
04:02:39.070251 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
04:02:39.072601 +++ killed by SIGSEGV +++
Process 1464 detached
Mmh, there are some reports on this list with similar SIGSEGV:
http://marc.info/?l=linux-omapm=120393103218574w=2
http://marc.info/?l=linux-omapm=120400327301855w=2
http://marc.info/?l=linux-omapm=120834030203728w=2
But It doesn't look like the archives have a detailed solution for this.
Seems that changing some parameters (e.g. switching to other binder driver,
SDK etc.) made the error go away.
I'm CCing Anil and colorant
Re: Android on N810 File System Problem
Jonathan Herriott wrote:
I'm using vanilla Kernel 2.6.21.0 with the patch from
http://android-on-n8xx.googlecode.com/files/linux-2.6.21_rx-34_android-m5-rc14.bz2.
I was told in another thread that I need to use the m3 userspace
files, but when trying to use those, I have the same issue.
I'm assuming you want the strace when running init:
\h:\w\$ strace -f -ff -tt -s 200 /init
04:02:38.896362 execve(/init, [/init], [/* 59 vars */]) = 0
04:02:38.909790 gettid()= 1464
04:02:38.912689 syscall_983045(0xbea0d614, 0, 0x20, 0, 0xbe9ee000,
0xbea0d6d0, 0xbea0d720, 0xf0005, 0xbea0d720, 0, 0x80b8, 0x80b4, 0,
0xbea0d608, 0x17c77, 0x17f2c, 0x6010, 0xbea0d614, 0, 0, 0xc764, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
04:02:38.916168 socket(PF_FILE, SOCK_STREAM, 0) = 3
04:02:38.919250 connect(3, {sa_family=AF_FILE,
[EMAIL PROTECTED], 19) = -1 ECONNREFUSED (Connection refused)
04:02:38.923248 close(3)= 0
04:02:38.926208 sigaction(SIGCHLD, {0x8211, [], SA_NOCLDSTOP}, NULL,
0xc0fb8) = 0
04:02:38.929718 umask(0)= 022
04:02:38.932373 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost
isig icanon echo ...}) = 0
04:02:38.936523 dup(1) = 3
04:02:38.939422 write(3, init: HOW ARE YOU GENTLEMEN\n, 28init: HOW
ARE YOU GENTLEMEN
) = 28
04:02:38.943328 close(0)= 0
04:02:38.945983 close(1)= 0
04:02:38.948577 close(2)= 0
04:02:38.951202 open(/dev/null, O_RDWR|O_LARGEFILE) = 0
04:02:38.954345 dup2(0, 1) = 1
04:02:38.956939 dup2(0, 2) = 2
04:02:38.959625 write(3, init: reading config file\n, 26init:
reading config file
) = 26
04:02:38.963592 brk(0) = 0x2
04:02:38.966217 brk(0x2)= 0x2
04:02:38.968994 brk(0x21000)= 0x21000
04:02:38.971832 open(/etc/init.rc, O_RDONLY|O_LARGEFILE) = 4
04:02:38.975006 lseek(4, 0, SEEK_END) = 5746
04:02:38.991088 lseek(4, 0, SEEK_SET) = 0
04:02:38.993286 brk(0x22000)= 0x22000
04:02:38.998413 read(4, ## Global environment setup\n##\nenv {\n
PATH /sbin:/system/sbin:/system/bin\nLD_LIBRARY_PATH /system/lib
\nANDROID_BOOTLOGO 1\nANDROID_ROOT /system\n
ANDROID_ASSETS /system/app\n ANDROID_..., 5746) = 5746
04:02:39.002288 close(4)= 0
04:02:39.003845 brk(0x23000)= 0x23000
04:02:39.005310 mkdir(/proc, 0755)= -1 EEXIST (File exists)
04:02:39.006622 mkdir(/dev, 0755) = -1 EEXIST (File exists)
04:02:39.007843 mkdir(/dev/pts, 0755) = -1 EEXIST (File exists)
04:02:39.009368 mkdir(/sys, 0755) = -1 EEXIST (File exists)
04:02:39.011230 mkdir(/d, 0755) = -1 EEXIST (File exists)
04:02:39.012451 mount(/dev/pts, /dev/pts, devpts, 0, NULL) = -1
EBUSY (Device or resource busy)
04:02:39.017883 mount(/proc, /proc, proc, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.026428 mount(/sys, /sys, sysfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.033416 mount(/d, /d, debugfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.038238 mount(/tmp, /tmp, tmpfs, 0, NULL) = 0
04:02:39.043457 open(/proc/cmdline, O_RDONLY|O_LARGEFILE) = 4
04:02:39.046417 read(4, root=1f03 rootfstype=jffs2 ro\n, 1023) = 30
04:02:39.048187 close(4)= 0
04:02:39.049346 chmod(/proc/cmdline, 0400) = 0
04:02:39.050689 open(/system_properties, O_RDWR|O_CREAT|O_EXCL|
O_LARGEFILE, 0600) = 4
04:02:39.052368 ftruncate(4, 32768) = 0
04:02:39.053588 open(/system_properties, O_RDONLY|O_LARGEFILE) = 5
04:02:39.056884 unlink(/system_properties) = 0
04:02:39.058624 mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED,
4, 0) = -1 EINVAL (Invalid argument)
04:02:39.059997 close(5)= 0
04:02:39.061096 close(4)= 0
04:02:39.063110 open(/etc/default.prop, O_RDONLY|O_LARGEFILE) = 4
04:02:39.064422 lseek(4, 0, SEEK_END) = 130
04:02:39.065521 lseek(4, 0, SEEK_SET) = 0
04:02:39.066619 read(4, # default system properties\n# these may be
overridden by /data/local.prop\n\nnet.bt.name = Android\n\n# end
default system properties\n, 130) = 130
04:02:39.069152 close(4)= 0
04:02:39.070251 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
04:02:39.072601 +++ killed by SIGSEGV +++
Process 1464 detached
Mmh, there are some reports on this list with similar SIGSEGV:
http://marc.info/?l=linux-omapm=120393103218574w=2
http://marc.info/?l=linux-omapm=120400327301855w=2
http://marc.info/?l=linux-omapm=120834030203728w=2
But It doesn't look like the archives have a detailed solution for
this. Seems that changing some parameters (e.g. switching to other
binder driver, SDK etc.) made the error go away.
I'm CCing Anil and colorant, maybe they remember what helped.
Dirk
On Thu, Apr 24, 2008 at 10:42 PM, Dirk Behme [EMAIL PROTECTED] wrote:
Jonathan,
CCing OMAP mailing list, there are more people to help.
Jonathan Herriott wrote:
Hi,
I'm trying to get android installed on an N810. I have successfully
installed the kernel,
Which kernel
Re: Text Display problem on MISTRAL'S QVGA LCD
You used the wrong (old) OMAP ML. [EMAIL PROTECTED] shouldn't be used any more. OMAP ML moved to http://vger.kernel.org/vger-lists.html#linux-omap Use linux-omap@vger.kernel.org instead. CCed now. balaji narayanam wrote: Dear all, I am working on MISTRAL'S QVGA LCD INTERFACED TO OSK5912. I am using Linux-2.6.22 kernel version. I am able to play the .avi files using mplayer. But I am unable to dispaly the text data on the QVGA LCD screen. When ever I sent any text data to the QVGA LCD, it is displaying only Junk data on the screen. I hope it might be due to the Font size Problem. I request to help by giving an example, how to display the text data on the MISTRAL'S QVGA LCD. An echo Hello world /dev/tty0 works just fine for me using the (font) settings in linux-git/arch/arm/configs/omap_osk_5912_defconfig Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Adding support for OMAP3 Beagle Board
Syed Mohammed, Khasim wrote:
Adding support for OMAP3 Beagle Board
Signed-off-by: Syed Mohammed Khasim [EMAIL PROTECTED]
---
arch/arm/mach-omap2/Kconfig |4 +
arch/arm/mach-omap2/Makefile |1
arch/arm/mach-omap2/board-omap3beagle.c | 79 ++
include/asm-arm/arch-omap/board-omap3beagle.h | 53 +
include/asm-arm/arch-omap/hardware.h |4 +
5 files changed, 141 insertions(+)
Index: my_branch/arch/arm/mach-omap2/Kconfig
===
--- my_branch.orig/arch/arm/mach-omap2/Kconfig 2008-04-16 14:41:28.0
+0530
+++ my_branch/arch/arm/mach-omap2/Kconfig 2008-04-16 14:45:38.0
+0530
@@ -109,3 +109,7 @@
config MACH_OMAP3EVM
bool OMAP 3530 EVM board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+
+config MACH_OMAP3_BEAGLE
+ bool OMAP3 BEAGLE board
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
Index: my_branch/arch/arm/mach-omap2/Makefile
===
--- my_branch.orig/arch/arm/mach-omap2/Makefile 2008-04-16 14:41:28.0
+0530
+++ my_branch/arch/arm/mach-omap2/Makefile 2008-04-16 14:45:38.0
+0530
@@ -35,6 +35,7 @@
board-3430sdp-usb.o \
board-3430sdp-flash.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
board-apollon-mmc.o \
board-apollon-keys.o
Index: my_branch/arch/arm/mach-omap2/board-omap3beagle.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ my_branch/arch/arm/mach-omap2/board-omap3beagle.c 2008-04-16
14:45:52.0 +0530
@@ -0,0 +1,79 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3beagle.c
+ *
+ * Copyright (C) 2008 Texas Instruments
+ *
+ * Modified from mach-omap2/board-3430sdp.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+
+#include asm/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include asm/arch/gpio.h
+#include asm/arch/board.h
+#include asm/arch/common.h
+
+static struct omap_uart_config omap3_beagle_uart_config __initdata = {
+ .enabled_uarts = ((1 0) | (1 1) | (1 2)),
+};
+
+static int __init omap3_beagle_i2c_init(void)
+{
+ omap_register_i2c_bus(1, 2600, NULL, 0);
+ omap_register_i2c_bus(2, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, NULL, 0);
+ return 0;
+}
+
+static void __init omap3_beagle_init_irq(void)
+{
+ omap2_init_common_hw();
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_board_config_kernel omap3_beagle_config[] __initdata = {
+ {OMAP_TAG_UART, omap3_beagle_uart_config },
+};
+
+static void __init omap3_beagle_init(void)
+{
+ omap_board_config = omap3_beagle_config;
+ omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
+ omap_serial_init();
Do you like to add here MMC and USB init like recently proposed by
Koen Kooi?
If I understand correctly, these patches currently won't boot on
BeagleBoard if MMC and USB are missing?
Many thanks
Dirk
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [android-internals] Re: Android on Nokia n810 (OMAP2420)
Nishanth Menon wrote:
Looping in OMAP ML to the good news..
Congrats!
sim0nx said the following on 04/05/2008 06:35 AM:
I can't believe it !!!
Android runs on the maemo n810 !!!
Great!
Do you have some screenshots we can add to
http://elinux.org/Android_on_OMAP#Screenshots
?
Anything else we should add/correct at
http://elinux.org/Android_on_OMAP
?
Thanks
Dirk
Btw: Do you have any power management issues like
http://elinux.org/Android_on_OMAP#Power_management
? We still don't know anything about them :(
After reading this:
http://groups.google.lu/group/android-internals/browse_thread/thread/93570c41bce07f16?hl=en
for the 100th time, and following the instructions on the mentioned
link:
http://nemustech.blogspot.com/2007/12/android-porting-to-real-target-hw.html
it works.
Here are the specifics I've implemented:
* patch /etc/init.rc
begin : init.rc
## qemu-init {
## exec /etc/qemu-init.sh
## }
network-property {
exec /etc/set_network.sh
}
/bin/chmod -R a+rw /data /tmp
/bin/chmod a+rw .
/bin/chmod -R a+rw data
# rm /dev/log (if you have)
# mkdir /dev/log;touch /dev/log/{main,events,radio}
* you can see usefull infos from strace log and /dev/log/main
and instead of:
chroot . /a.sh
I execute the android init process:
chroot . /init
Not sure yet what exactly of those steps solved the problem (maybe the
qemu one), but it does work.
After a quick try I see that the touchscreen doesn't work (the
keyboard does though), but that shouldn't be too hard to fix.
BTW, this is using an m5 kernel, and binder.c
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Android
Internals group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-internals?hl=en
-~--~~~~--~~--~--~---
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: source.mvista links are broken
Kevin Hilman wrote: Tony Lindgren [EMAIL PROTECTED] writes: * Iqbal [EMAIL PROTECTED] [080404 13:07]: Looks like the OMAP tree links are broken and the summary,short log and other fields don't work. http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commit;h=8a88c221c88399bc694c367dbea01ffc4153ef20 Yeah, I've noticed that too. Probably git needs updating on source.mvista.com, it seems to have issues with reading packed objects. I've fixed it to some extent by scp'ing over some object files, and then there was a brief file permissions problem too... In any case, please use the kernel.org instead: http://git.kernel.org/git/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git I've notified Kevin about the issue, so we probably have to wait for git to get updated. git on source.mvista.com is now updated to 1.5.4.5. Let me know if there are any more problems. omap-git git version git version 1.5.4.5 omap-git cg-version cogito-0.18.2 omap-git cat .git/HEAD 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d omap-git cat .git/branches/origin git://source.mvista.com/git/linux-omap-2.6 omap-git cg-update origin Recovering from a previously interrupted fetch... Fetching pack (head and objects)... error: refs/heads/origin does not point to a valid object! error: refs/heads/origin does not point to a valid object! remote: Total 0 (delta 0), reused 0 (delta 0) remote: aborting due to possible repository corruption on the remote side. error: waitpid (async) failed fatal: error in sideband demultiplexer cg-fetch: fetching pack failed omap-git Switching to git.kernel.org works: omap-git cat .git/branches/origin git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-git cg-update origin Recovering from a previously interrupted fetch... Fetching pack (head and objects)... error: refs/heads/origin does not point to a valid object! error: refs/heads/origin does not point to a valid object! remote: Counting objects: 896, done. remote: Compressing objects: 100% (490/490), done. remote: Total 896 (delta 453), reused 848 (delta 405) Receiving objects: 100% (896/896), 1.53 MiB | 108 KiB/s, done. Resolving deltas: 100% (453/453), done. Fetching tags... Missing tag v2.6.25-rc8... remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 1 (delta 0) Unpacking objects: 100% (1/1), done. Up to date. Applying changes... Fast-forwarding 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d - 722c80b23c0d53c16467e35ea43741c597bfbba3 on top of 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d ... omap-git Seems that there is still something broken with MV git? Dirk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
