The davinci_cpdma mixes up physical addresses as seen from the CPU
and DMA addresses as seen from a DMA master, since it can operate
on both normal memory or an on-chip buffer. If dma_addr_t is
different from phys_addr_t, this means we get a compile-time warning
about the type mismatch:
ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
In file included from ethernet/ti/davinci_cpdma.c:21:0:
dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
static inline void *dma_alloc_coherent(struct device *dev, size_t size,
This slightly restructures the code so the address we use for
mapping RAM into a DMA address is always a dma_addr_t, avoiding
the warning. The code is correct even if both types are 32-bit
because the DMA master in this device only supports 32-bit addressing
anyway, independent of the types that are used.
We still assign this value to pool->phys, and that is wrong if
the driver is ever used with an IOMMU, but that value appears to
be never used, so there is no problem really. I've added a couple
of comments about where we do things that are slightly violating
the API.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
memories allocated with devm_* apis must not be freed with kfree apis,
so removing the kfree calls
Fixes: e194312854 ('drivers: net: davinci_cpdma: Convert kzalloc() to devm_kzalloc().')
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We recently change the kzalloc() to devm_kzalloc() so freeing "ctlr"
here could lead to a double free.
Fixes: e194312854 ('drivers: net: davinci_cpdma: Convert kzalloc() to devm_kzalloc().')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Convert kzalloc() to devm_kzalloc().
Signed-off-by: George Cherian <george.cherian@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If an error occurs during the initialization in emac_dev_open() (the
driver's ndo_open function), interrupts, DMA descriptors etc. must be freed.
The current rollback code is buggy in several ways.
1) Freeing the interrupts. The current code will not free all interrupts
that were requested by the driver. Furthermore, the code tries to do a
platform_get_resource(priv->pdev, IORESOURCE_IRQ, -1) in its last
iteration.
This patch fixes these bugs.
2) Wrong order of err: and rollback: labels. If the setup of the PHY in
the code fails, the interrupts that have been requested before are
not freed:
request irq
if requesting irqs fails, goto rollback
setup phy
if phy setup fails, goto err
return 0
rollback:
free irqs
err:
This patch brings the code into the correct order.
3) The code calls napi_enable() and emac_int_enable(), but does not
undo both in case of an error.
This patch adds calls of emac_int_disable() and napi_disable() to the
rollback code.
4) RX DMA descriptors are not freed in case of an error: Right before
requesting the irqs, the function creates DMA descriptors for the
RX channel. These RX descriptors are never freed when we jump to either
rollback or err.
This patch adds code for freeing the DMA descriptors in the case of
an initialization error. This required a modification of
cpdma_ctrl_stop() in davinci_cpdma.c: We must be able to call this
function to free the DMA descriptors while the DMA channels are
in IDLE state (before cpdma_ctlr_start() was called).
Tested on a custom board with the Texas Instruments AM1808.
Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
Signed-off-by: David S. Miller <davem@davemloft.net>
Silences the below warnings when building with ARM_LPAE enabled, which
gives longer dma_addr_t by default:
drivers/net/ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
drivers/net/ethernet/ti/davinci_cpdma.c:182:3: warning: passing argument 3 of 'dma_alloc_attrs' from incompatible pointer type [enabled by default]
drivers/net/ethernet/ti/davinci_cpdma.c: In function 'desc_phys':
drivers/net/ethernet/ti/davinci_cpdma.c:222:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/net/ethernet/ti/davinci_cpdma.c:223:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is needed when the cpsw driver is built as module.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts:
drivers/net/ethernet/freescale/fec_main.c
drivers/net/ethernet/renesas/sh_eth.c
net/ipv4/gre.c
The GRE conflict is between a bug fix (kfree_skb --> kfree_skb_list)
and the splitting of the gre.c code into seperate files.
The FEC conflict was two sets of changes adding ethtool support code
in an "!CONFIG_M5272" CPP protected block.
Finally the sh_eth.c conflict was between one commit add bits set
in the .eesr_err_check mask whilst another commit removed the
.tx_error_check member and assignments.
Signed-off-by: David S. Miller <davem@davemloft.net>
Since the DMA mapping may fail the caller should check the return value.
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Additional 4 bytes found in the skb is the CRC calculated by the
CPDMA hardware, check the CRC bit in CPDMA status field of
Descriptor and remove the CRC length from the skb. This extra
4 byte can be seen when capturing packets using tcpdump.
This has been tested in TI816x platform.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If compiled as modules each one of these modules is missing something.
With this patch the modules are loaded on demand and don't taint the
kernel due to license issues.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In case that we run into OOM during the allocation of the new rx-skb we
don't get one and we have one skb less than we used to have. If this
continues to happen then we end up with no rx-skbs at all.
This patch changes the following:
- if we fail to allocate the new skb, then we treat the currently
completed skb as the new one and so drop the currently received data.
- instead of testing multiple times if the device is gone we rely one
the status field which is set to -ENOSYS in case the channel is going
down and incomplete requests are purged.
cpdma_chan_stop() removes most of the packages with -ENOSYS. The
currently active packet which is removed has the "tear down" bit set.
So if that bit is set, we send ENOSYS as well otherwise we pass the
status bits which are required to figure out which of the two possible
just finished.
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The gfp_mask argument is not used in cpdma_chan_submit() and always set
to GFP_KERNEL even in atomic sections. This patch drops it since it is
unused.
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
__cpdma_chan_process() holds the lock with interrupts off (and its
caller as well), same goes for cpdma_ctlr_start(). With interrupts off,
jiffies will not make any progress and if the wait condition never gets
true we wait for ever.
Tgis patch adds a a simple udelay and counting down attempt.
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Converting more ARM platforms to multiplatform support. This time, OMAP
gets converted, which is a major step since this is by far the largest
platform in terms of code size. The same thing happens to the vt8500
platform.
Conflicts include:
* Two mach/uncompress.h files are removed, the changes made to them
elsewhere can be discarded now.
* Moving the OMAP4 irq_match array has context clashes with turning
omap4_sar_ram_init into an omap_early_initcall()
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUSUyOmCrR//JCVInAQI2zRAAnDUA3ufvANykRxNIII67D0u8XAgokzx6
hwq0ywwcQknd2aetN1khs2rY3sQ+T73CcsFzOR448YHjbWg1RCZlCzL89uUH6SdR
Bir/NC2jYkB1vSVB7krWhZzpeHNsFfWW1bCzwJzJfNmAZp64js3sOR1kRKjMpA2z
RGLktrFQ1JRKF/az+xnIsrleSnS2cQguPKIs5hYxPztzN/HdvbD7ZST0ttW7wqzg
C2AA5dnWs+C++pNXyfKlN+nL1CnyLWGXbuZUejUvAxYxgtyd/gC4/aTfNi8S9RNh
eiFTmVwl8lsWqPWx7yzyHk+p19x7ypfBgydLU/z4yC3asUJoN5jyCF6GSqzetHJB
jpDqTp3lQzIlJPgLryq07Xe38vUeVIKvV4e8ySOsSBlKr6aRl5684HJSCAZR9SFa
qzHavusA5JZJKf+94UbDCPNzSqzMQYnILA039M8ekvrMZhFG89St0+NLDaxVQfO/
OrTEnwth/TJBKvOUPIuamjZzHH/RiGkumWiKrEGKOlpwHPGtdglQeziJFo8pNkwR
hjtnwn4RPPK8FIl59fERFI1hRvhUlwuhYcA2R/WTjcZw2d+jwZPzhhun37dLMVlw
fk5lhz0GBaRUmua4xFqJTkpOwHf2l/9wbzhEpmL4c/ZSrtjYwfeL/tY6aT9e8MZK
INaMr7X2QTw=
=nl4h
-----END PGP SIGNATURE-----
Merge tag 'multiplatform' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC multiplatform support from Arnd Bergmann:
"Converting more ARM platforms to multiplatform support. This time,
OMAP gets converted, which is a major step since this is by far the
largest platform in terms of code size. The same thing happens to the
vt8500 platform."
* tag 'multiplatform' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
net: cwdavinci_cpdma: export symbols for cpsw
remoteproc: omap: depend on OMAP_MBOX_FWK
[media] davinci: do not include mach/hardware.h
ARM: OMAP2+: Make sure files with omap initcalls include soc.h
ARM: OMAP2+: Include soc.h to drm.c to fix compiling
ARM: OMAP2+: Fix warning for hwspinlock omap_postcore_initcall
ARM: multi_v7_defconfig: add ARCH_ZYNQ
ARM: multi_v7_defconfig: remove unnecessary CONFIG_GPIOLIB
arm: vt8500: Remove remaining mach includes
arm: vt8500: Convert debug-macro.S to be multiplatform friendly
arm: vt8500: Remove single platform Kconfig options
ARM: OMAP2+: Remove now obsolete uncompress.h and debug-macro.S
ARM: OMAP2+: Add minimal support for booting vexpress
ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support
ARM: OMAP2+: Disable code that currently does not work with multiplaform
ARM: OMAP2+: Add multiplatform debug_ll support
ARM: OMAP: Fix dmaengine init for multiplatform
ARM: OMAP: Fix i2c cmdline initcall for multiplatform
ARM: OMAP2+: Use omap initcalls
ARM: OMAP2+: Limit omap initcalls to omap only on multiplatform kernels
CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
used for rx and tx respectively.
Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With the support for ARM AM33xx in multiplatform kernels
in 3.9, an older bug appears in ARM allmodconfig:
When the cpsw driver is built as a module with cpdma
support enabled, it uses symbols that the cpdma driver
does not export.
Without this patch, building allmodconfig results in:
ERROR: "cpdma_ctlr_int_ctrl" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_control_set" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_ctlr_eoi" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org
cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
cpdma_ctlr_destroy() can safely be removed.
Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* Introduced parameter to add port number for directed packet in cpdma_chan_submit
* Source port detection macro with DMA descriptor status
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When there is heavy transmission traffic in the CPDMA, then Rx descriptors
memory is also utilized as tx desc memory looses all rx descriptors and the
driver stops working then.
This patch adds boundary for tx and rx descriptors in bd ram dividing the
descriptor memory to ensure that during heavy transmission tx doesn't use
rx descriptors.
This patch is already applied to davinci_emac driver, since CPSW and
davici_dmac shares the same CPDMA, moving the boundry seperation from
Davinci EMAC driver to CPDMA driver which was done in the following
commit
commit 86d8c07ff2
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue Jan 3 05:27:47 2012 +0000
net/davinci: do not use all descriptors for tx packets
The driver uses a shared pool for both rx and tx descriptors.
During open it queues fixed number of 128 descriptors for receive
packets. For each received packet it tries to queue another
descriptor. If this fails the descriptor is lost for rx.
The driver has no limitation on tx descriptors to use, so it
can happen during a nmap / ping -f attack that the driver
allocates all descriptors for tx and looses all rx descriptors.
The driver stops working then.
To fix this limit the number of tx descriptors used to half of
the descriptors available, the rx path uses the other half.
Tested on a custom board using nmap / ping -f to the board from
two different hosts.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
chan->count is used by rx channel. If the desc count is not updated by
the clean up loop in cpdma_chan_stop, the value written to the rxfree
register in cpdma_chan_start will be incorrect.
Signed-off-by: Tao Hou <hotforest@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the NULL test is necessary, the initialization involving a dereference of
the tested value should be moved after the NULL test.
The sematic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
type T;
expression E;
identifier i,fld;
statement S;
@@
- T i = E->fld;
+ T i;
... when != E
when != i
if (E == NULL) S
+ i = E->fld;
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a number of warnings such as:
CC drivers/net/ethernet/ti/davinci_cpdma.o
drivers/net/ethernet/ti/davinci_cpdma.c:279:1: warning: data definition
has no type or storage class
drivers/net/ethernet/ti/davinci_cpdma.c:279:1: warning: type defaults to
‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’
drivers/net/ethernet/ti/davinci_cpdma.c:279:1: warning: parameter names
(without types) in function declaration
Signed-off-by: Daniel Mack <zonque@gmail.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Christian Riesch <christian.riesch@omicron.at>
Signed-off-by: David S. Miller <davem@davemloft.net>
The davinci_emac driver can be a module, so the symbols
it needs from the cpdma driver must be exported.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
chan->chan_num is 0..CPDMA_MAX_CHANNELS-1 for tx channels and
CPDMA_MAX_CHANNELS..2*CPDMA_MAX_CHANNELS-1 for rx channels. However,
the rx and tx teardown registers expect zero based channel numbering.
Since the upper bits of the registers are reserved, the teardown also
worked before, this patch is cleanup only.
Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
Signed-off-by: David S. Miller <davem@davemloft.net>
Free the channel lock before calling __cpdma_chan_process to prevent
dead lock.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Tested-by: Ameya Palande <2ameya@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
