- 08 1月, 2013 4 次提交
-
-
由 Linus Walleij 提交于
Remove hard-coded target addresses altogether. Skip the prefix "runtime_*" from the variables, since all of these are now runtime and their names are unique enough already. Acked-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Nowadays the clients should use the dmaengine framework to tell the DMA driver what target address to use, so delete these addresses, they are for an out-of-tree driver anyway. Acked-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
We're only ever going to support the U300 with this driver so skip the separation of platform data from driver, and push it down into the driver itself. Acked-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This extracts the platform data that we will keep generic from the U300 platform and associates it with the COH901318 driver in <linux/platform_data/dma-coh901318.h>. Acked-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 18 12月, 2012 2 次提交
-
-
由 Andy Shevchenko 提交于
The kernel emits a warning if CONFIG_DMA_API_DEBUG=y: WARNING: at lib/dma-debug.c:933 check_unmap+0x5d6/0x6ac() dw_dmac dw_dmac.0: DMA-API: device driver failed to check map error[device address=0x0000000035698305] [size=14365 bytes] [mapped as single] Fix this by adding the required checking of the dma_map_single() return value. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Cc: Vinod Koul <vinod.koul@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andy Shevchenko 提交于
The unmap_src() and unmap_dst() will be used later as well. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Cc: Vinod Koul <vinod.koul@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 01 12月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
Based on earlier discussions[1] we attempted to find a suitable location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion to dmaengine is complete. Unfortunately that was before I was able to try to test compile of the ARM multiplatform builds for omap2+, and the end result was not very good. So I'm creating yet another all over the place patch to cut the last dependency for building omap2+ for ARM multiplatform. After this, we have finally removed the driver dependencies to the arch/arm code, except for few drivers that are being worked on. The other option was to make the <plat-omap/dma-omap.h> path to work, but we'd have to add some new header directory to for multiplatform builds. Or we would have to manually include arch/arm/plat-omap/include again from arch/arm/Makefile for omap2+. Neither of these alternatives sound appealing as they will likely lead addition of various other headers exposed to the drivers, which we want to avoid for the multiplatform kernels. Since we already have a minimal include/linux/omap-dma.h, let's just use that instead and add a note to it to not use the custom omap DMA functions any longer where possible. Note that converting omap DMA to dmaengine depends on dmaengine supporting automatically incrementing the FIFO address at the device end, and converting all the remaining legacy drivers. So it's going to be few more merge windows. [1] https://patchwork.kernel.org/patch/1519591/# cc: Russell King <linux@arm.linux.org.uk> cc: Kevin Hilman <khilman@ti.com> cc: "Benoît Cousson" <b-cousson@ti.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: "David S. Miller" <davem@davemloft.net> cc: Vinod Koul <vinod.koul@intel.com> cc: Dan Williams <djbw@fb.com> cc: Mauro Carvalho Chehab <mchehab@infradead.org> cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> cc: David Woodhouse <dwmw2@infradead.org> cc: Kyungmin Park <kyungmin.park@samsung.com> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Tomi Valkeinen <tomi.valkeinen@ti.com> cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> cc: Hans Verkuil <hans.verkuil@cisco.com> cc: Vaibhav Hiremath <hvaibhav@ti.com> cc: Lokesh Vutla <lokeshvutla@ti.com> cc: Rusty Russell <rusty@rustcorp.com.au> cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> cc: Afzal Mohammed <afzal@ti.com> cc: linux-crypto@vger.kernel.org cc: linux-media@vger.kernel.org cc: linux-mtd@lists.infradead.org cc: linux-usb@vger.kernel.org cc: linux-fbdev@vger.kernel.org Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 29 11月, 2012 2 次提交
-
-
由 Bill Pemberton 提交于
CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: NBill Pemberton <wfp5p@virginia.edu> Cc: Li Yang <leoli@freescale.com> Cc: Zhang Wei <zw@zh-kernel.org> Cc: Barry Song <baohua.song@csr.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Bill Pemberton 提交于
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: NBill Pemberton <wfp5p@virginia.edu> Acked-by: NBarry Song <baohua.song@csr.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 11月, 2012 4 次提交
-
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
- 20 11月, 2012 26 次提交
-
-
由 Andrew Lunn 提交于
The dmatest module for DMA engines calls device_control(dtc->chan, DMA_TERMINATE_ALL, 0); after completing the tests. The documentation in include/linux/dmaengine.h suggests this function is optional and dma_async_device_register() also does not BUG_ON() when not passed a function. However, dmatest is not the only code in the kernel unconditionally calling device_control. So add an implementation indicating all operations are not implemented. Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The ->probe() and ->remove() functions were missing the usual __devinit and __devexit qualifiers. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
This patch finally adds a Device Tree binding to the mv_xor driver. Thanks to the previous cleanup patches, the Device Tree binding is relatively simply: one DT node per XOR engine, with sub-nodes for each XOR channel of the XOR engine. The binding obviously comes with the necessary documentation. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: devicetree-discuss@lists.ozlabs.org
-
由 Thomas Petazzoni 提交于
Even though the driver cannot be unloaded at the moment, it is still good to properly free the IRQ handlers in the channel removal function. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The pool_size is always PAGE_SIZE, and since it is a software configuration paramter (and not a hardware description parameter), we cannot make it part of the Device Tree binding, so we'd better remove it from the platform_data as well. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
There is no need for the platform_data to give this ID, it is simply the channel number, so we can compute it inside the driver when registering the channels. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The backpointer from mv_xor_chan to mv_xor_device is now useless, get rid of it. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
Now that mv_xor_device is no longer used to designate the per-channel DMA devices, use it know to designate the XOR engine themselves (currently composed of two XOR channels). So, now we have the nice organization where: - mv_xor_device represents each XOR engine in the system - mv_xor_chan represents each XOR channel of a given XOR engine Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
Even though the DMA engine infrastructure has support for multiple channels per device, the mv_xor driver registers one DMA engine device for each channel, because the mv_xor channels inside the same XOR engine have different capabilities, and the DMA engine infrastructure only allows to express capabilities at the DMA engine device level. The mv_xor driver has therefore been registering one DMA engine device and one DMA engine channel for each XOR channel since its introduction in the kernel. However, it kept two separate internal structures, mv_xor_device and mv_xor_channel, which didn't make a lot of sense since there was a 1:1 mapping between those structures. This patch gets rid of this duplication, and merges everything into the mv_xor_chan structure. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
In preparation for the removal of the mv_xor_device structure, we directly pass mv_xor_chan pointers to the self-test functions included in the driver. These functions were anyway selecting the first (and only channel) available in each DMA device, so the behaviour is unchanged. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The mv_xor_device structure embeds a 'struct dma_device', which is named 'common', a not very meaningful name. Rename it to 'dmadev', which will help avoid confusions later as we merge the mv_xor_device and mv_xor_chan structures together. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The mv_xor_chan structure embeds a 'struct dma_chan', which is named 'common', a not very meaningful name. Rename it to 'dmachan', which will help avoid confusions later as we merge the mv_xor_device and mv_xor_chan structures together. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
It was only used in places where we could get the 'struct device *' pointer through a different way. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
In many place, we need to get the 'struct device *' pointer from a 'struct mv_chan *', so we add a helper that makes this a bit easier. It will also help reducing the change noise in further patches. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
In mv_xor_memcpy_self_test() and mv_xor_xor_self_test(), all DMA functions are called by passing dma_chan->device->dev as the 'device *', except the calls to dma_sync_single_for_cpu() which uselessly goes through mv_chan->device->pdev->dev. Simplify this by using dma_chan->device->dev direclty in dma_sync_single_for_cpu() calls. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The to_mv_xor_device() macro is not being used by the driver, so we can get rid of it. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The 'shared' word no longer makes sense in a number of places as we renamed the 'mv_xor_shared' driver to 'mv_xor'. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
Since we got rid of the per-XOR channel 'mv_xor' driver, now the per-XOR engine driver that used to be called 'mv_xor_shared' can simply be named 'mv_xor'. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
'struct mv_xor_shared_platform_data' used to be the platform_data structure for the 'mv_xor_shared', but this driver is going to be renamed simply 'mv_xor', so also rename its platform_data structure accordingly. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
mv_xor_platform_data used to be the platform_data structure associated to the 'mv_xor' driver. This driver no longer exists, and this data structure really contains the properties of each XOR channel part of a given XOR engine. Therefore 'struct mv_xor_channel_data' is a more appropriate name. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
Now that XOR channels are directly registered by the main 'mv_xor_shared' device ->probe() function and all users of the 'mv_xor' device have been removed, we can get rid of the latter. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
Extend the XOR engine driver (currently called "mv_xor_shared") so that XOR channels can be passed in the platform_data structure, and be registered from there. This will allow the users of the driver to be converted to the single platform_driver variant of the mv_xor driver. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
Instead of doing the initialization/cleanup of the XOR channels directly in the ->probe() and ->remove() hooks, we create separate utility functions mv_xor_channel_add() and mv_xor_channel_remove(). This will allow to easily introduce in a future patch a different way of registering XOR channels: instead of having one platform_device per channel, we'll trigger the registration of all XOR channels of a given XOR engine directly from the XOR engine ->probe() function. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The driver currently pokes into the platform_data structure during its normal operation to get the pool_size value. Poking into the platform_data structure is not nice when moving to the Device Tree, so this commit adds a new pool_size field in the mv_xor_device structure, which gets initialized at ->probe() time. The driver then uses this field instead of the platform_data. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Thomas Petazzoni 提交于
The usage of dev_printk() is deprecated, and the dev_err(), dev_info() and dev_notice() functions should be used instead. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
- 15 11月, 2012 1 次提交
-
-
由 Alexander Duyck 提交于
I have encountered several systems that have an invalid tag map. This invalid tag map results in only two tags being generated 0x1F which is usually applied to the first core in a Hyper-threaded pair and 0x00 which is applied to the second core in a Hyper-threaded pair. The net result of all this is that DCA causes significant cache thrash because the 0x1F tag will send traffic to the second socket, which the 0x00 tag will not DCA tag the frame resulting in no benefit. For now the best solution from the driver's perspective is to just disable DCA if the tag map is invalid. The correct solution for this would be to have the BIOS on affected systems updated so that the correct tags are generated for a given APIC ID. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Tested-by: NStephen Ko <stephen.s.ko@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-