[PATCH 2/2] spi: imx: fix use of native chip-selects with devicetree

[Greg Ungerer]

Hi Geert, Uwe,

On 22/03/17 06:15, Geert Uytterhoeven wrote:
> On Tue, Mar 21, 2017 at 8:23 PM, Uwe Kleine-König
> <u.kleine-koenig at pengutronix.de> wrote:
>> On Tue, Mar 21, 2017 at 11:22:27PM +1000, Greg Ungerer wrote:
>>> On 21/03/17 22:11, Uwe Kleine-König wrote:
>>>> On Tue, Mar 21, 2017 at 09:53:52PM +1000, Greg Ungerer wrote:
>>>>> On 21/03/17 18:05, Uwe Kleine-König wrote:
>>>>>> On Tue, Mar 21, 2017 at 12:05:20PM +1000, Greg Ungerer wrote:
>>>>>>> On 20/03/17 23:22, Vladimir Zapolskiy wrote:
>>>>>>>> For that type of bindings locally I have a hackish spi-imx driver change,
>>>>>>>> which supports this option, but I'm unsure if it is universal enough.
>>>>>>>
>>>>>>> Do you mean supporting no cs-gpios tag?
>>>>>>> That would be nice, but it would seem not many users of this are
>>>>>>> using native chip selects.
>>>>>>
>>>>>> The reason for this is that the native chip selects are less flexible
>>>>>> than gpios because you cannot control when they deassert. IIRC they do
>>>>>> it too much for some chips. So the only reason to stick to them is that
>>>>>> on some SoCs not all pins have a GPIO function. Not sure if transfer
>>>>>> speed is another reason, but I would expect that the gain isn't that
>>>>>> big.
>>>>>
>>>>> For the particular SPI device I am using, a Silicon Labs 32260,
>>>>> it actually wants the assertion and de-assertion of the chip-select
>>>>> between each byte. So it is the only way it can work for me.
>>>>
>>>> That should be doable with gpio-cs, too. You just need the right flags
>>>> in your spi transfer IIRC.
>>>
>>> Do you know which flag(s)  do that?
>>
>> Looking at the source it's not about flags, but you have to split your
>> transfer into several messages.
> 
> ... and set spi_transfer.cs_change.

Yep, that looks like the one. Though it would appear not all
spi drivers support it. The spi-imx driver for one doesn't look
at it at all.


>> AFAICT that's how the spi stuff is
>> supposed to work. That is, at the start of a message CS is asserted and
>> (only) at it's end CS is deasserted. So the imx core with native chip
>> select actually misbehaves by toggling CS between each word.
> 
> Indeed.

If you look around the kernel source for cs_change there is
a number of devices that use it. A bunch od ADC/DACs in
particular (including in backlight support). 

So I don't know that I would characterize the iMX one as
misbehaving so much as only natively supporting the model
where chip select is asserted/deasserted per burst. It is
strait forward to implement the GPIO method instead of the
native chip select with the iMX pin multiplexing.

Regards
Greg