I do not think this is a bug.
There are many spi devices that need frames that are longer then 8bit.
I understand that, and that would be the frame size setting that can be set, where mine is set to default or 8bit, but looking at various specs that I googled, each frame seem to need the cs asserted to give a frame boundary.
If this is not the case, then fine, I would like to modify the Kernel to achieve this result without having the large cs gaps, but haven't yet found the relevent kernel code to achieve this.
I think the file you are looking for is : /drivers/spi/intel_mid_ssp_spi.c (available in yocto as a patch to kernel 3.10). But without chip documentation (at least to know if hardware support the behaviour you want) it will be difficult to modify it.
But as said Erik_van_der_Zalm it's not a bug. It's how SPI driver is operating. The large cs gap you see is result of context switch between calls, in order to reduce this gap you need to write a SPI driver for your device and not use spidev as i'm not sure it uses DMA. But with a 8bits register on your slave device you do not have any choice but use 8 bits transfers, if you use 32bits transfer it's normal for the CS line to stay low.
I am not sure how much it will help, but I am also trying to understand what the SPI driver is doing. I have been browsing through the code and talking a little about it in the thread: Sources for /dev/spidev5.1 and what it calls