xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ARM: imx: Update spi_imx platform data to reflect current state

Browse Source 
The docs for the spi_imx platform data still refer to a -32 offset used to
specify a native chip select.  This was removed in commit 602c8f4485
("spi: imx: fix use of native chip-selects with devicetree") and no
longer works as documented.  Update documentation.

The macro MXC_SPI_CS() is no longer is needed.

If a board uses all native chip selects, then it's not necessary to
specify a chip select array at all, as all native is the default (this is
how device-tree configured SPI masters work too).  Most of the spi-imx
platform data users have their chip select arrays removed by this patch.

This patch also fixes a bug in mx31moboard introduced in the '602 commit.
When that board was updated in commit 901f26bce6 ("ARM: imx: set
correct chip_select in platform setup") to reflect the SPI change, only
SPI bus 2 was updated and SPI bus 1 was left with non-sequential chip
selects.  The mc13783 spi device on bus 1 had its chip select updated as
if it were on bus 2.

CC: Sascha Hauer <kernel@pengutronix.de>
CC: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
This commit is contained in:
Trent Piepho
2018-04-02 13:06:05 -07:00
committed by Shawn Guo
parent 60cc43fc88
commit fe1bd78bf1
6 changed files with 27 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
include/linux/platform_data/spi-imx.h
View File

@@ -5,24 +5,29 @@
/*
* 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
* @chipselect: Array of chipselects for this master or NULL. Numbers >= 0
* mean GPIO pins, -ENOENT means internal CSPI chipselect
* matching the position in the array. E.g., if chipselect[1] =
* -ENOENT then a SPI slave using chip select 1 will use the
* native SS1 line of the CSPI. Omitting the array will use
* all native chip selects.
* 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, on some SoCs, 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)
*
* @num_chipselect: If @chipselect is specified, ARRAY_SIZE(chipselect),
* otherwise the number of native chip selects.
*/
struct spi_imx_master {
int *chipselect;
int num_chipselect;
};
#define MXC_SPI_CS(no) ((no) - 32)
#endif /* __MACH_SPI_H_*/