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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The ->probe() and ->remove() functions were missing the usual
__devinit and __devexit qualifiers.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree-discuss@lists.ozlabs.org
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It was only used in places where we could get the 'struct device *'
pointer through a different way.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The to_mv_xor_device() macro is not being used by the driver, so we
can get rid of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
'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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The usage of dev_printk() is deprecated, and the dev_err(), dev_info()
and dev_notice() functions should be used instead.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
From Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
arm: at91: mach header cleanup
This first patch serie start the cleanup of the header in mach
by moving all the platform data to include/linux/platform_data
and move the board header and drivers header next to them
* tag 'for-3.8-at91_header_clean' of git://github.com/at91linux/linux-at91:
arm: at91: move at91rm9200 rtc header in drivers/rtc
arm: at91: move reset controller header to arm/arm/mach-at91
arm: at91: move pit define to the driver
arm: at91: move at91_shdwc.h to arch/arm/mach-at91
arm: at91: move board header to arch/arm/mach-at91
arn: at91: move at91_tc.h to arch/arm/mach-at91
arm: at91 move at91_aic.h to arch/arm/mach-at91
arm: at91 move board.h to arch/arm/mach-at91
arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
arm: at91: drop machine defconfig
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From Michal Simek:
* 'arm-next' of git://git.xilinx.com/linux-xlnx:
zynq: move static peripheral mappings
zynq: remove use of CLKDEV_LOOKUP
zynq: use pl310 device tree bindings
zynq: use GIC device tree bindings
+ Linux 3.7-rc3
This code will be eventually in drivers, and for the
code in the drivers we don't want to have any cpu_is_omap
usage. Those macros should be private to arch/arm/mach-omap1
and arch/arm/mach-omap2.
To fix this, let's move the define for dma_omap2plus()
to dma-omap.h, and use the existing dma_attr passed in
the platform_data as the revision registers are what they
are.
Note that we can now also remove the relative includes
introduced by the recent clean-up patches.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Pull slave-dmaengine fixes from Vinod Koul:
"Three fixes for slave dmanegine.
Two are for typo omissions in sifr dmaengine driver and the last one
is for the imx driver fixing a missing unlock"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: sirf: fix a typo in moving running dma_desc to active queue
dmaengine: sirf: fix a typo in dma_prep_interleaved
dmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc()
list_move_tail(&schan->queued, &schan->active) makes the list_empty(schan->queued)
undefined, we either should change it to:
list_move_tail(schan->queued.next, &schan->active)
or
list_move_tail(&sdesc->node, &schan->active)
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Drivers should not use cpu_is_omap or cpu_class_is_omap macros,
they should be private to the platform init code. And we'll be
removing plat/cpu.h and only have a private soc.h for the
arch/arm/*omap* code.
This patch is intended as preparation for the core omap changes
and removes the need to include plat/cpu.h from several drivers.
This is needed for the ARM common zImage support.
These changes are OK to do because:
- omap-rng.c does not need plat/cpu.h
- omap-aes.c and omap-sham.c get the proper platform_data
passed to them so they don't need extra checks in the driver
- omap-dma.c and omap-pcm.c can test the arch locally as
omap1 and omap2 cannot be compiled together because of
conflicting compiler flags
Cc: Deepak Saxena <dsaxena@plexity.net>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkatraman S <svenkatr@ti.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: linux-kernel@vger.kernel.org
[tony@atomide.com: mmc changes folded in to an earlier patch]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Move plat/dma.h to plat-omap/dma-omap.h as part of single
zImage work
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
It changes the driver to use platform_device_id rather than cpu_is_xxx
to determine the controller type, and updates the platform code
accordingly.
As the result, mach/hardware.h inclusion gets removed from the driver.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Pull slave-dmaengine updates from Vinod Koul:
"This time we have Andy updates on dw_dmac which is attempting to make
this IP block available as PCI and platform device though not fully
complete this time.
We also have TI EDMA moving the dma driver to use dmaengine APIs, also
have a new driver for mmp-tdma, along with bunch of small updates.
Now for your excitement the merge is little unusual here, while
merging the auto merge on linux-next picks wrong choice for pl330
(drivers/dma/pl330.c) and this causes build failure. The correct
resolution is in linux-next. (DMA: PL330: Fix build error) I didn't
back merge your tree this time as you are better than me so no point
in doing that for me :)"
Fixed the pl330 conflict as in linux-next, along with trivial header
file conflicts due to changed includes.
* 'next' of git://git.infradead.org/users/vkoul/slave-dma: (29 commits)
dma: tegra: fix interrupt name issue with apb dma.
dw_dmac: fix a regression in dwc_prep_dma_memcpy
dw_dmac: introduce software emulation of LLP transfers
dw_dmac: autoconfigure data_width or get it via platform data
dw_dmac: autoconfigure block_size or use platform data
dw_dmac: get number of channels from hardware if possible
dw_dmac: fill optional encoded parameters in register structure
dw_dmac: mark dwc_dump_chan_regs as inline
DMA: PL330: return ENOMEM instead of 0 from pl330_alloc_chan_resources
DMA: PL330: Remove redundant runtime_suspend/resume functions
DMA: PL330: Remove controller clock enable/disable
dmaengine: use kmem_cache_zalloc instead of kmem_cache_alloc/memset
DMA: PL330: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
dma: tegra: use list_move_tail instead of list_del/list_add_tail
mxs/dma: Enlarge the CCW descriptor area to 4 pages
dw_dmac: utilize slave_id to pass request line
dmaengine: mmp_tdma: add dt support
dmaengine: mmp-pdma support
spi: davici - make davinci select edma
...
Pull sound updates from Takashi Iwai:
"This contains pretty many small commits covering fairly large range of
files in sound/ directory. Partly because of additional API support
and partly because of constantly developed ASoC and ARM stuff.
Some highlights:
- Introduced the helper function and documentation for exposing the
channel map via control API, as discussed in Plumbers; most of PCI
drivers are covered, will follow more drivers later
- Most of drivers have been replaced with the new PM callbacks (if
the bus is supported)
- HD-audio controller got the support of runtime PM and the support
of D3 clock-stop. Also changing the power_save option in sysfs
kicks off immediately to enable / disable the power-save mode.
- Another significant code change in HD-audio is the rewrite of
firmware loading code. Other than that, most of changes in
HD-audio are continued cleanups and standardization for the generic
auto parser and bug fixes (HBR, device-specific fixups), in
addition to the support of channel-map API.
- Addition of ASoC bindings for the compressed API, used by the
mid-x86 drivers.
- Lots of cleanups and API refreshes for ASoC codec drivers and
DaVinci.
- Conversion of OMAP to dmaengine.
- New machine driver for Wolfson Microelectronics Bells.
- New CODEC driver for Wolfson Microelectronics WM0010.
- Enhancements to the ux500 and wm2000 drivers
- A new driver for DA9055 and the support for regulator bypass mode."
Fix up various arm soc header file reorg conflicts.
* tag 'sound-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (339 commits)
ALSA: hda - Add new codec ALC283 ALC290 support
ALSA: hda - avoid unneccesary indices on "Headphone Jack" controls
ALSA: hda - fix indices on boost volume on Conexant
ALSA: aloop - add locking to timer access
ALSA: hda - Fix hang caused by race during suspend.
sound: Remove unnecessary semicolon
ALSA: hda/realtek - Fix detection of ALC271X codec
ALSA: hda - Add inverted internal mic quirk for Lenovo IdeaPad U310
ALSA: hda - make Realtek/Sigmatel/Conexant use the generic unsol event
ALSA: hda - make a generic unsol event handler
ASoC: codecs: Add DA9055 codec driver
ASoC: eukrea-tlv320: Convert it to platform driver
ALSA: ASoC: add DT bindings for CS4271
ASoC: wm_hubs: Ensure volume updates are handled during class W startup
ASoC: wm5110: Adding missing volume update bits
ASoC: wm5110: Add OUT3R support
ASoC: wm5110: Add AEC loopback support
ASoC: wm5110: Rename EPOUT to HPOUT3
ASoC: arizona: Add more clock rates
ASoC: arizona: Add more DSP options for mixer input muxes
...
Do the same as commit a03a202e95 ("dmaengine: failure to get a
specific DMA channel is not critical") to get rid of the following
messages during kernel boot:
dmaengine_get: failed to get dma1chan0: (-22)
dmaengine_get: failed to get dma1chan1: (-22)
dmaengine_get: failed to get dma1chan2: (-22)
dmaengine_get: failed to get dma1chan3: (-22)
..
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
