1. 27 Feb, 2020 1 commit
    • Thommy Jakobsson's avatar
      spi/zynqmp: remove entry that causes a cs glitch · 5dd83049
      Thommy Jakobsson authored
      In the public interface for chipselect, there is always an entry
      commented as "Dummy generic FIFO entry" pushed down to the fifo right
      after the activate/deactivate command. The dummy entry is 0x0,
      irregardless if the intention was to activate or deactive the cs. This
      causes the cs line to glitch rather than beeing activated in the case
      when there was an activate command.
      
      This has been observed on oscilloscope, and have caused problems for at
      least one specific flash device type connected to the qspi port. After
      the change the glitch is gone and cs goes active when intended.
      
      The reason why this worked before (except for the glitch) was because
      when sending the actual data, the CS bits are once again set. Since
      most flashes uses mode 0, there is always a half clk period anyway for
      cs to clk active setup time. If someone would rely on timing from a
      chip_select call to a transfer_one, it would fail though.
      
      It is unknown why the dummy entry was there in the first place, git log
      seems to be of no help in this case. The reference manual gives no
      indication of the necessity of this. In fact the lower 8 bits are a
      setup (or hold in case of deactivate) time expressed in cycles. So this
      should not be needed to fulfill any setup/hold timings.
      Signed-off-by: default avatarThommy Jakobsson <thommyj@gmail.com>
      Reviewed-by: default avatarNaga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
      Link: https://lore.kernel.org/r/20200224162643.29102-1-thommyj@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      5dd83049
  2. 26 Feb, 2020 1 commit
  3. 21 Feb, 2020 2 commits
  4. 06 Feb, 2020 2 commits
  5. 23 Jan, 2020 1 commit
  6. 17 Jan, 2020 3 commits
  7. 14 Jan, 2020 4 commits
  8. 13 Jan, 2020 1 commit
  9. 10 Jan, 2020 2 commits
  10. 09 Jan, 2020 3 commits
  11. 07 Jan, 2020 7 commits
  12. 27 Dec, 2019 2 commits
  13. 25 Dec, 2019 8 commits
  14. 18 Dec, 2019 1 commit
  15. 17 Dec, 2019 2 commits