• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1562 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.

can't access spi device from u-boot

ranchu
Guru 20755 points

Hello,

I try to access spi device (lcd controller) from u-boot.

From kernel it works just fine (which means that there is no hw failure),

But on trying to do same access from u-boot, I have difficulties:

1. the original driver was hand in claim_bus routine. It turned out that the driver does not use the right base register. I had to patch, to make it point to the correct base offset: 0x481a2100 .

2. But I still have no access. I noticed that the driver support only 8 bit access, I patched it to 16 bit, but still no access.

3. I've noticed that cm_alwon register has wrong value in u-boot (0x2 instead of 0x30000 ) :

TI8148_EVM#md 0x48181590
48181590: 00000002 00030000 00030000 00030000 ................

So I changed it to 0x30000, and repeated the access sequence, but now it hangs on spi_claim_bus  again !!!

Is there anyone who have functional spi access from u-boot with dm8148 ?

Is it a matter of wrong pll clocks ? I've verified that sysclk10 control register is the same as in kernel (CM_SYSCLK10_CLKSEL
 
0x48180324 <- 0x3).

What else can make it freeze in claim_bus ?

Best Regards,

Ran

  • 0
    TI__Guru**** 170625 points

    Ran,

    Ran Shalit said:

    3. I've noticed that cm_alwon register has wrong value in u-boot (0x2 instead of 0x30000 ) :

    TI8148_EVM#md 0x48181590
    48181590: 00000002 00030000 00030000 00030000 ................

    What make you think this 0x2 value is wrong and 0x30000 value is correct?

    Ran Shalit said:
    So I changed it to 0x30000, and repeated the access sequence, but now it hangs on spi_claim_bus  again !!!

    This is expected, as you change CM_ALWON_SPI_CLKCTRL from enable to disable, thus stop the SPI0/1/2/3 clock.

    BR
    Pavel

  • 0 in reply to Pavel Botev
    TI__Guru**** 170625 points
    For example of how to use the spi_claim_bus() function, refer to the below files:

    u-boot/drivers/mtd/spi/spi_flash.c
    u-boot/drivers/mtd/spi/spansion.c
    u-boot/drivers/mtd/spi/winbond.c

    spi_claim_bus() must be called before doing any transfers with a SPI slave. It will enable and initialize any SPI hardware as necessary, and make sure that the SCK line is in the correct idle state. It is not allowed to claim the same bus for several slaves without releasing the bus in between.

    SCK line is the McSPI clock pin, not the functional clock coming from the device PRCM, controlled from the CM_ALWON_SPI_CLKCTRL register.

    BR
    Pavel
  • 0 in reply to Pavel Botev
    Guru 20755 points

    Hi,

    Thanks,

    The mainline omap driver for spi does not support 16 bit,
    but fortunately someone provided a patch to support more other wordlen (our lcd need 16 bit wordlen)
    for anyone with similar issue this link may be helpful:

    github.com/.../omap3_spi.c

    Regards,
    Ran