XSpiPs Reset value causes first transfer to be handled differently than subsequent transfers

https://github.com/Xilinx/embeddedsw/blob/be4f96f3f73b0e47036eeb77949c1cc638b7648c/XilinxProcessorIPLib/drivers/spips/src/xspips_hw.h#L97

After many hours of diagnosing the problem, we found that the XSpi driver for SPI interfaces sets the reset state of the driver to NOT have any Chip Select active.

The XSpiPs driver, however, has a reset value that sets Chip Select to 0 upon cfgInitialize. This causes the first transaction on the SPI line's to have zero delay between the clock becoming active and the chip select being asserted.

After a transaction is completed, the reset state becomes "no chip selected" and subsequent transfers have an appropriate delay between the clock and chip select lines.

This is primarily seen in manual chip select mode.

In auto chip select mode, the driver also has issues between transfers where the chip select line is de-asserted for a fraction of the clock cycle, and can cause problems with SPI devices that communicate with 16-bit transfers as they perceive the chip select bump as a deassertion.

Start with XilinxProcessorIPLib/drivers/spips/src/xspips_hw.h at line 97 and compare the XSpi and XSpiPs reset behavior described in the report. Reproduce transfers in manual and auto chip-select modes, then verify that the reset and transfer behavior no longer causes a different first transfer or a chip-select bump between transfers.