Use common function to set GPIOs for MX3 and MX5
Subsystems (4)
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
@@ -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
@@ -28,31 +28,6 @@ extern u32 mx31_get_ipg_clk(void);#define imx_get_uartclk mx31_get_ipg_clkextern 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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.
PATCH 1/1 Use common function to set GPIOs for MX3 and MX5
In reply to Stefano BabicHi Stefano,
Quoted 23 lines · Stefano Babic
drivers/spi/mxc_spi.c +1
-0@@ -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
-30x53f84000, }; -#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.
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 =====================================================================
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_polin 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.
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
voidspi_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 =====================================================================
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
voidspi_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.
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 whyspi_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 renamedspi_xfer()tospi_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 =====================================================================
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 whyspi_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 renamedspi_xfer()tospi_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.
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 whyspi_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 hadCONFIG_ENV_IS_IN_SPI_FLASHset. 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.cwith a workaround for the pmic driver (which amounts to '#definespi_xferspi_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 =====================================================================
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 hadCONFIG_ENV_IS_IN_SPI_FLASHset. 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_FLASHset, 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 inmem_malloc_initand the second one inspi_setup_slave. I see thatmem_alloc_initis hit first, and whenspi_setup_slaveis 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 completelyspi_xfer, and the logic you put inspi_xferI 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.cwith a workaround for the pmic driver (which amounts to '#definespi_xferspi_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.
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.
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 themx51evk.hheader fileCONFIG_FSL_PMIC_MODEwas 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 =====================================================================
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_MODEin config and inmxc_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.
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 #ifdefCONFIG_MX51directive.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 =====================================================================
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
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.dePATCH 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
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.dePATCH 1/1 Use common function to set GPIOs for MX3 and MX5
In reply to David JanderQuoted 2 lines · David Jander
Hi again,
Hi David,
Quoted 4 lines
Are you sure? In
arch/arm/lib/board.cfunctionstart_armboot(),init_sequenceis processed first, which containsenv_init()beforedram_init()and just after completinginit_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 callmem_malloc_init()inenv_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 =====================================================================
PATCH v2 1/1 Use common function to set GPIOs for MX3 and MX5
In reply to Stefano BabicThe 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
@@ -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
@@ -28,31 +28,6 @@ extern u32 mx31_get_ipg_clk(void);#define imx_get_uartclk mx31_get_ipg_clkextern 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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