Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 20 10月, 2014 1 次提交
  3. 23 9月, 2014 7 次提交
  5. 22 5月, 2014 1 次提交
  7. 11 4月, 2014 4 次提交
  9. 13 2月, 2014 1 次提交
    • O
      dma: mv_xor: Silence a bunch of LPAE-related warnings · 31fd8f5b
      由 Olof Johansson 提交于 
      Enabling some of the mvebu platforms in the multiplatform config for ARM
enabled these drivers, which also triggered a bunch of warnings when LPAE
is enabled (thus making phys_addr_t 64-bit).

Most changes are switching printk formats, but also a bit of changes to what
used to be array-based pointer arithmetic that could just be done with the
address types instead.

The warnings were:

drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
    'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
    different size [-Wint-to-pointer-cast]
drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
    different size [-Wpointer-to-int-cast]
drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
    'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
    'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
    'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
Acked-by: NVinod Koul <vinod.koul@intel.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      31fd8f5b
  11. 13 12月, 2013 3 次提交
  13. 15 11月, 2013 3 次提交
  15. 14 11月, 2013 1 次提交
  17. 25 10月, 2013 1 次提交
  19. 10 9月, 2013 1 次提交
  21. 23 8月, 2013 2 次提交
  23. 13 8月, 2013 2 次提交
  25. 04 7月, 2013 1 次提交
  27. 08 1月, 2013 1 次提交
  29. 07 1月, 2013 2 次提交
  31. 29 11月, 2012 2 次提交
  33. 23 11月, 2012 4 次提交
    • T
      dma: mv_xor: fix error handling path · 73d9cdca
      由 Thomas Petazzoni 提交于 
      The ->probe() function of the mv_xor function contains in its error
handling code a loop to cleanup the XOR channels that had been
successfully initialized if some other XOR channel fails to be
initialized. It does that by traveling the list of XOR channels, and
cleanup those for which the pointer is not NULL.

However, since the mv_xor_channel_add() function return a PTR_ERR
style value, the pointer is not NULL on error. So, when handling the
error of a given channel initialization, we cleanup this channel
initialization and mark this channel entry as NULL in the array. This
allows the remaining of the cleanup (for other channels) to work
properly.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      73d9cdca
    • T
      dma: mv_xor: fix error checking of irq_of_parse_and_map() · f8eb9e7d
      由 Thomas Petazzoni 提交于 
      The irq_of_parse_and_map() function returns 0 on failure, and does not
return an error code, so we fix the calling site of
irq_of_parse_and_map() in the mv_xor driver.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      f8eb9e7d
    • T
      dma: mv_xor: use request_irq() instead of devm_request_irq() · 2d0a0745
      由 Thomas Petazzoni 提交于 
      Even through the usage of devm_*() functions is generally recommended
over their classic variants, in the case of devm_request_irq()
combined with irq_of_parse_and_map(), it doesn't work nicely.

We have the following scenario:

 irq_of_parse_and_map(...)
 devm_request_irq(...)

For some reason, the driver initialization fails at a later
point. Since irq_of_parse_and_map() is no device-managed, we do a:

 irq_dispose_mapping(...)

Unfortunately, this doesn't work, because the free_irq() must be done
prior to calling irq_dispose_mapping(). But with the devm mechanism,
the automatic free_irq() would happen only after we get out of the
->probe() function.

So basically, we revert to using request_irq() with traditional error
handling, so that in case of error, free_irq() gets called before
irq_dispose_mapping().
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      2d0a0745
    • T
      dma: mv_xor: clear the window override control registers · c4b4b732
      由 Thomas Petazzoni 提交于 
      The XOR channels on Marvell SoCs have a Window Override Control
register that allow to do some fancy things with addresses. Those
features are not used by the driver, but some U-Boot versions anyway
modify those registers.

For some reason, the U-Boot on OpenBlocks AX3-4 was setting an invalid
value in those registers when the addition 2 GB DRAM chip was plugged
into the board, causing the XOR driver to fail in using the XOR
engines.

By setting those registers to 0 during the driver initialization, we
ensure that the registers are configured according with the driver
operation model.

Thanks to Lior Amsalem <alior@marvell.com> for his help in debugging
this problem.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      c4b4b732
  35. 20 11月, 2012 3 次提交