SPI common code does not support use of CS signals discontinuously

[zee_z]

Hello i.MX7/8 community,

I found very confusing explanation about SPI slave usage of the i.MX7/8 SPI controllers.

In the kroot/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt

It says:

- fsl,spi-only-use-cs1-sel : spi common code does not support use of CS signals
discontinuously. i.MX8DXL-EVK board only uses CS1
without using CS0. Therefore, add this property to
re-config the chip select value in the LPSPI driver.

What does such a statement mean (bolded)?

Does it mean that SPI Slave mode supports SS per 8 bits received, so each 8 bits received must have distinct SS (falling edge begin of read, rising edge end of read)? As shown on the first two figures?

Or it does mean that there is a burst of octets, back to back, for example 23 octets, 184 bits, all the time SS active low? And if SPI Slave Mode does support bursts of octets, do we need to use SPI0 CS1 (- fsl,spi-only-use-cs1-sel as a DTSI property to be mandatory given)?

In other words, for the SPI Slave Mode, does CS0 support only octet by octet xfer, and does CS1 only support burst of octets?

Thank you for the answers!

Zee

_______

[zee_z]

Please, forget all of these garbage I wrote above. I was/am a complete idiot... Since I think exactly as designated NXP designers. I apologize to play as a complete idiot... As N@P designers.

I did deeper analysis of the vendor/variscite/kernel_imx/drivers/spi-fsl-lpspi.c, and found garbage in spi-fsl-lpspi.c code.

This code does NOT work for the SPI Slave mode at all. It is buggy, and it has disaster while setting the SPI Slave mode registers...

It does the following!

17.7.3.1.9
Configuration Register 1 (CFGR1)

Pins 25-24

Pin Configuration PINCFG
Configures which pins are used for input and output data during serial transfers.
00b - SDI is used for input data and SDO is used for output data
01b - SDI is used for both input and output data, only half-duplex serial transfers are supported
10b - SDO is used for both input and output data, only half-duplex serial transfers are supported
11b - SDO is used for input data and SDI is used for output data

Uses the swap, which drives two output pins against each other!

Wow!

Zee

_______

[Sanket_Parekh]

Hello @zee_z ,

I hope you are doing well.

I hope you have found the solution, if the issue is solved, can I close the thread?

Thanks & Regards,

Sanket Parekh

[zee_z]

I am doing well.

I hope (in vain) U, NXP, you do well. Aren't you? I doubt...

What about NXP, writing its own driver, to understand what NXP did as catastrophic mistakes???

What about NXP's analysis of this problem?

Are you, NXP, completely in the control of your own actions... Owning an i.MX8 silicon?

What about the politically correct spi slave documentation?

What are the patches, NXP should apply to fix this and other problems?

_______

Waiting for the answers!

Zee

_______

[Sanket_Parekh]

Hi @zee_z 

Please accept my apologies for the inconvenience.

Could you please share more details about the exact issue faced while using lpspi?

PINCFG[25:24] in the CFGR1 register is used to set the direction for SDO/SDI pins.

In slave mode,

SDO is used for input data and SDI is used for output data

There are some limitations when using spi-fsl-lpspi.c in slave mode.

Please refer to the below commit.

spi: lpspi: Add slave mode support

Thanks & Regards,

Sanket Parekh

[zee_z]

Yes, There is, for the complete truth, new development (from complete desperation).  From HERE!

https://github.com/ZoranStojsavljevic/spi_slave_spidev(dot)c

It is a Design Verification Testing (DVT). Works for us... But for others???

U and NXP still know and can do better, Sanket, don't you agree and also them?

Zee

_______

[Sanket_Parekh]

Hi @zee_z 

I hope you are doing well.

Please accept my apologies for the inconvenience caused.

I couldn't understand your query.

& I do not have access to the links shared by you.

Could you please elaborate more on this?

Thanks & Regards,

Sanket Parekh

[Sanket_Parekh]

Hi @zee_z 

Any updates from your side?

Thanks & Regards

Sanket Parekh

[zee_z]

Yes, There is, out from complete truth, new development (from complete desperation).  From HERE!

https://github.com/ZoranStojsavljevic/spi_slave_spidev.c

It is a Design Verification Testing (DVT). Works for us... But for others (do not think so)???

U and NXP still know and can do better, Sanket, don't you agree and also them, NXP crew?

Zee

_______