DSPI2 on Vybrid Linux 3.0.15 Kernel

cancel
Showing results for 
Search instead for 
Did you mean: 

DSPI2 on Vybrid Linux 3.0.15 Kernel

Jump to solution
492 Views
Contributor III

Hello.

We are using Yocto and Timesys BSP to build our custom Linux BSP. (Kernel 3.0.15)

Our board is based on the Vybrid VF65GS10.

We want to use DSPI2 on the vybrid, but are unsuccessful in doing so.

The kernel boots properly, we have added iomuxing according to the reference manual, initialized dspi2 and spidev driver.

We  have enabled the clock for dspi2.

When we test the SPI Bus from userspace (e.g. echo "hello world" >> /dev/spidev2.0) we can see the chipselect toggling, but goes high again immediately after 1 microsecond. The clock goes from high to low, but never changes afterwards.

Data lines show nothing.

Any hints or tips would be gladly appreciated.

For reference, some of our modifications are already discussed in posts;

DSPI drive usage in Linux Side

Re: SPI Driver on Linux Side

Our BSP alterations:

arch/arm/mach-mvf/clock.c

static struct clk dspi_clk[] = {

         {

         __INIT_CLK_DEBUG(dspi0_clk)

         .id = 0,

         .parent = &ipg_clk,

         .enable_reg = MXC_CCM_CCGR0,

         .enable_shift = MXC_CCM_CCGRx_CG12_OFFSET,

         .enable = _clk_enable,

         .disable = _clk_disable,

         },

         {

         __INIT_CLK_DEBUG(dspi1_clk)

         .id = 1,

         .parent = &ipg_clk,

         .enable_reg = MXC_CCM_CCGR0,

         .enable_shift = MXC_CCM_CCGRx_CG13_OFFSET,

         .enable = _clk_enable,

         .disable = _clk_disable,

         },

         {

         __INIT_CLK_DEBUG(dspi2_clk)

         .id = 2,

         .parent = &ipg_clk,

         .enable_reg = MXC_CCM_CCGR6,

         .enable_shift = MXC_CCM_CCGRx_CG12_OFFSET,

         .enable = _clk_enable,

         .disable = _clk_disable,

         },

};

..

//      _REGISTER_CLOCK("mvf-dspi.0", NULL, dspi_clk[0]),

        _REGISTER_CLOCK("mvf-dspi.2", NULL, dspi_clk[2]),

arch/arm/plat-mxc/include/mach/iomux-mvf.h

//   #define MVF600_DSPI_PAD_CTRL    (PAD_CTL_SPEED_LOW | PAD_CTL_DSE_25ohm)

     #define MVF600_DSPI_PAD_CTRL    (PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_20ohm | PAD_CTL_ODE | PAD_CTL_PUS_100K_UP | PAD_CTL_PKE

          | PAD_CTL_PUE)

/*DSPI0*/

#define MVF600_PAD41_PTB19__DSPI0_PCS0                          \

                 IOMUX_PAD(0x00A4, 0x00A4, 1, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_OBE_ENABLE)

#define MVF600_PAD42_PTB20__DSPI0_SIN                           \

                 IOMUX_PAD(0x00A8, 0x00A8, 1, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_IBE_ENABLE)

#define MVF600_PAD43_PTB21__DSPI0_SOUT                          \

                 IOMUX_PAD(0x00AC, 0x00AC, 1, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_OBE_ENABLE)

#define MVF600_PAD44_PTB22__DSPI0_SCK                           \

                 IOMUX_PAD(0x00B0, 0x00B0, 1, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_OBE_ENABLE)

/*DSPI2*/

#define MVF600_PAD64_PTD30__DSPI2_PCS0                           \

                 IOMUX_PAD(0x0100, 0x0100, 5, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_OBE_IBE_ENABLE)

#define MVF600_PAD65_PTD29__DSPI2_SIN                            \

                 IOMUX_PAD(0x0104, 0x0104, 5, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_OBE_IBE_ENABLE)

#define MVF600_PAD66_PTD28__DSPI2_SOUT                           \

                 IOMUX_PAD(0x0108, 0x0108, 5, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_OBE_IBE_ENABLE)

#define MVF600_PAD67_PTD27__DSPI2_SCK                            \

                 IOMUX_PAD(0x010C, 0x010C, 5, 0x0000, 0, \

                                 MVF600_DSPI_PAD_CTRL | PAD_CTL_OBE_IBE_ENABLE)

arch/arm/mach-mvf/board-twr-vf700.c

   /*DSPI0*/

     /*

        MVF600_PAD41_PTB19__DSPI0_PCS0,

        MVF600_PAD42_PTB20__DSPI0_SIN,

        MVF600_PAD43_PTB21__DSPI0_SOUT,

        MVF600_PAD44_PTB22__DSPI0_SCK,

    */

      

    /*DSPI2*/

        MVF600_PAD64_PTD30__DSPI2_PCS0,

        MVF600_PAD65_PTD29__DSPI2_SIN,

        MVF600_PAD66_PTD28__DSPI2_SOUT,

        MVF600_PAD67_PTD27__DSPI2_SCK

..

static struct spi_mvf_chip generic_chip_info = {

        .mode = SPI_MODE_2,

        .bits_per_word = 16,

        .void_write_data = 0,

        .dbr = 0,

        .pbr = 0,

        .br = 0,

        .pcssck = 0,

        .pasc = 0,

        .pdt = 0,

        .cssck = 0,

        .asc = 0,

        .dt = 0,

  

};

static struct spi_board_info mvf_spi_board_info[] __initdata = {

        {  

                // The modalias must be the same as spi device driver name

                //.modalias = "m25p80",

                .modalias = "spidev",

                .max_speed_hz = 1000000,

                .bus_num = 2,

                .chip_select = 0,

        //.platform_data = &at26df081a_platform_data,

                .controller_data = &generic_chip_info

        },

};

..

// dspi

        mvf_add_dspi(2, &mvf_vf600_spi_data);

        spi_device_init();

Labels (3)
1 Solution
27 Views
Senior Contributor II

Hi Andreas,

I reviewed the changes you made, but nothing immediately stood out to me that would be a problem. Can you confirm that there are no conflicts with the new register pad settings you defined? By that, I mean ensure that there are no other pads defined in your board definition file that use PTD27-30. Same goes for the new clock you added.

We typically handle issues like these, bringing device drivers up on custom hardware, under professional services. If this is something you would be interested in, you may contact sales@timesys.com for more information.

Thanks,

Timesys Support

View solution in original post

5 Replies
28 Views
Senior Contributor II

Hi Andreas,

I reviewed the changes you made, but nothing immediately stood out to me that would be a problem. Can you confirm that there are no conflicts with the new register pad settings you defined? By that, I mean ensure that there are no other pads defined in your board definition file that use PTD27-30. Same goes for the new clock you added.

We typically handle issues like these, bringing device drivers up on custom hardware, under professional services. If this is something you would be interested in, you may contact sales@timesys.com for more information.

Thanks,

Timesys Support

View solution in original post

27 Views
Contributor III

Thank you for your support.

We have been over this multiple times, and finally managed to solve the issue.

As you point out, the iomuxing and pin definitions are indeed correct.

We may have been fooled by the fact that we have been testing the SPI-dev different ways (with different results).

We have tested again with the original iomuxing. For our HW, the original settings work just as fine.

E.g.

#define MVF600_DSPI_PAD_CTRL    (PAD_CTL_SPEED_LOW | PAD_CTL_DSE_25ohm)

Thanks.

0 Kudos
27 Views
Senior Contributor II

Hello,

We will review and follow up with our findings.

Thank you,

Timesys Support

27 Views
NXP Apps Support
NXP Apps Support

timesyssupport​ do you have an update?

0 Kudos
27 Views
NXP Apps Support
NXP Apps Support

timesyssupport​ can you help to review this case?

0 Kudos