How to handle SPI components requiring heading/leading clock cycles with CS off

How to handle SPI components requiring heading/leading clock cycles with CS off

[Christophe Leroy]

Some components requires some clock cycles with chipselect off before 
or/and after the data transfer done with CS on.

Typically IDT801034 QUAD PCM CODEC datasheet states "Note *: CCLK should 
have one cycle before CS goes low, and two cycles after CS goes high".

The only way I see to achieve that is to transfer a 4 bits word with CS 
off before and after the data.
I've not found any way to do so in the current SPI subsystem 
implementation, is there any ?
If not, what would be the best approach to implement that ?

Cheers,
Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to handle SPI components requiring heading/leading clock cycles with CS off

[Mark Brown]

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

On Tue, Aug 23, 2016 at 06:10:48PM +0200, Christophe Leroy wrote:

> The only way I see to achieve that is to transfer a 4 bits word with CS off
> before and after the data.
> I've not found any way to do so in the current SPI subsystem implementation,
> is there any ?
> If not, what would be the best approach to implement that ?

If you leave the device with cs_change set so the chip select is low it
should do the right thing after the first message, though obviously you
won't be able to share the chip select then.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: How to handle SPI components requiring heading/leading clock cycles with CS off

[Christophe Leroy]

Le 24/08/2016 à 11:44, Mark Brown a écrit :
> On Tue, Aug 23, 2016 at 06:10:48PM +0200, Christophe Leroy wrote:
>
>> The only way I see to achieve that is to transfer a 4 bits word with CS off
>> before and after the data.
>> I've not found any way to do so in the current SPI subsystem implementation,
>> is there any ?
>> If not, what would be the best approach to implement that ?
>
> If you leave the device with cs_change set so the chip select is low it
> should do the right thing after the first message, though obviously you
> won't be able to share the chip select then.
>


What is needed is to get some SPI clock cycles with CS off i.e. CS high.
With cs_change, CS will remain low i.e. CS active
      _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _
CLK   |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
__   ___                                 ___________
CS      |_______________________________|           |_______________

This means we need to transmit some data with CS high, otherwise the SPI 
chip doesn't deliver clock.


Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to handle SPI components requiring heading/leading clock cycles with CS off

[Mark Brown]

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

On Wed, Aug 24, 2016 at 12:49:55PM +0200, Christophe Leroy wrote:
> Le 24/08/2016 à 11:44, Mark Brown a écrit :

> > If you leave the device with cs_change set so the chip select is low it
> > should do the right thing after the first message, though obviously you
> > won't be able to share the chip select then.

> What is needed is to get some SPI clock cycles with CS off i.e. CS high.
> With cs_change, CS will remain low i.e. CS active

No, it'll change chip select so if it's already set it'll deassert and
if you leave it deasserted at the end of a transaction it should leave
it deasserted.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: How to handle SPI components requiring heading/leading clock cycles with CS off

[Christophe Leroy]

Le 24/08/2016 à 12:56, Mark Brown a écrit :
> On Wed, Aug 24, 2016 at 12:49:55PM +0200, Christophe Leroy wrote:
>> Le 24/08/2016 à 11:44, Mark Brown a écrit :
>
>>> If you leave the device with cs_change set so the chip select is low it
>>> should do the right thing after the first message, though obviously you
>>> won't be able to share the chip select then.
>
>> What is needed is to get some SPI clock cycles with CS off i.e. CS high.
>> With cs_change, CS will remain low i.e. CS active
>
> No, it'll change chip select so if it's already set it'll deassert and
> if you leave it deasserted at the end of a transaction it should leave
> it deasserted.
>

In function  spi_transfer_one_message(), my understanding is that:

CS is asserted inconditionnaly at begining of the function, regardless 
of its previous status.
Then for all transfers but the last, when cs_change is set CS is 
deasserted for 10us then re-asserted.
If cs_change is set for the last tranfer, the function leaves CS asserted.

So I don't see how I can transfer some data with CS de-asserted.

Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to handle SPI components requiring heading/leading clock cycles with CS off

[Mark Brown]

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

On Wed, Aug 24, 2016 at 01:03:57PM +0200, Christophe Leroy wrote:

> CS is asserted inconditionnaly at begining of the function, regardless of
> its previous status.
> Then for all transfers but the last, when cs_change is set CS is deasserted
> for 10us then re-asserted.
> If cs_change is set for the last tranfer, the function leaves CS asserted.

> So I don't see how I can transfer some data with CS de-asserted.

Oh, yes we reset at the start of the function.  You'd need to change the
core to support this, and even then your compatibility with controllers
is going to be very limited.

What is this device, is there some reason for this?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: How to handle SPI components requiring heading/leading clock cycles with CS off

[Christophe Leroy]

Le 24/08/2016 à 13:12, Mark Brown a écrit :
> On Wed, Aug 24, 2016 at 01:03:57PM +0200, Christophe Leroy wrote:
>
>> CS is asserted inconditionnaly at begining of the function, regardless of
>> its previous status.
>> Then for all transfers but the last, when cs_change is set CS is deasserted
>> for 10us then re-asserted.
>> If cs_change is set for the last tranfer, the function leaves CS asserted.
>
>> So I don't see how I can transfer some data with CS de-asserted.
>
> Oh, yes we reset at the start of the function.  You'd need to change the
> core to support this, and even then your compatibility with controllers
> is going to be very limited.
>
> What is this device, is there some reason for this?
>

No I can't see any special reason for this. But I can confirm that 
without the two additional clock cycles with CS\ high, the commands are 
not taken into account.

This device (IDT 821034) is a quad PCM codec for audio that I want to 
implement within ALSA.

Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to handle SPI components requiring heading/leading clock cycles with CS off

[Mark Brown]

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

On Wed, Aug 24, 2016 at 01:19:50PM +0200, Christophe Leroy wrote:

> No I can't see any special reason for this. But I can confirm that without
> the two additional clock cycles with CS\ high, the commands are not taken
> into account.

Right, I just looked at the datasheet and it says in the serial control
interface section that it needs a three clock cycle idle state.  Clearly
the designers weren't having a very good day when they did the digital
here but based on that you probably only need to send an extra byte with
chip select deasserted at the end of the transfer to satisfy it rather
than padding at both start and end.  Like I say it'll need a new core
feature though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]