1. 18 Oct, 2013 10 commits
    • Trent Piepho's avatar
      spi: spi-mxs: Remove check of spi mode bits · d426eadb
      Trent Piepho authored
      The spi core already checks for a slave setting mode bits that we
      didn't list as supported when the master was registered.  There is no
      need to do it again in the master driver.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      d426eadb
    • Trent Piepho's avatar
      spi: spi-mxs: Fix race in setup method · 9c97e342
      Trent Piepho authored
      Despite many warnings in the SPI documentation and code, the spi-mxs
      driver sets shared chip registers in the ->setup method.  This method can
      be called when transfers are in progress on other slaves controlled by the
      master.  Setting registers or any other shared state will corrupt those
      transfers.
      
      So fix mxs_spi_setup() to not call mxs_spi_setup_transfer().
      mxs_spi_setup_transfer() is already called for each transfer when they
      are actually performed in mxs_spi_transfer_one(), so the call in
      mxs_spi_setup() isn't necessary to setup anything.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      9c97e342
    • Trent Piepho's avatar
      spi: spi-mxs: Remove bogus setting of ssp clk rate field · 1a33073f
      Trent Piepho authored
      The ssp struct has a clock rate field, to provide the actual value, in Hz,
      of the SSP output clock (the rate of SSP_SCK) after mxs_ssp_set_clk_rate()
      is called.  It is set by mxs_ssp_set_clk_rate(), for SSP using drivers (like
      SPI and MMC) to *read* if they want to know the actual clock rate.  The SPI
      driver isn't supposed to *write* to it.
      
      For some reason the spi-mxs driver decides to write to this field on init,
      and sets it to the value of the SSP input clock (clk_sspN, from the MXS
      clocking block) in kHz.  It shouldn't be setting the value, and certainly
      shouldn't be setting it with the wrong clock in the wrong units.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      1a33073f
    • Trent Piepho's avatar
      spi: spi-mxs: Remove full duplex check, spi core already does it · 210f65fe
      Trent Piepho authored
      Because the driver sets the SPI_MASTER_HALF_DUPLEX flag, the spi core
      will check transfers to insure they are not full duplex.  It's not
      necessary to check that in the spi-mxs driver as well.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      210f65fe
    • Trent Piepho's avatar
      spi: spi-mxs: Fix chip select control bits in DMA mode · 0b782f70
      Trent Piepho authored
      In DMA mode the chip select control bits would be ORed into the CTRL0
      register without first clearing the bits.  This means that after
      addressing slave 1, the CTRL0 bit to address slave 1 would be still be
      set when addressing slave 0, resulting in slave 1 continuing to be
      addressed.
      
      The message handling function would pass the CS value to the txrx
      function, which would re-program the bits on each transfer in the
      message.  The selected CS does not change during a message so this is
      inefficient.  It also means there are two different sets of code for
      selecting the CS, one for PIO that worked and one for DMA that didn't.
      
      Change the code to set the CS bits in the message handling function
      once.  Now the DMA and PIO txrx functions don't need to care about CS
      at all.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      0b782f70
    • Trent Piepho's avatar
      spi: spi-mxs: Fix extra CS pulses and read mode in multi-transfer messages · df23286e
      Trent Piepho authored
      There are two bits which control the CS line in the CTRL0 register:
      LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
      in SPI mode.
      
      Setting DEASSERT_CS causes CS to be de-asserted at the end of the transfer.
      It should normally be set only for the final segment of the final transfer.
      The DMA code explicitly sets it in this case, but because it never clears
      the bit from the ctrl0 register, it will remain set for all transfers in
      subsequent messages.  This results in a CS pulse between transfers.
      
      There is a similar problem with the read mode bit never being cleared
      in DMA mode.
      
      This patch fixes DEASSERT_CS and READ being left on in DMA mode.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      df23286e
    • Trent Piepho's avatar
      spi: spi-mxs: Change flag arguments in txrx functions to bit flags · 28cad125
      Trent Piepho authored
      There are three flag arguments to the PIO and DMA txrx functions.  Two
      are passed as pointers to integers, even though they are input only
      and not modified, which makes no sense to do.  The third is passed as
      an integer.
      
      The compiler must use an argument register or stack variable for each
      flag this way.  Using bitflags in a single flag argument is more
      efficient and produces smaller code, since all the flags can fit in a
      single register.  And all the flag arguments get cumbersome,
      especially when more are added for things like GPIO chipselects.
      
      The "first" flag is never used, so can just be deleted.
      
      The "last" flag is renamed to DEASSERT_CS, since that's really what it
      does.  The spi_transfer cs_change flag means that CS might be
      de-asserted on a transfer which is not last and not de-assert on the
      last transfer, so it is not which transfer is the last we need to know
      but rather the transfers after which CS should be de-asserted.
      
      This also extends the driver to not ignore cs_change when setting the
      DEASSERT_CS nee "last" flag.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      28cad125
    • Trent Piepho's avatar
      spi: spi-mxs: Always clear INGORE_CRC, to keep CS asserted · 75e73fa2
      Trent Piepho authored
      INGORE_CRC, better named DEASSERT_CS, should be cleared on all tranfers
      except the last.  So instead of only clearing it on the first transfer, we
      can just always clear it.  It will set on the last transfer.
      
      This removes the only use of the "first" flag in the transfer functions, so
      that flag can be then be removed.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      75e73fa2
    • Trent Piepho's avatar
      spi: spi-mxs: Remove mxs_spi_enable and mxs_spi_disable · f5bc7384
      Trent Piepho authored
      These functions consist of nothing but one single writel call and are
      only called once.  And the names really aren't accurate or clear,
      since they don't enable or disble SPI.  Rather they set the bit that
      controls the state of CS at the end of transfer.  It easier to follow
      the code to just set this bit with a writel() along with all the other
      bits being set in the same function.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      f5bc7384
    • Trent Piepho's avatar
      spi: spi-mxs: Always set LOCK_CS · 58f46e41
      Trent Piepho authored
      There are two bits which control the CS line in the CTRL0 register:
      LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
      in SPI mode.
      
      LOCK_CS keeps CS asserted though the entire transfer.  This should
      always be set.  The DMA code will always set it, explicitly on the
      first segment of the first transfer, and then implicitly on all the
      rest by never clearing the bit from the value read from the ctrl0
      register.
      
      The PIO code will explicitly set it for the first transfer, leave it
      set for intermediate transfers, and then clear it for the final
      transfer.  It should not clear it.
      
      The only reason to not set LOCK_CS would be to attempt an altered
      protocol where CS pulses between each word.  Though don't get your
      hopes up if you want to do this, as the hardware doesn't appear to do
      this in any sane manner.  It appears to be related to the hardware
      FIFO fill level.
      
      The code can be simplified by just setting LOCK_CS once and then not
      needing to deal with it at all in the PIO and DMA transfer functions.
      Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      58f46e41
  2. 13 Oct, 2013 17 commits
  3. 12 Oct, 2013 10 commits
  4. 11 Oct, 2013 3 commits
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · 46f37519
      Linus Torvalds authored
      Pull MIPS fix from Ralf Baechle:
       "Just one fix.  The stack protector was loading the value of the canary
        instead of its address"
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: stack protector: Fix per-task canary switch
      46f37519
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · cd4edf7a
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "All over the map..
      
         - nouveau:
           disable MSI, needs more work, will try again next merge window
         - radeon:
            audio + uvd regression fixes, dpm fixes, reset fixes
         - i915:
           the dpms fix might fix your haswell
      
        And one pain in the ass revert, so we have VGA arbitration that when
        implemented 4-5 years ago really hoped that GPUs could remove
        themselves from arbitration completely once they had a kernel driver.
      
        It seems Intel hw designers decided that was too nice a facility to
        allow us to have so they removed it when they went on-die (so since
        Ironlake at least).  Now Alex Williamson added support for VGA
        arbitration for newer GPUs however this now exposes itself to
        userspace as requireing arbitration of GPU VGA regions and the X
        server gets involved and disables things that it can't handle when VGA
        access is possibly required around every operation.
      
        So in order to not break userspace we just reverted things back to the
        old known broken status so maybe we can try and design out way out.
      
        Ville also had a patch to use stop machine for the two times Intel
        needs to access VGA space, that might be acceptable with some rework,
        but for now myself and Daniel agreed to just go back"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (23 commits)
        Revert "i915: Update VGA arbiter support for newer devices"
        Revert "drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done"
        drm/radeon: re-enable sw ACR support on pre-DCE4
        drm/radeon/dpm: disable bapm on TN asics
        drm/radeon: improve soft reset on CIK
        drm/radeon: improve soft reset on SI
        drm/radeon/dpm: off by one in si_set_mc_special_registers()
        drm/radeon/dpm/btc: off by one in btc_set_mc_special_registers()
        drm/radeon: forever loop on error in radeon_do_test_moves()
        drm/radeon: fix hw contexts for SUMO2 asics
        drm/radeon: fix typo in CP DMA register headers
        drm/radeon/dpm: disable multiple UVD states
        drm/radeon: use hw generated CTS/N values for audio
        drm/radeon: fix N/CTS clock matching for audio
        drm/radeon: use 64-bit math to calculate CTS values for audio (v2)
        drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocation
        Revert "drm/fb-helper: don't sleep for screen unblank when an oops is in progress"
        drm/gma500: fix things after get/put page helpers
        drm/nouveau/mc: disable msi support by default, it's busted in tons of places
        drm/i915: Only apply DPMS to the encoder if enabled
        ...
      cd4edf7a
    • David Henningsson's avatar