1. 23 Nov, 2020 1 commit
  2. 16 Nov, 2020 2 commits
  3. 12 Nov, 2020 4 commits
  4. 09 Nov, 2020 7 commits
  5. 03 Nov, 2020 2 commits
  6. 02 Nov, 2020 1 commit
  7. 30 Oct, 2020 3 commits
  8. 14 Oct, 2020 1 commit
  9. 12 Oct, 2020 2 commits
    • Federico Vaga's avatar
      sw:drv: bugfix concurrent tasklet scheduling · 9295311d
      Federico Vaga authored
      One process was able to perform a complete DMA transfer, and
      communicate the success to the client. Then it would try to schedule
      the next pending transfer, **but** the client could be fast enough to
      submit a new request **before** the end of the IRQ handler.
      
      This leads to this status: gn412x_dma_schedule_next() is called twice,
      once from the IRQ handler, once from the client (issue_pending()). In
      both cases they will see a pending transfer, and they will schedule
      gn412x_dma_start_task() twice. One will successfully start a new DMA
      transfer, the other one will fail printing an error.
      
      ------8<---------
               python3-19944 [002] ....... 15660.640429: spec_fpga_dbg_dma_write <-vfs_write
               python3-19944 [002] ....... 15660.640898: gn412x_dma_issue_pending <-spec_fpga_dbg_dma_transfer
               python3-19944 [002] ....... 15660.640898: gn412x_dma_schedule_next <-gn412x_dma_issue_pending
           ksoftirqd/2-31    [002] .....11 15660.640902: gn412x_dma_start_task <-__tasklet_action.isra.11
       irq/17-gn412x-g-5469  [000] ....... 15660.651980: gn412x_dma_irq_handler <-handle_nested_irq
               python3-19944 [002] ....... 15660.652086: spec_fpga_dbg_dma_read <-vfs_read
               python3-19944 [002] ....... 15660.652087: gn412x_dma_issue_pending <-spec_fpga_dbg_dma_transfer
               python3-19944 [002] ....... 15660.652087: gn412x_dma_schedule_next <-gn412x_dma_issue_pending
       irq/17-gn412x-g-5469  [000] ....... 15660.652089: gn412x_dma_schedule_next <-gn412x_dma_irq_handler
           ksoftirqd/2-31    [002] .....11 15660.652089: gn412x_dma_start_task <-__tasklet_action.isra.11
           ksoftirqd/2-31    [002] .....11 15660.652093: gn412x_dma_start_task <-__tasklet_action.isra.11
           ksoftirqd/2-31    [002] .....11 15660.652098: dev_err <-gn412x_dma_start_task
       irq/17-gn412x-g-5469  [000] ....... 15660.661041: gn412x_dma_irq_handler <-handle_nested_irq
       irq/17-gn412x-g-5469  [000] ....... 15660.661044: gn412x_dma_schedule_next <-gn412x_dma_irq_handler
      ------8<---------
      [15660.652101] spec_gn412x_dma spec-gn412x-dma.3.auto: Failed to start DMA transfer: channel busy
      ------8<---------
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      Signed-off-by: Tristan Gingold's avatarTristan Gingold <tristan.gingold@cern.ch>
      9295311d
    • Federico Vaga's avatar
      sw:drv: bugfix report ABORT|ERROR state · fc859af6
      Federico Vaga authored
      when checking for ERROR or ABORT what the code was doing was:
        (ERROR || ABORT)
      
      Fix it by applying the mask properly and compere the state value
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      Reported-by: Tristan Gingold's avatarTristan Gingold <tristan.gingold@cern.ch>
      fc859af6
  10. 02 Oct, 2020 6 commits
  11. 29 Sep, 2020 2 commits
  12. 20 Aug, 2020 1 commit
    • Federico Vaga's avatar
      sw:drv: fix GN412x HW bug in FCL · 493405a4
      Federico Vaga authored
      Programming cards in parallel does not work quite well. At best the
      GN412x chip reports errors on all plugged cards. In other cases it
      freezes the PC.
      
      With this patch I am going to serialize the FCL access. Like this
      cards will be programmed one after the other.
      
      I do not know the origin of the bug, but it must be in the GN412x chip.
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      493405a4
  13. 30 Jul, 2020 1 commit
  14. 08 Jul, 2020 2 commits
  15. 06 Jul, 2020 4 commits
  16. 02 Jul, 2020 1 commit