3 Replies Latest reply on Jul 13, 2015 5:01 PM by primiano

    Intel MID SSP SPI driver getting stuck in kernel space

    primiano
    primiano Jul 5, 2015 5:03 PM

      Hi,

      I'm trying to interface my Edison with a CPLD. What I need to do is to stream data via SPI from Edison -> CPLD uninterruptedly. I am seeing some weird behaviour of the intel_mid_ssp_spi.c driver and I think that ultimately there might be some bug in the kernel driver. What is the right way to move this forward, is there a bug tracker somewhere?

       

      The repro case is the following (Full source code here edison_spi_bug.c)

      - I just create a dummy spi device driver which spawns a kthread and performs a spi_write call every 100ms.

      - If I use a small tx buffer (the one passed to spi APIs) everything works fine most of the times (read: the bug reproduces more rarely).

      - If I bump the tx buffer size to 512 bytes, after 20-30 cycles the intel_mid_ssp_spi.c driver loops forever in the poll_transfer(...)  function and never acks the transfer (read: the kernel becomes unusable and I have to reboot).

      - I never queue more than a single 512 buffer per time (read: the kthread pump blocks waiting the previous TX buffer to have been transferred before enqueueing the next one, and there is a pause of 100ms between the two)

      - I am using the kernel sources from the Edison/Yocto BSP (3.10.17) with the to_upstream_edison patch and the standard .config. The rest of the system if perfectly functional.

       

      Another thing I couldn't figure out is:  all the SPI descriptors code in the Intel BSP (for instance edison-kernel/platform_spidev.c) has the following:

        /* SPI DMA is currently not usable on Tangier */

        .dma_enabled = false,

       

      which causes the SPI master driver to fall back into blocking read/writes. What is Tangier (Seems to be the codename of the SoC, is it the Edison)? Why DMA for SPI is not supported? It seems pretty vital considering that SPI is the only serious streaming interface the Edison has.

       

      I am looking for a way to stream data via SPI at full rate (i.e. 25 MHz) without bubbles in the pipeline (% CS strobes and assuming only one device per master). Is that realistically achievable with the current Edison or should I just look into some other SoC?

       

      Thanks,

      Primiano

        • 1. Re: Intel MID SSP SPI driver getting stuck in kernel space
          CMata_Intel
          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
            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
              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:

              intel_edison_spi_working.c

               

              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?


              [1] DMA SPI 8 bit write working in 3.10.17