- 17 Oct, 2012 14 commits
-
-
Tony Lindgren authored
We cannot keep this in plat as it causes problems with the ARM single zImage support. Cc: Felipe Balbi <balbi@ti.com> Cc: linux-pcmcia@lists.infradead.org Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
There's no need to have this file in plat/fpga.h. We can make it local to plat-omap replacing fpga_read/write functions directly with readb/writeb as that's how they are already defined in fpga.h. Note that 2420 based H4 is also using the fpga, so let's keep the led support around in plat-omap until we flip over mach-omap2 to device tree. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: linux-fbdev@vger.kernel.org Cc: Felipe Balbi <balbi@ti.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Conflicts: arch/arm/mach-omap2/board-omap3logic.c arch/arm/mach-omap2/gpmc.c drivers/media/platform/omap/omap_vout.c drivers/media/platform/omap/omap_vout_vrfb.c
-
Tony Lindgren authored
Conflicts: arch/arm/mach-omap1/devices.c arch/arm/mach-omap2/omap_hwmod_33xx_data.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c drivers/mmc/host/omap.c
-
Tony Lindgren authored
Conflicts: arch/arm/mach-omap2/board-3430sdp.c arch/arm/mach-omap2/board-h4.c arch/arm/mach-omap2/board-rx51-peripherals.c arch/arm/mach-omap2/board-rx51.c arch/arm/mach-omap2/pm34xx.c drivers/mtd/nand/omap2.c drivers/mtd/onenand/omap2.c
-
Paul Walmsley authored
Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in cleaning out arch/arm/plat-omap/, as his upstreams request. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> [tony@atomide.com: updated to remove rotate macros] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Conflicts: drivers/crypto/omap-aes.c drivers/crypto/omap-sham.c drivers/dma/omap-dma.c
-
Tony Lindgren authored
-
Tomi Valkeinen authored
Replace cpu_is_*() check with omap_vrfb_supported(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Add an exported function omap_vrfb_supported() which returns true if the vrfb driver has been loaded succesfully. This can be used to decide if VRFB can be used or not. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Now that VRFB driver handles its registers independently, we can remove the VRFB related code from OMAP's sdrc. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
Tomi Valkeinen authored
Now that vrfb driver is not omap dependent anymore, we can move vrfb.h from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
-
Tomi Valkeinen authored
This patch converts vrfb library into a platform device, in an effort to remove omap dependencies. The platform device is registered in arch/arm/plat-omap/fb.c and assigned resources depending on whether running on omap2 or omap3. The vrfb driver will parse those resources and use them to access vrfb configuration registers and the vrfb virtual rotation areas. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
Tomi Valkeinen authored
cpu_is_* calls are no longer used in omapdss, so the includes for <plat/cpu.h> can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
- 16 Oct, 2012 6 commits
-
-
git://gitorious.org/x0148406-public/linux-kernelTony Lindgren authored
Merge tag 'gpmc-czimage' of git://gitorious.org/x0148406-public/linux-kernel into omap-for-v3.8/cleanup-headers-gpmc gpmc cleanup for common ARM zImage
-
Tomi Valkeinen authored
Use omapdss_version in hdmi.c to select the proper hdmi features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Use omapdss_version in dss.c to select the proper dss features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Use omapdss_version in dispc.c to select the proper dispc features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Pass the omapdss_version to dss_features.c and use it to select the proper dss features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Add new enum, omapdss_version, that is used to tell which DSS hardware version the SoC has. This enum is initialized during platform init, and passed in the platform data to omapdss driver. Note that the versions are not "continuous", that is, you cannot check if the version is less or greater than something, but you need to check for exact version match. In other words, this is invalid: /* test if DSS is 3630 or earlier */ if (ver <= OMAPDSS_VER_OMAP3630) ... Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
- 15 Oct, 2012 20 commits
-
-
Tony Lindgren authored
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>
-
Paul Walmsley authored
The DSPBridge driver includes arch/arm/plat-omap/include/plat/clock.h. All of the <plat/ ...> includes are causing problems with the ARM single image kernel effort. Remove this one. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Lokesh Vutla authored
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>
-
Lokesh Vutla authored
Similar to omap1, some of the omap2+ dma channel definitions are used by some drivers. For moving omap2+ dma channel definitions to mach-omap2/, the used ones should be defined locally to driver. Drivers can eliminate it using DT, platform data, or IORESOURCE_DMA And moving omap2+ DMA channel definitions to mach-omap2 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Lokesh Vutla authored
Some of the omap1 dma channel definitions are used by some drivers. For moving omap1 dma channel definitions to mach-omap1/, the used ones should be defined locally to driver. Driver can eliminate it by using DT, platform data, or IORESOURCE_DMA. And moving OMAP1 DMA channel definitions to mach-omap1 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Lokesh Vutla authored
None of the DMA channel definitions defined in plat/dma-44xx.h are used. So removing it. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This is needed for the ARM common zImage support. We can use the existing slot features to pass omap1 specific options to the driver. For omap2 we don't want to pass anything new as that will be eventually moved to use device tree based init. Note that this patch depends on earlier patch that moves plat/mmc.h into include/linux/platform_data. Cc: linux-mmc@vger.kernel.org Cc: Venkatraman S <svenkatr@ti.com> Acked-by: Chris Ball <cjb@laptop.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
We need to remove this from plat for ARM common zImage support. Also remove includes not needed by the omap_hsmmc.c driver. Cc: linux-mmc@vger.kernel.org Acked-by: Chris Ball <cjb@laptop.org> Acked-by: Venkatraman S <svenkatr@ti.com> [tony@atomide.com: fold in removal of unused driver includes] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Afzal Mohammed authored
Requirement of gpmc header outside of mach-omap2 has been cutoff, move gpmc header file in plat-omap folder to local mach-omap2 folder Objective - common zImage participation of omap Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
nand driver handles gpmc-nand block fully, hence no more users for these exported nand functions, remove it. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
gpmc-nand bch registers are now available in driver, make use of it to handle bch[48] instead of relying on gpmc exported functions. And so nand driver no longer needs gpmc header, remove it. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
Update helper function that provides gpmc-nand register details for nand driver with bch register information. Using this nand driver can be made self sufficient to handle remaining gpmc-nand operations by itself instead of relying on gpmc exported nand functions. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
Capability of bch schemes could be discovered using soc revision checks. If soc revision indicates that selected ecc scheme is not supported bail out. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
Bring onto driver the macros defined in gpmc.h that are not necessary outside driver, helps in removing inclusion of gpmc.h too. Also remove GPMC prefix on those macros to make clear it's independence with gpmc header. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
For common arm zImage existing nand header file in platform specific location was moved to generic platform data location, but it contained more than platform data, remove it. New local header has been created for exposing functions. Also move gpmc-nand platform data to platform header meant for nand from gpmc header file Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
For common arm zImage existing onenand header file in platform specific location was moved to generic platform data location, but it contained more than platform data, remove it. New local header has been created for exposing functions. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
platform data now contains a field to indicate whether soc belongs to omap34xx family, use it instead of cpu_is_* check. This helps in removing dependency of platform specific header file - cpu.h Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
onenand driver needs to know whether soc is falling under 34xx family to properly handle onenand. But driver is not supposed to do cpu_is_* check, hence educate platform data with this information. Driver can make use of it to avoid cpu_is_* check. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
Now that gpmc-nand registers are available in driver, use it to read nand data. "65b97cf6 mtd: nand: omap2: handle nand on gpmc" modified all other instances. After initial versions of that patch, a new change added reading nand data using gpmc exposed function. In the final version this change was not taken care. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
memory as is now obtained via resource, upon freeing use resource size. This also helps get rid of one macro. Signed-off-by: Afzal Mohammed <afzal@ti.com>
-