Re: [Ltib] Having trouble to run 'spidev_test' on Phytec 3250 board.
From:
Jorge A. Castro
Subject:
Re: [Ltib] Having trouble to run 'spidev_test' on Phytec 3250 board.
Date:
Thu, 19 Aug 2010 16:58:37 -0600
User-agent:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6
Hi Quentin
Thanks for the information. I'm now trying to test some drivers in my
board (like I2C, SPI and CAN), and this application may help me to find
out if SPI is properly working.
Thanks again.
Regards
Jorge Castro
On 08/19/2010 04:52 PM, Quentin YANG wrote:
Hi Jorge,
You can find the 'spidev_test.c' under '
X:\lpc3250\ltib-qs\rpm\BUILD\linux-2.6.34\Documentation\spi\'
Just copy and compile it in user space. (i.e.,
X:\lpc3250\ltib-qs\rootfs\home\user\ )
I attached my 'spidev_test' project.
(It's an Eclipse Makefile project.)
Regards,
Quentin
On Fri, Aug 20, 2010 at 1:33 AM, Jorge A.
Castro <address@hidden>
wrote:
Hi Quentin,
I'm using a LPC3250 from Future Design Inc, which is pretty similar
than Phytec 3250. I'm wondering if I can find that spidev_test in order
to test this drive in my board. Do you know where to find it? I was
looking in the LTIB configuration but I didn't found it.
Thanks,
Jorge
On 08/18/2010 07:30 PM, Quentin YANG wrote:
Hi Kevin,
I can successfully run 'spidev_test' from user space as shown below.
According to source code: driver/spi/spi.c
............................
bad_bits = spi->mode & ~spi->master->mode_bits;
if (bad_bits) {
dev_dbg(&spi->dev, "setup: unsupported mode bits %x\n",
bad_bits);
return -EINVAL;
}
..............................
It seems has something to do with '~spi->master->mode_bits'.
Any comments on this error?
What could be the reason?
Question Two:
Have you ever tried to run 'spidev_test' on dev:ssp1 on Phytec board?
I could not see any 'SPI CLK signal' on PCM-988/GPIO Expansion Board
Patch Field 43E although I was able to run 'spidev_test'.
I am wondering whether it's hardware related or just firmware's problem?
If you can run 'spidev_test' on your phytec board on dev:ssp1, then I
can rule out the possibility of hardware fault.
I am waiting for the arrival of our Hardware debugger TRACE32, which is
the last resort.