-
1. Re: Intel MID SSP SPI driver getting stuck in kernel space
CMata_Intel Jul 7, 2015 6:28 PM (in response to primiano)Hi primiano,
Thank you very much for your feedback, this has already been sent to the proper team. We are going to investigate more about this and as soon as we get updates/information we will post them here.
Kind Regards,
Charlie.
-
2. Re: Intel MID SSP SPI driver getting stuck in kernel space
JPMontero_Intel Jul 10, 2015 1:40 PM (in response to primiano)Hi primiano,
Thank you for reporting it, we are already working on it. It could be fix in a future software release.
Regards,
JPMontero_Intel -
3. Re: Intel MID SSP SPI driver getting stuck in kernel space
primiano Jul 13, 2015 5:01 PM (in response to JPMontero_Intel)Nevermind, I managed to make it work via DMA.
"It could be fix in a future software release" sounds a more formal rewording of "we acknowledge the issue but we are not interested in fixing this anytime soon". It is fine, but please let us be in the position to fixing that for you if we care about.
I had to sit in a lab with an oscilloscope and do some git surgery to backport some post 3.0.17 patches from [1], plus some other manual hacking.
I can now make the SPI work at full speed (25 MHz) using DMA with nearly zero bubbles.
The modified kernel sources are available here
Commits · primiano/edison-kernel · GitHub
And an example of usage here:
The thing that really baffled me is that, in the current reference kernel tree (i.e. 3.0.17 + upstream patch) I've stumbled upon bits of code which cannot possibly work (* see below for a concrete example). Together with the fact that the only source for that code seems to be a monster-patch file, this makes me wonder whether the code you are releasing has been reviewed (even internally) or tested at all.
If I can speak frankly, I am really negatively impressed by the very closed attitude that you guys are having as regards the Edison.
I do understand that IoT is essentially a rounding error in Intel's business and here you're trying to achieve the best result with the minimum effort. Which is great, I think everybody here still agrees that hardware-wise the Edison is excellent energy vs computational power tradeoff.
I do understand that writing kernel drivers that work properly requires engineering resources, and here it seems that you decided to dedicate very little of them for the Edison. Which is still ok.
What I do not understand is: since you can't afford to release a BSP that just works properly (IIRC we had to wait for 6+ months to "unveil" and expose the Quark u-c) why don't you just make the documentation of the basic HW IP open and let others do that for you? This would make life of Edison users **so much** easier.
Honestly, I think that there are loads of competent people out there in the open-source world which could have been written much better drivers than what you made available in these release rushes.
Just to be clear, I am not talking about HW specs of the microarchitecture, just the very few peripherals that the Edison has: SPI, I2C, I2S, and DMA IPs. Having to understand the meaning of your kernel drivers without a HW reference manual, using a mixture of git archaeology from other Intel-based BSPs and a oscilloscope is a **huge** pain and is definitely IMHO not making the Edison an appealing product for the DIY/hacking market.
I had similar experiences to these with Freescale iMX6 SoCs. I've seen similar problems there, but at least in that case the availability of docs allowed people to fix issues without having to wait for BSP re-spins.
Out of curiosity, what is the reason for not making the reference manual of the basic Edison's peripherals open? Is it really the case that a SPI or SG-DMA IP represent such a big competitive advantage that you can't even make some documentation available?
* From the original (i.e. pre-backports) intel_mid_ssp_spi.c: on line 1066:
if (likely(dma_enabled)) .... map_dma_buffers(sspc);
few lines below,
if (likely(chip->dma_enabled))...map_dma_buffers(sspc)
but later on line 626 map_dma_buffers bails out with an error if the dma buffers have been already mapped, which is the case, as that code is invoking map_dma_buffers twice. How is that supposed to work?