• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 534 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP L138 SPI

ranchu
Guru 20755 points
Other Parts Discussed in Thread: OMAPL138, OMAP-L138Hello, I am trying to understand the logic behind the implementation of SPI interface IN U-BOOT (davinci_spi.c) , and came across this validity routine : int spi_cs_is_valid(unsigned int bus, unsigned int cs) { return bus == 0 && cs == 0; } Althout OMAPL138 can have 2 ports, and if I understand correct port is the same as bus, it seems that configuration fail if bus is different then 0. I wander if any one can solve this issue for me: what is the logic behind this validity routine. Many Thanks, Ran
  • 0
    TI__Intellectual 2725 points
    Hi, It seems that currently both atmel & davinci boards supports only 1 spi instance at a time. In order to support different spi instances, In case of atmel declare SPIx_BASE as required & set CONFIG_DEFAULT_SPI_BUS to required bus In case of davinci set CONFIG_SYS_SPI_BASE to base address of required spi instance Also, spi_cs_is_valid() function needs to be updated to support different spi instances. spi_cs_is_valid() function is board dependednt. Hope this helps. Regards, Gururaja
  • 0 in reply to Gururaja Hebbar
    Guru 20755 points
    Hi Gururaja, Thanks for your reply. Is the limitation you are talking about is OMAP L138 limit, or because of the specific implementation in-U-BOOT ? In the OMAP l138 I didn't find any description of limit in using only one SPI interface at a time. What did you actually mean that we can use only one instance at a time ? Anyway, If I want to check both ports even if I'm not using both of them at the same time, I still need to change many things in the implementation in the U-BOOT (davinci_spi.c). Regards, Ran
  • 0 in reply to ranchu
    TI__Intellectual 2725 points
    Hi, >>Is the limitation you are talking about is OMAP L138 limit or because of the specific implementation in-U-BOOT No no. Its not the limitation of OMAP-L138. Its the u-boot spi driver implementation for davinci/atmel that has limited it. >>What did you actually mean that we can use only one instance at a time ? when any spi related command is issue from u-boot console, it speciafically looks for result from spi_cs_is_valid(). Currenly davinci spi driver only allows (bus == 0) to pass which means spi0. So if you want to support other or many spi port at once, then 1. you need to change spi_cs_is_valid() to check for various bus values & 2. validate the bus argument to spi_setup_slave(). may be using a switch as in case of atmel. from ds->regs = (struct davinci_spi_regs *)CONFIG_SYS_SPI_BASE; to struct davinci_spi_regs *regs; switch (bus) { case 0: regs = (struct davinci_spi_regs *)CONFIG_SYS_SPI0_BASE; break; case 1: regs = (struct davinci_spi_regs *)CONFIG_SYS_SPI1_BASE; break; ... ... default: return NULL; } ds->regs = regs; Regards Gururaja
  • 0 in reply to Gururaja Hebbar
    Guru 20755 points
    Hi Gururaja, It was a bit time since you've answered my questions, thanks and hope everything is well with you. I came back to this issue since in the OMAP-L138 EVM (LogicPD) SPI1 is used for the spi-flash, and SPI0 is used for the MII, and I therefore dont understanf why we probe the SPI FLASH using bus=0 (command in u-boot> sf probe 0:0). Maybe "bus" is not the same as "port" ? Thank you very much, Ran
  • 0 in reply to Gururaja Hebbar
    Guru 20755 points
    OK, I got it. in u-boot I probe the flash with sf probe 0:0 ([bus]:cs) I thought that it mean that SPI flash is using port 0 (while it is defenitly connected to port SPI1), but on diving into the code, I see that it does not use this bus parameter anyway, and always access the memory register of SPI1 anyway. defenitly confusing... Thank you for the help! Ran
  • 0 in reply to ranchu
    Expert 1935 points

    yes I found that, too.  The spi driver from TI (davinci_spi.c) hard codes the spi bus used, ignoring the bus parameter from the spi driver.

    It's pretty easy to change the code so it uses the correct base address given the bus number...

    (put the correct base address in the struct during initialization based on the bus)

    TI should fix this.