summaryrefslogtreecommitdiffstats
path: root/drivers/spi/spi_s3c64xx.c
Commit message (Collapse)AuthorAgeFilesLines
* spi/s3c64xx: Bug fix for SPI with different FIFO levelPadmavathi Venna2011-07-061-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The existing macro fails for following scenarios. 1) S5P64X0 channel 1 2) S5PV210 channel 1 The FIFO data level supported in the above SoCs either 64 or 256 bytes depending on the channel. Because of this the TX_DONE is the 25 bit in the status register. The existing macro works for the following scenarios 1) S3C6410 all channels 2) S5PC100 all channels The FIFO data level supported in the above SoCs 64 bytes on all the channels. Because of this the TX_DONE is the 21 bit in the status register. So when we use the existing macro for the non-working SoCs it is not anding with the TX_DONE bit for transmission status check. Signed-off-by: Padmavathi Venna <padma.v@samsung.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
* spi/s3c64xx: Correction for 16,32 bits bus widthJassi Brar2010-09-291-15/+41
| | | | | | | | | We can't do without setting channel and bus width to same size. In order to do that, use loop read/writes in polling mode and appropriate burst size in DMA mode. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Consider the clk_from_cmu flagJassi Brar2010-09-291-38/+56
| | | | | | | | | Newer SoCs have the SPI clock scaling control in platform's clock management unit. Inorder for such SoCs to work, we need to check the flag clk_from_cmu before making any clock changes. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Prevent unnecessary map-unmapJassi Brar2010-09-291-0/+8
| | | | | | | | Since we use DMA mode only for xfers bigger than FIFO size, do not map/unmap buffers for polling mode transfers. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/spi_s3c64xx: Warn if PIO transfers time outMark Brown2010-09-081-0/+6
| | | | | | | | | | When using PIO we have a timeout for the TX and RX FIFOs to ensure that the data actually gets transferred. Warn if we hit that timeout - it should never happen, but this makes sure we'll find out if it does. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Fix incorrect reuse of 'val' local variable.Jassi Brar2010-09-081-2/+3
| | | | | | | | Instead of, wrongly, reusing the 'val' variable, use a dedicated one for reading the status register. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Fix compilation warningJassi Brar2010-09-081-2/+3
| | | | | | | | | | | Fix compilation warning by typecasting the tx_buf pointer. [I'm not thrilled with resorting to a cast; but I cannot see a better way to go about this. I don't want to drop the const from struct spi_transfer ~~glikely] Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/spi_s3c64xx: Increase dead reckoning time in wait_for_xfer()Mark Brown2010-09-081-1/+1
| | | | | | | | | | | | For small transfers at high speeds the expected transfer time can easily be well under 1ms, causing the delay in wait_for_xfer() to be only the dead reckoning fudge factor of 5ms currently included. Experiments on some of my systems shows that this is marginal for some transfers so double it to 10ms. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/spi_s3c64xx: Move to subsys_initcall()Mark Brown2010-09-081-1/+1
| | | | | | | | | Allow the use of the S3C64xx SPI controller with things like PMICs by moving the init up to subsys_initcall(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/spi_s3c64xx: Staticise non-exported functionsMark Brown2010-09-011-4/+4
| | | | | | Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/spi_s3c64xx: Make probe more robust against missing board configMark Brown2010-09-011-2/+7
| | | | | | | | | | | | The S3C64xx SPI driver requires the machine to call s3c64xx_spi_set_info() to select a few options, including the clock to use for the SPI controller. If this is not done then a NULL will be passed as the clock name for clk_get(), causing an obscure crash. Guard against this and other missing configuration by validating that the clock name has been filled in in the platform data that ets passed in. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/spi_s3c64xx.c: Fix continuation line formatsJoe Perches2010-02-021-6/+5
| | | | | | | | String constants that are continued on subsequent lines with \ are not good. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Add new parameter to cs callbackJassi Brar2010-01-201-3/+4
| | | | | | | | | Since most of the chip-selects are simply going to be like gpio_set_value, it would do good to have the same callback type so that it could simply be made to point at gpio_set_value. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Include moved headerJassi Brar2010-01-201-1/+1
| | | | | | | | Header for platform specific stuff has been rename to include the SoC type. Include the new header instead. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Check before mem-region releaseJassi Brar2010-01-201-1/+2
| | | | | | | Add precautionary check before releasing memory region. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Move src_clk to local driver dataJassi Brar2010-01-201-19/+17
| | | | | | | | | | The pointer to SPI rate source clock had better be the member of driver local data structure rather than platform specific. Also, remove definitions of variable 'sci' that are rendered useless as a consequence. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Differentiate ip and rate clockJassi Brar2010-01-201-20/+8
| | | | | | | | The instance of SPI clock for controller and that used for generating signals ought to be independently handled. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi/s3c64xx: Rename s3c64xx_spi_cntrlr_infoJassi Brar2010-01-201-12/+12
| | | | | | | | Rename 'struct s3c64xx_spi_cntrlr_info' to lesser wordy 'struct s3c64xx_spi_info' Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* spi: Add s3c64xx SPI Controller driverJassi Brar2009-12-171-0/+1196
Each SPI controller has exactly one CS line and as such doesn't provide for multi-cs. We implement a workaround to support multi-cs by _not_ configuring the mux'ed CS pin for each SPI controller. The CS mechanism is assumed to be fully machine specific - the driver doesn't even assume some GPIO pin is used to control the CS. The driver selects between DMA and POLLING mode depending upon the xfer size - DMA mode for xfers bigger than FIFO size, POLLING mode otherwise. The driver has been designed to be capable of running SoCs since s3c64xx and till date, for that reason some of the register fields have been passed via, SoC specific, platform data. Signed-off-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
OpenPOWER on IntegriCloud