Skip to contentSkip to conversation

Use common function to set GPIOs for MX3 and MX5

PATCH New Stefano Babic 5 participants 21 messages Aug 20, 2010 – Aug 26, 2010

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

The patch adds support for setting gpios to the MX51 processor and change name to the corresponding functions for MX31. In this way, it is possible to get rid of nasty #ifdef switches related to the processor type.

---
 arch/arm/include/asm/arch-mx31/mx31-regs.h |   14 +++-
 arch/arm/include/asm/arch-mx31/mx31.h      |   25 -------
 arch/arm/include/asm/arch-mx51/imx-regs.h  |    6 ++
 board/davedenx/qong/qong.c                 |   29 ++++----
 drivers/gpio/Makefile                      |    2 +-
 drivers/gpio/mx31_gpio.c                   |   88 -----------------------
 drivers/gpio/mxc_gpio.c                    |  107 ++++++++++++++++++++++++++++
 drivers/spi/mxc_spi.c                      |    9 +--
 include/configs/imx31_phycore.h            |    2 +-
 include/configs/qong.h                     |    2 +-
 include/mxc_gpio.h                         |   52 +++++++++++++
 11 files changed, 197 insertions(+), 139 deletions(-)
 delete mode 100644 drivers/gpio/mx31_gpio.c
 create mode 100644 drivers/gpio/mxc_gpio.c
 create mode 100644 include/mxc_gpio.h
arch/arm/include/asm/arch-mx31/mx31-regs.h +11 -3
index d72585c..f05e743 100644
@@ -57,6 +57,14 @@ struct clock_control_regs {
 	u32 pdr2;
 };
 
+/* GPIO Registers */
+struct gpio_regs {
+	u32	gpio_dr;
+	u32	gpio_dir;
+	u32	gpio_psr;
+};
+
+
 /* Bit definitions for RCSR register in CCM */
 #define CCM_RCSR_NF16B	(1 << 31)
 #define CCM_RCSR_NFMS	(1 << 30)
@@ -153,9 +161,9 @@ struct clock_control_regs {
 /*
  * GPIO
  */
-#define GPIO1_BASE	0x53FCC000
-#define GPIO2_BASE	0x53FD0000
-#define GPIO3_BASE	0x53FA4000
+#define GPIO1_BASE_ADDR	0x53FCC000
+#define GPIO2_BASE_ADDR	0x53FD0000
+#define GPIO3_BASE_ADDR	0x53FA4000
 #define GPIO_DR		0x00000000	/* data register */
 #define GPIO_GDIR	0x00000004	/* direction register */
 #define GPIO_PSR	0x00000008	/* pad status register */
arch/arm/include/asm/arch-mx31/mx31.h +0 -25
index f702d26..5a5aa11 100644
@@ -28,31 +28,6 @@ extern u32 mx31_get_ipg_clk(void);
 #define imx_get_uartclk mx31_get_ipg_clk
 extern void mx31_gpio_mux(unsigned long mode);
 
-enum mx31_gpio_direction {
-	MX31_GPIO_DIRECTION_IN,
-	MX31_GPIO_DIRECTION_OUT,
-};
-
-#ifdef CONFIG_MX31_GPIO
-extern int mx31_gpio_direction(unsigned int gpio,
-			       enum mx31_gpio_direction direction);
-extern void mx31_gpio_set(unsigned int gpio, unsigned int value);
-extern int mx31_gpio_get(unsigned int gpio);
-#else
-static inline int mx31_gpio_direction(unsigned int gpio,
-				      enum mx31_gpio_direction direction)
-{
-	return 1;
-}
-static inline int mx31_gpio_get(unsigned int gpio)
-{
-	return 1;
-}
-static inline void mx31_gpio_set(unsigned int gpio, unsigned int value)
-{
-}
-#endif
-
 void mx31_uart1_hw_init(void);
 void mx31_spi2_hw_init(void);
 
arch/arm/include/asm/arch-mx51/imx-regs.h +6 -0
index 3887d3c..0e3bc2a 100644
@@ -256,6 +256,12 @@ struct weim {
 	u32	cswcr2;
 };
 
+/* GPIO Registers */
+struct gpio_regs {
+	u32	gpio_dr;
+	u32	gpio_dir;
+	u32	gpio_psr;
+};
 #endif /* __ASSEMBLER__*/
 
 #endif				/*  __ASM_ARCH_MXC_MX51_H__ */
board/davedenx/qong/qong.c +15 -14
index 781333b..59589c2 100644
@@ -27,6 +27,7 @@
 #include <asm/arch/mx31-regs.h>
 #include <nand.h>
 #include <fsl_pmic.h>
+#include <mxc_gpio.h>
 #include "qong_fpga.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -42,9 +43,9 @@ int dram_init (void)
 
 static void qong_fpga_reset(void)
 {
-	mx31_gpio_set(QONG_FPGA_RST_PIN, 0);
+	mxc_gpio_set(QONG_FPGA_RST_PIN, 0);
 	udelay(30);
-	mx31_gpio_set(QONG_FPGA_RST_PIN, 1);
+	mxc_gpio_set(QONG_FPGA_RST_PIN, 1);
 
 	udelay(300);
 }
@@ -115,11 +116,11 @@ int board_init (void)
 
 	/* FPGA reset  Pin */
 	/* rstn = 0 */
-	mx31_gpio_set(QONG_FPGA_RST_PIN, 0);
-	mx31_gpio_direction(QONG_FPGA_RST_PIN, MX31_GPIO_DIRECTION_OUT);
+	mxc_gpio_set(QONG_FPGA_RST_PIN, 0);
+	mxc_gpio_direction(QONG_FPGA_RST_PIN, MXC_GPIO_DIRECTION_OUT);
 
 	/* set interrupt pin as input */
-	mx31_gpio_direction(QONG_FPGA_IRQ_PIN, MX31_GPIO_DIRECTION_IN);
+	mxc_gpio_direction(QONG_FPGA_IRQ_PIN, MXC_GPIO_DIRECTION_IN);
 
 #endif
 
@@ -201,27 +202,27 @@ static void board_nand_setup(void)
 	qong_fpga_reset();
 
 	/* Enable NAND flash */
-	mx31_gpio_set(15, 1);
-	mx31_gpio_set(14, 1);
-	mx31_gpio_direction(15, MX31_GPIO_DIRECTION_OUT);
-	mx31_gpio_direction(16, MX31_GPIO_DIRECTION_IN);
-	mx31_gpio_direction(14, MX31_GPIO_DIRECTION_IN);
-	mx31_gpio_set(15, 0);
+	mxc_gpio_set(15, 1);
+	mxc_gpio_set(14, 1);
+	mxc_gpio_direction(15, MXC_GPIO_DIRECTION_OUT);
+	mxc_gpio_direction(16, MXC_GPIO_DIRECTION_IN);
+	mxc_gpio_direction(14, MXC_GPIO_DIRECTION_IN);
+	mxc_gpio_set(15, 0);
 
 }
 
 int qong_nand_rdy(void *chip)
 {
 	udelay(1);
-	return mx31_gpio_get(16);
+	return mxc_gpio_get(16);
 }
 
 void qong_nand_select_chip(struct mtd_info *mtd, int chip)
 {
 	if (chip >= 0)
-		mx31_gpio_set(15, 0);
+		mxc_gpio_set(15, 0);
 	else
-		mx31_gpio_set(15, 1);
+		mxc_gpio_set(15, 1);
 
 }
 
drivers/gpio/Makefile +1 -1
index 528ca2e..738396a 100644
@@ -27,7 +27,7 @@ LIB 	:= $(obj)libgpio.a
 
 COBJS-$(CONFIG_AT91_GPIO)	+= at91_gpio.o
 COBJS-$(CONFIG_KIRKWOOD_GPIO)	+= kw_gpio.o
-COBJS-$(CONFIG_MX31_GPIO)	+= mx31_gpio.o
+COBJS-$(CONFIG_MXC_GPIO)	+= mxc_gpio.o
 COBJS-$(CONFIG_PCA953X)		+= pca953x.o
 COBJS-$(CONFIG_S5PC1XX)		+= s5p_gpio.o
 
drivers/gpio/mx31_gpio.c deleted +0 -88

88 lines not on this page · raw message

drivers/gpio/mxc_gpio.c new file +107 -0

107 lines not on this page · raw message

drivers/spi/mxc_spi.c +3 -6
index e15a63c..54af2e3 100644
@@ -23,6 +23,7 @@
 #include <spi.h>
 #include <asm/errno.h>
 #include <asm/io.h>
+#include <mxc_gpio.h>
 
 #ifdef CONFIG_MX27
 /* i.MX27 has a completely wrong register layout and register definitions in the
@@ -68,9 +69,6 @@ static unsigned long spi_bases[] = {
 	0x53f84000,
 };
 
-#define OUT	MX31_GPIO_DIRECTION_OUT
-#define mxc_gpio_direction	mx31_gpio_direction
-#define mxc_gpio_set		mx31_gpio_set
 #elif defined(CONFIG_MX51)
 #include <asm/arch/imx-regs.h>
 #include <asm/arch/clock.h>
@@ -111,13 +109,12 @@ static unsigned long spi_bases[] = {
 	CSPI2_BASE_ADDR,
 	CSPI3_BASE_ADDR,
 };
-#define mxc_gpio_direction(gpio, dir)	(0)
-#define mxc_gpio_set(gpio, value)	{}
-#define OUT	1
 #else
 #error "Unsupported architecture"
 #endif
 
+#define OUT	MXC_GPIO_DIRECTION_OUT
+
 struct mxc_spi_slave {
 	struct spi_slave slave;
 	unsigned long	base;
include/configs/imx31_phycore.h +1 -1
index 1dbafa0..62944a9 100644
@@ -183,7 +183,7 @@
 #ifdef CONFIG_IMX31_PHYCORE_EET
 #define BOARD_LATE_INIT
 
-#define CONFIG_MX31_GPIO			1
+#define CONFIG_MXC_GPIO
 
 #define CONFIG_HARD_SPI				1
 #define CONFIG_MXC_SPI				1
include/configs/qong.h +1 -1
index 100fa3f..2ee1d60 100644
@@ -52,7 +52,7 @@
 #define CONFIG_MXC_UART	1
 #define CONFIG_SYS_MX31_UART1	1
 
-#define CONFIG_MX31_GPIO
+#define CONFIG_MXC_GPIO
 
 #define CONFIG_MXC_SPI
 #define CONFIG_DEFAULT_SPI_BUS	1
include/mxc_gpio.h new file +52 -0

52 lines not on this page · raw message

Signature · 1 line
1.6.3.3
#1 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 4 lines · Stefano Babic

The patch adds support for setting gpios to the MX51 processor and change name to the corresponding functions for MX31. In this way, it is possible to get rid of nasty #ifdef switches related to the processor type.

Argh! I was just writing the exact same code as in this patch :-( Thanks a lot anyway.

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#2 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

In reply to Stefano Babic

Hi Stefano,

Quoted 23 lines · Stefano Babic
drivers/spi/mxc_spi.c +1 -0
index e15a63c..54af2e3 100644
@@ -23,6 +23,7 @@
 #include <spi.h>
 #include <asm/errno.h>
 #include <asm/io.h>
+#include <mxc_gpio.h>
 
 #ifdef CONFIG_MX27
 /* i.MX27 has a completely wrong register layout and register definitions

in the @@ -68,9 +69,6 @@ static unsigned long spi_bases[] = {

drivers/spi/mxc_spi.c +0 -3
 	0x53f84000,
 };
 
-#define OUT	MX31_GPIO_DIRECTION_OUT
-#define mxc_gpio_direction	mx31_gpio_direction
-#define mxc_gpio_set		mx31_gpio_set
 #elif defined(CONFIG_MX51)
 #include <asm/arch/imx-regs.h>
 #include <asm/arch/clock.h>

drivers/spi/mxc_spi.c static unsigned long spi_bases[] = { · line 116

Quoted 6 lines
drivers/spi/mxc_spi.c +0 -3
@@ -111,13 +109,12 @@ static unsigned long spi_bases[] = {
 	CSPI2_BASE_ADDR,
 	CSPI3_BASE_ADDR,
 };
-#define mxc_gpio_direction(gpio, dir)	(0)
-#define mxc_gpio_set(gpio, value)	{}
-#define OUT	1

After this change, it seems something else is missing:
GCC somehow removed the following code for i.MX51 without actually compiling the arguments to the functions (???), but now it becomes evident this only compiles for i.MX31:

void spi_cs_activate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL);
}

void spi_cs_deactivate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio,
			      !(mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL));
}

On i.MX51 SSPOL is set in the config register, and per SS individually. Therefore, MXC_CSPICTRL_SSPOL isn't defined for i.MX51.

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#3 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 2 lines · David Jander

Hi Stefano,

Hi David,

Quoted 4 lines

After this change, it seems something else is missing:
GCC somehow removed the following code for i.MX51 without actually compiling the arguments to the functions (???), but now it becomes evident this only compiles for i.MX31:

Understood, in SPI driver. Really I had another patch in my private tree, but I have not yet sent. However, as you note, it makes no sense to split changes in two patches.

I will rebase my tree and send V2 version of the pacth, inclusive the changes for mxc_spi.c

Quoted 5 lines

void spi_cs_activate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL);

I know, I had already change this code...I store ss_pol in the priivate structure to be independent from the processor register.

I will send the compound patch soon.

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#4 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Stefano,

Quoted 11 lines · Stefano Babic
Quoted 4 lines

After this change, it seems something else is missing:
GCC somehow removed the following code for i.MX51 without actually compiling the arguments to the functions (???), but now it becomes evident this only compiles for i.MX31:

Understood, in SPI driver. Really I had another patch in my private tree, but I have not yet sent. However, as you note, it makes no sense to split changes in two patches.

I will rebase my tree and send V2 version of the pacth, inclusive the changes for mxc_spi.c

Ok, thanks!

Quoted 10 lines
Quoted 5 lines

void spi_cs_activate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL);

I know, I had already change this code...I store ss_pol in the priivate structure to be independent from the processor register.

I will send the compound patch soon.

Great. I'll wait.
In the meantime I have just done this to get it working:

#ifdef CONFIG_MX31
void spi_cs_activate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL);
}

void spi_cs_deactivate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio,
			      !(mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL));
}
#elif defined (CONFIG_MX51)
void spi_cs_activate(struct spi_slave *slave)
{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	unsigned int val = mxcs->cfg_reg & 
			(1 << (slave->cs + MXC_CSPICON_SSPOL));
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, val);
}

void spi_cs_deactivate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	unsigned int val = !(mxcs->cfg_reg & 
			(1 << (slave->cs + MXC_CSPICON_SSPOL)));
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, val);
}

#endif

Seems to work, but never mind...

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#5 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 11 lines · David Jander

Great. I'll wait.
In the meantime I have just done this to get it working:

#ifdef CONFIG_MX31
void spi_cs_activate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL);
}

Ok, but one goal I have is to get rid of nasty #ifdef CONFIG_MX*. I introduce general gpio functions to make code more common, and I do not want to fall back adding processor switches.

Quoted 1 line

Seems to work, but never mind...

Ok, I will resend my patch, I hope you can give a chance a test it on your target.

Best regards,
Stefano

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#6 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 12 lines · Stefano Babic
Quoted 10 lines · David Jander

Great. I'll wait.
In the meantime I have just done this to get it working:

#ifdef CONFIG_MX31
void spi_cs_activate(struct spi_slave *slave)

{
	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
	if (mxcs->gpio > 0)
		mxc_gpio_set(mxcs->gpio, mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL);
}
Quoted 3 lines

Ok, but one goal I have is to get rid of nasty #ifdef CONFIG_MX*. I introduce general gpio functions to make code more common, and I do not want to fall back adding processor switches.

Absolutely right. I just posted it as reference for your patch eventually, not because I thought it was good that way.

Quoted 4 lines
Quoted 1 line

Seems to work, but never mind...

Ok, I will resend my patch, I hope you can give a chance a test it on your target.

Will do.
Btw, do you have any idea why spi_xchg_single() hangs while transmitting the second word without claiming the bus again?

Also, I don't know if you already fixed mxc_spi.c, to use the correct byte- ordering when sending u8 buffers. I have a fix, but it is not yet ready. I essentially renamed spi_xfer() to spi_xfer_fsl(), to be used in the (broken) pmic driver, and wrote a new spi_xfer() function which works correcly for u8 buffers.

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#7 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 2 lines · David Jander

Absolutely right. I just posted it as reference for your patch eventually, not because I thought it was good that way.

Yes, I know. I want only to point out what we have to reach ;-)

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

Seems to work, but never mind...

Ok, I will resend my patch, I hope you can give a chance a test it on your target.

Will do.
Btw, do you have any idea why spi_xchg_single() hangs while transmitting the second word without claiming the bus again?

Can you see where does it hang ? Which device is connected to your SPI bus ? Does it work with the pmic (I think so, see later...).

Quoted 3 lines

Also, I don't know if you already fixed mxc_spi.c, to use the correct byte- ordering when sending u8 buffers.

Well, it seems we are working at the same issues, and probably it is better if we try some coordination ;-)

I have already fix the byte ordering, but I am fixing now the misaligned access (this is the reason I have not sent the changes for gpios in the mxc_spi.c: I am reworking this driver...). In the mainline driver, only 32-bit aligned buffers are allowed, and this is a strong limitation. I cannot use some other components in u-boot, such as SPI flash, because the code allocates u8 buffers that can be disaligned. And with other devices (sensors, eeprom, ...) does not work, because most of them require to transfer only one or two bytes as command.

Now that I think...is it maybe your case now ? The FIFO can be accessed only as word, other accesses are not allowed according to the manual.

However, I am currently working on several issues for MX51. It should be nice to know which are your plans to save both some time ;-)

Quoted 3 lines

I have a fix, but it is not yet ready.
I essentially renamed spi_xfer() to spi_xfer_fsl(), to be used in the (broken) pmic driver,

As I said, I changed the pmic driver, too. I do not agree we must have "special" functions, only because something is broken. The pmic works because it is connected to the FSL SPI controller, and the endianess is consistent. However, it is common for a SPI driver to allocate a "char" buffer, and the first byte in the buffer is the first byte sent to the SPI bus. This is not the case with mxc_spi.c

Regards,
Stefano

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#8 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Hi Stefano,

Quoted 6 lines · Stefano Babic
Quoted 3 lines

Will do.
Btw, do you have any idea why spi_xchg_single() hangs while transmitting the second word without claiming the bus again?

Can you see where does it hang ? Which device is connected to your SPI bus ? Does it work with the pmic (I think so, see later...).

Just figured out one big mistake. I was debugging spi_flash.c, and had CONFIG_ENV_IS_IN_SPI_FLASH set. That means, first SPI access is done before malloc is available, and guess what? spi_setup_slave() uses malloc ;-) So I did something in the way of this:

static struct mxc_spi_slave mxc_spi_slave_pool[4];

struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)

{
	unsigned int ctrl_reg;
	struct mxc_spi_slave *mxcs;
	int ret;

	if (bus >= ARRAY_SIZE(spi_bases))
		return NULL;

	//mxcs = malloc(sizeof(struct mxc_spi_slave));
	//if (!mxcs)
	//	return NULL;
	mxcs = &mxc_spi_slave_pool[cs];

The C++ comments show original code, the line below is new.

It still hangs though, waiting for MXC_CSPICTRL_TC to become active. Busy finding out why...

I see a one byte access followed by a 5 byte access, of which only 8.5 clock pulses come out of SCLK, and then nothing more. MXC_CSPICTRL_TC stays low.

Quoted 5 lines
Quoted 2 lines

Also, I don't know if you already fixed mxc_spi.c, to use the correct byte- ordering when sending u8 buffers.

Well, it seems we are working at the same issues, and probably it is better if we try some coordination ;-)

Good idea.

Quoted 8 lines

I have already fix the byte ordering, but I am fixing now the misaligned access (this is the reason I have not sent the changes for gpios in the mxc_spi.c: I am reworking this driver...). In the mainline driver, only 32-bit aligned buffers are allowed, and this is a strong limitation. I cannot use some other components in u-boot, such as SPI flash, because the code allocates u8 buffers that can be disaligned. And with other devices (sensors, eeprom, ...) does not work, because most of them require to transfer only one or two bytes as command.

I assumed that u-boot spi drivers use only u8 buffers for simplicity. So my fix looks as this:

int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
void *din, unsigned long flags)

{
	int n_blks = (bitlen + 31) / 32;
	u32 out, in;
	u8 *in_b, *out_b;
	int i;
	
	out_b = (u8 *)dout;
	in_b = (u8 *)din;
	
	for(i = 0; i< n_blks; i++, bitlen -= 32) {
		if(dout) {
			out = out_b[0];
			if(bitlen > 8)
				out = (out<<8) | out_b[1];
			if(bitlen > 16)
				out = (out<<8) | out_b[2];
			if(bitlen > 24)
				out = (out<<8) | out_b[3];
			out_b += 4;
		} else {
			out=0;
		}
		in = spi_xchg_single(slave, out, bitlen, flags);
		if(din) {
			if(bitlen > 24) {
				in_b[3] = in & 0xff;
				in >>= 8;
			}
			if(bitlen > 16) {
				in_b[2] = in & 0xff;
				in >>= 8;
			}
			if(bitlen > 8) {
				in_b[1] = in & 0xff;
				in >>= 8;
			}
			in_b[0] = in & 0xff;
			in_b += 4;
		}
	}
	return 0;
}

Does this sound like it could work?

Quoted 2 lines

Now that I think...is it maybe your case now ? The FIFO can be accessed only as word, other accesses are not allowed according to the manual.

I am aware of that. That's why I used spi_xchg_single() as is.

Quoted 2 lines

However, I am currently working on several issues for MX51. It should be nice to know which are your plans to save both some time ;-)

Well, I am in a bit of a hurry, and essentially what I need is to be able to access SPI-nor flash (spansion type) for environment and booting linux. MMC/SD access would be nice, but is not yet necessary.

Quoted 10 lines
Quoted 3 lines

I have a fix, but it is not yet ready.
I essentially renamed spi_xfer() to spi_xfer_fsl(), to be used in the (broken) pmic driver,

As I said, I changed the pmic driver, too. I do not agree we must have "special" functions, only because something is broken. The pmic works because it is connected to the FSL SPI controller, and the endianess is consistent. However, it is common for a SPI driver to allocate a "char" buffer, and the first byte in the buffer is the first byte sent to the SPI bus. This is not the case with mxc_spi.c

I know. I thought to do it in two steps: Fix mxc_spi.c with a workaround for the pmic driver (which amounts to '#define spi_xfer spi_xfer_fsl' at the beginning of this driver basically) and fix the pmic driver later, since it is probably not trivial, and needs to be done carefully (you know, one can smoke a board by mistake :-)

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#9 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 2 lines · David Jander

Hi Stefano,

Hi David,

Quoted 10 lines · Stefano Babic
Quoted 5 lines
Quoted 3 lines

Will do.
Btw, do you have any idea why spi_xchg_single() hangs while transmitting the second word without claiming the bus again?

Can you see where does it hang ? Which device is connected to your SPI bus ? Does it work with the pmic (I think so, see later...).

Just figured out one big mistake. I was debugging spi_flash.c, and had CONFIG_ENV_IS_IN_SPI_FLASH set. That means, first SPI access is done before malloc is available, and guess what? spi_setup_slave() uses malloc ;-)

I have CONFIG_ENV_IS_IN_SPI_FLASH set, too.
I try to figure out how the functions are called, but I do not get the same issue. I set with the debugger two breakpoints, one in mem_malloc_init and the second one in spi_setup_slave. I see that mem_alloc_init is hit first, and when spi_setup_slave is called, malloc is available. I get a valid pointer for the private structure. It seems there something in our config files that makes the things different. I do not yet know why.

Quoted 1 line

The C++ comments show original code, the line below is new.

Understood, if malloc is not called, we have to use static or (better) try to call mem_malloc_init() first

Quoted 1 line

I see a one byte access followed by a 5 byte access,

That is correct, you see the code in spi_flash.c. First the ID command is sent (0x97), without reading nothing (that is, din is NULL). Then the answer is read (dout is NULL), and the id buffer is 5 bytes long.

Quoted 48 lines

I assumed that u-boot spi drivers use only u8 buffers for simplicity. So my fix looks as this:

int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
void *din, unsigned long flags)

{
	int n_blks = (bitlen + 31) / 32;
	u32 out, in;
	u8 *in_b, *out_b;
	int i;
	
	out_b = (u8 *)dout;
	in_b = (u8 *)din;
	
	for(i = 0; i< n_blks; i++, bitlen -= 32) {
		if(dout) {
			out = out_b[0];
			if(bitlen > 8)
				out = (out<<8) | out_b[1];
			if(bitlen > 16)
				out = (out<<8) | out_b[2];
			if(bitlen > 24)
				out = (out<<8) | out_b[3];
			out_b += 4;
		} else {
			out=0;
		}
		in = spi_xchg_single(slave, out, bitlen, flags);
		if(din) {
			if(bitlen > 24) {
				in_b[3] = in & 0xff;
				in >>= 8;
			}
			if(bitlen > 16) {
				in_b[2] = in & 0xff;
				in >>= 8;
			}
			if(bitlen > 8) {
				in_b[1] = in & 0xff;
				in >>= 8;
			}
			in_b[0] = in & 0xff;
			in_b += 4;
		}
	}
	return 0;
}
Quoted 1 line

Does this sound like it could work?

I am trying another approach. As the MX51 has 32 bytes FIFO, it makes sense to use it and not send a single word, if we can. This must not change the behavior for the MX31, because this processor has no FIFO and a single word can be sent.
So I replaced completely spi_xfer, and the logic you put in spi_xfer I have (more or less, I have not checked in details) moved inside the spi_xcgh:single, that now has the meaning for me as single transation:
up to 1 word for i.MX31, up to 32 words (128 bytes) for i.MX51.

Take into account that loading the kernel using a single word takes a lot of time..

Quoted 6 lines
Quoted 2 lines

However, I am currently working on several issues for MX51. It should be nice to know which are your plans to save both some time ;-)

Well, I am in a bit of a hurry, and essentially what I need is to be able to access SPI-nor flash (spansion type) for environment and booting linux. MMC/SD access would be nice, but is not yet necessary.

Ok, quite the same. I have a ST flash, but we get the same problems, I see.

Quoted 5 lines

I know. I thought to do it in two steps: Fix mxc_spi.c with a workaround for the pmic driver (which amounts to '#define spi_xfer spi_xfer_fsl' at the beginning of this driver basically) and fix the pmic driver later, since it is probably not trivial, and needs to be done carefully (you know, one can smoke a board by mistake :-)

I know, this makes funny setting voltages via software....

Best regards,
Stefano

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#10 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Hi again,

Quoted 5 lines · Stefano Babic
Quoted 4 lines

Just figured out one big mistake. I was debugging spi_flash.c, and had CONFIG_ENV_IS_IN_SPI_FLASH set. That means, first SPI access is done before malloc is available, and guess what? spi_setup_slave() uses malloc ;-)

Quoted 8 lines

I have CONFIG_ENV_IS_IN_SPI_FLASH set, too.
I try to figure out how the functions are called, but I do not get the same issue. I set with the debugger two breakpoints, one in mem_malloc_init and the second one in spi_setup_slave. I see that mem_alloc_init is hit first, and when spi_setup_slave is called, malloc is available. I get a valid pointer for the private structure. It seems there something in our config files that makes the things different. I do not yet know why.

Are you sure? In arch/arm/lib/board.c function start_armboot(), init_sequence is processed first, which contains env_init() before dram_init() and just after completing init_sequence, mem_malloc_init() is called. How can you have working malloc then?

Quoted 4 lines
Quoted 1 line

The C++ comments show original code, the line below is new.

Understood, if malloc is not called, we have to use static or (better) try to call mem_malloc_init() first

I don't know if that is possible. I know that physically RAM is initialized before u-boot even starts (it runs from RAM), but logically, dram_init() is called _after_ env_init(), so I'm not sure if you are supposed to call mem_malloc_init() in env_init()...

Quoted 5 lines
Quoted 1 line

I see a one byte access followed by a 5 byte access,

That is correct, you see the code in spi_flash.c. First the ID command is sent (0x97), without reading nothing (that is, din is NULL). Then the answer is read (dout is NULL), and the id buffer is 5 bytes long.

I am slowly progressing... now the transfer succeeds, but I only read FF ;-)

Quoted 10 lines
Quoted 1 line

[...]

I am trying another approach. As the MX51 has 32 bytes FIFO, it makes sense to use it and not send a single word, if we can. This must not change the behavior for the MX31, because this processor has no FIFO and a single word can be sent.
So I replaced completely spi_xfer, and the logic you put in spi_xfer I have (more or less, I have not checked in details) moved inside the spi_xcgh:single, that now has the meaning for me as single transation:
up to 1 word for i.MX31, up to 32 words (128 bytes) for i.MX51.

Quoted 2 lines

Take into account that loading the kernel using a single word takes a lot of time..

A good point. I was following the premise that u-boot drivers should be simple, but a little bit of speed for booting is surely not a bad idea ;-)

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

However, I am currently working on several issues for MX51. It should be nice to know which are your plans to save both some time ;-)

Well, I am in a bit of a hurry, and essentially what I need is to be able to access SPI-nor flash (spansion type) for environment and booting linux. MMC/SD access would be nice, but is not yet necessary.

Ok, quite the same. I have a ST flash, but we get the same problems, I see.

I am just now picking up where I left last week, so give me a few hours and I should have something working, I guess.

Quoted 7 lines
Quoted 5 lines

I know. I thought to do it in two steps: Fix mxc_spi.c with a workaround for the pmic driver (which amounts to '#define spi_xfer spi_xfer_fsl' at the beginning of this driver basically) and fix the pmic driver later, since it is probably not trivial, and needs to be done carefully (you know, one can smoke a board by mistake :-)

I know, this makes funny setting voltages via software....

I always say: "Electronics work on smoke. If the smoke escapes, it stops working" :-)

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#11 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 2 lines · David Jander

I am just now picking up where I left last week, so give me a few hours and
I should have something working, I guess.

Ok, I guess I was pessimistic. There is a weird bug in mxc_spi.c: CPOL is negated!
I just saw that in the mx51evk.h header file CONFIG_FSL_PMIC_MODE was set to low-active clock (CPOL=1), which is not supposed to work. But it did work, and on the scope clock-polarity was active-high.

In spi_cfg(), I saw this line:

if (!(mode & SPI_CPOL))

	sclkpol = 1;

AFAIK, this should be:

if (mode & SPI_CPOL)

	sclkpol = 1;

At least for the MX51. Can you confirm that this is different on the MX31?

Now I get a correct flash id.

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#12 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 5 lines · David Jander

Ok, I guess I was pessimistic. There is a weird bug in mxc_spi.c: CPOL is negated!
I just saw that in the mx51evk.h header file CONFIG_FSL_PMIC_MODE was set to low-active clock (CPOL=1), which is not supposed to work. But it did work, and on the scope clock-polarity was active-high.

Ok

Quoted 4 lines

In spi_cfg(), I saw this line:

if (!(mode & SPI_CPOL))

Quoted 8 lines
	sclkpol = 1;

AFAIK, this should be:

if (mode & SPI_CPOL)

	sclkpol = 1;

At least for the MX51. Can you confirm that this is different on the MX31?

Agree. According to the MX51 Manual, the register must be set with:
0 Active high polarity (0 = Idle).
1 Active low polarity (1 = Idle).

So we need to change both CONFIG_FSL_PMIC_MODE in config and in mxc_spi.c. Do you send a patch or do you prefer I will do this job ? I will add your signed-off-by if you agree.

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#13 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Hi Stefano,

Quoted 11 lines · Stefano Babic

[...]

Quoted 10 lines

In spi_cfg(), I saw this line:

if (!(mode & SPI_CPOL))

	sclkpol = 1;

AFAIK, this should be:

if (mode & SPI_CPOL)

	sclkpol = 1;
Quoted 6 lines
Quoted 2 lines

At least for the MX51. Can you confirm that this is different on the MX31?

Agree. According to the MX51 Manual, the register must be set with:
0 Active high polarity (0 = Idle).
1 Active low polarity (1 = Idle).

I just checked in the reference manual of the i.MX31, and there the meaning of this bit has the same polarity as on the i.MX51, so you'll need to fix this also at the end of the spi_setup_slave() function, in the #else path of the #ifdef CONFIG_MX51 directive.

if (!(mode & SPI_CPOL))

	ctrl_reg |= MXC_CSPICTRL_POL;

should be:

if (mode & SPI_CPOL)

	ctrl_reg |= MXC_CSPICTRL_POL;

Would be nice if someone with a MX31 board could verify this.

Quoted 3 lines

So we need to change both CONFIG_FSL_PMIC_MODE in config and in mxc_spi.c. Do you send a patch or do you prefer I will do this job ? I will add your signed-off-by if you agree.

I agree, and I guess you can better include it in your patch-set, otherwise I'd have to wait for your patches and then provide my own patch on top of that.... too complicated :-)

I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later.

Right now I have correct detection of the chip, but the environment is not saved and read back correctly. Still investigating... maybe some chip configuration prolem in the spansion driver?

Best regards,

Signature · 2 lines
David Jander
Protonic Holland.
#14 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 2 lines · David Jander

Hi Stefano,

Hi David,

Quoted 6 lines

I just checked in the reference manual of the i.MX31, and there the meaning of this bit has the same polarity as on the i.MX51, so you'll need to fix this also at the end of the spi_setup_slave() function, in the #else path of the #ifdef CONFIG_MX51 directive.

if (!(mode & SPI_CPOL))

Quoted 8 lines
	ctrl_reg |= MXC_CSPICTRL_POL;

should be:

if (mode & SPI_CPOL)

	ctrl_reg |= MXC_CSPICTRL_POL;

Would be nice if someone with a MX31 board could verify this.

I can test myself on a qong board - I hope someone else can test on other MX.31 boards.

Quoted 3 lines

I agree, and I guess you can better include it in your patch-set, otherwise I'd have to wait for your patches and then provide my own patch on top of that.... too complicated :-)

I will do it - I think I could send in a short time the whole patchset for review :-).

Quoted 3 lines

I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later.

I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC).

Quoted 3 lines

Right now I have correct detection of the chip, but the environment is not saved and read back correctly. Still investigating... maybe some chip configuration prolem in the spansion driver?

Probably. I have got some issues with the ST that do not depend from the modifications in SPI driver.

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#15 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 6 lines · On Monday 23 August 2010 17:55:44 Stefano Babic wrote:
Quoted 2 lines

I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later.

I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC).

Small correction:

I'm not the custodian of the "MTD subsystem", but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here.

Cheers,
Stefan

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

#16 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Hi Stefan,

Quoted 8 lines · On Monday 23 August 2010 17:55:44 Stefano Babic wrote:
Quoted 6 lines
Quoted 2 lines

I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later.

I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC).

Quoted 6 lines

Small correction:

I'm not the custodian of the "MTD subsystem", but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here.

In fact I cannot see that you extended the CC list. Wanna have another go? ;)

Cheers
Detlev

Signature · 8 lines
Paul Simon sang "Fifty Ways to Lose Your Lover", because quite
frankly, "A Million Ways to Tell a Developer He Is a D*ckhead"
doesn't scan nearly as well.  But I'm sure he thought about it.
                            -- linux/Documentation/ManagementStyle
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
#17 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Quoted 11 lines · On Monday, August 23, 2010 17:03:24 Detlev Zundel wrote:

Hi Stefan,

Quoted 10 lines · On Monday 23 August 2010 17:55:44 Stefano Babic wrote:
Quoted 6 lines
Quoted 2 lines

I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later.

I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC).

Small correction:

Quoted 7 lines
Quoted 4 lines

I'm not the custodian of the "MTD subsystem", but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here.

In fact I cannot see that you extended the CC list. Wanna have another go? ;)

i did since he added me to the cc ...

but as David said, he posted a sep patch, so i'll stick to that thread. i generally delete threads about parts i dont care about (like whatever a "MX3" and "MX5" are).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100823/48105c27/attachment.pgp

#18 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

Hi Mike,

Quoted 17 lines · On Monday, August 23, 2010 17:03:24 Detlev Zundel wrote:
Quoted 16 lines

Hi Stefan,

Quoted 14 lines · On Monday 23 August 2010 17:55:44 Stefano Babic wrote:
Quoted 6 lines
Quoted 2 lines

I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later.

I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC).

Small correction:

I'm not the custodian of the "MTD subsystem", but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here.

Quoted 4 lines
Quoted 2 lines

In fact I cannot see that you extended the CC list. Wanna have another go? ;)

i did since he added me to the cc ...

Hm, hm, hm. That strange invisible CC phaenomenon again. I just checked again and on the mail that I received you are definitely not on the CC list....

Anyway, sorry for the noise
Detlev

Signature · 6 lines
To you I'm an atheist; to God, I'm the Loyal Opposition.
                                        -- Woody Allen
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
#19 lore raw

PATCH 1/1 Use common function to set GPIOs for MX3 and MX5

In reply to David Jander
Quoted 2 lines · David Jander

Hi again,

Hi David,

Quoted 4 lines

Are you sure? In arch/arm/lib/board.c function start_armboot(), init_sequence is processed first, which contains env_init() before dram_init() and just after completing init_sequence, mem_malloc_init() is called. How can you have working malloc then?

Well, I tried to investigate to see if I get the same issue, env_init is called before mem_malloc_init, but it does nothing (in env_sf.c):

int env_init(void)

{
        /* SPI flash isn't usable before relocation */
        gd->env_addr = (ulong)&default_environment[0];
        gd->env_valid = 1;

        return 0;
}

And really I can see that mem_malloc_init() is called before spi_setup_slave(). I guess there is a different configuration on our targets, that makes the difference, but I do not know which one.

Quoted 4 lines

I don't know if that is possible. I know that physically RAM is initialized before u-boot even starts (it runs from RAM), but logically, dram_init() is called _after_ env_init(), so I'm not sure if you are supposed to call mem_malloc_init() in env_init()...

Yes, but as I see env_init does not read from flash and does not call spi_setup_flash(). This is done by env_relocate_spec(), but this function is called later.

Quoted 1 line

I am slowly progressing... now the transfer succeeds, but I only read FF ;-)

I think I have a good status now. I can correctly read/write the whole flash. I have still an issue with saveenv (the first time does not work, and it works after I called "sf probe"...crazy, but probably depends on my target, I am investigating), but I should find a fix for that too.

Quoted 2 lines

A good point. I was following the premise that u-boot drivers should be simple, but a little bit of speed for booting is surely not a bad idea ;-)

Even using the whole FIFO I need about 8 Seconds to read the whole Flash (4 MB). In normal case, this means I need 3 Seconds for a kernel.

Quoted 2 lines

I am just now picking up where I left last week, so give me a few hours and I should have something working, I guess.

Ok. We can make a point later. As I said, things are not so bad on my target.

Quoted 2 lines

I always say: "Electronics work on smoke. If the smoke escapes, it stops working" :-)

;-)))

Best regards,
Stefano

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#20 lore raw

PATCH v2 1/1 Use common function to set GPIOs for MX3 and MX5

In reply to Stefano Babic

The patch adds support for setting gpios to the MX51 processor and change name to the corresponding functions for MX31. In this way, it is possible to get rid of nasty #ifdef switches related to the processor type.

---
 arch/arm/include/asm/arch-mx31/mx31-regs.h |   14 +++-
 arch/arm/include/asm/arch-mx31/mx31.h      |   25 -------
 arch/arm/include/asm/arch-mx51/imx-regs.h  |    6 ++
 board/davedenx/qong/qong.c                 |   29 ++++----
 drivers/gpio/Makefile                      |    2 +-
 drivers/gpio/mx31_gpio.c                   |   88 -----------------------
 drivers/gpio/mxc_gpio.c                    |  107 ++++++++++++++++++++++++++++
 drivers/spi/mxc_spi.c                      |   15 ++--
 include/configs/imx31_phycore.h            |    2 +-
 include/configs/qong.h                     |    2 +-
 include/mxc_gpio.h                         |   52 +++++++++++++
 11 files changed, 201 insertions(+), 141 deletions(-)
 delete mode 100644 drivers/gpio/mx31_gpio.c
 create mode 100644 drivers/gpio/mxc_gpio.c
 create mode 100644 include/mxc_gpio.h
arch/arm/include/asm/arch-mx31/mx31-regs.h +11 -3
index d72585c..f05e743 100644
@@ -57,6 +57,14 @@ struct clock_control_regs {
 	u32 pdr2;
 };
 
+/* GPIO Registers */
+struct gpio_regs {
+	u32	gpio_dr;
+	u32	gpio_dir;
+	u32	gpio_psr;
+};
+
+
 /* Bit definitions for RCSR register in CCM */
 #define CCM_RCSR_NF16B	(1 << 31)
 #define CCM_RCSR_NFMS	(1 << 30)
@@ -153,9 +161,9 @@ struct clock_control_regs {
 /*
  * GPIO
  */
-#define GPIO1_BASE	0x53FCC000
-#define GPIO2_BASE	0x53FD0000
-#define GPIO3_BASE	0x53FA4000
+#define GPIO1_BASE_ADDR	0x53FCC000
+#define GPIO2_BASE_ADDR	0x53FD0000
+#define GPIO3_BASE_ADDR	0x53FA4000
 #define GPIO_DR		0x00000000	/* data register */
 #define GPIO_GDIR	0x00000004	/* direction register */
 #define GPIO_PSR	0x00000008	/* pad status register */
arch/arm/include/asm/arch-mx31/mx31.h +0 -25
index f702d26..5a5aa11 100644
@@ -28,31 +28,6 @@ extern u32 mx31_get_ipg_clk(void);
 #define imx_get_uartclk mx31_get_ipg_clk
 extern void mx31_gpio_mux(unsigned long mode);
 
-enum mx31_gpio_direction {
-	MX31_GPIO_DIRECTION_IN,
-	MX31_GPIO_DIRECTION_OUT,
-};
-
-#ifdef CONFIG_MX31_GPIO
-extern int mx31_gpio_direction(unsigned int gpio,
-			       enum mx31_gpio_direction direction);
-extern void mx31_gpio_set(unsigned int gpio, unsigned int value);
-extern int mx31_gpio_get(unsigned int gpio);
-#else
-static inline int mx31_gpio_direction(unsigned int gpio,
-				      enum mx31_gpio_direction direction)
-{
-	return 1;
-}
-static inline int mx31_gpio_get(unsigned int gpio)
-{
-	return 1;
-}
-static inline void mx31_gpio_set(unsigned int gpio, unsigned int value)
-{
-}
-#endif
-
 void mx31_uart1_hw_init(void);
 void mx31_spi2_hw_init(void);
 
arch/arm/include/asm/arch-mx51/imx-regs.h +6 -0
index 3887d3c..0e3bc2a 100644
@@ -256,6 +256,12 @@ struct weim {
 	u32	cswcr2;
 };
 
+/* GPIO Registers */
+struct gpio_regs {
+	u32	gpio_dr;
+	u32	gpio_dir;
+	u32	gpio_psr;
+};
 #endif /* __ASSEMBLER__*/
 
 #endif				/*  __ASM_ARCH_MXC_MX51_H__ */
board/davedenx/qong/qong.c +15 -14
index 781333b..59589c2 100644
@@ -27,6 +27,7 @@
 #include <asm/arch/mx31-regs.h>
 #include <nand.h>
 #include <fsl_pmic.h>
+#include <mxc_gpio.h>
 #include "qong_fpga.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -42,9 +43,9 @@ int dram_init (void)
 
 static void qong_fpga_reset(void)
 {
-	mx31_gpio_set(QONG_FPGA_RST_PIN, 0);
+	mxc_gpio_set(QONG_FPGA_RST_PIN, 0);
 	udelay(30);
-	mx31_gpio_set(QONG_FPGA_RST_PIN, 1);
+	mxc_gpio_set(QONG_FPGA_RST_PIN, 1);
 
 	udelay(300);
 }
@@ -115,11 +116,11 @@ int board_init (void)
 
 	/* FPGA reset  Pin */
 	/* rstn = 0 */
-	mx31_gpio_set(QONG_FPGA_RST_PIN, 0);
-	mx31_gpio_direction(QONG_FPGA_RST_PIN, MX31_GPIO_DIRECTION_OUT);
+	mxc_gpio_set(QONG_FPGA_RST_PIN, 0);
+	mxc_gpio_direction(QONG_FPGA_RST_PIN, MXC_GPIO_DIRECTION_OUT);
 
 	/* set interrupt pin as input */
-	mx31_gpio_direction(QONG_FPGA_IRQ_PIN, MX31_GPIO_DIRECTION_IN);
+	mxc_gpio_direction(QONG_FPGA_IRQ_PIN, MXC_GPIO_DIRECTION_IN);
 
 #endif
 
@@ -201,27 +202,27 @@ static void board_nand_setup(void)
 	qong_fpga_reset();
 
 	/* Enable NAND flash */
-	mx31_gpio_set(15, 1);
-	mx31_gpio_set(14, 1);
-	mx31_gpio_direction(15, MX31_GPIO_DIRECTION_OUT);
-	mx31_gpio_direction(16, MX31_GPIO_DIRECTION_IN);
-	mx31_gpio_direction(14, MX31_GPIO_DIRECTION_IN);
-	mx31_gpio_set(15, 0);
+	mxc_gpio_set(15, 1);
+	mxc_gpio_set(14, 1);
+	mxc_gpio_direction(15, MXC_GPIO_DIRECTION_OUT);
+	mxc_gpio_direction(16, MXC_GPIO_DIRECTION_IN);
+	mxc_gpio_direction(14, MXC_GPIO_DIRECTION_IN);
+	mxc_gpio_set(15, 0);
 
 }
 
 int qong_nand_rdy(void *chip)
 {
 	udelay(1);
-	return mx31_gpio_get(16);
+	return mxc_gpio_get(16);
 }
 
 void qong_nand_select_chip(struct mtd_info *mtd, int chip)
 {
 	if (chip >= 0)
-		mx31_gpio_set(15, 0);
+		mxc_gpio_set(15, 0);
 	else
-		mx31_gpio_set(15, 1);
+		mxc_gpio_set(15, 1);
 
 }
 
drivers/gpio/Makefile +1 -1
index 528ca2e..738396a 100644
@@ -27,7 +27,7 @@ LIB 	:= $(obj)libgpio.a
 
 COBJS-$(CONFIG_AT91_GPIO)	+= at91_gpio.o
 COBJS-$(CONFIG_KIRKWOOD_GPIO)	+= kw_gpio.o
-COBJS-$(CONFIG_MX31_GPIO)	+= mx31_gpio.o
+COBJS-$(CONFIG_MXC_GPIO)	+= mxc_gpio.o
 COBJS-$(CONFIG_PCA953X)		+= pca953x.o
 COBJS-$(CONFIG_S5PC1XX)		+= s5p_gpio.o
 
drivers/gpio/mx31_gpio.c deleted +0 -88

88 lines not on this page · raw message

drivers/gpio/mxc_gpio.c new file +107 -0

107 lines not on this page · raw message

drivers/spi/mxc_spi.c +7 -8
index e15a63c..802cd2e 100644
@@ -23,6 +23,7 @@
 #include <spi.h>
 #include <asm/errno.h>
 #include <asm/io.h>
+#include <mxc_gpio.h>
 
 #ifdef CONFIG_MX27
 /* i.MX27 has a completely wrong register layout and register definitions in the
@@ -68,9 +69,6 @@ static unsigned long spi_bases[] = {
 	0x53f84000,
 };
 
-#define OUT	MX31_GPIO_DIRECTION_OUT
-#define mxc_gpio_direction	mx31_gpio_direction
-#define mxc_gpio_set		mx31_gpio_set
 #elif defined(CONFIG_MX51)
 #include <asm/arch/imx-regs.h>
 #include <asm/arch/clock.h>
@@ -111,13 +109,12 @@ static unsigned long spi_bases[] = {
 	CSPI2_BASE_ADDR,
 	CSPI3_BASE_ADDR,
 };
-#define mxc_gpio_direction(gpio, dir)	(0)
-#define mxc_gpio_set(gpio, value)	{}
-#define OUT	1
 #else
 #error "Unsupported architecture"
 #endif
 
+#define OUT	MXC_GPIO_DIRECTION_OUT
+
 struct mxc_spi_slave {
 	struct spi_slave slave;
 	unsigned long	base;
@@ -126,6 +123,7 @@ struct mxc_spi_slave {
 	u32		cfg_reg;
 #endif
 	int		gpio;
+	int		ss_pol;
 };
 
 static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
@@ -147,7 +145,7 @@ void spi_cs_activate(struct spi_slave *slave)
 {
 	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
 	if (mxcs->gpio > 0)
-		mxc_gpio_set(mxcs->gpio, mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL);
+		mxc_gpio_set(mxcs->gpio, mxcs->ss_pol);
 }
 
 void spi_cs_deactivate(struct spi_slave *slave)
@@ -155,7 +153,7 @@ void spi_cs_deactivate(struct spi_slave *slave)
 	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
 	if (mxcs->gpio > 0)
 		mxc_gpio_set(mxcs->gpio,
-			      !(mxcs->ctrl_reg & MXC_CSPICTRL_SSPOL));
+			      !(mxcs->ss_pol));
 }
 
 #ifdef CONFIG_MX51
@@ -394,6 +392,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
 	mxcs->slave.bus = bus;
 	mxcs->slave.cs = cs;
 	mxcs->base = spi_bases[bus];
+	mxcs->ss_pol = (mode & SPI_CS_HIGH) ? 1 : 0;
 
 #ifdef CONFIG_MX51
 	/* Can be used for i.MX31 too ? */
include/configs/imx31_phycore.h +1 -1
index 1dbafa0..62944a9 100644
@@ -183,7 +183,7 @@
 #ifdef CONFIG_IMX31_PHYCORE_EET
 #define BOARD_LATE_INIT
 
-#define CONFIG_MX31_GPIO			1
+#define CONFIG_MXC_GPIO
 
 #define CONFIG_HARD_SPI				1
 #define CONFIG_MXC_SPI				1
include/configs/qong.h +1 -1
index 100fa3f..2ee1d60 100644
@@ -52,7 +52,7 @@
 #define CONFIG_MXC_UART	1
 #define CONFIG_SYS_MX31_UART1	1
 
-#define CONFIG_MX31_GPIO
+#define CONFIG_MXC_GPIO
 
 #define CONFIG_MXC_SPI
 #define CONFIG_DEFAULT_SPI_BUS	1
include/mxc_gpio.h new file +52 -0

52 lines not on this page · raw message

Signature · 1 line
1.6.3.3