Skip to content
GitLab
  1. Nov 19, 2014
  3. Nov 17, 2014
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: Add DMA_PRIVATE · fef4cbf2
      Ludovic Desroches authored 
      same issue as commit 7f5ae355

:
"Without DMA_PRIVATE the driver is not able to allocate more than one channel.
Since it uses dma_get_any_slave_channel that calls private_candidate, the
second allocation fails at
/* some channels are already publicly allocated */
"

Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      fef4cbf2
    • Ludovic Desroches's avatar
      ARM: dts: at_xdmac: fix bad value of dma-cells in documentation · 466b3cf1
      Ludovic Desroches authored 
      

The dma-cells value in the example was 2 instead of 1.

Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      466b3cf1
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: fix missing spin_unlock · 87809839
      Ludovic Desroches authored 
      

Lock taken when entering the function but unlock missing before it
returns.

Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      87809839
    • Cyrille Pitchen's avatar
      dmaengine: at_xdmac: fix a bug in transfer residue computation · 57819276
      Cyrille Pitchen authored 
      

The total size of the transfer was wrong in at_xdmac_prep_slave_sg()
resulting in bad computation of the transfer residue by
at_xdmac_tx_status().

Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      57819276
    • Cyrille Pitchen's avatar
      dmaengine: at_xdmac: fix software lockup at_xdmac_tx_status() · 4e097820
      Cyrille Pitchen authored 
      

According to the Atmel eXtended DMA controller datasheet, requesting a
DMA transfer flush for a channel is only revelant when this transfer is
source peripheral synchronized.

So we have to check this condition before requesting a channel flush by
writing the channel bit into the Global channel SoftWare Flush (GSWF)
register then waiting for flush to complete by monitoring the end of
Flush Interrupt Status (FIS) bit in the Channel Interrupt Status (CIS)
register.

Indeed, for non source peripheral synchronized transfer, writing the
channel bit into the GSWF register does nothing. Especially, the FIS bit
is never set into the CIS register. The former code looped forever
waiting for this bit to be set.

Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      4e097820
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: remove chancnt affectation · 77e6c9bf
      Ludovic Desroches authored 
      

Remove chancnt affectation since it is done in dma_async_device_regiser.

Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      77e6c9bf
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: prefer usage of readl/writel_relaxed · 6e5ae29b
      Ludovic Desroches authored 
      

_relaxed version of readl and writel are not implemented on all
architecture so COMPILE_TEST has to be removed in order to not cause
some build failures.

Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      6e5ae29b
    • Vinod Koul's avatar
      dmaengine: xdmac: fix print warning on dma_addr_t variable · 82e24246
      Vinod Koul authored 
      

As documented in printk-formats.txt the dma_addr_t should be printed with
%pad specfiers. This way it works on all archs.

 make.cross ARCH=s390

All warnings:

   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_slave_sg':
>> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/at_xdmac.c:628:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
       dev_dbg(chan2dev(chan),
       ^
   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic':
>> drivers/dma/at_xdmac.c:663:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan), "%s: buf_addr=0x%08x, buf_len=%d, period_len=%d, dir=%s, flags=0x%lx\n",
     ^
>> drivers/dma/at_xdmac.c:690:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/at_xdmac.c:716:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
       dev_dbg(chan2dev(chan),

>> drivers/dma/at_xdmac.c:731:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan),
     ^
   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy':
>> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan), "%s: src=0x%08x, dest=0x%08x, len=%d, flags=0x%lx\n",
     ^
>> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan), "%s: remaining_size=%u\n", __func__, remaining_size);
                              ^
>> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/at_xdmac.c:852:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
       dev_dbg(chan2dev(chan),
       ^
   drivers/dma/at_xdmac.c: In function 'at_xdmac_tx_status':
>> drivers/dma/at_xdmac.c:929:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan),

Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      82e24246
    • Vinod Koul's avatar
      dmaengine: xdmac: fix print warning on size_t variable · c66ec04e
      Vinod Koul authored 
      

As documented in printk-formats.txt the size_t should be printed with
%zu/%zd specfiers. This way it works on all archs.

make.cross ARCH=avr32

All warnings:

   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic':
>> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 6 has type 'size_t'
>> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 7 has type 'size_t'
   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy':
>> drivers/dma/at_xdmac.c:765: warning: format '%d' expects type 'int', but argument 7 has type 'size_t'
>> drivers/dma/at_xdmac.c:794: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t'
>> drivers/dma/at_xdmac.c:815: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t'

Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      c66ec04e
    • Vinod Koul's avatar
      dmaengine: at_xdmac: fix usage of read, write wrappers · 2abd4198
      Vinod Koul authored 
      

This driver uses read_relaxed and writel_relaxed to read, write to IO
memory. the config defines COMPILE_TEST so gets compiled on different archs.
This causes issue as few archs like x86 etc don't define it.
So use readl/writel which is defined in all archs

Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      2abd4198
    • kbuild test robot's avatar
      dmaengine: at_xdmac: fix semicolon.cocci warnings · 5ac7d582
      kbuild test robot authored 
      

drivers/dma/at_xdmac.c:702:3-4: Unneeded semicolon

 Removes unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Signed-off-by: default avatarFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      5ac7d582
  5. Nov 06, 2014
  7. Nov 03, 2014
  9. Nov 02, 2014
    • Paolo Bonzini's avatar
      KVM: vmx: defer load of APIC access page address during reset · a73896cb
      Paolo Bonzini authored 
      

Most call paths to vmx_vcpu_reset do not hold the SRCU lock.  Defer loading
the APIC access page to the next vmentry.

This avoids the following lockdep splat:

[ INFO: suspicious RCU usage. ]
3.18.0-rc2-test2+ #70 Not tainted
-------------------------------
include/linux/kvm_host.h:474 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
1 lock held by qemu-system-x86/2371:
 #0:  (&vcpu->mutex){+.+...}, at: [<ffffffffa037d800>] vcpu_load+0x20/0xd0 [kvm]

stack backtrace:
CPU: 4 PID: 2371 Comm: qemu-system-x86 Not tainted 3.18.0-rc2-test2+ #70
Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013
 0000000000000001 ffff880209983ca8 ffffffff816f514f 0000000000000000
 ffff8802099b8990 ffff880209983cd8 ffffffff810bd687 00000000000fee00
 ffff880208a2c000 ffff880208a10000 ffff88020ef50040 ffff880209983d08
Call Trace:
 [<ffffffff816f514f>] dump_stack+0x4e/0x71
 [<ffffffff810bd687>] lockdep_rcu_suspicious+0xe7/0x120
 [<ffffffffa037d055>] gfn_to_memslot+0xd5/0xe0 [kvm]
 [<ffffffffa03807d3>] __gfn_to_pfn+0x33/0x60 [kvm]
 [<ffffffffa0380885>] gfn_to_page+0x25/0x90 [kvm]
 [<ffffffffa038aeec>] kvm_vcpu_reload_apic_access_page+0x3c/0x80 [kvm]
 [<ffffffffa08f0a9c>] vmx_vcpu_reset+0x20c/0x460 [kvm_intel]
 [<ffffffffa039ab8e>] kvm_vcpu_reset+0x15e/0x1b0 [kvm]
 [<ffffffffa039ac0c>] kvm_arch_vcpu_setup+0x2c/0x50 [kvm]
 [<ffffffffa037f7e0>] kvm_vm_ioctl+0x1d0/0x780 [kvm]
 [<ffffffff810bc664>] ? __lock_is_held+0x54/0x80
 [<ffffffff812231f0>] do_vfs_ioctl+0x300/0x520
 [<ffffffff8122ee45>] ? __fget+0x5/0x250
 [<ffffffff8122f0fa>] ? __fget_light+0x2a/0xe0
 [<ffffffff81223491>] SyS_ioctl+0x81/0xa0
 [<ffffffff816fed6d>] system_call_fastpath+0x16/0x1b

Reported-by: default avatarTakashi Iwai <tiwai@suse.de>
Reported-by: default avatarAlexei Starovoitov <alexei.starovoitov@gmail.com>
Reviewed-by: default avatarWanpeng Li <wanpeng.li@linux.intel.com>
Tested-by: default avatarWanpeng Li <wanpeng.li@linux.intel.com>
Fixes: 38b99173


Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a73896cb
    • Jan Kiszka's avatar
      KVM: nVMX: Disable preemption while reading from shadow VMCS · 282da870
      Jan Kiszka authored 
      

In order to access the shadow VMCS, we need to load it. At this point,
vmx->loaded_vmcs->vmcs and the actually loaded one start to differ. If
we now get preempted by Linux, vmx_vcpu_put and, on return, the
vmx_vcpu_load will work against the wrong vmcs. That can cause
copy_shadow_to_vmcs12 to corrupt the vmcs12 state.

Fix the issue by disabling preemption during the copy operation.
copy_vmcs12_to_shadow is safe from this issue as it is executed by
vmx_vcpu_run when preemption is already disabled before vmentry.

This bug is exposed by running Jailhouse within KVM on CPUs with
shadow VMCS support.  Jailhouse never expects an interrupt pending
vmexit, but the bug can cause it if, after copy_shadow_to_vmcs12
is preempted, the active VMCS happens to have the virtual interrupt
pending flag set in the CPU-based execution controls.

Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      282da870