linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* IMX SPI - 17-24 bit bug and >32 bit support.
@ 2010-12-15 21:33 Bill Pringlemeir
  2010-12-15 21:55 ` Sascha Hauer
  0 siblings, 1 reply; 3+ messages in thread
From: Bill Pringlemeir @ 2010-12-15 21:33 UTC (permalink / raw)
  To: linux-arm-kernel


Attach is an example patch to the spi_imx.c file.  The iMX spi doesn't
handle 17-24bit values properly.  At least in sound/soc, the 24 bit
values are being passed with three data bytes per unit.  Also the SPI
count is being filled with '3' as a length.  Such data passed to the
current iMX spi driver will cause it to loop forever as it decrements
the unsigned length by '4' and eventually accesses invalid memory.

I believe that the reset of the kernel believes that the SPI layer
should use three bytes per transfer/receive item if the SPI word
length is 17 to 24 bits.

The other issue is that the current driver does not support SPI
transfers of greater than 32bits (called 'BURST LENGTH' in iMX
documentation).

Currently I have left the original code and just conditionalized it on
SPI_IMX_FLEXIBLE.  I have changed the 'tx', and 'rx' pointers to call
fixed routines.  I have only currently coded for 'little endian'.  I
am unsure whether any iMx processor can work with little endian.

I haven't limited the word size to 128*32 bits which is the maximum
burst for the iMx25 and investigated the maximums for the other
supported processors.  I suspect there is a better way to do the
wrapping of bytes.

I have tested this code with 8 and 24 bit transfer sizes on the
transmit side with the iMx25.

Thanks,
Bill Pringlemeir.

Signed-off-by: Bill Pringlemeir <bpringle@sympatico.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx_spi.patch
Type: text/x-diff
Size: 4413 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101215/49f6c84f/attachment.bin>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* IMX SPI - 17-24 bit bug and >32 bit support.
       [not found] <878vzq3em5.fsf@sympatico.ca>
@ 2010-12-15 21:39 ` Bill Pringlemeir
  0 siblings, 0 replies; 3+ messages in thread
From: Bill Pringlemeir @ 2010-12-15 21:39 UTC (permalink / raw)
  To: linux-arm-kernel

On 15 Dec 2010, bpringle at sympatico.ca wrote:

> I am unsure whether any iMx processor can work with little endian.

Arrgh... big endian.  I know it works with little.  More specifically
are the iMx SPI registers switchable to be big endian.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* IMX SPI - 17-24 bit bug and >32 bit support.
  2010-12-15 21:33 IMX SPI - 17-24 bit bug and >32 bit support Bill Pringlemeir
@ 2010-12-15 21:55 ` Sascha Hauer
  0 siblings, 0 replies; 3+ messages in thread
From: Sascha Hauer @ 2010-12-15 21:55 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Dec 15, 2010 at 04:33:54PM -0500, Bill Pringlemeir wrote:
> 
> Attach is an example patch to the spi_imx.c file.  The iMX spi doesn't
> handle 17-24bit values properly.  At least in sound/soc, the 24 bit
> values are being passed with three data bytes per unit.  Also the SPI
> count is being filled with '3' as a length.  Such data passed to the
> current iMX spi driver will cause it to loop forever as it decrements
> the unsigned length by '4' and eventually accesses invalid memory.
> 
> I believe that the reset of the kernel believes that the SPI layer
> should use three bytes per transfer/receive item if the SPI word
> length is 17 to 24 bits.

I remember soneone mentioned this already. Patches for this are welcome.

> 
> The other issue is that the current driver does not support SPI
> transfers of greater than 32bits (called 'BURST LENGTH' in iMX
> documentation).

The support for transfers > 32 bit is arguably broken at least on the
older cspi cores. That's why the we have the following comment next to
the spi platform data:

/*
 * struct spi_imx_master - device.platform_data for SPI controller devices.
 * @chipselect: Array of chipselects for this master. Numbers >= 0 mean gpio
 *              pins, numbers < 0 mean internal CSPI chipselects according
 *              to MXC_SPI_CS(). Normally you want to use gpio based chip
 *              selects as the CSPI module tries to be intelligent about
 *              when to assert the chipselect: The CSPI module deasserts the
 *              chipselect once it runs out of input data. The other problem
 *              is that it is not possible to mix between high active and low
 *              active chipselects on one single bus using the internal
 *              chipselects. Unfortunately Freescale decided to put some
 *              chipselects on dedicated pins which are not usable as gpios,
 *              so we have to support the internal chipselects.
 * @num_chipselect: ARRAY_SIZE(chipselect)
 */

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-12-15 21:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-15 21:33 IMX SPI - 17-24 bit bug and >32 bit support Bill Pringlemeir
2010-12-15 21:55 ` Sascha Hauer
     [not found] <878vzq3em5.fsf@sympatico.ca>
2010-12-15 21:39 ` Bill Pringlemeir

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).