diff options
author | Greg Ungerer <gerg@linux-m68k.org> | 2017-03-17 15:03:02 +1000 |
---|---|---|
committer | Shawn Guo <shawnguo@kernel.org> | 2017-03-20 15:38:56 +0800 |
commit | 901f26bce64a96bd9d038fda3604bd0ab1098c3b (patch) | |
tree | bbf2c8c94ade99cfd150bf2bef5d028ffc7ac27d /arch/tile | |
parent | 55edcbb2db3a41c1520425b84c620286f4e5e394 (diff) | |
download | blackbird-op-linux-901f26bce64a96bd9d038fda3604bd0ab1098c3b.tar.gz blackbird-op-linux-901f26bce64a96bd9d038fda3604bd0ab1098c3b.zip |
ARM: imx: set correct chip_select in platform setup
Some platform based configuration setup of spi-imx SPI devices does
not set the "chip_select" to the actual hardware chip select used.
This works because the cs_gpio mapping that is associated with this
platform setup maps the chip_select offset used to the appropriate
hardware chip select. The spi-imx driver uses the chip_select as an
index into the cs_gpio array and ultimately gets the correct hardware
chip select for its hardware setup.
The motivation is to be able to eventually modify the spi-imx code to
use the "chip_select" directly for harwdare setup instead of indirectly
via the cs_gpio mapping array.
This change only affects platforms using the hardware chip select
addressing method for their SPI devices (sometimes called native chip
select). The majority of devices using the spi-imx driver use the GPIO
addressing method.
The change to use the correct "chip_select" is strait forward. But the
cs_gpio mapping arrary also needs to be modifed to match that change. In
simple terms the cs_gpio mapping should always have the hardware chip
select number at its same index offset.
There is no functional change with these patches. The three affected
platforms should work exactly as before. However I don't have any of
these platforms (or access to them) and so I can't test them. So this
patch is compile tested only.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Diffstat (limited to 'arch/tile')
0 files changed, 0 insertions, 0 deletions