RE: [PATCH v5 1/1] davinci: spi: replace existing driver

2010-10-12 Thread Nori, Sekhar
Hi Mike,

On Mon, Oct 11, 2010 at 23:39:35, Michael Williamson wrote:

 
  Hmm, looks like the Tx and Rx DMA must always run for the same duration. I 
  was
  under the impression Tx is required to keep the clock running, and so must 
  always
  run for the length of transfer requested, but Rx DMA can finish earlier.
 

 That may be true.  The scenario I was seeing was a requested Tx length of 1 
 with no
 Rx buffer supplied.  The length of the internal buffer was bigger than 1, so 
 the resulting
 Rx DMA size in the a_b_cnt was greater than the Tx size, and it stalled.

  I guess replacing the line:
 
  param.a_b_cnt = rx_buf_count  16 | data_type;
 
  with
 
  param.a_b_cnt = davinci_spi-rcount  16 | data_type;
 
  will also fix the issue?
 

 A better fix.  should be fine.

I tested this on DA830 and DA850 EVMs with SPI nor flash - it works fine.
I added your Tested-By to the DMA patches as well. Thanks for the testing
and bug fixing.

Updated set of patches pushed to my branch[1]. Testing on DM* platforms
is the next task.

Thanks,
Sekhar

[1] 
http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

___
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 v5 1/1] davinci: spi: replace existing driver

2010-10-11 Thread Nori, Sekhar
Hi Mike,

On Sat, Oct 09, 2010 at 18:25:54, Michael Williamson wrote:
 On 10/08/2010 03:22 PM, Michael Williamson wrote:

  On 10/6/2010 11:37 AM, Nori, Sekhar wrote:

  On Mon, Sep 20, 2010 at 23:12:53, Michael Williamson wrote:

 
  I just finished pushing the DMA related patches to the git branch[1].
  I have not tested yet, but feel free to give it a go (maybe I will get
  lucky again!).
 
 
 
  I gave it a go for our platform.  The good news is, polled and interrupt 
  driven mode still work!
  The bad news is that DMA mode hangs up the kernel on the first read 
  attempt, stalled waiting
  for the transfer completion notification (hmmm I think this was a spot 
  where things were
  tweaked a bit? :) )
 
  I'll see if I can narrow it down some more if you don't get to it first.
 

 I think I found it.  This patch (below, and on [2]) got it working for me. 
 The Rx DMA
 size on transfer requests with no receive buffer provided needs to match the 
 requested
 size (and the transmit size), not the size of the temporary buffer.  All good 
 as the
 DMA address increment is 0 in this case.

 I'll try to do some more testing next week, but so far so good.

Sorry, I couldn’t get to testing even today. Should be on it
tomorrow.


 ---
 diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
 index 662ebbe..8206df1 100755
 --- a/drivers/spi/davinci_spi.c
 +++ b/drivers/spi/davinci_spi.c
 @@ -632,13 +632,11 @@ static int davinci_spi_bufs(struct spi_device *spi, 
 struct spi_transfer *t)
* source address never increments.
*/

 - if (t-rx_buf) {
 + rx_buf_count = davinci_spi-rcount;
 + if (t-rx_buf)
   rx_buf = t-rx_buf;
 - rx_buf_count = davinci_spi-rcount;
 - } else {
 + else
   rx_buf = davinci_spi-rx_tmp_buf;
 - rx_buf_count = sizeof(davinci_spi-rx_tmp_buf);
 - }

   t-rx_dma = dma_map_single(spi-dev, rx_buf, rx_buf_count,
   DMA_FROM_DEVICE);

Hmm, looks like the Tx and Rx DMA must always run for the same duration. I was
under the impression Tx is required to keep the clock running, and so must 
always
run for the length of transfer requested, but Rx DMA can finish earlier.

I guess replacing the line:

param.a_b_cnt = rx_buf_count  16 | data_type;

with

param.a_b_cnt = davinci_spi-rcount  16 | data_type;

will also fix the issue?


 
  Also, do you have patches adding SPI support for DA850 platform?
  I can include these patches on this branch so others who will be
  testing dont have to repeat the work.
 
 
 
  I cloned your repository at [1] and published the additions needed to made 
  to test it on the
  mitydsp-l138 platform (da850 based) at [2] (never mind the UART one at the 
  end).  I had to add
  clock support for the spi devices and define the platform SPI 
  resources/registration routines.
  I'd appreciate a quick peek at those to make sure that I didn't make any 
  errors.  The spi
  registration may be refactorable (sp?) to support da830, I didn't look to 
  closely at that.
 
  If any of it is usable, great.

Sure it is! I checked-in your patches with some modifications to my
branch. The most notable change being usage of da8xx instead of da850 since
the same code should work on da830 as well. Apart from this there are
some cosmetic changes (patches squashed, some non-relevant hunks dropped
etc). Do update the patches in your tree if you are OK with the changes.

Thanks,
Sekhar

___
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 v5 1/1] davinci: spi: replace existing driver

2010-10-11 Thread Michael Williamson
On 10/11/2010 12:57 PM, Nori, Sekhar wrote:
 Hi Mike,
 
 On Sat, Oct 09, 2010 at 18:25:54, Michael Williamson wrote:
 On 10/08/2010 03:22 PM, Michael Williamson wrote:
 
 On 10/6/2010 11:37 AM, Nori, Sekhar wrote:
 
 On Mon, Sep 20, 2010 at 23:12:53, Michael Williamson wrote:
 

 I just finished pushing the DMA related patches to the git branch[1].
 I have not tested yet, but feel free to give it a go (maybe I will get
 lucky again!).



 I gave it a go for our platform.  The good news is, polled and interrupt 
 driven mode still work!
 The bad news is that DMA mode hangs up the kernel on the first read 
 attempt, stalled waiting
 for the transfer completion notification (hmmm I think this was a spot 
 where things were
 tweaked a bit? :) )

 I'll see if I can narrow it down some more if you don't get to it first.


 I think I found it.  This patch (below, and on [2]) got it working for me. 
 The Rx DMA
 size on transfer requests with no receive buffer provided needs to match the 
 requested
 size (and the transmit size), not the size of the temporary buffer.  All 
 good as the
 DMA address increment is 0 in this case.

 I'll try to do some more testing next week, but so far so good.
 
 Sorry, I couldn’t get to testing even today. Should be on it
 tomorrow.
 

 ---
 diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
 index 662ebbe..8206df1 100755
 --- a/drivers/spi/davinci_spi.c
 +++ b/drivers/spi/davinci_spi.c
 @@ -632,13 +632,11 @@ static int davinci_spi_bufs(struct spi_device *spi, 
 struct spi_transfer *t)
* source address never increments.
*/

 - if (t-rx_buf) {
 + rx_buf_count = davinci_spi-rcount;
 + if (t-rx_buf)
   rx_buf = t-rx_buf;
 - rx_buf_count = davinci_spi-rcount;
 - } else {
 + else
   rx_buf = davinci_spi-rx_tmp_buf;
 - rx_buf_count = sizeof(davinci_spi-rx_tmp_buf);
 - }

   t-rx_dma = dma_map_single(spi-dev, rx_buf, rx_buf_count,
   DMA_FROM_DEVICE);
 
 Hmm, looks like the Tx and Rx DMA must always run for the same duration. I was
 under the impression Tx is required to keep the clock running, and so must 
 always
 run for the length of transfer requested, but Rx DMA can finish earlier.
 

That may be true.  The scenario I was seeing was a requested Tx length of 1 
with no
Rx buffer supplied.  The length of the internal buffer was bigger than 1, so 
the resulting
Rx DMA size in the a_b_cnt was greater than the Tx size, and it stalled.

 I guess replacing the line:
 
 param.a_b_cnt = rx_buf_count  16 | data_type;
 
 with
 
 param.a_b_cnt = davinci_spi-rcount  16 | data_type;
 
 will also fix the issue?
 

A better fix.  should be fine.



 Also, do you have patches adding SPI support for DA850 platform?
 I can include these patches on this branch so others who will be
 testing dont have to repeat the work.



 I cloned your repository at [1] and published the additions needed to made 
 to test it on the
 mitydsp-l138 platform (da850 based) at [2] (never mind the UART one at the 
 end).  I had to add
 clock support for the spi devices and define the platform SPI 
 resources/registration routines.
 I'd appreciate a quick peek at those to make sure that I didn't make any 
 errors.  The spi
 registration may be refactorable (sp?) to support da830, I didn't look to 
 closely at that.

 If any of it is usable, great.
 
 Sure it is! I checked-in your patches with some modifications to my
 branch. The most notable change being usage of da8xx instead of da850 since
 the same code should work on da830 as well. Apart from this there are
 some cosmetic changes (patches squashed, some non-relevant hunks dropped
 etc). Do update the patches in your tree if you are OK with the changes.
 

OK.  I'll try to rebase off your tree and retest.  

-Mike
___
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 v5 1/1] davinci: spi: replace existing driver

2010-10-11 Thread Michael Williamson
On 10/11/2010 12:57 PM, Nori, Sekhar wrote:
 Hi Mike,
 
 On Sat, Oct 09, 2010 at 18:25:54, Michael Williamson wrote:
 On 10/08/2010 03:22 PM, Michael Williamson wrote:
 
 On 10/6/2010 11:37 AM, Nori, Sekhar wrote:
 
 On Mon, Sep 20, 2010 at 23:12:53, Michael Williamson wrote:
 

 I just finished pushing the DMA related patches to the git branch[1].

[ stuff deleted ]



 Also, do you have patches adding SPI support for DA850 platform?
 I can include these patches on this branch so others who will be
 testing dont have to repeat the work.



 I cloned your repository at [1] and published the additions needed to made 
 to test it on the
 mitydsp-l138 platform (da850 based) at [2] (never mind the UART one at the 
 end).  I had to add
 clock support for the spi devices and define the platform SPI 
 resources/registration routines.
 I'd appreciate a quick peek at those to make sure that I didn't make any 
 errors.  The spi
 registration may be refactorable (sp?) to support da830, I didn't look to 
 closely at that.

 If any of it is usable, great.
 
 Sure it is! I checked-in your patches with some modifications to my
 branch. The most notable change being usage of da8xx instead of da850 since
 the same code should work on da830 as well. Apart from this there are
 some cosmetic changes (patches squashed, some non-relevant hunks dropped
 etc). Do update the patches in your tree if you are OK with the changes.
 

I think that the spi device names in the clk_lookup table in da830.c may need 
to be updated.  Right now
they are shown as dm_spi.0.  Should they be spi_davinci.o and 
spi_davinci.1?

-Mike

___
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 v5 1/1] davinci: spi: replace existing driver

2010-10-09 Thread Michael Williamson
On 10/08/2010 03:22 PM, Michael Williamson wrote:
 Hi Sekhar,
 
 On 10/6/2010 11:37 AM, Nori, Sekhar wrote:
 
 Hi Mike,

 On Mon, Sep 20, 2010 at 23:12:53, Michael Williamson wrote:

 Let me know if you want testing on the DMA portion of the patch (when your 
 ready, of course).

 I just finished pushing the DMA related patches to the git branch[1].
 I have not tested yet, but feel free to give it a go (maybe I will get
 lucky again!).

 
 
 I gave it a go for our platform.  The good news is, polled and interrupt 
 driven mode still work!  
 The bad news is that DMA mode hangs up the kernel on the first read attempt, 
 stalled waiting 
 for the transfer completion notification (hmmm I think this was a spot 
 where things were 
 tweaked a bit? :) )
 
 I'll see if I can narrow it down some more if you don't get to it first.
  

I think I found it.  This patch (below, and on [2]) got it working for me. The 
Rx DMA
size on transfer requests with no receive buffer provided needs to match the 
requested
size (and the transmit size), not the size of the temporary buffer.  All good 
as the
DMA address increment is 0 in this case.

I'll try to do some more testing next week, but so far so good.

---
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 662ebbe..8206df1 100755
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -632,13 +632,11 @@ static int davinci_spi_bufs(struct spi_device *spi, 
struct spi_transfer *t)
 * source address never increments.
 */
 
-   if (t-rx_buf) {
+   rx_buf_count = davinci_spi-rcount;
+   if (t-rx_buf)
rx_buf = t-rx_buf;
-   rx_buf_count = davinci_spi-rcount;
-   } else {
+   else
rx_buf = davinci_spi-rx_tmp_buf;
-   rx_buf_count = sizeof(davinci_spi-rx_tmp_buf);
-   }
 
t-rx_dma = dma_map_single(spi-dev, rx_buf, rx_buf_count,
DMA_FROM_DEVICE);

 
 Also, do you have patches adding SPI support for DA850 platform?
 I can include these patches on this branch so others who will be
 testing dont have to repeat the work.

 
 
 I cloned your repository at [1] and published the additions needed to made to 
 test it on the
 mitydsp-l138 platform (da850 based) at [2] (never mind the UART one at the 
 end).  I had to add 
 clock support for the spi devices and define the platform SPI 
 resources/registration routines.  
 I'd appreciate a quick peek at those to make sure that I didn't make any 
 errors.  The spi 
 registration may be refactorable (sp?) to support da830, I didn't look to 
 closely at that.
 
 If any of it is usable, great.
 
 Thanks,
 Sekhar

 [1] 
 http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

 
 
 [2] 
 http://support.criticallink.com/gitweb/?p=linux-davinci.git;a=shortlog;h=refs/heads/spi-testing
 
 -Mike

___
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 v5 1/1] davinci: spi: replace existing driver

2010-10-08 Thread Michael Williamson
Hi Sekhar,

On 10/6/2010 11:37 AM, Nori, Sekhar wrote:

 Hi Mike,
 
 On Mon, Sep 20, 2010 at 23:12:53, Michael Williamson wrote:

 Let me know if you want testing on the DMA portion of the patch (when your 
 ready, of course).
 
 I just finished pushing the DMA related patches to the git branch[1].
 I have not tested yet, but feel free to give it a go (maybe I will get
 lucky again!).



I gave it a go for our platform.  The good news is, polled and interrupt driven 
mode still work!  
The bad news is that DMA mode hangs up the kernel on the first read attempt, 
stalled waiting 
for the transfer completion notification (hmmm I think this was a spot 
where things were 
tweaked a bit? :) )

I'll see if I can narrow it down some more if you don't get to it first.
 

 Also, do you have patches adding SPI support for DA850 platform?
 I can include these patches on this branch so others who will be
 testing don’t have to repeat the work.
 


I cloned your repository at [1] and published the additions needed to made to 
test it on the
mitydsp-l138 platform (da850 based) at [2] (never mind the UART one at the 
end).  I had to add 
clock support for the spi devices and define the platform SPI 
resources/registration routines.  
I'd appreciate a quick peek at those to make sure that I didn't make any 
errors.  The spi 
registration may be refactorable (sp?) to support da830, I didn't look to 
closely at that.

If any of it is usable, great.

 Thanks,
 Sekhar
 
 [1] 
 http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite
 


[2] 
http://support.criticallink.com/gitweb/?p=linux-davinci.git;a=shortlog;h=refs/heads/spi-testing

-Mike
___
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 v5 1/1] davinci: spi: replace existing driver

2010-10-06 Thread Nori, Sekhar
Hi Mike,

On Mon, Sep 20, 2010 at 23:12:53, Michael Williamson wrote:

 Let me know if you want testing on the DMA portion of the patch (when your 
 ready, of course).

I just finished pushing the DMA related patches to the git branch[1].
I have not tested yet, but feel free to give it a go (maybe I will get
lucky again!).

Also, do you have patches adding SPI support for DA850 platform?
I can include these patches on this branch so others who will be
testing don’t have to repeat the work.

Thanks,
Sekhar

[1] 
http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-27 Thread Nori, Sekhar
Hi Mike,

On Mon, Sep 20, 2010 at 23:12:53, Michael Williamson wrote:


 Let me know if you want testing on the DMA portion of the patch (when your 
 ready, of course).


I just got back to this last Friday. Will let you know once done.
Meanwhile I added your Tested-By: to the existing patches.

Thanks for testing.

Regards,
Sekhar

___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-20 Thread Nori, Sekhar
Hi Michael,

On Sat, Sep 18, 2010 at 18:38:13, Michael Williamson wrote:
 On 09/14/2010 09:26 AM, Nori, Sekhar wrote:
  Hi Mike,
 
  On Tue, Sep 14, 2010 at 18:40:56, Michael Williamson wrote:
  On 9/14/2010 3:14 AM, Nori, Sekhar wrote:
 
  On Tue, Sep 14, 2010 at 11:34:59, Caglar Akyuz wrote:
 
  Yes, your patches seems ok and mostly complete. I'm waiting for hardware 
  to
  test those, will let you know when I do some testing.
 
  Thanks! To save time, I haven't tested these patches myself. I have only 
  made
  sure individual patches don't break the build. Was planning to test after
  the complete series is ready.
 
 
 
  If it would help, If there are portions of the patch set that can be tested
  with DMA disabled or something, I'd be willing to kick the tires.  I have
  da850 hardware available.
 
  Thanks for being brave and offering to help! Yes, interrupt and polled mode
  can be tried. Since a lot of testing has already happened on the original 
  patch,
  I was planning to test the series only after it is complete. Any issues 
  found can
  be narrowed down to the differences (which I hope will be justifiable).
 
  Thanks,
  Sekhar

 So I am testing with a configuration which is pretty much the same as the 
 da850 EVM;
 a SPI-NOR flash on the first chip select of SPI1.  Both poll and interrupt 
 modes
 work.  So far so good, and Brian's work really sorted out a bunch of questions
 I had looking at the original spi code.  Nice work, Nori, for break the patch
 into logical blocks.  I do have a couple of comments:

Really?? Just worked? Wooohooo...


 * I'm not sure I understand why there is a intr_line field in the platform
 data and then a possibility to configure an io_type as interrupt or polled 
 at
 the chip select level.  I got burned by setting the io_type to 
 SPI_IO_TYPE_INTR
 and not setting intr_line to non-zero.  The probe just hung because it was
 trying to use interrupts but never setting SPILVL register.  These fields 
 aren't
 mutually exclusive.  Is the intent to support a configuration with one chip 
 select
 running in polled mode and another in interrupt mode?  If so, then it seems 
 the SPILVL
 register logic needs some attention during each transfer.

The intr_line to be set is constant for the SoC. So, irrespective of what the
individual devices on a given board choose to operate (interrupted, polled or 
DMA)
the SoC code (da850.c) should setup the intr_line according to how the SPI 
interrupt
is wired within the SoC. Can you clarify what you mean by needs some attention 
during
each transfer?


 * As a (novice) user, I'd really like to see some comments / hints added to 
 the
 ../mach-davinci/include/mach/spi.h file to describe how all of the platform 
 fields
 should be set.  Some of the fields aren't very obvious as to how to initialize
 them without having a data sheet on one screen and plowing through the
 driver on another.  This might have cleaned up my confusion on the first item.

Good point. Will ensure this.

Thanks,
Sekhar

___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-20 Thread Michael Williamson
On 9/20/2010 11:08 AM, Nori, Sekhar wrote:

 Hi Michael,
 
 On Sat, Sep 18, 2010 at 18:38:13, Michael Williamson wrote:

 * I'm not sure I understand why there is a intr_line field in the platform
 data and then a possibility to configure an io_type as interrupt or polled 
 at
 the chip select level.  I got burned by setting the io_type to 
 SPI_IO_TYPE_INTR
 and not setting intr_line to non-zero.  The probe just hung because it was
 trying to use interrupts but never setting SPILVL register.  These fields 
 aren't
 mutually exclusive.  Is the intent to support a configuration with one chip 
 select
 running in polled mode and another in interrupt mode?  If so, then it seems 
 the SPILVL
 register logic needs some attention during each transfer.
 
 The intr_line to be set is constant for the SoC. So, irrespective of what the
 individual devices on a given board choose to operate (interrupted, polled or 
 DMA)
 the SoC code (da850.c) should setup the intr_line according to how the SPI 
 interrupt
 is wired within the SoC. Can you clarify what you mean by needs some 
 attention during
 each transfer?
 


Ah... OK.  Thank you.  I now see that the SPILVL can be INT0 or INT1 for other 
davinci
SoCs like the DM644x.  For the da850 (OMAP-L138), SPILVL is valid only for 
INT1.  So 
pretty much, if your using a da850 (at least), intr_line has to be 1.  On other 
platforms,
it carries a lot more meaning...

Please ignore my ignorance...

Let me know if you want testing on the DMA portion of the patch (when your 
ready, of course).  

-Mike



___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-18 Thread Michael Williamson
On 09/14/2010 09:26 AM, Nori, Sekhar wrote:
 Hi Mike,
 
 On Tue, Sep 14, 2010 at 18:40:56, Michael Williamson wrote:
 On 9/14/2010 3:14 AM, Nori, Sekhar wrote:

 On Tue, Sep 14, 2010 at 11:34:59, Caglar Akyuz wrote:

 Yes, your patches seems ok and mostly complete. I'm waiting for hardware to
 test those, will let you know when I do some testing.

 Thanks! To save time, I haven't tested these patches myself. I have only 
 made
 sure individual patches don't break the build. Was planning to test after
 the complete series is ready.



 If it would help, If there are portions of the patch set that can be tested
 with DMA disabled or something, I'd be willing to kick the tires.  I have
 da850 hardware available.
 
 Thanks for being brave and offering to help! Yes, interrupt and polled mode
 can be tried. Since a lot of testing has already happened on the original 
 patch,
 I was planning to test the series only after it is complete. Any issues found 
 can
 be narrowed down to the differences (which I hope will be justifiable).
 
 Thanks,
 Sekhar

So I am testing with a configuration which is pretty much the same as the da850 
EVM;
a SPI-NOR flash on the first chip select of SPI1.  Both poll and interrupt modes
work.  So far so good, and Brian's work really sorted out a bunch of questions 
I had looking at the original spi code.  Nice work, Nori, for break the patch
into logical blocks.  I do have a couple of comments:

* I'm not sure I understand why there is a intr_line field in the platform 
data and then a possibility to configure an io_type as interrupt or polled at
the chip select level.  I got burned by setting the io_type to 
SPI_IO_TYPE_INTR
and not setting intr_line to non-zero.  The probe just hung because it was
trying to use interrupts but never setting SPILVL register.  These fields aren't
mutually exclusive.  Is the intent to support a configuration with one chip 
select 
running in polled mode and another in interrupt mode?  If so, then it seems the 
SPILVL
register logic needs some attention during each transfer.

* As a (novice) user, I'd really like to see some comments / hints added to the 
../mach-davinci/include/mach/spi.h file to describe how all of the platform 
fields 
should be set.  Some of the fields aren't very obvious as to how to initialize 
them without having a data sheet on one screen and plowing through the 
driver on another.  This might have cleaned up my confusion on the first item.

Looking forward to seeing this moving into the mainline.  Thanks!

-Mike

___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-18 Thread Michael Williamson
[...]

 I had looking at the original spi code.  Nice work, Nori, for break the patch

s/Nori/Sekhar

Sorry about that, Sekhar.

-Mike

___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-14 Thread Nori, Sekhar
On Tue, Sep 14, 2010 at 11:34:59, Caglar Akyuz wrote:

 Yes, your patches seems ok and mostly complete. I'm waiting for hardware to
 test those, will let you know when I do some testing.

Thanks! To save time, I haven't tested these patches myself. I have only made
sure individual patches don't break the build. Was planning to test after
the complete series is ready.

Regards,
Sekhar

___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-14 Thread Michael Williamson
On 9/14/2010 3:14 AM, Nori, Sekhar wrote:

 On Tue, Sep 14, 2010 at 11:34:59, Caglar Akyuz wrote:
 
 Yes, your patches seems ok and mostly complete. I'm waiting for hardware to
 test those, will let you know when I do some testing.
 
 Thanks! To save time, I haven't tested these patches myself. I have only made
 sure individual patches don't break the build. Was planning to test after
 the complete series is ready.
 


If it would help, If there are portions of the patch set that can be tested 
with DMA disabled or something, I'd be willing to kick the tires.  I have 
da850 hardware available.

-Mike

___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-14 Thread Nori, Sekhar
Hi Mike,

On Tue, Sep 14, 2010 at 18:40:56, Michael Williamson wrote:
 On 9/14/2010 3:14 AM, Nori, Sekhar wrote:

  On Tue, Sep 14, 2010 at 11:34:59, Caglar Akyuz wrote:
 
  Yes, your patches seems ok and mostly complete. I'm waiting for hardware to
  test those, will let you know when I do some testing.
 
  Thanks! To save time, I haven't tested these patches myself. I have only 
  made
  sure individual patches don't break the build. Was planning to test after
  the complete series is ready.
 


 If it would help, If there are portions of the patch set that can be tested
 with DMA disabled or something, I'd be willing to kick the tires.  I have
 da850 hardware available.

Thanks for being brave and offering to help! Yes, interrupt and polled mode
can be tried. Since a lot of testing has already happened on the original patch,
I was planning to test the series only after it is complete. Any issues found 
can
be narrowed down to the differences (which I hope will be justifiable).

Thanks,
Sekhar
___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-13 Thread Michael Williamson
Hi Sekhar,

On 08/23/2010 05:30 AM, Nori, Sekhar wrote:
 On Mon, Aug 23, 2010 at 14:24:10, Caglar Akyuz wrote:
 On Monday 23 August 2010 07:28:48 am Nori, Sekhar wrote:
 Hi Caglar,


 Hi,

 [...]

 I have been spending time on this (admittedly on and off) since I wrote
  that email and have broken down the work into ~20 patches so far. Starting
  to scratch the DMA related changes right now. So, I guess I am somewhere
  midway.

 I pushed a branch containing the work so far here:

 http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=ref
 s/heads/davinci-spi-rewrite



I've been trying to take a peek, but the arago site seems to be flakey lately,
giving a lot of messages like the one below.  Not sure if you are aware of this.

Looking forward to seeing this...  Thanks!

-Mike

(Arago Error Message).
XML Parsing Error: undefined entity
Location: http://arago-project.org/git/projects/?p=linux-davinci.git;a=summary
Line Number 41, Column 20:div class=titlenbsp;/div
---^
___
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 v5 1/1] davinci: spi: replace existing driver

2010-09-13 Thread Caglar Akyuz
On Tuesday 14 September 2010 08:43:41 am Nori, Sekhar wrote:
 On Tue, Sep 14, 2010 at 05:15:25, Michael Williamson wrote:
  Hi Sekhar,
 
  On 08/23/2010 05:30 AM, Nori, Sekhar wrote:
   On Mon, Aug 23, 2010 at 14:24:10, Caglar Akyuz wrote:
   On Monday 23 August 2010 07:28:48 am Nori, Sekhar wrote:
   Hi Caglar,
  
   Hi,
  
   [...]
  
   I have been spending time on this (admittedly on and off) since I
   wrote that email and have broken down the work into ~20 patches so
   far. Starting to scratch the DMA related changes right now. So, I
   guess I am somewhere midway.
  
   I pushed a branch containing the work so far here:
  
   http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog
  ;h=ref s/heads/davinci-spi-rewrite
 
  I've been trying to take a peek, but the arago site seems to be flakey
  lately, giving a lot of messages like the one below.  Not sure if you are
  aware of this.
 
 Hmm, I have seen this kind of error in the past, but not lately. Accessed
  the site just now without issues.
 
  Looking forward to seeing this...  Thanks!
 
 Got side-tracked the last two weeks. The DMA changes are the major
 chunk left. Hopefully will have the final patch set ready with
 little more effort.
 

Yes, your patches seems ok and mostly complete. I'm waiting for hardware to 
test those, will let you know when I do some testing.

Regards,
Caglar

 Thanks,
 Sekhar
 
 ___
 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 v5 1/1] davinci: spi: replace existing driver

2010-08-23 Thread Caglar Akyuz
On Monday 23 August 2010 07:28:48 am Nori, Sekhar wrote:
 Hi Caglar,
 

Hi,

[...]

 I have been spending time on this (admittedly on and off) since I wrote
  that email and have broken down the work into ~20 patches so far. Starting
  to scratch the DMA related changes right now. So, I guess I am somewhere
  midway.
 
 I pushed a branch containing the work so far here:
 
 http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=ref
 s/heads/davinci-spi-rewrite
 

This is great.

 This isn't tested or submit-worthy yet. I was hoping to break down the
 complete work, test it and get reviewed by Brian. Also, the final work
 may differ from Brian's work slightly as I did some improvements while
 I was the fat patch breaking down.
 
 The breakdown wasn't mechanical because Brian's improvements are very
 intertwined and if I just simply 'selected hunks' it wouldn't make for
 a very reviewable patch series.
 

I was hoping to reach to an exact copy of Brian's version since that version 
is tested by Brian and some others. but if you say so...
  
 Have you also been parallely working on this? If not, I hope you can start
 from what I have already completed. I will continue to work on it anyway.
 This way hopefully the patch series should be ready sooner.
 

I'll start this week working on this, so your patches are perfect for me. I 
don't want to interrupt your working process, I'll follow your tree closely 
for your in-coming changes.

Regards,
Caglar

 Thanks,
 Sekhar
 
___
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 v5 1/1] davinci: spi: replace existing driver

2010-08-23 Thread Nori, Sekhar
On Mon, Aug 23, 2010 at 14:24:10, Caglar Akyuz wrote:
 On Monday 23 August 2010 07:28:48 am Nori, Sekhar wrote:
  Hi Caglar,
 

 Hi,

 [...]

  I have been spending time on this (admittedly on and off) since I wrote
   that email and have broken down the work into ~20 patches so far. Starting
   to scratch the DMA related changes right now. So, I guess I am somewhere
   midway.
 
  I pushed a branch containing the work so far here:
 
  http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=ref
  s/heads/davinci-spi-rewrite
 

 This is great.

  This isn't tested or submit-worthy yet. I was hoping to break down the
  complete work, test it and get reviewed by Brian. Also, the final work
  may differ from Brian's work slightly as I did some improvements while
  I was the fat patch breaking down.
 
  The breakdown wasn't mechanical because Brian's improvements are very
  intertwined and if I just simply 'selected hunks' it wouldn't make for
  a very reviewable patch series.
 

 I was hoping to reach to an exact copy of Brian's version since that version
 is tested by Brian and some others. but if you say so...

Yeah, that was my initial goal too. Anyway, at the end of it we can review
the delta separately and make sure the changes are worth making and don't
actually break functionality.

Thanks,
Sekhar

___
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 v5 1/1] davinci: spi: replace existing driver

2010-08-22 Thread Nori, Sekhar
Hi Caglar,

On Fri, Aug 20, 2010 at 16:36:33, Caglar Akyuz wrote:
 On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
  Hi Brian,
 
  On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
   Grant -
  
  
For my part, I've already sunk way more time into this than I ever
   intended, and I really have no clue how to break this patch down into
   smaller patches.  I don't really care much if the patch gets accepted
   or not - I am just trying to help out all of the other users that are
   stuck with a broken driver like I was.  Maybe if TI wants to give
   their customers a driver that actually works they'll pick it up and do
   the rest of the work that's necessary to get it accepted.
 
  Thanks for all the work on this so far. We will work on breaking
  this patch up and getting the fixes accepted upstream.
 

 Is there any improvement on this or anybody is actively working on submitting
 patches?

 I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different
 peripherals. If nobody is expected to submit something soon, then I can work
 on preparing incremental patches while working with the driver. I can start
 sending patches next week or so.

I have been spending time on this (admittedly on and off) since I wrote that
email and have broken down the work into ~20 patches so far. Starting to
scratch the DMA related changes right now. So, I guess I am somewhere midway.

I pushed a branch containing the work so far here:

http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

This isn't tested or submit-worthy yet. I was hoping to break down the
complete work, test it and get reviewed by Brian. Also, the final work
may differ from Brian's work slightly as I did some improvements while
I was the fat patch breaking down.

The breakdown wasn't mechanical because Brian's improvements are very
intertwined and if I just simply 'selected hunks' it wouldn't make for
a very reviewable patch series.

Have you also been parallely working on this? If not, I hope you can start
from what I have already completed. I will continue to work on it anyway.
This way hopefully the patch series should be ready sooner.

Thanks,
Sekhar

___
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 v5 1/1] davinci: spi: replace existing driver

2010-08-22 Thread Grant Likely


Nori, Sekhar nsek...@ti.com wrote:

Hi Caglar,

On Fri, Aug 20, 2010 at 16:36:33, Caglar Akyuz wrote:
 On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
  Hi Brian,
 
  On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
   Grant -
  
  
For my part, I've already sunk way more time into this than I ever
   intended, and I really have no clue how to break this patch down into
   smaller patches.  I don't really care much if the patch gets accepted
   or not - I am just trying to help out all of the other users that are
   stuck with a broken driver like I was.  Maybe if TI wants to give
   their customers a driver that actually works they'll pick it up and do
   the rest of the work that's necessary to get it accepted.
 
  Thanks for all the work on this so far. We will work on breaking
  this patch up and getting the fixes accepted upstream.
 

 Is there any improvement on this or anybody is actively working on submitting
 patches?

 I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different
 peripherals. If nobody is expected to submit something soon, then I can work
 on preparing incremental patches while working with the driver. I can start
 sending patches next week or so.

I have been spending time on this (admittedly on and off) since I wrote that
email and have broken down the work into ~20 patches so far. Starting to
scratch the DMA related changes right now. So, I guess I am somewhere midway.

I pushed a branch containing the work so far here:

http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

I like what I see so far.  Feel free to post subsets of the whole series as 
soon as you feel they are ready so I can start adding bits to my next-door 
branch.

g.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
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 v5 1/1] davinci: spi: replace existing driver

2010-08-20 Thread Caglar Akyuz
On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
 Hi Brian,
 
 On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
  Grant -
 
 
   For my part, I've already sunk way more time into this than I ever
  intended, and I really have no clue how to break this patch down into
  smaller patches.  I don't really care much if the patch gets accepted
  or not - I am just trying to help out all of the other users that are
  stuck with a broken driver like I was.  Maybe if TI wants to give
  their customers a driver that actually works they'll pick it up and do
  the rest of the work that's necessary to get it accepted.
 
 Thanks for all the work on this so far. We will work on breaking
 this patch up and getting the fixes accepted upstream.
 

Is there any improvement on this or anybody is actively working on submitting 
patches?

I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different 
peripherals. If nobody is expected to submit something soon, then I can work 
on preparing incremental patches while working with the driver. I can start 
sending patches next week or so.

Best Regards,
Caglar

 Regards,
 Sekhar
 ___
 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 v5 1/1] davinci: spi: replace existing driver

2010-08-20 Thread Grant Likely
On Fri, Aug 20, 2010 at 5:06 AM, Caglar Akyuz caglarak...@gmail.com wrote:
 On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
 Hi Brian,

 On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
  Grant -
 
 
   For my part, I've already sunk way more time into this than I ever
  intended, and I really have no clue how to break this patch down into
  smaller patches.  I don't really care much if the patch gets accepted
  or not - I am just trying to help out all of the other users that are
  stuck with a broken driver like I was.  Maybe if TI wants to give
  their customers a driver that actually works they'll pick it up and do
  the rest of the work that's necessary to get it accepted.

 Thanks for all the work on this so far. We will work on breaking
 this patch up and getting the fixes accepted upstream.


 Is there any improvement on this or anybody is actively working on submitting
 patches?

 I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different
 peripherals. If nobody is expected to submit something soon, then I can work
 on preparing incremental patches while working with the driver. I can start
 sending patches next week or so.

 Best Regards,
 Caglar

Thanks Caglar for picking up this work.  I look forward to seeing the
patches.  Let me know if you need any help with getting them in shape
for merging.

g.
___
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 v5 1/1] davinci: spi: replace existing driver

2010-08-03 Thread Grant Likely
On Mon, Aug 2, 2010 at 8:10 AM, Brian Niebuhr bniebu...@gmail.com wrote:
 Grant -

 That's fine - I understand your position.  I do wish you had decided
 earlier that you weren't going to accept the patch in that form though
 so I could have decided whether I wanted to spend any more time on it.
  For my part, I've already sunk way more time into this than I ever
 intended, and I really have no clue how to break this patch down into
 smaller patches.  I don't really care much if the patch gets accepted
 or not - I am just trying to help out all of the other users that are
 stuck with a broken driver like I was.

Hi Brian.  I'm sorry to hear that, but I totally understand having
heavy demands on your time.  Thanks for the work that you have done.
I know it is frustrating when things don't go in as easily as hoped.
I also want to see your changes merged, but I also have to be mindful
of other engineers looking at your commit after the fact and being
able to bisect it.

If you do change your mind, my offer still stands to help you break
the patch down into logical pieces.  It is actually pretty easy to do.

 Maybe if TI wants to give
 their customers a driver that actually works they'll pick it up and do
 the rest of the work that's necessary to get it accepted.  I'm just
 way too swamped with other work to keep going on this.

 Thanks for your help though.  Sorry to waste all of the time you've
 put into this.

It hasn't been wasted time.  You've done all the hard work.  Sounds
like Sekhar from TI will pick up the driver and split it up, which is
an almost mechanical process when you know how to do it.  Thanks for
the time you have spent on this.

Cheers,
g.
___
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 v5 1/1] davinci: spi: replace existing driver

2010-08-02 Thread Nori, Sekhar

Hi Brian,

On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
 Grant -


  For my part, I've already sunk way more time into this than I ever
 intended, and I really have no clue how to break this patch down into
 smaller patches.  I don't really care much if the patch gets accepted
 or not - I am just trying to help out all of the other users that are
 stuck with a broken driver like I was.  Maybe if TI wants to give
 their customers a driver that actually works they'll pick it up and do
 the rest of the work that's necessary to get it accepted.

Thanks for all the work on this so far. We will work on breaking
this patch up and getting the fixes accepted upstream.

Regards,
Sekhar
___
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

2010-07-28 Thread Brian Niebuhr
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,
+