19 Sep, 2014
1 commit
-
We're moving to the dmaengine API, so let's remove the unused
pieces of the omap legacy DMA code to make sure we don't get
any new users for these:omap_set_dma_color_mode
omap_set_dma_src_index
omap_set_dma_dest_index
omap_dma_unlink_lch
omap_clear_dma
omap_dma_running
omap_dma_set_prio_lch
omap_set_dma_dst_endian_type
omap_set_dma_src_endian_type
omap_get_dma_index
omap_dma_disable_irq
omap_request_dma_chain
omap_free_dma_chain
omap_dma_chain_a_transfer
omap_start_dma_chain_transfers
omap_stop_dma_chain_transfers
omap_get_dma_chain_index
omap_get_dma_chain_dst_pos
omap_get_dma_chain_src_pos
omap_modify_dma_chain_params
omap_dma_chain_statusCc: Russell King
Signed-off-by: Tony Lindgren
22 Jul, 2014
1 commit
-
we have currently 2 DMA drivers that try to co-exist.
drivers/dma/omap-dma.c which registers it's own IRQ and is device tree
aware and uses arch/arm/plat-omap/dma.c instance created by
arch/arm/mach-omap2/dma.c to maintain channel usage (omap_request_dma).Currently both try to register interrupts and mach-omap2/plat-omap dma.c
attempts to use the IRQ number registered by hwmod to register it's own
interrupt handler.Now, there is no reasonable way of static allocating DMA irq in GIC
SPI when we use crossbar. However, since the dma_chan structure is
freed as a result of IRQ not being present due to devm allocation,
maintaining information of channel by platform code fails at a later
point in time when that region of memory is reused.So, if hwmod does not indicate an IRQ number, then, assume that
dma-engine will take care of the interrupt handling.Signed-off-by: Nishanth Menon
Signed-off-by: Tony Lindgren
11 Jun, 2014
1 commit
-
Pull MMC update from Chris Ball:
"MMC highlights for 3.16:Core:
- support HS400 mode of eMMC 5.0, via DT bindings mmc-hs400-1_{2,8}v
- if card init at 3.3v doesn't work, try 1.8v and 1.2v tooDrivers:
- moxart: New driver for MOXA ART SoCs
- rtsx_usb_sdmmc: New driver for Realtek USB card readers
- sdhci: Large rework around IRQ/regulator handling, remove card_tasklet
- sdhci-pci-o2micro: Add SeaBird SeaEagle SD3 support
- sunxi: New driver for Allwinner sunxi SoCs
- usdhi6rol0: New driver for Renesas SD/SDIO controller"* tag 'mmc-updates-for-3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (95 commits)
mmc: sdhci-s3c: use mmc_of_parse and remove the card_tasklet
mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
mmc: sdhci-of-esdhc: Fixup compile error
mmc: tegra: fix reporting of base clock frequency
mmc: tegra: disable UHS modes
mmc: sdhci-dove: use mmc_of_parse() and remove card_tasklet CD handler
MAINTAINERS: mmc: Add path to git tree
mmc: dove: fix missing MACH_DOVE dependency
mmc: sdhci: SD tuning is broken for some controllers
mmc: sdhci-esdhc-imx: fix mmc ddr mode regression issue
mmc: sdhci-pci-o2micro: Add SeaBird SeaEagle SD3 support
mmc: omap_hsmmc: split omap-dma header file
mmc: omap_hsmmc: fix cmd23 multiblock read/write
mmc: omap_hsmmc: use devm_ioremap_resource
mmc: omap_hsmmc: use devm_request_threaded_irq
mmc: omap_hsmmc: use devm_request_irq
mmc: omap_hsmmc: use devm_clk_get
mmc: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
mmc: wmt-sdmmc: Use GFP_KERNEL instead of hard-coded value
mmc: omap: Use DIV_ROUND_UP instead of open coded
...
05 Jun, 2014
1 commit
-
Pull main fbdev changes from Tomi Valkeinen:
"Mainly fixes and small improvements. The biggest change seems to be
backlight control support for mx3fb"* tag 'fbdev-main-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (31 commits)
drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap
video: fbdev: s3fb.c: Fix for possible null pointer dereference
video: fbdev: grvga.c: Fix for possible null pointer dereference
matroxfb: perform a dummy read of M_STATUS
video: of: display_timing: fix default native-mode setting
video: delete unneeded call to platform_get_drvdata
video: mx3fb: Add backlight control support
video: omap: delete support for early fbmem allocation
video: of: display_timing: remove two unsafe error messages
fbdev: fbmem: remove positive test on unsigned values
fbcon: Fix memory leak in con2fb_release_oldinfo()
video: Kconfig: Add a dependency to the Goldfish framebuffer driver
video: exynos: Add a dependency to the menu
video: mx3fb: Use devm_kzalloc
video/nuc900: allow modular build
video: atmel needs FB_BACKLIGHT
video: export fb_prepare_logo
video/mbx: fix building debugfs support
video/omap: fix modular build
video: clarify I2C dependencies
...
22 May, 2014
1 commit
-
moving dmaengine consumer specific function to omap-dmaengine.h
to Resolve build failure seen with sh-allmodconfig:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1Cc: Russell King - ARM Linux
Cc: Tony Lindgren
Signed-off-by: Balaji T K
Acked-by: Tony Lindgren
Signed-off-by: Ulf Hansson
Signed-off-by: Chris Ball
21 May, 2014
1 commit
-
It is not possible to reference the omap_dma_filter_fn filter
function from a built-in driver if the dmaengine driver itself
is a loadable module, which is a valid configuration otherwise.This provides only the dummy alternative if the function
is referenced by a built-in driver to allow a successful
build. The filter function is only required by ATAGS based
platforms, which will continue to be broken after this change
for the bogus configuration. When booting from DT, with the
dma channels correctly listed there, it will work fine.Signed-off-by: Arnd Bergmann
Acked-by: Tony Lindgren
Cc: Russell King
Cc: Vinod Koul
Cc: dmaengine@vger.kernel.org
Signed-off-by: Vinod Koul
09 May, 2014
1 commit
-
The framebuffer layer can be a loadable module, which forces
omapfb to be a module as well. However, this breaks the lcd
drivers, which are linked into the omapfb driver but each
have their own module_init() function. To solve this,
we split out the lcd drivers into separate modules and
export omapfb_register_panel, which is the only interface
required between the main omapfb driver and the lcd panel
drivers.We also have to introduce a new Kconfig symbol for H3, since
that lcd driver has a dependency on TPS65010, which we can
express better in Kconfig than Makefile syntax.Signed-off-by: Arnd Bergmann
Signed-off-by: Peter Griffin
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Tomi Valkeinen
04 Apr, 2014
6 commits
-
Export the DMA register information from the SoC specific data, such
that we can access the registers directly in omap-dma.c, mapping the
register region ourselves as well.Rather than calculating the DMA channel register in its entirety for
each access, we pre-calculate an offset base address for the allocated
DMA channel and then just use the appropriate register offset.Acked-by: Tony Lindgren
Acked-by: Vinod Koul
Signed-off-by: Russell King -
This really needs to be there, because otherwise the plat-omap code can
kfree() this data structure, and then re-use the pointer later.Acked-by: Tony Lindgren
Signed-off-by: Russell King -
We can do much better with this by using a structure to describe each
register, rather than code.Acked-by: Tony Lindgren
Signed-off-by: Russell King -
The disable_irq_lch method is never actually used, so there's not much
point it existing; remove it.Acked-by: Tony Lindgren
Signed-off-by: Russell King -
Program the transfer parameters directly into the hardware, rather
than using the functions in arch/arm/plat-omap/dma.c.Acked-by: Tony Lindgren
Acked-by: Vinod Koul
Signed-off-by: Russell King -
Provide and use a hook to obtain the underlying DMA platform operations
so that omap-dma.c can access the hardware more directly without
involving the legacy DMA driver.Acked-by: Tony Lindgren
Acked-by: Vinod Koul
Signed-off-by: Russell King
01 Dec, 2012
1 commit
-
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 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
cc: Kevin Hilman
cc: "Benoît Cousson"
cc: Herbert Xu
cc: "David S. Miller"
cc: Vinod Koul
cc: Dan Williams
cc: Mauro Carvalho Chehab
cc: Laurent Pinchart
cc: Guennadi Liakhovetski
cc: David Woodhouse
cc: Kyungmin Park
cc: Greg Kroah-Hartman
cc: Tomi Valkeinen
cc: Florian Tobias Schandinat
cc: Hans Verkuil
cc: Vaibhav Hiremath
cc: Lokesh Vutla
cc: Rusty Russell
cc: Artem Bityutskiy
cc: Afzal Mohammed
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: Felipe Balbi
Signed-off-by: Tony Lindgren
31 Jul, 2012
1 commit
-
Tested-by: Tony Lindgren
Signed-off-by: Russell King