Adds driver for Xilinx' xps_spi SPI controller.

drivers/spi/xilinx_spi.c new file +4 -0

 
+static ulong xilinx_spi_base_list[] = {
+#ifdef XPAR_SPI_0_BASEADDR
+	XPAR_SPI_0_BASEADDR,
+#endif

drivers/spi/Makefile include $(TOPDIR)/config.mk · line 30

Quoted 7 lines · On Tuesday, August 03, 2010 11:47:42 Graeme Smecher wrote:

drivers/spi/Makefile +1 -0

 
  COBJS-$(CONFIG_ALTERA_SPI) += altera_spi.o
+COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o
  COBJS-$(CONFIG_ATMEL_DATAFLASH_SPI) += atmel_dataflash_spi.o

this is a sorted list. please keep it that way

Quoted 12 lines

drivers/spi/xilinx_spi.c new file +9 -0

 
+static ulong xilinx_spi_base_list[] = {
+#ifdef XPAR_SPI_0_BASEADDR
+	XPAR_SPI_0_BASEADDR,
+#endif
+#ifdef XPAR_SPI_1_BASEADDR
+	XPAR_SPI_1_BASEADDR,
+#endif
+#ifdef XPAR_SPI_2_BASEADDR
+	XPAR_SPI_2_BASEADDR,

drivers/spi/xilinx_spi.c line 44

Quoted 6 lines

drivers/spi/xilinx_spi.c new file +5 -0

+#endif
+#ifdef XPAR_SPI_3_BASEADDR
+	XPAR_SPI_3_BASEADDR,
+#endif
+};

if this is only ever read, you might want to declare it const so it ends up in the rodata section.

what if someone defines just XPAR_SPI_3_BASEADDR ? do you want to be consistent in bus id 3 always corresponds to XPAR_SPI_3_BASEADDR ? or are you OK with the numbers always being relative ? doesnt matter to me, just highlighting some things that might have been missed.

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Documentation for the SPI core is available here:

http://www.xilinx.com/support/documentation/ip_documentation/xps_spi.pdf

Signed-off-by Graeme Smecher<[email protected]>

---
  drivers/spi/Makefile     |    1 +
  drivers/spi/xilinx_spi.c |  173 ++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 174 insertions(+), 0 deletions(-)

create mode 100644 drivers/spi/xilinx_spi.c

Quoted 5 lines · Graeme Smecher

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Documentation for the SPI core is available here:

Quoted 9 lines

http://www.xilinx.com/support/documentation/ip_documentation/xps_spi.pdf

Signed-off-by Graeme Smecher<[email protected]>

---
  drivers/spi/Makefile     |    1 +
  drivers/spi/xilinx_spi.c |  173 ++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 174 insertions(+), 0 deletions(-)

create mode 100644 drivers/spi/xilinx_spi.c

Just a friendly reminder -- I'd be really happy to see this, and my other patch (July 29, "Add support for Winbond W25Q64 SPI flash"), integrated into the tree. Please let me know if there's anything I can do to grease the skids.

Hi,

Quoted 17 lines · On Tue, 17 Aug 2010 09:27:10 -0700 Graeme…

Quoted 5 lines · Graeme Smecher

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Documentation for the SPI core is available here:

Quoted 10 lines

http://www.xilinx.com/support/documentation/ip_documentation/xps_spi.pdf

Signed-off-by Graeme Smecher<[email protected]>

---
   drivers/spi/Makefile     |    1 +
   drivers/spi/xilinx_spi.c |  173 ++++++++++++++++++++++++++++++++++++++++++++++
   2 files changed, 174 insertions(+), 0 deletions(-)

create mode 100644 drivers/spi/xilinx_spi.c

Quoted 5 lines

Just a friendly reminder -- I'd be really happy to see this, and my other patch (July 29, "Add support for Winbond W25Q64 SPI flash"), integrated into the tree. Please let me know if there's anything I can do to grease the skids.

Thanks! But both, this and your other patch have been submitted when the merge window for next v2010.09 release was closed. So the patches probably won't be integrated before the next merge window opens, since these are not bug fixes. Normally you do not have to resubmit the patches when the next merge window opens again, maybe send a reminder again. Some info about release cycle can be found here [1].

Best regards,
Anatolij

[1] http://www.denx.de/wiki/U-Boot/ReleaseCycle

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Dear Graeme Smecher,

In message<[email protected]> you wrote:

Quoted 3 lines

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Hm... if the core really differs in only trivial ways from the altera_spi driver, then why do we need a duplication of that code?

Can we plase have a single driver source that supports both instead?

Hi Wolfgang,

Quoted 3 lines · Wolfgang Denk

Dear Graeme Smecher,

In message<[email protected]>

Quoted 8 lines

Quoted 3 lines

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Hm... if the core really differs in only trivial ways from the altera_spi driver, then why do we need a duplication of that code?

Can we plase have a single driver source that supports both instead?

Hm... It's possible to combine xilinx_spi.c and altera_spi.c. However, I suspect joining them will make maintenance more complicated rather than simpler. I can't, for example, test a combined driver on Altera hardware (and the Altera maintainer will likely have the same problem with Xilinx hardware.)

My guess is that most SPI interfaces are nearly identical at a register level, especially for drivers that don't support interrupts and other complications. (See mxc_spi.c for another example.) Xilinx and Altera's SPI interfaces are just two examples that happen to both be FPGA-based -- I could probably have adapted any of the other SPI drivers instead.

Are you sure combining drivers is the most logical approach? Let me know, and I'll have a crack at it.

thanks,
Graeme

Dear Graeme Smecher,

Quoted 6 lines

Hi Wolfgang,

Quoted 3 lines · Wolfgang Denk

Dear Graeme Smecher,

In message<[email protected]>

Quoted 19 lines · you

Quoted 7 lines

Quoted 3 lines

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Hm... if the core really differs in only trivial ways from the altera_spi driver, then why do we need a duplication of that code?

Can we plase have a single driver source that supports both instead?

Hm... It's possible to combine xilinx_spi.c and altera_spi.c. However, I suspect joining them will make maintenance more complicated rather than simpler. I can't, for example, test a combined driver on Altera hardware (and the Altera maintainer will likely have the same problem with Xilinx hardware.)

My guess is that most SPI interfaces are nearly identical at a register level, especially for drivers that don't support interrupts and other complications. (See mxc_spi.c for another example.) Xilinx and Altera's SPI interfaces are just two examples that happen to both be FPGA-based -- I could probably have adapted any of the other SPI drivers instead.

Quoted 5 lines

Are you sure combining drivers is the most logical approach? Let me know, and I'll have a crack at it.

thanks,
Graeme

What was the conclusion here? Shall I drop the patch or will you submit a rebased version?

Hi Marek,

Quoted 39 lines · Marek Vasut

Dear Graeme Smecher,

Quoted 8 lines

Hi Wolfgang,

Quoted 5 lines · Wolfgang Denk

Dear Graeme Smecher,

In message<[email protected]

Quoted 1 line

Quoted 26 lines · you

Quoted 8 lines

Quoted 3 lines

This code differs in only trivial ways from the altera_spi driver. It plays nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

Hm... if the core really differs in only trivial ways from the altera_spi driver, then why do we need a duplication of that code?

Can we plase have a single driver source that supports both instead?

Hm... It's possible to combine xilinx_spi.c and altera_spi.c. However, I suspect joining them will make maintenance more complicated rather than simpler. I can't, for example, test a combined driver on Altera hardware (and the Altera maintainer will likely have the same problem with Xilinx hardware.)

My guess is that most SPI interfaces are nearly identical at a register level, especially for drivers that don't support interrupts and other complications. (See mxc_spi.c for another example.) Xilinx and Altera's SPI interfaces are just two examples that happen to both be FPGA-based -- I could probably have adapted any of the other SPI drivers instead.

Are you sure combining drivers is the most logical approach? Let me know, and I'll have a crack at it.

thanks,
Graeme

Quoted 2 lines

What was the conclusion here? Shall I drop the patch or will you submit a rebased version?

Please drop the patch for now, since I'm not in a position to maintain it. The trail of bread-crumbs on the mailing list is a good compromise until someone (me, later on?) steps up.

thanks,
Graeme