spi: xilinx-ps: Set SPI master mode bits

Properly setup master->mode_bits to the supported modes of the device. The SPI
core will check if a master can support the mode requested by a SPI slave
device. If mode_bits is not initialized the core will error out on all modes but
SPI_MODE_0.

Also get rid of the mode superfluous checks in xspips_setup_transfer() and
xspips_setup(). The SPI core will take care of making sure that this master can
support the salve device.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
spi: xilinx-ps: Introduce a timeout to the transfer completion

If the interrupt never kicks in, e.g. due to a peripheral malfunctions, the
driver will get stuck forever in xspips_start_transfer() for the completion to
complete. This patch adds a timeout to the completion so the driver can fail
gracefully and return an error if the interrupt never kicks in.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
spi: xilinx-ps: Make sure the SPI peripheral clock is fast enough

UG585 section 17.2.6 ("SPI Clocks") has the following statement:
"The SPI reference clock (spi_ref_clk) must be set to a higher frequency than
the CPU_1x clock frequency."

This patch makes sure that this is indeed the case. It will query the CPU_1x
frequency and if it is higher than the spi_ref_clk frequency it will set the
spi_ref_clk frequency to the CPU_1x frequency.

Without this patch about 1 in 5 SPI transactions don't get started and just time
out (When running the SPI clock at 100 MHz and CPU_1x at 111 MHz, a lower SPI
clocks should increase the failure rate). It seems as if the MANSTRT signal is
not properly synchronized and lost at the clock domain border. With the patch
applied I can run a million consecutive SPI transfers without a single failure.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
xilinx_emacps: Fix deadlock

The xilinx_emacps uses it's lock in an unsafe manner which leads to an
occasional deadlock. The lock is acquired inside the interrupt handler and also
in non-interrupt context without disabling interrupts first. So if the lock is
held in non-interrupt and the interrupt handler kicks in the interrupt handler
will spin forever on the lock waiting for it to be released. This patch fixes it
by using irq_lock_irqsave instead irq_lock in code which potentially runs in a
non-interrupt context.

Part of the issue was introduced in commit commit 4e4f61ba ("xilinx_emacps: Fix
for Rx lockdown HW issue").

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>