cs_change for SPI transfers

cs_change for SPI transfers

[Manuel Stahl]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

Hi,

I think there's an error in most IIO devices that use SPI transfers.

Haavard Skinnemoen wrote:
> The normal behaviour is:
>   * After all transfers except the last: CS stays active
>   * After the last transfer: CS goes inactive
>
> The cs_change flag is used to invert this behaviour. So for the last
> transfer, cs_change indicates that CS should stay active after the
> transfer (though the driver may not actually be able to do so, e.g. if
> the message is followed by a message to a different device.)
>

The drivers in IIO set cs_change for all transfers (including the last 
in a message), which is not what we want. I can prepare a patch to 
correct this.

Regards,
-- 
Manuel Stahl
Fraunhofer-Institut IIS
Leistungsoptimierte Systeme

Nordostpark 93
D90411 Nürnberg
Telefon  +49 (0)911/58061-6419
Fax      +49 (0)911/58061-6398
E-Mail   manuel.stahl@iis.fraunhofer.de

http://www.iis.fraunhofer.de
http://www.smart-power.fraunhofer.de

[-- Attachment #2: manuel_stahl.vcf --]
[-- Type: text/x-vcard, Size: 170 bytes --]

begin:vcard
fn:Manuel Stahl
n:Stahl;Manuel
email;internet:manuel.stahl@iis.fraunhofer.de
tel;work:+49 911 58061-6419
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: cs_change for SPI transfers

[Jonathan Cameron]

On 01/10/11 14:22, Manuel Stahl wrote:
> Hi,
> 
> I think there's an error in most IIO devices that use SPI transfers.
> 
> Haavard Skinnemoen wrote:
>> The normal behaviour is:
>>   * After all transfers except the last: CS stays active
>>   * After the last transfer: CS goes inactive
>>
>> The cs_change flag is used to invert this behaviour. So for the last
>> transfer, cs_change indicates that CS should stay active after the
>> transfer (though the driver may not actually be able to do so, e.g. if
>> the message is followed by a message to a different device.)
>>
> 
> The drivers in IIO set cs_change for all transfers (including the
> last in a message), which is not what we want. I can prepare a patch
> to correct this.

Yikes.

They win for completely counter intuitive interface... I guess I can see why
they did it like that (to make 0 the default behaviour).
Clearer naming would have been nice. cs_change_non_default or something...

Please do submit a patch set for this.

Jonathan