1. 31 Jul, 2015 3 commits
    • Cyrille Pitchen's avatar
      dmaengine: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg() · 1c8a38b1
      Cyrille Pitchen authored
      This patch adds the missing update of the transfer data width in
      at_xdmac_prep_slave_sg().
      
      Indeed, for each item in the scatter-gather list, we check whether the
      transfer length is aligned with the data width provided by
      dmaengine_slave_config(). If so, we directly use this data width for the
      current part of the transfer we are preparing. Otherwise, the data width
      is reduced to 8 bits (1 byte). Of course, the actual number of register
      accesses must also be updated to match the new data width.
      
      So one chunk was missing in the original patch (see Fixes tag below): the
      number of register accesses was correctly set to (len >> fixed_dwidth) in
      mbr_ubc but the real data width was not updated in mbr_cfg. Since mbr_cfg
      may change for each part of the scatter-gather transfer this also explains
      why the original patch used the Descriptor View 2 instead of the
      Descriptor View 1.
      
      Let's take the example of a DMA transfer to write 8bit data into an Atmel
      USART with FIFOs. When FIFOs are enabled in the USART, its Transmit
      Holding Register (THR) works in multidata mode, that is to say that up to
      4 8bit data can be written into the THR in a single 32bit access and it is
      still possible to write only one data with a 8bit access. To take
      advantage of this new feature, the DMA driver was modified to allow
      multiple dwidths when doing slave transfers.
      For instance, when the total length is 22 bytes, the USART driver splits
      the transfer into 2 parts:
      
      First part: 20 bytes transferred through 5 32bit writes into THR
      Second part: 2 bytes transferred though 2 8bit writes into THR
      
      For the second part, the data width was first set to 4_BYTES by the USART
      driver thanks to dmaengine_slave_config() then at_xdmac_prep_slave_sg()
      reduces this data width to 1_BYTE because the 2 byte length is not aligned
      with the original 4_BYTES data width. Since the data width is modified,
      the actual number of writes into THR must be set accordingly.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Fixes: 6d3a7d9e ("dmaengine: at_xdmac: allow muliple dwidths when doing slave transfers")
      Cc: stable@vger.kernel.org #4.0 and later
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      1c8a38b1
    • Cyrille Pitchen's avatar
      dmaengine: at_hdmac: fix residue computation · 93dce3a6
      Cyrille Pitchen authored
      As claimed by the programmer datasheet and confirmed by the IP designer,
      the Block Transfer Size (BTSIZE) bitfield of the Channel x Control A
      Register (CTRLAx) always refers to a number of Source Width (SRC_WIDTH)
      transfers.
      
      Both the SRC_WIDTH and BTSIZE bitfields can be extacted from the CTRLAx
      register to compute the DMA residue. So the 'tx_width' field is useless
      and can be removed from the struct at_desc.
      
      Before this patch, atc_prep_slave_sg() was not consistent: BTSIZE was
      correctly initialized according to the SRC_WIDTH but 'tx_width' was always
      set to reg_width, which was incorrect for MEM_TO_DEV transfers. It led to
      bad DMA residue when 'tx_width' != SRC_WIDTH.
      
      Also the 'tx_width' field was mostly set only in the first and last
      descriptors. Depending on the kind of DMA transfer, this field remained
      uninitialized for intermediate descriptors. The accurate DMA residue was
      computed only when the currently processed descriptor was the first or the
      last of the chain. This algorithm was a little bit odd. An accurate DMA
      residue can always be computed using the SRC_WIDTH and BTSIZE bitfields
      in the CTRLAx register.
      
      Finally, the test to check whether the currently processed descriptor is
      the last of the chain was wrong: for cyclic transfer, last_desc->lli.dscr
      is NOT equal to zero, since set_desc_eol() is never called, but logically
      equal to first_desc->txd.phys. This bug has a side effect on the
      drivers/tty/serial/atmel_serial.c driver, which uses cyclic DMA transfer
      to receive data. Since the DMA residue was wrong each time the DMA
      transfer reaches the second (and last) period of the transfer, no more
      data were received by the USART driver till the cyclic DMA transfer loops
      back to the first period.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Acked-by: default avatarTorsten Fleischer <torfl6749@gmail.com>
      Tested-by: default avatarJirí Prchal <jiri.prchal@aksignal.cz>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      93dce3a6
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: fix bug about channel configuration · 20cadcb4
      Ludovic Desroches authored
      When using descriptor view 2 or higher, we don't write the configuration
      into AT_XDMAC_CC register because this configuration will be fetch from
      the descriptor. Unfortunately, the PROT bit is not updated with this
      method, we have to do it manually before enabling the channel.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      20cadcb4
  2. 07 Jul, 2015 2 commits
    • Krzysztof Kozlowski's avatar
      dmaengine: pl330: Really fix choppy sound because of wrong residue calculation · 5dd90e5b
      Krzysztof Kozlowski authored
      When pl330 driver was used during sound playback, after some time or
      after a number of plays the sound became choppy or totally noisy. For
      example on Odroid XU3 board the first four executions of aplay with
      small WAVE worked fine, but fifth was unrecognizable with errors:
      	$ aplay /usr/share/sounds/alsa/Front_Right.wava
      	underrun!!! (at least 0.095 ms long)
      
      Issue was caused by wrong residue reported by pl330 driver to
      pcm_dmaengine for its cyclic dma transfers.
      
      The pl330_tx_status(), residue reporting function, used a "last" flag in
      a descriptor to indicate that there is no more data to send.
      
      The pl330_tx_submit() iterated over descriptors trying to remove this
      flag from them and then mark last descriptor as "last".  However when
      iterating it actually removed the flag not from descriptors but always
      from last of it (and then reset it). Thus effectively once some
      descriptor was marked as last, then it stayed like this forever causing
      residue to be reported too low.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
      Fixes: aee4d1fa ("dmaengine: pl330: improve pl330_tx_status() function")
      Cc: <stable@vger.kernel.org>
      Reported-by: gabriel@unseen.is
      Suggested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      5dd90e5b
    • Krzysztof Kozlowski's avatar
      dmaengine: pl330: Fix overflow when reporting residue in memcpy · ae128293
      Krzysztof Kozlowski authored
      During memcpy operations the residue was always set to an u32 overflowed
      value.
      
      In pl330_tx_status() function number of currently transferred bytes was
      subtracted from internal "bytes_requested" field. However this
      "bytes_requested" was not initialized at start to length of memcpy
      buffer so transferred bytes were subtracted from 0 causing overflow.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: <stable@vger.kernel.org>
      Fixes: aee4d1fa ("dmaengine: pl330: improve pl330_tx_status() function")
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      ae128293
  3. 05 Jul, 2015 4 commits
    • Linus Torvalds's avatar
      Linux 4.2-rc1 · d770e558
      Linus Torvalds authored
      d770e558
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v4.2-2' of... · a585d2b7
      Linus Torvalds authored
      Merge tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
      
      Pull late x86 platform driver updates from Darren Hart:
       "The following came in a bit later and I wanted them to bake in next a
        few more days before submitting, thus the second pull.
      
        A new intel_pmc_ipc driver, a symmetrical allocation and free fix in
        dell-laptop, a couple minor fixes, and some updated documentation in
        the dell-laptop comments.
      
        intel_pmc_ipc:
         - Add Intel Apollo Lake PMC IPC driver
      
        tc1100-wmi:
         - Delete an unnecessary check before the function call "kfree"
      
        dell-laptop:
         - Fix allocating & freeing SMI buffer page
         - Show info about WiGig and UWB in debugfs
         - Update information about wireless control"
      
      * tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
        intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver
        tc1100-wmi: Delete an unnecessary check before the function call "kfree"
        dell-laptop: Fix allocating & freeing SMI buffer page
        dell-laptop: Show info about WiGig and UWB in debugfs
        dell-laptop: Update information about wireless control
      a585d2b7
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 1dc51b82
      Linus Torvalds authored
      Pull more vfs updates from Al Viro:
       "Assorted VFS fixes and related cleanups (IMO the most interesting in
        that part are f_path-related things and Eric's descriptor-related
        stuff).  UFS regression fixes (it got broken last cycle).  9P fixes.
        fs-cache series, DAX patches, Jan's file_remove_suid() work"
      
      [ I'd say this is much more than "fixes and related cleanups".  The
        file_table locking rule change by Eric Dumazet is a rather big and
        fundamental update even if the patch isn't huge.   - Linus ]
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (49 commits)
        9p: cope with bogus responses from server in p9_client_{read,write}
        p9_client_write(): avoid double p9_free_req()
        9p: forgetting to cancel request on interrupted zero-copy RPC
        dax: bdev_direct_access() may sleep
        block: Add support for DAX reads/writes to block devices
        dax: Use copy_from_iter_nocache
        dax: Add block size note to documentation
        fs/file.c: __fget() and dup2() atomicity rules
        fs/file.c: don't acquire files->file_lock in fd_install()
        fs:super:get_anon_bdev: fix race condition could cause dev exceed its upper limitation
        vfs: avoid creation of inode number 0 in get_next_ino
        namei: make set_root_rcu() return void
        make simple_positive() public
        ufs: use dir_pages instead of ufs_dir_pages()
        pagemap.h: move dir_pages() over there
        remove the pointless include of lglock.h
        fs: cleanup slight list_entry abuse
        xfs: Correctly lock inode when removing suid and file capabilities
        fs: Call security_ops->inode_killpriv on truncate
        fs: Provide function telling whether file_remove_privs() will do anything
        ...
      1dc51b82
    • Linus Torvalds's avatar
      bluetooth: fix list handling · 9b284cbd
      Linus Torvalds authored
      Commit 835a6a2f ("Bluetooth: Stop sabotaging list poisoning")
      thought that the code was sabotaging the list poisoning when NULL'ing
      out the list pointers and removed it.
      
      But what was going on was that the bluetooth code was using NULL
      pointers for the list as a way to mark it empty, and that commit just
      broke it (and replaced the test with NULL with a "list_empty()" test on
      a uninitialized list instead, breaking things even further).
      
      So fix it all up to use the regular and real list_empty() handling
      (which does not use NULL, but a pointer to itself), also making sure to
      initialize the list properly (the previous NULL case was initialized
      implicitly by the session being allocated with kzalloc())
      
      This is a combination of patches by Marcel Holtmann and Tedd Ho-Jeong
      An.
      
      [ I would normally expect to get this through the bt tree, but I'm going
        to release -rc1, so I'm just committing this directly   - Linus ]
      Reported-and-tested-by: default avatarJörg Otte <jrg.otte@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Original-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Original-by: Marcel Holtmann <marcel@holtmann.org>:
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b284cbd
  4. 04 Jul, 2015 31 commits