You should search for "eCSPI" in the Search Box. There are a lot of previous issues there. Some may relate to your problem. One is having a problem with chip-selects, partly because the driver supports them as very slow GPIOs which the software turns on and off, rather than having the better solution where the hardware CS lines are used instead.
i.MX53 is only supported by Freescale with 2.6.35. The SPI drivers were quite buggy.
2.6.38 was released for some reason, but isn't the "official" release for i.MX53.
The Freescale SPI drivers in 2.6.35 were replaced with "mainline" drivers in 2.6.38.
I would assume (but don't know) that the "mainline" drivers were used in 3.x and 4.x Linux.
The Link in my post (above) links to the post detailing one of the problems I had with SPI. Those problems weren't in the SPI driver itself, but in the "platform setup" code that controlled the master clock power modes. As detailed in my post, in 2.6.35 this was set in "arch/arm/mach-mx5/system.c". I have no idea how this is set up in 4.4 and on the i.MX6 (this stuff tends to move around), but suggest you check the i.MX53 and i.MX6 Reference Manuals, find the equivalent control registers and search for any code in 4.4 doing the same thing.
This is unlikely to be related to your problem.
> there us a drift in CS line
What do you mean by that? "Drifting" in level up and down or time early and late? You can expect a lot of variation in time as they're being driven as GPIOs in software. In this post there's a clock glitch, and sometimes I think it said the chip-select was too late and happened after the eCSPI had started clocking:
https://community.nxp.com/thread/386935#comment-625531
The "7 or 8 pulses" is just plain weird. something seriously wrong there.
Tom
