RE: i2c-davinci.c: CPU FREQ causes lock up due to xfr_complete
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jon Cormier Sent: Tuesday, July 29, 2014 9:20 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: Tim Iskander Subject: i2c-davinci.c: CPU FREQ causes lock up due to xfr_complete Reported issue: 1. Enable I2C1, flash the new kernel and reboot 2. Immediately after reboot, attempt to change the processor clock: echo 456000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed 3. Process blocks However, if we do the following: 1. Enable I2C1, flash the new kernel and reboot 2. Immediately after reboot, run: i2cdetect -y 2 0x08 0x08 or just i2cdetect -y 2 3. Then run: echo 456000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed 4. Command succeeds I found this problem as well, and I haven't had time to put together a proper patch. Right now we're just working around it. There are several problems with the use of a completion for this task: 1. If no I2C transfer has occurred, a cpufreq transition will block forever (which is the bug you found) 2. Once an I2C transfer has occurred the cpufreq transition will never block since the completion is never reinitialized. 3. Even if you do reinitialize the completion for every I2C transfer, (1) is not solved and there is still a race condition where the cpufreq transition could start just before an I2C transfer starts and the I2C transfer occurs during the cpufreq transition. Personally I think the correct solution is to use a mutex instead of a completion. The cpufreq code would take the mutex during the prechange callback and release it during the postchange callback. Likewise the I2C transfer function would hold the mutex while an I2C transfer is ongoing. That way an I2C transfer cannot occur during a cpufreq transition and vice-versa. As I mentioned, I have not had time to put together a proper patch, but I would be happy to see this issue addressed if someone else can do it. Here's the kernel hung task stack trace: INFO: task sh:1428 blocked for more than 120 seconds. echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. sh D c026dc74 0 1428 1426 0x [c026dc74] (schedule+0x2a8/0x334) from [c026e2e0] (schedule_timeout+0x1c/0x218) [c026e2e0] (schedule_timeout+0x1c/0x218) from [c026e164] (wait_for_common+0xf0/0x1b8) [c026e164] (wait_for_common+0xf0/0x1b8) from [c019ca1c] (i2c_davinci_cpufreq_transition+0x18/0x50) [c019ca1c] (i2c_davinci_cpufreq_transition+0x18/0x50) from [c00599a4] (notifier_call_chain+0x38/0x68) [c00599a4] (notifier_call_chain+0x38/0x68) from [c0059a80] (__srcu_notifier_call_chain+0x40/0x58) [c0059a80] (__srcu_notifier_call_chain+0x40/0x58) from [c0059aac] (srcu_notifier_call_chain+0x14/0x18) [c0059aac] (srcu_notifier_call_chain+0x14/0x18) from [c019dd78] (cpufreq_notify_transition+0xc8/0xfc) [c019dd78] (cpufreq_notify_transition+0xc8/0xfc) from [c00373ac] (davinci_target+0x144/0x154) [c00373ac] (davinci_target+0x144/0x154) from [c019d404] (__cpufreq_driver_target+0x28/0x38) [c019d404] (__cpufreq_driver_target+0x28/0x38) from [c019f260] (cpufreq_set+0x54/0x70) [c019f260] (cpufreq_set+0x54/0x70) from [c019d698] (store_scaling_setspeed+0x58/0x6c) [c019d698] (store_scaling_setspeed+0x58/0x6c) from [c019e3d0] (store+0x58/0x74) [c019e3d0] (store+0x58/0x74) from [c00d8854] (sysfs_write_file+0x108/0x140) [c00d8854] (sysfs_write_file+0x108/0x140) from [c009512c] (vfs_write+0xb0/0x118) [c009512c] (vfs_write+0xb0/0x118) from [c0095244] (sys_write+0x3c/0x68) [c0095244] (sys_write+0x3c/0x68) from [c002bea0] (ret_fast_syscall+0x0/0x28) Kernel panic - not syncing: hung_task: blocked tasks [c003069c] (unwind_backtrace+0x0/0xd0) from [c026d810] (panic+0x44/0xc8) [c026d810] (panic+0x44/0xc8) from [c006aa7c] (watchdog+0x1d4/0x21c) [c006aa7c] (watchdog+0x1d4/0x21c) from [c0054670] (kthread+0x78/0x80) [c0054670] (kthread+0x78/0x80) from [c002c8dc] (kernel_thread_exit+0x0/0x8) According to the stack trace the kernel gets stuck in the i2c_davinci_cpufreq_transition function when it calls wait_for_completion(dev-xfr_complete); The two other places this xfr_complete variable is referenced is the init_completion in the probe and the complete at the end of the i2c_davinci_xfer function. My understanding as to what this was intended for was to ensure that a transfer in progress completed before changing the clock frequency. But as its currently done the only thing it does is make sure there has been a completed i2c transfer on this device ever. Is my understanding correct? Currently the workaround is to simply disable the wait_for_completion as seen below. How would you fix this to ensure a transfer in progress completes before changing clocks without hanging if no transfer was ever attempted? diff --git a/drivers/i2c/busses/i2c-davinci.c
L138/DA850 USB support in mainline?
What is the current level of support for USB on L138/DA850 in the mainline kernel? A similar question was asked here: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-Jul y/023201.html but not really answered. I'm curious because TI's site at: http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel seems to suggest that USB is still not there, but from reading forum posts it seems as if people are using USB on L138/DA850 with mainline kernels. We are currently using a TI release, but I would like to migrate to a mainline version. USB appears to be the only questionable feature at this point. Can anyone clarify what support might be missing before I take the time to make the jump, only to find out that it's not going to work anyway? I don't mind doing some work to glue pieces together, but if major functionality is missing, it would be nice to know beforehand. Thanks for the help! Brian Brian Niebuhr Principal Design Engineer EF Johnson 3900 NW 12th St. Ste. 200 Lincoln, NE 68521 402-479-8434 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: SPI Transfer 64KB - OMAP-L138
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Stefano Babic Sent: Wednesday, March 09, 2011 5:02 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: SPI Transfer 64KB - OMAP-L138 Hi, I have seen an issue transfering blocks = 64KiB on the SPI interface with the OMAP-L138. The problem seems to me similar (I think it is the same) as I the one already found in archive: http://comments.gmane.org/gmane.linux.davinci/20581 I am testing with 2.6.38 kernel, after I have applied all recent patches recently sent to add spi support for this processor (mainly to set up the platform devices). I can confirm that transfering blocks smaller as 64KiB works flawlessly. Reading the archive, it seems to me that this issue is not yet solved. However, before going to a deeper analyses, I would like to know if someone else has seen the same problem, and if there is already a fix for it. As far as I am aware there have not been any patches to address this issue. As Sekhar noted in the email thread you referenced, the best solution would probably be to add another dimension to the DMA transfer. I don't think it would be terribly difficult, but it's also not nearly as straightforward as the existing implementation. Regards, Brian Best regards, Stefano Babic -- = 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: off...@denx.de = ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMAproblem
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Pierre Sent: Tuesday, November 23, 2010 5:13 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMAproblem Hi, I have tested the new driver using DMA mode on our custom DM355 board. I replaced the linux 2.6.32 spi driver by this driver and it seemed to work except for on point. The dm355 spi polling mode was correctly working but the DMA mode was causing some communication problems. It appeared that when dm355 was reading on the spi, it was actually resending received data to our slave device on the spi bus, i didn't fully checked what i am saying i am just supposing that it's what occured. If I understand you correctly, what you are saying is that when you are trying to read data from your SPI device, the data on the DM355 output signal (MOSI) is not what you expected, and is causing issues. If that is the case, I can say that I made no effort to make sure that the inactive portion of a half-duplex SPI transfer had any particular data pattern. In other words, if you have been getting a certain pattern of outbound data it is purely coincidence, and the different implementations of polled and DMA mode expose the fact that you had been getting lucky. I am not a SPI expert by any means, but it has been my approach that SPI is a full-duplex protocol and you need to specify outbound data if you want certain outbound data sent. As it turns out, most SPI devices have a protocol for determining when they are supposed to be sending or receiving, and if the device is sending it usually ignores whatever it is receiving. You mention in your later email that using a zeroed Tx buffer makes everything work OK. I think that's actually the most correct solution. The driver could be modified to ensure that it transmits zeros on a half-duplex read, and maybe it should, but I think the best solution is for the application to specify what it wants to be sent and not rely on non-portable behavior from a driver. If I'm misunderstanding the problem, then just ignore all of the above :-) Anyway the behaviour was different in DMA and polling mode. I didn't dig deep into the driver i just solved the problem (quick and dirty) by setting tx buffer to zero in the spidev driver. The problem can be caused by using SPIDAT as dma buffer when the tx buffer is empty. (If it helps i have tested before the spi patch V5 from Brian Niebuhr and the problem was already there) So is this a bug or a feature ? I don't have time right know to work on that problem but i can test solutions if anyone have. Regards. Pierre ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v5 0/1] davinci: spi: replace existing driver
Fixed in this version: - Addressed all comments from the previous version ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/dm355.c |8 +- arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/include/mach/spi.h| 35 +- drivers/spi/davinci_spi.c | 1098 --- 7 files changed, 521 insertions(+), 656 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v5 1/1] davinci: spi: replace existing driver
INTRODUCTION
I have been working on a custom OMAP-L138 board that has multiple spi
devices (seven) on one controller. These devices have a wide range of
transfer parameters (speed, phase, polarity, internal and gpio chip
selects). During my testing I found multiple errors in the davinci spi
driver as a result of this complex setup. The primary issues were:
1. There is a race condition due to the SPIBUF read busy-waits for slow
devices
2. I found some DMA transfer length errors under some conditions
3. The chip select code caused extra byte transfers (with no chip
select active) due to writes to SPIDAT1
4. Several issues prevented using multiple SPI devices, especially
the DMA code, as disucussed previously on the davinci list.
The fixes to these problems were not simple. I ended up making fairly
large changes to the driver, and those changes are contained in these
patches. The full list of changes follows.
CHANGE LIST
1. davinci_spi_chipelect() now performs both activation and deactivation
of chip selects. This lets spi_bitbang fully control chip
select activation, as intended by the SPI API.
2. Chip select activation does not cause extra writes to the SPI bus
3. Chip select activation does not use SPIDEF for control. This change
will also allow for implementation of inverted (active high)
chip selects in the future.
4. Added back gpio chip select capability from the old driver
5. Fixed prescale calculation for non-integer fractions of spi clock
6. Allow specification of SPI transfer parameters on a per-device
(instead of per-controller) basis
7. Allow specification of polled, interrupt-based, or DMA operation on
a per-device basis
8. Allow DMA with when more than one device is connected
9. Combined pio and dma txrx_bufs functions into one since they share
large parts of their functionality, and to simplify item (8).
10. Use only SPIFMT0 to allow more than 4 devices
TESTING
I have tested the driver using a custom SPI stress test on my
OMAP-L138-based board with three devices connected. I have tested
configurations with all three devices polled, all three interrupt-based,
all three DMA, and a mixture.
I have compiled with the davinci_all_defconfig, but I don't have EVMs
for the other davinci platforms to test with.
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 10 +
arch/arm/mach-davinci/board-dm355-leopard.c | 10 +
arch/arm/mach-davinci/board-dm365-evm.c | 10 +
arch/arm/mach-davinci/dm355.c |8 +-
arch/arm/mach-davinci/dm365.c |6 -
arch/arm/mach-davinci/include/mach/spi.h| 35 +-
drivers/spi/davinci_spi.c | 1098 ---
7 files changed, 521 insertions(+), 656 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a319101..ad8779b 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -32,6 +32,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/usb.h
+#include mach/spi.h
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -300,10 +301,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = false,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = true,
+};
+
static struct spi_board_info dm355_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index f1d8132..b2d8d48 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -29,6 +29,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/usb.h
+#include mach/spi.h
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -222,10 +223,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = false,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = true,
+};
+
static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a
[PATCH v3 0/1] davinci: spi: replace existing driver
Fixed in this version: - Got rid of the incorrect IORESOURCE flags. DMA resources are now selected by index. - Added a third SPI controller version to differentiate the version on DM355 with no Tx interrupt and the version on DM365 and DM6467 with a Tx interrupt. This should fix the interrupt-mode issues on DM365. ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/dm355.c |8 +- arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/include/mach/spi.h| 35 +- drivers/spi/davinci_spi.c | 1329 --- 7 files changed, 640 insertions(+), 768 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 0/1] davinci: spi: replace existing driver
Fixed in this version: -Fixed whitespace mangling ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/dm355.c |8 +- arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/include/mach/spi.h| 35 +- drivers/spi/davinci_spi.c | 1112 --- 7 files changed, 528 insertions(+), 663 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 1/1] davinci: spi: replace existing driver
INTRODUCTION
I have been working on a custom OMAP-L138 board that has multiple spi
devices (seven) on one controller. These devices have a wide range of
transfer parameters (speed, phase, polarity, internal and gpio chip
selects). During my testing I found multiple errors in the davinci spi
driver as a result of this complex setup. The primary issues were:
1. There is a race condition due to the SPIBUF read busy-waits for slow
devices
2. I found some DMA transfer length errors under some conditions
3. The chip select code caused extra byte transfers (with no chip
select active) due to writes to SPIDAT1
4. Several issues prevented using multiple SPI devices, especially
the DMA code, as disucussed previously on the davinci list.
The fixes to these problems were not simple. I ended up making fairly
large changes to the driver, and those changes are contained in these
patches. The full list of changes follows.
CHANGE LIST
1. davinci_spi_chipelect() now performs both activation and deactivation
of chip selects. This lets spi_bitbang fully control chip
select activation, as intended by the SPI API.
2. Chip select activation does not cause extra writes to the SPI bus
3. Chip select activation does not use SPIDEF for control. This change
will also allow for implementation of inverted (active high)
chip selects in the future.
4. Added back gpio chip select capability from the old driver
5. Fixed prescale calculation for non-integer fractions of spi clock
6. Allow specification of SPI transfer parameters on a per-device
(instead of per-controller) basis
7. Allow specification of polled, interrupt-based, or DMA operation on
a per-device basis
8. Allow DMA with when more than one device is connected
9. Combined pio and dma txrx_bufs functions into one since they share
large parts of their functionality, and to simplify item (8).
10. Use only SPIFMT0 to allow more than 4 devices
TESTING
I have tested the driver using a custom SPI stress test on my
OMAP-L138-based board with three devices connected. I have tested
configurations with all three devices polled, all three interrupt-based,
all three DMA, and a mixture.
I have compiled with the davinci_all_defconfig, but I don't have EVMs
for the other davinci platforms to test with.
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 10 +
arch/arm/mach-davinci/board-dm355-leopard.c | 10 +
arch/arm/mach-davinci/board-dm365-evm.c | 10 +
arch/arm/mach-davinci/dm355.c |8 +-
arch/arm/mach-davinci/dm365.c |6 -
arch/arm/mach-davinci/include/mach/spi.h| 35 +-
drivers/spi/davinci_spi.c | 1112 ---
7 files changed, 528 insertions(+), 663 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a319101..ad8779b 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -32,6 +32,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/usb.h
+#include mach/spi.h
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -300,10 +301,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = false,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = true,
+};
+
static struct spi_board_info dm355_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index f1d8132..b2d8d48 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -29,6 +29,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/usb.h
+#include mach/spi.h
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -222,10 +223,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = false,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = true,
+};
+
static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a
RE: [spi-devel-general] [PATCH v2 0/1] davinci: spi:replaceexisting driver
-Original Message- From: Sudhakar Rajashekhara [mailto:sudhakar@ti.com] Sent: Wednesday, July 07, 2010 6:21 AM To: Brian Niebuhr; 'Brian Niebuhr'; spi-devel-gene...@lists.sourceforge.net Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [spi-devel-general] [PATCH v2 0/1] davinci: spi:replaceexisting driver Hi Brian, On Tue, Jul 06, 2010 at 19:45:56, Brian Niebuhr wrote: On Sat, Jul 03, 2010 at 04:08:53, Brian Niebuhr wrote: I have included all of the recommended changes in this [...] Quick update. I tested this patch on DM355 and DM365 EVMs. On DM355 all the 3 modes (DMA, Polled and Interrupt) worked fine. But in interrupt mode, on DM355, if I set intr_level = 1, then kernel hangs during booting after printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. Sudhakar - When you changed the interrupt level, did you also change the IORESOURCE_IRQ entry for SPI0? Maybe we could set the interrupt level automatically based on the IORESOURCE_IRQ provided? IORESOURCE_IRQ entry for dm365 were already present in dm365.c. I should have been more clear: The intr_level setting chooses which IRQ is used to signal events. If you change intr_level to 1 then you also need to change the IRQ that is provided as a resource to the driver to match. On DM355 intr_level=0 corresponds to SPINT0_0 (42) and intr_level=1 corresponds to SPINT0_1 (43). On DM365 only DMA and Polled mode worked fine. In interrupt mode, whether I set intr_level to ZERO or ONE, kernel booting hangs, similar to DM355. Does the interrupt mode of the existing driver work on DM365? AFAIK, support for interrupt mode was not present in the earlier driver by Sandeep Paulraj. I don't have one of these boards, so I can't debug the issue. If you have any ideas where the problem might be I'd appreciate the help in getting this resolved. As I mentioned in my earlier e-mail, on DM365 kernel booting hangs after Printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. Control is in spi_sync() function waiting for completion. I've got an idea what the problem is: When I was writing the driver I was looking at the DM355 for as an example of the version 1 SPI controller. The DM355 doesn't have a TX interrupt, so I thought that was a feature of the version 1 controller. However, DM365 does have a TX interrupt, even though it has a version 1 controller. The interrupt handler in the driver changes its processing based on whether it is a version 1 or version 2 device, but obviously that's not quite correct. Could you try one experiment for me on the DM365 board? Could you change SPIINT_MASKINT to 0x015Fu and retest on the DM365 only? This should make it behave like the DM355. If that fixes the problem, then at least I know where the problem is. I don't have a good idea how to solve it yet, though. If the change I mentioned above fixes the issue on DM355, then I am not sure whether my earlier mail was clear in this regard or not but interrupt mode works fine on DM355 if intr_level = 0. Kernel booting hangs on DM355 if intr_level = 1. I've got to imagine that it's just a configuration issue of some sort on DM365. I am also of the same opinion. Thanks, Sudhakar -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ spi-devel-general mailing list spi-devel-gene...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [spi-devel-general] [PATCH v2 0/1] davinci: spi: replaceexisting driver
On Sat, Jul 03, 2010 at 04:08:53, Brian Niebuhr wrote: I have included all of the recommended changes in this version of the patch. I also combined the patches into one patch to avoid bisecting issues. This makes the diff on davinci_spi.c very large. If people who are using this driver could test this version of the driver and Ack it, I would appreciate it. ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-sourc e/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/dm355.c | 12 +- arch/arm/mach-davinci/dm365.c | 12 +- arch/arm/mach-davinci/include/mach/spi.h| 37 +- drivers/spi/davinci_spi.c | 1328 --- 7 files changed, 648 insertions(+), 771 deletions(-) Quick update. I tested this patch on DM355 and DM365 EVMs. On DM355 all the 3 modes (DMA, Polled and Interrupt) worked fine. But in interrupt mode, on DM355, if I set intr_level = 1, then kernel hangs during booting after printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. Sudhakar - When you changed the interrupt level, did you also change the IORESOURCE_IRQ entry for SPI0? Maybe we could set the interrupt level automatically based on the IORESOURCE_IRQ provided? The problem is, I don't see any way of doing that without a bunch of machine-specific ifdefs in the driver. On DM365 only DMA and Polled mode worked fine. In interrupt mode, whether I set intr_level to ZERO or ONE, kernel booting hangs, similar to DM355. Does the interrupt mode of the existing driver work on DM365? I don't have one of these boards, so I can't debug the issue. If you have any ideas where the problem might be I'd appreciate the help in getting this resolved. If the change I mentioned above fixes the issue on DM355, then I've got to imagine that it's just a configuration issue of some sort on DM365. I'll update the status of testing on OMAP-L1x EVMs later. I am using the Linux kernel from [1] for testing. [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinc i.git;a=summary ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 0/1] davinci: spi: replace existing driver
I have included all of the recommended changes in this version of the patch. I also combined the patches into one patch to avoid bisecting issues. This makes the diff on davinci_spi.c very large. If people who are using this driver could test this version of the driver and Ack it, I would appreciate it. ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/dm355.c | 12 +- arch/arm/mach-davinci/dm365.c | 12 +- arch/arm/mach-davinci/include/mach/spi.h| 37 +- drivers/spi/davinci_spi.c | 1328 --- 7 files changed, 648 insertions(+), 771 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [spi-devel-general] [PATCH 0/3] davinci: spi: replace existingSPI driver
On Tue, Jun 15, 2010 at 00:43:06, Brian Niebuhr wrote: I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. I was testing this series on OMAP-L137, OMAP-L138 and DM365 EVMs and I found that on all these EVMS, Interrupt mode has problems. Driver works fine in DMA and POLL modes. Some problems which I had observed with the old driver are gone now. Do you have any idea what errors you're seeing in interrupt mode? I went and retested interrupt mode with several devices on my custom board and it still appeared to be working fine. It may be an interaction with code outside the driver because I'm running the identical driver code but I'm not running the latest kernel from the davinci git repository. I'm trying to figure out if I can get my DA850 EVM back into a state where I can debug this. Thanks for any hints you can give! You may be knowing that on OMAP-L138 EVM, we have M25P64 Flash on SPI. When the driver is configured in Interrupt mode, kernel booting just hangs. I noticed that the SPI probe function is not coming out of spi_bitbang_start() call. I configured the M25P64 on the DA850 EVM for both DMA and interrupt mode and my kernel still booted correctly. I wonder if your setting for intr_level is correct? For the DA850 it should be set to 1. I'm following up with a response to Nicolas showing the changes I made to the kernel to test this. Can you check if the changes you made match mine? Thanks, Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
I got OMAP-L138 EVM and I'm running kernel v2.6.34 from
khilman/linux-davinci.git and I would like to try the SPI
patch. I successfully applied the patch to the driver, and
now I'm trying to modify platform data in board-da850-evm.c.
I added the following lines :
[...]
I do not see spidev1.1 in /dev. Any clue?
Following is a diff of changes I made to the board configuration to add
the M25P64 SPI flash to the DA850 EVM. Note that this is NOT
recommended as a patch - I just put in some quick and dirty code to
reproduce Sudhakar's issue with the driver. See diff below:
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/boa
index 2ec3095..4ecae04 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -27,6 +27,8 @@
#include linux/regulator/machine.h
#include linux/mfd/tps6507x.h
#include linux/input/tps6507x-ts.h
+#include linux/spi/spi.h
+#include linux/spi/flash.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -35,6 +37,7 @@
#include mach/da8xx.h
#include mach/nand.h
#include mach/mux.h
+#include mach/spi.h
#define DA850_EVM_PHY_MASK 0x1
#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
@@ -92,6 +95,59 @@ static struct platform_device
da850_evm_norflash_device = {
.resource = da850_evm_norflash_resource,
};
+static struct mtd_partition spi_flash_partitions[] = {
+ [0] = {
+ .name = U-Boot,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = U-Boot Environment,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [2] = {
+ .name = Linux,
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = SZ_8M - (SZ_256K + SZ_64K + SZ_64K),
+ .mask_flags = 0,
+ },
+};
+
+struct davinci_spi_config m25p64_spi_cfg = {
+ .odd_parity = 0,
+ .parity_enable = 0,
+ .intr_level = 1,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+ .c2t_delay = 0,
+ .t2c_delay = 0,
+ .t2e_delay = 0,
+ .c2e_delay = 0,
+};
+
+static struct flash_platform_data spi_flash_data = {
+ .name = m25p80,
+ .parts = spi_flash_partitions,
+ .nr_parts = ARRAY_SIZE(spi_flash_partitions),
+ .type = m25p64,
+};
+
+static struct spi_board_info da850_spi_board_info[] = {
+ [0] = {
+ .modalias = m25p80,
+ .platform_data = spi_flash_data,
+ .controller_data = m25p64_spi_cfg,
+ .mode = SPI_MODE_0,
+ .max_speed_hz = 3000,
+ .bus_num = 1,
+ .chip_select = 0,
+ },
+};
+
static struct davinci_pm_config da850_pm_pdata = {
.sleepcount = 128,
};
@@ -629,6 +685,61 @@ static int __init da850_evm_config_emac(void)
}
device_initcall(da850_evm_config_emac);
+static struct davinci_spi_platform_data da850_spi_pdata1 = {
+ .version = SPI_VERSION_2,
+};
+
+static struct resource da850_spi_resources1[] = {
+ [0] = {
+ .start = 0x01F0E000,
+ .end = 0x01F0E000 + 0xfff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_DA8XX_SPINT1,
+ .end = IRQ_DA8XX_SPINT1,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = EDMA_CTLR_CHAN(0, 18),
+ .end = EDMA_CTLR_CHAN(0, 18),
+ .flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+ },
+ [3] = {
+ .start = EDMA_CTLR_CHAN(0, 19),
+ .end = EDMA_CTLR_CHAN(0, 19),
+ .flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+ },
+ [4] = {
+ .start = 1,
+ .end = 1,
+ .flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+ },
+};
+
+static struct platform_device da850_spi_pdev1 = {
+ .name = spi_davinci,
+ .id = 1,
+ .resource = da850_spi_resources1,
+ .num_resources = ARRAY_SIZE(da850_spi_resources1),
+ .dev = {
+ .platform_data = da850_spi_pdata1,
+ },
+};
+
+static void __init da850_init_spi1(unsigned char* chip_sel,
+ unsigned int num_sel, struct spi_board_info *info, unsigned
num_dev)
+{
+ struct davinci_spi_platform_data *pdata =
+ da850_spi_pdev1.dev.platform_data;
+
+ spi_register_board_info(info, num_dev);
+
+ pdata-chip_sel = chip_sel;
+ pdata-num_chipselect = num_sel;
+ platform_device_register(da850_spi_pdev1);
+}
+
static __init void da850_evm_init(void)
{
int ret;
@@ -739,6 +850,9 @@ static __init void da850_evm_init(void)
pr_warning(da850_evm_init: cpuidle
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
I modified board-da850-evm.c with what you proposed and it's working very well. I didn't test the spi flash (because I do not have one on my custum hardware), but my 2 SPI CS (spidev1.1 and spidev1.2) are working. Nicolas - Would you mind taking a few minutes and testing interrupt mode for the devices on your board? I'm trying to reproduce the issue that Sudhakar was seeing, and I would appreciate additional testing if you've got the time. Thanks, Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/3] davinci: spi: replace existing SPI driver
I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. I was testing this series on OMAP-L137, OMAP-L138 and DM365 EVMs and I found that on all these EVMS, Interrupt mode has problems. Driver works fine in DMA and POLL modes. Some problems which I had observed with the old driver are gone now. Do you have any idea what errors you're seeing in interrupt mode? I went and retested interrupt mode with several devices on my custom board and it still appeared to be working fine. It may be an interaction with code outside the driver because I'm running the identical driver code but I'm not running the latest kernel from the davinci git repository. I'm trying to figure out if I can get my DA850 EVM back into a state where I can debug this. Thanks for any hints you can give! ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 2/3] davinci: spi: add replacement SPI driver
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
index 910efbf..10c39d8 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -19,26 +19,39 @@
#ifndef __ARCH_ARM_DAVINCI_SPI_H
#define __ARCH_ARM_DAVINCI_SPI_H
+#define SPI_INTERN_CS 0xFF
+
+/* resource flags for IORESOURCE_DMA resources */
+#define IORESOURCE_DMA_RX_CHAN 0x01
+#define IORESOURCE_DMA_TX_CHAN 0x02
+#define IORESOURCE_DMA_EVENT_Q 0x04
+
enum {
- SPI_VERSION_1, /* For DM355/DM365/DM6467 */
+ SPI_VERSION_1, /* For DM355/DM365/DM6467*/
Above line in the patch is not required.
Right.
+
+ davinci_spi-version = pdata-version;
+
+ davinci_spi-bitbang.flags = SPI_NO_CS | SPI_LSB_FIRST
| SPI_LOOP;
+ if (davinci_spi-version == SPI_VERSION_2)
+ davinci_spi-bitbang.flags |= SPI_READY;
+
+ dma_rx_chan = davinci_spi_get_dma_by_flag(pdev,
IORESOURCE_DMA_RX_CHAN);
+ dma_tx_chan = davinci_spi_get_dma_by_flag(pdev,
IORESOURCE_DMA_TX_CHAN);
+ dma_eventq = davinci_spi_get_dma_by_flag(pdev,
IORESOURCE_DMA_EVENT_Q);
+ davinci_spi-dma_channels.dma_rx_channel = -1;
+ davinci_spi-dma_channels.dma_rx_sync_dev = dma_rx_chan;
+ davinci_spi-dma_channels.dma_tx_channel = -1;
+ davinci_spi-dma_channels.dma_tx_sync_dev = dma_tx_chan;
+ davinci_spi-dma_channels.dummy_param_slot = -1;
+ davinci_spi-dma_channels.eventq = dma_eventq;
Can the above configurations be done only in case if DMA mode?
DMA mode is selected on a per-device basis. This initialization is for
the controller, so it needs to be prepared to handle DMA if a device
uses it. If DMA is not required, no DMA resource need be assigned to
the controller.
Some way of informing the user about the mode in which the driver is
working is desirable.
Yes, I'll try to come up with something.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
diff --git a/arch/arm/mach-davinci/dm365.c
b/arch/arm/mach-davinci/dm365.c
index a146849..0bd9f93 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -625,12 +625,6 @@ static u64 dm365_spi0_dma_mask =
DMA_BIT_MASK(32);
static struct davinci_spi_platform_data dm365_spi0_pdata = {
.version= SPI_VERSION_1,
.num_chipselect = 2,
- .clk_internal = 1,
- .cs_hold= 1,
- .intr_level = 0,
- .poll_mode = 1,/* 0 - interrupt mode 1-
polling mode */
- .c2tdelay = 0,
- .t2cdelay = 0,
};
static struct resource dm365_spi0_resources[] = {
This patch does not contain modifications to resource
structure to 'or' the
IORESOURCE_DMA_RX_CHAN, IORESOURCE_DMA_TX_CHAN and
IORESOURCE_DMA_EVENT_Q
flags with IORESOURCE_DMA. I don't think without this
modification driver
will work.
You are right - my mistake. I will include that in the next version. I
assume you added these flags when you were testing?
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/3] davinci: spi: replace existing SPI driver
Can you please post this series to SPI development list (spi-devel-gene...@lists.sourceforge.net) CCing the maintainers David Brownell and Grant Likely? Done INTRODUCTION I have been working on a custom OMAP-L138 board that has multiple spi devices (seven) on one controller. These devices have a wide range of transfer parameters (speed, phase, polarity, internal and gpio chip selects). During my testing I found multiple errors in the davinci spi driver as a result of this complex setup. The primary issues were: 1. There is a race condition due to the SPIBUF read busy-waits for slow devices 2. I found some DMA transfer length errors under some conditions 3. The chip select code caused extra byte transfers (with no chip select active) due to writes to SPIDAT1 4. Several issues prevented using multiple SPI devices, especially the DMA code, as disucussed previously on the davinci list. This should be replicated in patch description for patch 1/3 as a record of why the original driver was removed. Will do. The fixes to these problems were not simple. I ended up making fairly large changes to the driver, and those changes are contained in these patches. The full list of changes follows. CHANGE LIST 1. davinci_spi_chipelect() now performs both activation and deactivation of chip selects. This lets spi_bitbang fully control chip select activation, as intended by the SPI API. 2. Chip select activation does not cause extra writes to the SPI bus 3. Chip select activation does not use SPIDEF for control. This change will also allow for implementation of inverted (active high) chip selects in the future. 4. Added back gpio chip select capability from the old driver 5. Fixed prescale calculation for non-integer fractions of spi clock 6. Allow specification of SPI transfer parameters on a per-device (instead of per-controller) basis 7. Allow specification of polled, interrupt-based, or DMA operation on a per-device basis 8. Allow DMA with when more than one device is connected 9. Combined pio and dma txrx_bufs functions into one since they share large parts of their functionality, and to simplify item (8). 10. Use only SPIFMT0 to allow more than 4 devices TESTING I have tested the driver using a custom SPI stress test on my OMAP-L138-based board with three devices connected. I have tested configurations with all three devices polled, all three interrupt-based, all three DMA, and a mixture. This should be replicated in patch description for patch 2/3 as a record of what the new driver provides. Will do. I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. DM6467, DM365 and OMAP-L137 EVMs have SPI devices as well. We can help test on at least some of those. No need to wait for test results before posting to SPI list though, it can happen in parallel to the review. Ok, thanks. SUMMARY This patch solves a lot of issues that should save a lot of people time down the road. Since I posted the original patch I have had at least 5 people contact me personally to get help applying the patch because SPI was broken on their boards. I have heard back from at least 2 that the original patch worked for them. You can include an Acked-by: from those developers. This will help build the case for the new driver. I'll see if I still have the emails. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/3] davinci: spi: replace existing SPI driver
NOTE This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which has since been reverted out of the davinci kernel. INTRODUCTION I have been working on a custom OMAP-L138 board that has multiple spi devices (seven) on one controller. These devices have a wide range of transfer parameters (speed, phase, polarity, internal and gpio chip selects). During my testing I found multiple errors in the davinci spi driver as a result of this complex setup. The primary issues were: 1. There is a race condition due to the SPIBUF read busy-waits for slow devices 2. I found some DMA transfer length errors under some conditions 3. The chip select code caused extra byte transfers (with no chip select active) due to writes to SPIDAT1 4. Several issues prevented using multiple SPI devices, especially the DMA code, as disucussed previously on the davinci list. The fixes to these problems were not simple. I ended up making fairly large changes to the driver, and those changes are contained in these patches. The full list of changes follows. CHANGE LIST 1. davinci_spi_chipelect() now performs both activation and deactivation of chip selects. This lets spi_bitbang fully control chip select activation, as intended by the SPI API. 2. Chip select activation does not cause extra writes to the SPI bus 3. Chip select activation does not use SPIDEF for control. This change will also allow for implementation of inverted (active high) chip selects in the future. 4. Added back gpio chip select capability from the old driver 5. Fixed prescale calculation for non-integer fractions of spi clock 6. Allow specification of SPI transfer parameters on a per-device (instead of per-controller) basis 7. Allow specification of polled, interrupt-based, or DMA operation on a per-device basis 8. Allow DMA with when more than one device is connected 9. Combined pio and dma txrx_bufs functions into one since they share large parts of their functionality, and to simplify item (8). 10. Use only SPIFMT0 to allow more than 4 devices TESTING I have tested the driver using a custom SPI stress test on my OMAP-L138-based board with three devices connected. I have tested configurations with all three devices polled, all three interrupt-based, all three DMA, and a mixture. I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. SUMMARY This patch solves a lot of issues that should save a lot of people time down the road. Since I posted the original patch I have had at least 5 people contact me personally to get help applying the patch because SPI was broken on their boards. I have heard back from at least 2 that the original patch worked for them. I appreciate any testing and feedback that others can provide. Brian Niebuhr (3): davinci: spi: remove old Davinci SPI driver davinci: spi: add replacement SPI driver davinci: spi: modify platform data for updated SPI driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/dm355.c |6 - arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/include/mach/spi.h| 41 +- drivers/spi/davinci_spi.c | 1196 ++- drivers/spi/davinci_spi.h | 186 + 8 files changed, 681 insertions(+), 784 deletions(-) create mode 100644 drivers/spi/davinci_spi.h ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/3] davinci: spi: remove old Davinci SPI driver
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com --- drivers/spi/davinci_spi.c | 1256 - 1 files changed, 0 insertions(+), 1256 deletions(-) delete mode 100644 drivers/spi/davinci_spi.c diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c deleted file mode 100644 index 95afb6b..000 --- a/drivers/spi/davinci_spi.c +++ /dev/null @@ -1,1256 +0,0 @@ -/* - * Copyright (C) 2009 Texas Instruments. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ - -#include linux/interrupt.h -#include linux/io.h -#include linux/gpio.h -#include linux/module.h -#include linux/delay.h -#include linux/platform_device.h -#include linux/err.h -#include linux/clk.h -#include linux/dma-mapping.h -#include linux/spi/spi.h -#include linux/spi/spi_bitbang.h -#include linux/slab.h - -#include mach/spi.h -#include mach/edma.h - -#define SPI_NO_RESOURCE((resource_size_t)-1) - -#define SPI_MAX_CHIPSELECT 2 - -#define CS_DEFAULT 0xFF - -#define SPI_BUFSIZ (SMP_CACHE_BYTES + 1) -#define DAVINCI_DMA_DATA_TYPE_S8 0x01 -#define DAVINCI_DMA_DATA_TYPE_S16 0x02 -#define DAVINCI_DMA_DATA_TYPE_S32 0x04 - -#define SPIFMT_PHASE_MASK BIT(16) -#define SPIFMT_POLARITY_MASK BIT(17) -#define SPIFMT_DISTIMER_MASK BIT(18) -#define SPIFMT_SHIFTDIR_MASK BIT(20) -#define SPIFMT_WAITENA_MASKBIT(21) -#define SPIFMT_PARITYENA_MASK BIT(22) -#define SPIFMT_ODD_PARITY_MASK BIT(23) -#define SPIFMT_WDELAY_MASK 0x3f00u -#define SPIFMT_WDELAY_SHIFT24 -#define SPIFMT_CHARLEN_MASK0x001Fu - -/* SPIGCR1 */ -#define SPIGCR1_SPIENA_MASK0x0100u - -/* SPIPC0 */ -#define SPIPC0_DIFUN_MASK BIT(11) /* MISO */ -#define SPIPC0_DOFUN_MASK BIT(10) /* MOSI */ -#define SPIPC0_CLKFUN_MASK BIT(9) /* CLK */ -#define SPIPC0_SPIENA_MASK BIT(8) /* nREADY */ -#define SPIPC0_EN1FUN_MASK BIT(1) -#define SPIPC0_EN0FUN_MASK BIT(0) - -#define SPIINT_MASKALL 0x0101035F -#define SPI_INTLVL_1 0x01FFu -#define SPI_INTLVL_0 0xu - -/* SPIDAT1 */ -#define SPIDAT1_CSHOLD_SHIFT 28 -#define SPIDAT1_CSNR_SHIFT 16 -#define SPIGCR1_CLKMOD_MASKBIT(1) -#define SPIGCR1_MASTER_MASK BIT(0) -#define SPIGCR1_LOOPBACK_MASK BIT(16) - -/* SPIBUF */ -#define SPIBUF_TXFULL_MASK BIT(29) -#define SPIBUF_RXEMPTY_MASKBIT(31) - -/* Error Masks */ -#define SPIFLG_DLEN_ERR_MASK BIT(0) -#define SPIFLG_TIMEOUT_MASKBIT(1) -#define SPIFLG_PARERR_MASK BIT(2) -#define SPIFLG_DESYNC_MASK BIT(3) -#define SPIFLG_BITERR_MASK BIT(4) -#define SPIFLG_OVRRUN_MASK BIT(6) -#define SPIFLG_RX_INTR_MASKBIT(8) -#define SPIFLG_TX_INTR_MASKBIT(9) -#define SPIFLG_BUF_INIT_ACTIVE_MASKBIT(24) -#define SPIFLG_MASK(SPIFLG_DLEN_ERR_MASK \ - | SPIFLG_TIMEOUT_MASK | SPIFLG_PARERR_MASK \ - | SPIFLG_DESYNC_MASK | SPIFLG_BITERR_MASK \ - | SPIFLG_OVRRUN_MASK | SPIFLG_RX_INTR_MASK \ - | SPIFLG_TX_INTR_MASK \ - | SPIFLG_BUF_INIT_ACTIVE_MASK) - -#define SPIINT_DLEN_ERR_INTR BIT(0) -#define SPIINT_TIMEOUT_INTRBIT(1) -#define SPIINT_PARERR_INTR BIT(2) -#define SPIINT_DESYNC_INTR BIT(3) -#define SPIINT_BITERR_INTR BIT(4) -#define SPIINT_OVRRUN_INTR BIT(6) -#define SPIINT_RX_INTR BIT(8) -#define SPIINT_TX_INTR BIT(9) -#define SPIINT_DMA_REQ_EN BIT(16) -#define SPIINT_ENABLE_HIGHZBIT(24) - -#define SPI_T2CDELAY_SHIFT 16 -#define SPI_C2TDELAY_SHIFT 24 - -/* SPI Controller registers */ -#define SPIGCR00x00 -#define SPIGCR10x04 -#define SPIINT 0x08 -#define SPILVL 0x0c -#define SPIFLG 0x10 -#define SPIPC0 0x14 -#define SPIPC1 0x18 -#define SPIPC2 0x1c -#define SPIPC3 0x20 -#define SPIPC4 0x24 -#define SPIPC5 0x28 -#define SPIPC6 0x2c -#define SPIPC7 0x30 -#define SPIPC8 0x34 -#define SPIDAT00x38 -#define SPIDAT10x3c -#define SPIBUF 0x40 -#define
RE: SPI Support for DA850 (OMAPL-138).
Mike - I do plan on resubmitting the driver as a replacement driver (remove the old and add the updated version) as suggested by TI. I am just trying to get some other work finished up first. If you want to try the version I submitted, the patch was actually against the arago kernel. You can try patching that version and pulling it into your kernel to see if that fixes your issues. Hopefully I'll get around to resubmitting the driver for consideration some time this week. Brian -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Mike Williamson Sent: Sunday, April 11, 2010 9:56 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: SPI Support for DA850 (OMAPL-138). Hi, I've been working with Kevin's tree and have been having some problems with the SPI interface for the DA850 (OMAP-L138), SPI version 2. I am getting a lot of failures in the davinci_spi_check_error routine that I'm not sure are real errors. I was googling around and found this thread: http://linux.omap.com/pipermail/davinci-linux-open-source/2009 -July/015025.html The thread raises the same issue that I have found in that the routine is declaring an error if the status of the SPI engine is claiming that the Tx buffer is empty (SPIFLG_TX_INTR_MASK) and there is also a check on a bit (SPIFLG_BUF_INIT_ACTIVE_MASK, bit 24) that is undocumented in the SPI user guide. I found that I had to turn off both of these checks in order for the SPI to work with our device in polled mode with no DMAs.The device is an m25p64 EEPROM, same configuration as on the 850 / OMAPL138 evm. Can anyone confirm if the spi implementation in Kevin's tree is working for VERSION_2 SPI devices (850 specifically), and what SPI configuration you're using? I am also wondering if the SPI patches from Brian Niebuhr have died on the wire (http://linux.davincidsp.com/pipermail/davinci-linux-open-sour ce/2010-March/018077.html). It seemed like he had identified several issues with the driver and had taken a crack at sorting them out. -Mike -- Michael Williamson 315-425-4045x230 www.criticallink.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/2 v2] spi: overhaul davinci spi driver to correct multiple errors
This patch is a significant overhaul of the davinci spi controller driver that corrects multiple errors: - Eliminate a race condition that exists for slow SPI devices - Fix DMA transfer length error - Fix limitations preventing multiple SPI devices on the same controller Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com The verbose description of the issues addressed from PATCH 0/2 should go here is well so it makes it into the permanent git history. I can certainly do that. That being said, I think for the sake of reviewing, you're going to need to break this up into reviewable pieces, each having a verbose description of the issues being solved. There is also a mixture of fixes, enhancements, renames etc. These should be done as separate patches. I know that it's more work to break it up like this, but that's the only way to make a large change like this reviewable by others. I guess I was hoping that this could be reviewed as if it were a new driver submission. I ended up more or less rewriting all of the functional parts of the driver (txrx_bufs(), chipselect(), IRQs and DMA callbacks), so it's very difficult to show this as a series of changes. I do understand the problem from your perspective, though. My thought was that if the TI folks were willing to look the driver over and they gave their blessing, that you would look at it as if it were a replacement driver and accept or deny it on that basis. Thanks for your consideration, Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/2] overhaul davinci spi driver to fix multiple errors
INTRODUCTION I have been working on a custom OMAP-L138 board that has multiple spi devices (seven) on one controller. These devices have a wide range of transfer parameters (speed, phase, polarity, internal and gpio chip selects). During my testing I found multiple errors in the davinci spi driver as a result of this complex setup. The primary issues were: 1. There is a race condition due to the SPIBUF read busy-waits for slow devices 2. I found some DMA transfer length errors under some conditions 3. The chip select code caused extra byte transfers (with no chip select active) due to writes to SPIDAT1 4. Several issues prevented using multiple SPI devices, especially the DMA code, as disucussed previously on the davinci list. The fixes to these problems were not simple. I ended up making fairly large changes to the driver, and those changes are contained in these patches. The full list of changes follows. CHANGE LIST 1. davinci_spi_chipelect() now performs both activation and deactivation of chip selects. This lets spi_bitbang fully control chip select activation, as intended by the SPI API. 2. Chip select activation does not cause extra writes to the SPI bus 3. Chip select activation does not use SPIDEF for control. This change will also allow for implementation of inverted (active high) chip selects in the future. 4. Added back gpio chip select capability from the old driver 5. Fixed prescale calculation for non-integer fractions of spi clock 6. Allow specification of SPI transfer parameters on a per-device (instead of per-controller) basis 7. Allow specification of polled, interrupt-based, or DMA operation on a per-device basis 8. Allow DMA with when more than one device is connected 9. Combined pio and dma txrx_bufs functions into one since they share large parts of their functionality, and to simplify item (8). 10. Use only SPIFMT0 to allow more than 4 devices TESTING I have tested the driver using a custom SPI stress test on my OMAP-L138-based board with three devices connected. I have tested configurations with all three devices polled, all three interrupt-based, all three DMA, and a mixture. I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. SUMMARY I realize that this is a very large patch, but I hope that it's not thrown out just because of its size. It does solve a lot of issues that should save a lot of people time down the road. I would appreciate any feedback from those who can test it out on other davinci EVMs. Brian Niebuhr (2): spi: overhaul davinci spi driver to correct multiple errors spi: modify davinci platform data for updated driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/board-dm646x-evm.c| 12 + arch/arm/mach-davinci/dm355.c |7 - arch/arm/mach-davinci/dm365.c |7 - arch/arm/mach-davinci/dm646x.c |7 - arch/arm/mach-davinci/include/mach/spi.h| 30 +- drivers/spi/davinci_spi.c | 1021 +++ drivers/spi/davinci_spi.h | 53 +- 10 files changed, 495 insertions(+), 672 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/2] spi: overhaul davinci spi driver to correct multiple errors
This patch is a significant overhaul of the davinci spi controller driver
that corrects multiple errors:
- Eliminate a race condition that exists for slow SPI devices
- Fix DMA transfer length error
- Fix limitations preventing multiple SPI devices on the same controller
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/include/mach/spi.h | 30 +-
drivers/spi/davinci_spi.c| 1021 --
drivers/spi/davinci_spi.h| 53 +-
3 files changed, 453 insertions(+), 651 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
index 7b54926..f88f1ec 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -34,18 +34,24 @@ enum {
struct davinci_spi_platform_data {
u8 version;
u16 num_chipselect;
- u32 wdelay;
- u32 odd_parity;
- u32 parity_enable;
- u32 wait_enable;
- u32 timer_disable;
- u32 clk_internal;
- u32 cs_hold;
- u32 intr_level;
- u32 poll_mode;
- u32 use_dma;
- u8 c2tdelay;
- u8 t2cdelay;
+ u8 *chip_sel;
+};
+
+struct davinci_spi_config {
+ u32 odd_parity : 1;
+ u32 parity_enable : 1;
+ u32 intr_level : 1;
+ u32 io_type : 2;
+#define SPI_IO_TYPE_INTR0
+#define SPI_IO_TYPE_POLL1
+#define SPI_IO_TYPE_DMA 2
+ u32 bytes_per_word : 2;
+ u32 wdelay : 6;
+ u32 timer_disable : 1;
+ u8 c2t_delay;
+ u8 t2c_delay;
+ u8 t2e_delay;
+ u8 c2e_delay;
};
#endif /* __ARCH_ARM_DAVINCI_SPI_H */
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 956f617..eec2fe9 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2009 Texas Instruments.
+ * Copyright (C) 2010 EF Johnson Technologies
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -33,43 +34,45 @@
#include davinci_spi.h
-static unsigned use_dma;
-
#defineDAVINCI_SPI_NO_RESOURCE ((resource_size_t)-1)
static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
{
- u8 *rx = davinci_spi-rx;
-
- *rx++ = (u8)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u8 *rx = davinci_spi-rx;
+ *rx++ = (u8)data;
+ davinci_spi-rx = rx;
+ }
}
static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
{
- u16 *rx = davinci_spi-rx;
-
- *rx++ = (u16)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u16 *rx = davinci_spi-rx;
+ *rx++ = (u16)data;
+ davinci_spi-rx = rx;
+ }
}
static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u8 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u8 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u16 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u16 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
@@ -89,26 +92,6 @@ static inline void clear_io_bits(void __iomem *addr, u32
bits)
iowrite32(v, addr);
}
-static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
-{
- struct davinci_spi *davinci_spi = spi_master_get_devdata(spi-master);
-
- if (enable)
- set_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
- else
- clear_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
-}
-
/*
* Interface to control the chip select signal
*/
@@ -116,25 +99,54 @@ static void davinci_spi_chipselect(struct spi_device *spi,
int value)
{
struct davinci_spi *davinci_spi;
struct davinci_spi_platform_data *pdata;
- u32 data1_reg_val = 0;
+ u8 i, chip_sel = spi-chip_select;
+ u32 spidat1;
+ u16 spidat1_cfg;
davinci_spi = spi_master_get_devdata(spi-master);
pdata
[PATCH 2/2] spi: modify davinci platform data for updated driver
These changes update the davinci platform data to match the modifications
that were done to the davinci spi controller driver. The driver update
allowed per-device transfer settings, which are provided by this patch.
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 10 ++
arch/arm/mach-davinci/board-dm355-leopard.c | 10 ++
arch/arm/mach-davinci/board-dm365-evm.c | 10 ++
arch/arm/mach-davinci/board-dm646x-evm.c| 12
arch/arm/mach-davinci/dm355.c |7 ---
arch/arm/mach-davinci/dm365.c |7 ---
arch/arm/mach-davinci/dm646x.c |7 ---
7 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a0724fa..b1a21a4 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -40,6 +40,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -445,10 +446,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 30 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index 84ad5d1..d87ff0b 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -36,6 +36,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -232,10 +233,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index ab3b0e2..8559c84 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -44,6 +44,7 @@
#include mach/nand.h
#include mach/keyscan.h
#include mach/gpio.h
+#include mach/spi.h
#include linux/videodev2.h
#include media/tvp514x.h
#include media/tvp7002.h
@@ -832,10 +833,19 @@ static struct spi_eeprom at25640 = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm365_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640,
+ .controller_data = at25640_spi_cfg,
.max_speed_hz = 20 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 94271a6..5430b00 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -58,6 +58,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/emac.h
+#include mach/spi.h
#include mach/clock.h
#include clock.h
@@ -911,10 +912,21 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 0,
+ .c2t_delay = 8,
+ .t2c_delay = 8,
+};
+
static struct spi_board_info dm646x_evm_spi_info[] __initconst = {
{
.modalias = at25
[PATCH 2/2 v2] spi: modify davinci platform data for updated driver
These changes update the davinci platform data to match the modifications
that were done to the davinci spi controller driver. The driver update
allowed per-device transfer settings, which are provided by this patch.
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 10 ++
arch/arm/mach-davinci/board-dm355-leopard.c | 10 ++
arch/arm/mach-davinci/board-dm365-evm.c | 10 ++
arch/arm/mach-davinci/board-dm646x-evm.c| 12
arch/arm/mach-davinci/dm355.c |7 ---
arch/arm/mach-davinci/dm365.c |7 ---
arch/arm/mach-davinci/dm646x.c |7 ---
7 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a0724fa..b1a21a4 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -40,6 +40,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -445,10 +446,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 30 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index 84ad5d1..d87ff0b 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -36,6 +36,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -232,10 +233,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index ab3b0e2..8559c84 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -44,6 +44,7 @@
#include mach/nand.h
#include mach/keyscan.h
#include mach/gpio.h
+#include mach/spi.h
#include linux/videodev2.h
#include media/tvp514x.h
#include media/tvp7002.h
@@ -832,10 +833,19 @@ static struct spi_eeprom at25640 = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm365_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640,
+ .controller_data = at25640_spi_cfg,
.max_speed_hz = 20 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 94271a6..5430b00 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -58,6 +58,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/emac.h
+#include mach/spi.h
#include mach/clock.h
#include clock.h
@@ -911,10 +912,21 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 0,
+ .c2t_delay = 8,
+ .t2c_delay = 8,
+};
+
static struct spi_board_info dm646x_evm_spi_info[] __initconst = {
{
.modalias = at25
[PATCH 1/2 v2] spi: overhaul davinci spi driver to correct multiple errors
This patch is a significant overhaul of the davinci spi controller driver
that corrects multiple errors:
- Eliminate a race condition that exists for slow SPI devices
- Fix DMA transfer length error
- Fix limitations preventing multiple SPI devices on the same controller
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/include/mach/spi.h | 30 +-
drivers/spi/davinci_spi.c| 990 --
drivers/spi/davinci_spi.h| 53 +-
3 files changed, 437 insertions(+), 636 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
index 7b54926..10c39d8 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -34,18 +34,24 @@ enum {
struct davinci_spi_platform_data {
u8 version;
u16 num_chipselect;
- u32 wdelay;
- u32 odd_parity;
- u32 parity_enable;
- u32 wait_enable;
- u32 timer_disable;
- u32 clk_internal;
- u32 cs_hold;
- u32 intr_level;
- u32 poll_mode;
- u32 use_dma;
- u8 c2tdelay;
- u8 t2cdelay;
+ u8 *chip_sel;
+};
+
+struct davinci_spi_config {
+ u32 odd_parity:1;
+ u32 parity_enable:1;
+ u32 intr_level:1;
+ u32 io_type:2;
+#define SPI_IO_TYPE_INTR0
+#define SPI_IO_TYPE_POLL1
+#define SPI_IO_TYPE_DMA 2
+ u32 bytes_per_word:2;
+ u32 wdelay:6;
+ u32 timer_disable:1;
+ u8 c2t_delay;
+ u8 t2c_delay;
+ u8 t2e_delay;
+ u8 c2e_delay;
};
#endif /* __ARCH_ARM_DAVINCI_SPI_H */
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 956f617..0bed840 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2009 Texas Instruments.
+ * Copyright (C) 2010 EF Johnson Technologies
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -33,43 +34,45 @@
#include davinci_spi.h
-static unsigned use_dma;
-
#defineDAVINCI_SPI_NO_RESOURCE ((resource_size_t)-1)
static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
{
- u8 *rx = davinci_spi-rx;
-
- *rx++ = (u8)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u8 *rx = davinci_spi-rx;
+ *rx++ = (u8)data;
+ davinci_spi-rx = rx;
+ }
}
static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
{
- u16 *rx = davinci_spi-rx;
-
- *rx++ = (u16)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u16 *rx = davinci_spi-rx;
+ *rx++ = (u16)data;
+ davinci_spi-rx = rx;
+ }
}
static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u8 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u8 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u16 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u16 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
@@ -89,26 +92,6 @@ static inline void clear_io_bits(void __iomem *addr, u32
bits)
iowrite32(v, addr);
}
-static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
-{
- struct davinci_spi *davinci_spi = spi_master_get_devdata(spi-master);
-
- if (enable)
- set_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
- else
- clear_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
-}
-
/*
* Interface to control the chip select signal
*/
@@ -116,25 +99,54 @@ static void davinci_spi_chipselect(struct spi_device *spi,
int value)
{
struct davinci_spi *davinci_spi;
struct davinci_spi_platform_data *pdata;
- u32 data1_reg_val = 0;
+ u8 i, chip_sel = spi-chip_select;
+ u32 spidat1;
+ u16 spidat1_cfg;
davinci_spi = spi_master_get_devdata(spi-master);
pdata = davinci_spi-pdata
RE: [PATCH 0/2] overhaul davinci spi driver to fix multiple errors
Sorry, the last version had a bunch of whitespace problems. I will resubmit the patch shortly. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: edma: clear events in edma_start()
This patch fixes an issue where a DMA channel can erroneously process an event generated by a previous transfer. A failure case is where DMA is being used for SPI transmit and receive channels on OMAP L138. In this case there is a single bit that controls all event generation from the SPI peripheral. Therefore it is possible that between when edma_stop() has been called for the transmit channel on a previous transfer and edma_start() is called for the transmit channel on a subsequent transfer, that a transmit event has been generated. The fix is to clear events in edma_start(). This prevents false events from being processed when events are enabled for that channel. Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com --- arch/arm/mach-davinci/dma.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 5cd48fa..52c16ff 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1290,7 +1290,8 @@ int edma_start(unsigned channel) /* EDMA channel with event association */ pr_debug(EDMA: ER%d %08x\n, j, edma_shadow0_read_array(ctlr, SH_ER, j)); - /* Clear any pending error */ + /* Clear any pending event or error */ + edma_write_array(ctlr, EDMA_ECR, j, mask); edma_write_array(ctlr, EDMA_EMCR, j, mask); /* Clear any SER */ edma_shadow0_write_array(ctlr, SH_SECR, j, mask); -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DMA for Davinci SPI controller with multiple slave devices
-Original Message- From: Nori, Sekhar [mailto:nsek...@ti.com] Sent: Thursday, January 14, 2010 12:44 AM To: Brian Niebuhr Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: DMA for Davinci SPI controller with multiple slave devices Hello Brian, On Thu, Jan 14, 2010 at 04:26:15, Brian Niebuhr wrote: I am working on building a kernel for a custom board based on an OMAP L138. As a baseline I am using the OMAP L138 SDK kernel. On my board there are multiple SPI slaves connected to the SPI1 controller. I'm getting some errors during boot because after the first slave has initialized, the others report an error that they can't aquire a DMA channel. I've been looking through the code and I understand why the error occurs, but I'm not sure how to fix it correctly. Here's what I know: - In arch/arm/mach-davinci/devices-da8xx.c there are two DMA channels (one Tx, one Rx) allocated for the SPI1 controller. - In drivers/spi/davinci_spi_master.c the controller maintains a struct davinci_spi_dma for every chip select. - In drivers/spi/davinci_spi_master.c, davinci_spi_probe() sets the dma_rx_sync_dev field of that structure for every chip select to the Rx DMA channel, and likewise the dma_tx_sync_dev field of that structure for every chip select to the Tx DMA channel. - Then for every SPI device, drivers/spi/davinci_spi_master.c:davinci_spi_setup() gets called which in turn calls davinci_spi_request_dma(). - So here is the problem: davinci_spi_request_dma() requests the channels specified in dma_rx_sync_dev and dma_tx_sync_dev, which are the same channels for every device. Therefore the first device succeeds but additional devices on that controller fail. Yes, this was reported before when the driver patch was submitted for review[1]. But, in the interest of having the driver hit upstream sooner versus having all features supported correctly, this has remained a TODO item. So I'm trying to figure out what the driver writer intended so I can solve this problem. I see two potential solutions: 1. Allocate more DMA channels in devices-da8xx.c. Then in davinci_spi_probe() set the dma_[rx|tx]_sync_dev fields to a different channel for each device. I don't fully understand though if they would need separate eventqs too. This seems unnecessary, though, because only one can be active at a time anyway. 2. Share the DMA channels between all devices on a controller. This seems like it would work fine except for the fact that the DMA callbacks would be messed up as written. However I also think that it would be possible to rewrite the callback function to work correctly. Right. Without a fix of some sort, the only other way is to not to use DMA at all and use PIO mode instead. I'm leaning toward (2), but I don't fully understand the driver. I believe (2) is the right way too. Does anyone have any suggestions on how to fix this, or am I just completely misunderstanding how this is supposed to work? A fix is needed. It would be great if this is something you can help on. I will attempt a fix, though it's going to be a while before I get to test it. If I can test before anyone else gets around to fixing it, I'll submit a patch. Brian Thanks, Sekhar [1] http://linux.omap.com/pipermail/davinci-linux-open-source/2009 -November/016979.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DMA for Davinci SPI controller with multiple slave devices
I am working on building a kernel for a custom board based on an OMAP L138. As a baseline I am using the OMAP L138 SDK kernel. On my board there are multiple SPI slaves connected to the SPI1 controller. I'm getting some errors during boot because after the first slave has initialized, the others report an error that they can't aquire a DMA channel. I've been looking through the code and I understand why the error occurs, but I'm not sure how to fix it correctly. Here's what I know: - In arch/arm/mach-davinci/devices-da8xx.c there are two DMA channels (one Tx, one Rx) allocated for the SPI1 controller. - In drivers/spi/davinci_spi_master.c the controller maintains a struct davinci_spi_dma for every chip select. - In drivers/spi/davinci_spi_master.c, davinci_spi_probe() sets the dma_rx_sync_dev field of that structure for every chip select to the Rx DMA channel, and likewise the dma_tx_sync_dev field of that structure for every chip select to the Tx DMA channel. - Then for every SPI device, drivers/spi/davinci_spi_master.c:davinci_spi_setup() gets called which in turn calls davinci_spi_request_dma(). - So here is the problem: davinci_spi_request_dma() requests the channels specified in dma_rx_sync_dev and dma_tx_sync_dev, which are the same channels for every device. Therefore the first device succeeds but additional devices on that controller fail. So I'm trying to figure out what the driver writer intended so I can solve this problem. I see two potential solutions: 1. Allocate more DMA channels in devices-da8xx.c. Then in davinci_spi_probe() set the dma_[rx|tx]_sync_dev fields to a different channel for each device. I don't fully understand though if they would need separate eventqs too. This seems unnecessary, though, because only one can be active at a time anyway. 2. Share the DMA channels between all devices on a controller. This seems like it would work fine except for the fact that the DMA callbacks would be messed up as written. However I also think that it would be possible to rewrite the callback function to work correctly. I'm leaning toward (2), but I don't fully understand the driver. Does anyone have any suggestions on how to fix this, or am I just completely misunderstanding how this is supposed to work? Thanks, Brian _ Brian Niebuhr Principal Design Engineer E.F. Johnson ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Buildroot on 6446EVM
One independent thing to try: Check make menuconfig of your kernel if any floating point emulation is enabled: Floating point emulation --- [*] NWFPE math emulation Dirk - Thanks for this suggestion - I would never have figured that one out. I had a different floating point emulation implementation selected, and when I switched to NWFPE things started working. Can I ask why you suspected floating point emulation? Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Buildroot on 6446EVM
Has anyone got buildroot to work on the 6446EVM? I am currently running the 2.6.23-davinci1 git kernel with a Montavista-generated cramfs root filesystem and that is working fine. However, adding just a couple of packages to create a minimal filesystem makes the filesystem huge. So I wanted to try buildroot to generate a uClibc-based toolchain and filesystem. I was able to get buildroot to create a cramfs root filesystem and I used it to replace my Montavista filesystem. However when the kernel gets to the point where it should run init, it just apparently hangs (no output whatsoever). I've tried various init= kernel parameters, including just init=/bin/sh, and I always get the same results. It's as if busybox can't start running. I assume that I just messed something up in the buildroot configuration, but I'm not sure what. If anyone has this working, could I get a copy of your buildroot .config and/or any tips on how to make it work? Thanks! Brian _ Brian Niebuhr Senior Design Engineer E.F. Johnson ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Buildroot on 6446EVM
Brian Niebuhr wrote: Has anyone got buildroot to work on the 6446EVM? I am currently running the 2.6.23-davinci1 git kernel with a Montavista-generated cramfs root filesystem and that is working fine. However, adding just a couple of packages to create a minimal filesystem makes the filesystem huge. So I wanted to try buildroot to generate a uClibc-based toolchain and filesystem. I was able to get buildroot to create a cramfs root filesystem and I used it to replace my Montavista filesystem. However when the kernel gets to the point where it should run init, it just apparently hangs (no output whatsoever). I've tried various init= kernel parameters, including just init=/bin/sh, and I always get the same results. It's as if busybox can't start running. I assume that I just messed something up in the buildroot configuration, but I'm not sure what. If anyone has this working, could I get a copy of your buildroot .config and/or any tips on how to make it work? I guess I have faced this problem before. I'm really not sure, but this can be related to EABI/OABI incompatibility. Just a tought. That was my original thought too. In fact, I had configured my kernel without EABI and I configured buildroot to use EABI. Once I noticed this, I did a make clean in buildroot, changed the buildroot ABI setting to OABI, and rebuilt buildroot. But unfortunately I got the same results. I am going to try getting a pristine copy of buildroot and configuring it correctly in the first place, but I'm guessing that's not going to help. Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Buildroot on 6446EVM
Buildroot is good at building all together, but not good at cleaning. Since your console is working and even init=/bin/sh is not working I suspected EABI/OABI stuff. Moreover, I read some warnings some time ago on the buildroot mailing list about this issue. Caglar - You were correct. After getting a brand new copy of buildroot and configuring it for OABI, /sbin/getty now runs. Unfortunately it hasn't gotten me much further because a shell still won't run. Once I log in, a shell never starts and getty just respawns. Using init=/bin/sh or init=/bin/ash just hangs like it did before with no output. I compiled a hello world program with the uclibc toolchain, and using that for init works just fine. So there's something about the busybox shell that isn't working right. In any case, I got a little further. Thanks for the help. Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
