The updates on Commits · 01org/edison-linux · GitHub are trying to repair some of the bugs and known issues that we have encountered in Edison's image. Nevertheless these changes are not yet implemented in the public image of Edison, in fact the changes in that git might or might not be all included in future releases of the Yocto image for Edison. I suggest you to wait for a future releases for Edison, they might repair some of the issues you mention, however there's no ETA for these future releases.
Thanks for the answer.
Although it would be nice to get a general idea of some form of time frame when some of these issues may be resolved in a public release. My assumption now probably not this year, but in the next few months?
(sorry if I am repeating myself here) likewise or alternatively it would be great if Intel posted up test builds (with disclaimers) with the stuff up on Github, that allow others to test out these fixes and/or gave a complete set of instructions on how to build the system using these. I personally believe do this would help Intel create better system releases. Example: I believe that the SPI deadlock would have been detected and hopefully some patch installed before the 2.1 release ever happened.
But I still keep my fingers crossed that there will soon be something released that resolves these issues.
I just tried it now with the latest SPI code from github and I'm still observing the lockup. I didn't test as many different ways this time, but my code for writing to an OLED locks up with the new patch, which is no different from before. It got through one 4096 byte transfer at 12MHz before hanging on the second. By the commit messages it sure sounded hopeful...
In the last couple months, I've worked on this issue quite a bit since for me as well it basically breaks the whole project. SPI is the only fast low-level interface there is!
One thing I found is that disabling preemption in the kernel improves it quite a bit -- at first I thought I had found a work-around and was super excited, but it still wasn't reliable. I don't remember the exact numbers, but with preemption the best I could do was about 26kHz, without preemption 1MHz mostly worked (it still did lock up eventually, but not immediately like it would have with preemption). At this point I just gave up, since 1MHz still isn't nearly after enough for me, but for some disabling preemption might help get a little more speed/reliability while we wait for the real solution. And maybe this will help anyone else working on fixing this.
Also, with preemption enabled, the best throughput by far was bitbanging with mmaped gpios (I don't remember the exact rate, but maybe close to 100kHz).
I personally don't have confidence in Intel anymore (the hardware is amazing -- no doubt there, but the lack of full open-source, vague bulk pricing/availablity and slow response to bugs seems to make it a poor choice for production hardware) so I'm rebuilding my hardware around the Allwinner A13 SoC. Using the Olimex A13-SOM as an evaluation board, I was quickly and easily able to get SPI working at 80MHz and play video at 60fps on the OLED (160x128 18-bit color). Now I'm learning high-speed signal layout and matched impedance stuff for the DDR3 routing...a bit of a pain, but at least it has working SPI!