Skip to contentSkip to conversation

Add support for 16-bit and 32-bit registers

PATCH Superseded Cory Maccarrone 2 participants 4 messages Nov 15, 2009 – Nov 18, 2009

Subsystems (2)

v1 of 5 Superseded Latest is v5 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Add support for 16-bit and 32-bit registers

The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver. To make this as portable as possible, I made the following changes:

* Moved register address offsets from drivers/mmc/host/omap.c to drivers/mmc/host/omap.h
* Implemented a lookup table for 16-bit and 32-bit register offsets
* Added a reg_size field in the mmc_omap_host structure
* Added code in mmc_omap_probe() to populate the reg_size field based on processor in use
* Added inline function to return the register offset based on the register size and register name
* Modified mmc-omap driver to use the new inline function to call out register names

This change should allow the omap7xx-series of processors to correctly utilize the MMC driver.

---
 drivers/mmc/host/omap.c |   42 +++++------------
 drivers/mmc/host/omap.h |  115 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 127 insertions(+), 30 deletions(-)
 create mode 100644 drivers/mmc/host/omap.h
drivers/mmc/host/omap.c +12 -30
index 5f970e2..c0071b3 100644
@@ -37,31 +37,7 @@
 #include <plat/mux.h>
 #include <plat/fpga.h>
 
-#define	OMAP_MMC_REG_CMD	0x00
-#define	OMAP_MMC_REG_ARGL	0x04
-#define	OMAP_MMC_REG_ARGH	0x08
-#define	OMAP_MMC_REG_CON	0x0c
-#define	OMAP_MMC_REG_STAT	0x10
-#define	OMAP_MMC_REG_IE		0x14
-#define	OMAP_MMC_REG_CTO	0x18
-#define	OMAP_MMC_REG_DTO	0x1c
-#define	OMAP_MMC_REG_DATA	0x20
-#define	OMAP_MMC_REG_BLEN	0x24
-#define	OMAP_MMC_REG_NBLK	0x28
-#define	OMAP_MMC_REG_BUF	0x2c
-#define OMAP_MMC_REG_SDIO	0x34
-#define	OMAP_MMC_REG_REV	0x3c
-#define	OMAP_MMC_REG_RSP0	0x40
-#define	OMAP_MMC_REG_RSP1	0x44
-#define	OMAP_MMC_REG_RSP2	0x48
-#define	OMAP_MMC_REG_RSP3	0x4c
-#define	OMAP_MMC_REG_RSP4	0x50
-#define	OMAP_MMC_REG_RSP5	0x54
-#define	OMAP_MMC_REG_RSP6	0x58
-#define	OMAP_MMC_REG_RSP7	0x5c
-#define	OMAP_MMC_REG_IOSR	0x60
-#define	OMAP_MMC_REG_SYSC	0x64
-#define	OMAP_MMC_REG_SYSS	0x68
+#include "omap.h"
 
 #define	OMAP_MMC_STAT_CARD_ERR		(1 << 14)
 #define	OMAP_MMC_STAT_CARD_IRQ		(1 << 13)
@@ -77,8 +53,10 @@
 #define	OMAP_MMC_STAT_CARD_BUSY		(1 <<  2)
 #define	OMAP_MMC_STAT_END_OF_CMD	(1 <<  0)
 
-#define OMAP_MMC_READ(host, reg)	__raw_readw((host)->virt_base + OMAP_MMC_REG_##reg)
-#define OMAP_MMC_WRITE(host, reg, val)	__raw_writew((val), (host)->virt_base + OMAP_MMC_REG_##reg)
+#define OMAP_MMC_REG(host, reg)		mmc_omap_get_register(host->reg_size, OMAP_MMC_REG_##reg)
+
+#define OMAP_MMC_READ(host, reg)	__raw_readw((host)->virt_base + OMAP_MMC_REG(host, reg))
+#define OMAP_MMC_WRITE(host, reg, val)	__raw_writew((val), (host)->virt_base + OMAP_MMC_REG(host, reg))
 
 /*
  * Command types
@@ -167,6 +145,8 @@ struct mmc_omap_host {
 	spinlock_t		clk_lock;     /* for changing enabled state */
 	unsigned int            fclk_enabled:1;
 
+	unsigned		reg_size:1;
+
 	struct omap_mmc_platform_data *pdata;
 };
 
@@ -679,9 +659,9 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
 	host->data->bytes_xfered += n;
 
 	if (write) {
-		__raw_writesw(host->virt_base + OMAP_MMC_REG_DATA, host->buffer, n);
+		__raw_writesw(host->virt_base + OMAP_MMC_REG(host, DATA), host->buffer, n);
 	} else {
-		__raw_readsw(host->virt_base + OMAP_MMC_REG_DATA, host->buffer, n);
+		__raw_readsw(host->virt_base + OMAP_MMC_REG(host, DATA), host->buffer, n);
 	}
 }
 
@@ -899,7 +879,7 @@ mmc_omap_prepare_dma(struct mmc_omap_host *host, struct mmc_data *data)
 	int dst_port = 0;
 	int sync_dev = 0;
 
-	data_addr = host->phys_base + OMAP_MMC_REG_DATA;
+	data_addr = host->phys_base + OMAP_MMC_REG(host, DATA);
 	frame = data->blksz;
 	count = sg_dma_len(sg);
 
@@ -1490,6 +1470,8 @@ static int __init mmc_omap_probe(struct platform_device *pdev)
 		}
 	}
 
+	host->reg_size = (cpu_is_omap7xx() ? OMAP_MMC_REG_SIZE_2 : OMAP_MMC_REG_SIZE_4);
+
 	return 0;
 
 err_plat_cleanup:
drivers/mmc/host/omap.h new file +115 -0

115 lines not on this page · raw message

Signature · 1 line
1.6.3.3
#1 lore raw
Quoted 3 lines · Cory Maccarrone

The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver. To make this as portable as possible, I made the following changes:

Hmm, I would not trade portability anyone currently needs for complexity...

Quoted 10 lines

* Moved register address offsets from drivers/mmc/host/omap.c to drivers/mmc/host/omap.h
* Implemented a lookup table for 16-bit and 32-bit register offsets
* Added a reg_size field in the mmc_omap_host structure
* Added code in mmc_omap_probe() to populate the reg_size field based on processor in use
* Added inline function to return the register offset based on the register size and register name
* Modified mmc-omap driver to use the new inline function to call out register names

All this could be probably done by making register definition an index and shifting it left by one or two depending on CPU. No lookup table needed.

Quoted 2 lines

This change should allow the omap7xx-series of processors to correctly utilize the MMC driver.

Did you test it? It does not work on 5910, see here:
http://thread.gmane.org/gmane.linux.kernel.mmc/649

Best regards,
ladis

#2 lore raw
Quoted 6 lines · Ladislav Michl
Quoted 3 lines · Cory Maccarrone

The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver.  To make this as portable as possible, I made the following changes:

Hmm, I would not trade portability anyone currently needs for complexity...

Agreed, this solution is more complicated than it probably needs to be.

Quoted 12 lines
Quoted 11 lines

* Moved register address offsets from drivers/mmc/host/omap.c to drivers/mmc/host/omap.h
* Implemented a lookup table for 16-bit and 32-bit register offsets
* Added a reg_size field in the mmc_omap_host structure
* Added code in mmc_omap_probe() to populate the reg_size field based on processor in use
* Added inline function to return the register offset based on the register size and register name
* Modified mmc-omap driver to use the new inline function to call out register names

Quoted 2 lines

All this could be probably done by making register definition an index and shifting it left by one or two depending on CPU. No lookup table needed.

Ah, good point, I hadn't considered that. I'll rework my implementation to do that and resubmit.

Quoted 6 lines
Quoted 3 lines

This change should allow the omap7xx-series of processors to correctly utilize the MMC driver.

Did you test it? It does not work on 5910, see here:
http://thread.gmane.org/gmane.linux.kernel.mmc/649

Not sure why it wouldn't work on the 5910. I tested it on my device, and it works properly for me, but then I don't have an omap-based device that uses 32-bit register definitions. I'm confused at the post you have above though...Is that with my patch, or is that with something else? It seems to reference the status of current git, which I don't think this patch shouldn't be in.

- Cory
--
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

#3 lore raw
Quoted 11 lines · Cory Maccarrone
Quoted 2 lines · Ladislav Michl

Did you test it? It does not work on 5910, see here:
http://thread.gmane.org/gmane.linux.kernel.mmc/649

Not sure why it wouldn't work on the 5910. I tested it on my device, and it works properly for me, but then I don't have an omap-based device that uses 32-bit register definitions. I'm confused at the post you have above though...Is that with my patch, or is that with something else? It seems to reference the status of current git, which I don't think this patch shouldn't be in.

To put it clear, current git does not work and it is unrelated to your patch. If driver works for you with your patch, then either your MMC card or controller in your SoC survives multiple init sequences or it has something to do with clock settings or... You can find two more people confirming this here: http://www.spinics.net/lists/linux-omap/msg09547.html
I'll probably need to find some time to read MMC spec.

ladis