* fix regulator support for the i.MX27 3ds
From: Sascha Hauer @ 2011-01-07 16:11 UTC (permalink / raw)
To: linux-arm-kernel
The mc13783 regulator names have been changed. Currently the 3ds board
is broken in -next.
Sascha
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Grant Likely @ 2011-01-07 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106115026.GA18081@www.tglx.de>
On Thu, Jan 6, 2011 at 4:50 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> * Russell King - ARM Linux | 2011-01-06 11:12:31 [+0000]:
>
>>Please see my email where I described the lifetime rules. ?Let's say
>>your module is removed. ?In doing so, you call platform_device_unregister()
>>followed by kfree(). ?After this, your module is removed from the system
>>and the memory backing the module code is unmapped.
>>
>>If something holds a reference to the platform device, then that's just
>>waiting for an OOPS to happen. ?When those references are finally given
>>up, your release function will be called - but the code has been unmapped.
>
> I got that. That is why I'm going go to use allready provided functions
> (platform_device_register_resndata() in this case) so I'm no longer
> allocating any memory. So I'm only holding a struct which is pointing to
> the platform_device. Everything else is unmapped by the driver core.
>
> So I just have just to of_device_node_put() myself. Hmmm.
>
> Grant, who is calling of_device_node_put() on nodes assigned in
> of_register_spi_devices() & of_i2c_register_devices()? I can't find any
> reference. The spi part is not putting the node or removing the irq
> mapping in error case so I guess there must be some magic triggered
> somewhere.
No, it is just a deficiency on the spi and i2c dt support at the
moment. It needs to be added. However, since the flattree is
currently entirely static (nodes don't get freed) the mismatched
reference counting isn't immediately an issue. However, it will
become a problem when add-in boards (like xilinx fpgas) start using
the dt to describe internal devices.
> Also adap->dev.of_node and master->dev.of_node has to be
> non-null for the device assignment to work. Who is putting these nodes
> back? I see drivers (i2c-cpm & i2c-mpc) taking refs but I fail to find a
> place where it is put back.
Same issue.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v2 0/3] add CNS3xxx AHCI support
From: Anton Vorontsov @ 2011-01-07 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D264DA4.6040308@pobox.com>
On Thu, Jan 06, 2011 at 06:17:56PM -0500, Jeff Garzik wrote:
> >[...]
> >>>It is overkill to rename the entirety of ahci_platform just for one override
> >>>function.
> >>>This sort of thing I would have expected to be added directly to
> >>>ahci_platform.c.
> >>It might be overkill for only one controller. but it is more clean and
> >>readable to have different SoC specific changes in separate files,
> >>especially when more SoCs need to make similar changes.
> >
> >I think that renaming the file is not necessary. You can just
> >rename the module in the makefile.
> >
> >Personally I like the current approach more than putting
> >controller-specific fixups directly into ahci_platform.
>
> My main objection is the renaming. If ahci_platform wants to export
> some symbols for SoC modules like ahci_platform_cns, that's ok.
>
> In general, follow the library approach rather than linking modules
> together in strange ways.
In ahci_platform case there's almost nothing to factor out to a
library. Each platform just needs its own small "fixups" that we
normally pass via platform data.
We would happily pass them via platform data, and initially Mac
did exactly this, see:
http://ns3.spinics.net/lists/linux-ide/msg39554.html
You may notice that all platform-specific quirks are in the
platform code, which is neat. But there is a problem: once
the platform code needs to use libata, then we have to
build libata into the kernel (no modules possible), i.e.
http://ns3.spinics.net/lists/linux-ide/msg39656.html
It's not something new, we have the same "problem" with SDHCI,
USB and plenty other drivers. But the solution is simple, for
example see drivers/mmc/host/sdhci-pltfm.c and sdhci-cns3xxx.c
(and sdhci-esdhc-imx.c as another example of platform-specific
hooks for sdhci-pltfm).
Of course, we could make full-fledged platform driver just for
CNS3xxx, but that's kind of overkill. IMO, it's better to make
ahci_platform flexible and suitable for generic use.
As for renaming, I agree that ahci_platform.c file does not
need to be renamed, I still think that we could just rename
the module (so far it is used only on CNS3xxx platforms, so
no big deal even if anybody rely on the module name, which
I doubt.)
Thanks,
--
Anton Vorontsov
Email: cbouatmailru at gmail.com
^ permalink raw reply
* [PATCH v2 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Nishanth Menon @ 2011-01-07 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <[PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP>
OMP3630 silicon can enable higher frequencies only depending on the board
characteristics meeting the recommended standards, and has to be selectively
toggled.
Beagle XM uses 3730 variant and the board design allows enabling 800MHz and
1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz
safely. For the moment, we tweak the default table to allow for 800Mhz OPP
usage.
Reported-by: Koen Kooi <koen@beagleboard.org>
Tested-by: Koen Kooi <koen@beagleboard.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
v2: fixed issue when !mh || !dh, updated commit message to point on rationale
for board specific tweaking
v1: http://marc.info/?t=129426060900008&r=1&w=2
arch/arm/mach-omap2/board-omap3beagle.c | 50 +++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..7dc0397 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -23,6 +23,7 @@
#include <linux/gpio.h>
#include <linux/input.h>
#include <linux/gpio_keys.h>
+#include <linux/opp.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -44,10 +45,12 @@
#include <plat/gpmc.h>
#include <plat/nand.h>
#include <plat/usb.h>
+#include <plat/omap_device.h>
#include "mux.h"
#include "hsmmc.h"
#include "timer-gp.h"
+#include "pm.h"
#define NAND_BLOCK_SIZE SZ_128K
@@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static void __init beagle_opp_init(void)
+{
+ int r = 0;
+
+ /* Initialize the omap3 opp table */
+ if (omap3_opp_init()) {
+ pr_err("%s: opp default init failed\n", __func__);
+ return;
+ }
+
+ /* Custom OPP enabled for XM */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
+ struct omap_hwmod *dh = omap_hwmod_lookup("iva");
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
+ __func__, mh, dh);
+ return;
+ }
+ /* Enable MPU 1GHz and lower opps */
+ dev = &mh->od->pdev.dev;
+ r = opp_enable(dev, 800000000);
+ /* TODO: MPU 1GHz needs SR and ABB */
+
+ /* Enable IVA 800MHz and lower opps */
+ dev = &dh->od->pdev.dev;
+ r |= opp_enable(dev, 660000000);
+ /* TODO: DSP 800MHz needs SR and ABB */
+ if (r) {
+ pr_err("%s: failed to enable higher opp %d\n",
+ __func__, r);
+ /*
+ * Cleanup - disable the higher freqs - we dont care
+ * about the results
+ */
+ dev = &mh->od->pdev.dev;
+ opp_disable(dev, 800000000);
+ dev = &dh->od->pdev.dev;
+ opp_disable(dev, 660000000);
+ }
+ }
+ return;
+}
+
static void __init omap3_beagle_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
beagle_display_init();
+ beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/2] ARM: Gemini: add RTC support for Gemini SoC
From: Hans Ulli Kroll @ 2011-01-07 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110107093155.GN31708@n2100.arm.linux.org.uk>
On Fri, 7 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Dec 14, 2010 at 04:08:25PM +0100, Hans Ulli Kroll wrote:
> > This patch adds the driver for the rtc chip on the Gemini SoC
>
> I'll take patch 2, but not patch 1. There is no requirement for patch 1
> to come via my tree - it can be handled by the RTC people.
>
> My tree is not for random driver code being merged into mainline just
> because it's used on some ARM platform somewhere.
>
> (I'm making this request as a result of feedback from Linus on last nights
> merge of the ARM tree.)
>
> Thanks.
>
ACK
I already imaged this, therefore I divided this into two parts.
Ulli
^ permalink raw reply
* [PATCH v2 8/8] MTD: Remove integrator-flash
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
As there is now no in-tree user of integrator-flash, remove
it completely.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
---
drivers/mtd/Kconfig | 3 +-
drivers/mtd/maps/Kconfig | 4 -
drivers/mtd/maps/Makefile | 1 -
drivers/mtd/maps/integrator-flash.c | 319 -----------------------------------
4 files changed, 1 insertions(+), 326 deletions(-)
delete mode 100644 drivers/mtd/maps/integrator-flash.c
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 7741470..e38f64f 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -156,8 +156,7 @@ config MTD_AFS_PARTS
You will still need the parsing functions to be called by the driver
for your particular device. It won't happen automatically. The
- 'armflash' map driver (CONFIG_MTD_ARM_INTEGRATOR) does this, for
- example.
+ 'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example.
config MTD_OF_PARTS
def_bool y
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 5d37d31..96cff58 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -335,10 +335,6 @@ config MTD_SOLUTIONENGINE
This enables access to the flash chips on the Hitachi SolutionEngine and
similar boards. Say 'Y' if you are building a kernel for such a board.
-config MTD_ARM_INTEGRATOR
- tristate "CFI Flash device mapped on ARM Integrator/P720T"
- depends on ARM && MTD_CFI
-
config MTD_CDB89712
tristate "Cirrus CDB89712 evaluation board mappings"
depends on MTD_CFI && ARCH_CDB89712
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index c7869c7..8ac0c1a 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -8,7 +8,6 @@ endif
# Chip mappings
obj-$(CONFIG_MTD_CDB89712) += cdb89712.o
-obj-$(CONFIG_MTD_ARM_INTEGRATOR)+= integrator-flash.o
obj-$(CONFIG_MTD_CFI_FLAGADM) += cfi_flagadm.o
obj-$(CONFIG_MTD_DC21285) += dc21285.o
obj-$(CONFIG_MTD_DILNETPC) += dilnetpc.o
diff --git a/drivers/mtd/maps/integrator-flash.c b/drivers/mtd/maps/integrator-flash.c
deleted file mode 100644
index 2aac41b..0000000
--- a/drivers/mtd/maps/integrator-flash.c
+++ /dev/null
@@ -1,319 +0,0 @@
-/*======================================================================
-
- drivers/mtd/maps/integrator-flash.c: ARM Integrator flash map driver
-
- Copyright (C) 2000 ARM Limited
- Copyright (C) 2003 Deep Blue Solutions Ltd.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-
- This is access code for flashes using ARM's flash partitioning
- standards.
-
-======================================================================*/
-
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/slab.h>
-#include <linux/ioport.h>
-#include <linux/platform_device.h>
-#include <linux/init.h>
-#include <linux/io.h>
-
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/partitions.h>
-#include <linux/mtd/concat.h>
-
-#include <asm/mach/flash.h>
-#include <mach/hardware.h>
-#include <asm/system.h>
-
-struct armflash_subdev_info {
- char *name;
- struct mtd_info *mtd;
- struct map_info map;
- struct flash_platform_data *plat;
-};
-
-struct armflash_info {
- struct resource *res;
- struct mtd_partition *parts;
- struct mtd_info *mtd;
- int nr_subdev;
- struct armflash_subdev_info subdev[0];
-};
-
-static void armflash_set_vpp(struct map_info *map, int on)
-{
- struct armflash_subdev_info *info =
- container_of(map, struct armflash_subdev_info, map);
-
- if (info->plat && info->plat->set_vpp)
- info->plat->set_vpp(on);
-}
-
-static const char *probes[] = { "cmdlinepart", "RedBoot", "afs", NULL };
-
-static int armflash_subdev_probe(struct armflash_subdev_info *subdev,
- struct resource *res)
-{
- struct flash_platform_data *plat = subdev->plat;
- resource_size_t size = res->end - res->start + 1;
- void __iomem *base;
- int err = 0;
-
- if (!request_mem_region(res->start, size, subdev->name)) {
- err = -EBUSY;
- goto out;
- }
-
- base = ioremap(res->start, size);
- if (!base) {
- err = -ENOMEM;
- goto no_mem;
- }
-
- /*
- * look for CFI based flash parts fitted to this board
- */
- subdev->map.size = size;
- subdev->map.bankwidth = plat->width;
- subdev->map.phys = res->start;
- subdev->map.virt = base;
- subdev->map.name = subdev->name;
- subdev->map.set_vpp = armflash_set_vpp;
-
- simple_map_init(&subdev->map);
-
- /*
- * Also, the CFI layer automatically works out what size
- * of chips we have, and does the necessary identification
- * for us automatically.
- */
- subdev->mtd = do_map_probe(plat->map_name, &subdev->map);
- if (!subdev->mtd) {
- err = -ENXIO;
- goto no_device;
- }
-
- subdev->mtd->owner = THIS_MODULE;
-
- /* Successful? */
- if (err == 0)
- return err;
-
- if (subdev->mtd)
- map_destroy(subdev->mtd);
- no_device:
- iounmap(base);
- no_mem:
- release_mem_region(res->start, size);
- out:
- return err;
-}
-
-static void armflash_subdev_remove(struct armflash_subdev_info *subdev)
-{
- if (subdev->mtd)
- map_destroy(subdev->mtd);
- if (subdev->map.virt)
- iounmap(subdev->map.virt);
- kfree(subdev->name);
- subdev->name = NULL;
- release_mem_region(subdev->map.phys, subdev->map.size);
-}
-
-static int armflash_probe(struct platform_device *dev)
-{
- struct flash_platform_data *plat = dev->dev.platform_data;
- unsigned int size;
- struct armflash_info *info;
- int i, nr, err;
-
- /* Count the number of devices */
- for (nr = 0; ; nr++)
- if (!platform_get_resource(dev, IORESOURCE_MEM, nr))
- break;
- if (nr == 0) {
- err = -ENODEV;
- goto out;
- }
-
- size = sizeof(struct armflash_info) +
- sizeof(struct armflash_subdev_info) * nr;
- info = kzalloc(size, GFP_KERNEL);
- if (!info) {
- err = -ENOMEM;
- goto out;
- }
-
- if (plat && plat->init) {
- err = plat->init();
- if (err)
- goto no_resource;
- }
-
- for (i = 0; i < nr; i++) {
- struct armflash_subdev_info *subdev = &info->subdev[i];
- struct resource *res;
-
- res = platform_get_resource(dev, IORESOURCE_MEM, i);
- if (!res)
- break;
-
- if (nr == 1)
- /* No MTD concatenation, just use the default name */
- subdev->name = kstrdup(dev_name(&dev->dev), GFP_KERNEL);
- else
- subdev->name = kasprintf(GFP_KERNEL, "%s-%d",
- dev_name(&dev->dev), i);
- if (!subdev->name) {
- err = -ENOMEM;
- break;
- }
- subdev->plat = plat;
-
- err = armflash_subdev_probe(subdev, res);
- if (err) {
- kfree(subdev->name);
- subdev->name = NULL;
- break;
- }
- }
- info->nr_subdev = i;
-
- if (err)
- goto subdev_err;
-
- if (info->nr_subdev == 1)
- info->mtd = info->subdev[0].mtd;
- else if (info->nr_subdev > 1) {
-#ifdef CONFIG_MTD_CONCAT
- struct mtd_info *cdev[info->nr_subdev];
-
- /*
- * We detected multiple devices. Concatenate them together.
- */
- for (i = 0; i < info->nr_subdev; i++)
- cdev[i] = info->subdev[i].mtd;
-
- info->mtd = mtd_concat_create(cdev, info->nr_subdev,
- dev_name(&dev->dev));
- if (info->mtd == NULL)
- err = -ENXIO;
-#else
- printk(KERN_ERR "armflash: multiple devices found but "
- "MTD concat support disabled.\n");
- err = -ENXIO;
-#endif
- }
-
- if (err < 0)
- goto cleanup;
-
- err = parse_mtd_partitions(info->mtd, probes, &info->parts, 0);
- if (err > 0) {
- err = add_mtd_partitions(info->mtd, info->parts, err);
- if (err)
- printk(KERN_ERR
- "mtd partition registration failed: %d\n", err);
- }
-
- if (err == 0) {
- platform_set_drvdata(dev, info);
- return err;
- }
-
- /*
- * We got an error, free all resources.
- */
- cleanup:
- if (info->mtd) {
- del_mtd_partitions(info->mtd);
-#ifdef CONFIG_MTD_CONCAT
- if (info->mtd != info->subdev[0].mtd)
- mtd_concat_destroy(info->mtd);
-#endif
- }
- kfree(info->parts);
- subdev_err:
- for (i = info->nr_subdev - 1; i >= 0; i--)
- armflash_subdev_remove(&info->subdev[i]);
- no_resource:
- if (plat && plat->exit)
- plat->exit();
- kfree(info);
- out:
- return err;
-}
-
-static int armflash_remove(struct platform_device *dev)
-{
- struct armflash_info *info = platform_get_drvdata(dev);
- struct flash_platform_data *plat = dev->dev.platform_data;
- int i;
-
- platform_set_drvdata(dev, NULL);
-
- if (info) {
- if (info->mtd) {
- del_mtd_partitions(info->mtd);
-#ifdef CONFIG_MTD_CONCAT
- if (info->mtd != info->subdev[0].mtd)
- mtd_concat_destroy(info->mtd);
-#endif
- }
- kfree(info->parts);
-
- for (i = info->nr_subdev - 1; i >= 0; i--)
- armflash_subdev_remove(&info->subdev[i]);
-
- if (plat && plat->exit)
- plat->exit();
-
- kfree(info);
- }
-
- return 0;
-}
-
-static struct platform_driver armflash_driver = {
- .probe = armflash_probe,
- .remove = armflash_remove,
- .driver = {
- .name = "armflash",
- .owner = THIS_MODULE,
- },
-};
-
-static int __init armflash_init(void)
-{
- return platform_driver_register(&armflash_driver);
-}
-
-static void __exit armflash_exit(void)
-{
- platform_driver_unregister(&armflash_driver);
-}
-
-module_init(armflash_init);
-module_exit(armflash_exit);
-
-MODULE_AUTHOR("ARM Ltd");
-MODULE_DESCRIPTION("ARM Integrator CFI map driver");
-MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:armflash");
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 7/8] ARM: aaec2000: Use physmap driver instead of integrator-flash
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Bellido <ml@acolin.be>
---
arch/arm/mach-aaec2000/core.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-aaec2000/core.c b/arch/arm/mach-aaec2000/core.c
index 3ef6833..100707c 100644
--- a/arch/arm/mach-aaec2000/core.c
+++ b/arch/arm/mach-aaec2000/core.c
@@ -21,12 +21,12 @@
#include <linux/signal.h>
#include <linux/clk.h>
#include <linux/gfp.h>
+#include <linux/mtd/physmap.h>
#include <mach/hardware.h>
#include <asm/irq.h>
#include <asm/sizes.h>
-#include <asm/mach/flash.h>
#include <asm/mach/irq.h>
#include <asm/mach/time.h>
#include <asm/mach/map.h>
@@ -260,8 +260,7 @@ void __init aaec2000_set_clcd_plat_data(struct aaec2000_clcd_info *clcd)
memcpy(&mach_clcd_panel, &clcd->panel, sizeof(struct clcd_panel));
}
-static struct flash_platform_data aaec2000_flash_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data aaec2000_flash_data = {
.width = 4,
};
@@ -272,7 +271,7 @@ static struct resource aaec2000_flash_resource = {
};
static struct platform_device aaec2000_flash_device = {
- .name = "armflash",
+ .name = "physmap-flash",
.id = 0,
.dev = {
.platform_data = &aaec2000_flash_data,
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 6/8] ARM: Integrator/CP: Use physmap driver instead of integrator-flash
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
Tested with an ARM-1136 core tile.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/mach-integrator/integrator_cp.c | 35 +++++------------------------
1 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c
index 85e48a5..a9a10f8 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -22,6 +22,7 @@
#include <linux/io.h>
#include <linux/gfp.h>
#include <linux/clkdev.h>
+#include <linux/mtd/physmap.h>
#include <mach/hardware.h>
#include <mach/platform.h>
@@ -35,7 +36,6 @@
#include <mach/lm.h>
#include <asm/mach/arch.h>
-#include <asm/mach/flash.h>
#include <asm/mach/irq.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
@@ -316,43 +316,20 @@ static struct clk_lookup cp_lookups[] = {
/*
* Flash handling.
*/
-static int intcp_flash_init(void)
-{
- u32 val;
-
- val = readl(INTCP_VA_CTRL_BASE + INTCP_FLASHPROG);
- val |= CINTEGRATOR_FLASHPROG_FLWREN;
- writel(val, INTCP_VA_CTRL_BASE + INTCP_FLASHPROG);
-
- return 0;
-}
-
-static void intcp_flash_exit(void)
-{
- u32 val;
-
- val = readl(INTCP_VA_CTRL_BASE + INTCP_FLASHPROG);
- val &= ~(CINTEGRATOR_FLASHPROG_FLVPPEN|CINTEGRATOR_FLASHPROG_FLWREN);
- writel(val, INTCP_VA_CTRL_BASE + INTCP_FLASHPROG);
-}
-
-static void intcp_flash_set_vpp(int on)
+static void intcp_flash_set_vpp(struct map_info *map, int on)
{
u32 val;
val = readl(INTCP_VA_CTRL_BASE + INTCP_FLASHPROG);
if (on)
- val |= CINTEGRATOR_FLASHPROG_FLVPPEN;
+ val |= CINTEGRATOR_FLASHPROG_FLVPPEN | CINTEGRATOR_FLASHPROG_FLWREN;
else
- val &= ~CINTEGRATOR_FLASHPROG_FLVPPEN;
+ val &= ~(CINTEGRATOR_FLASHPROG_FLVPPEN | CINTEGRATOR_FLASHPROG_FLWREN);
writel(val, INTCP_VA_CTRL_BASE + INTCP_FLASHPROG);
}
-static struct flash_platform_data intcp_flash_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data intcp_flash_data = {
.width = 4,
- .init = intcp_flash_init,
- .exit = intcp_flash_exit,
.set_vpp = intcp_flash_set_vpp,
};
@@ -363,7 +340,7 @@ static struct resource intcp_flash_resource = {
};
static struct platform_device intcp_flash_device = {
- .name = "armflash",
+ .name = "physmap-flash",
.id = 0,
.dev = {
.platform_data = &intcp_flash_data,
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 5/8] ARM: Integrator/AP: Use physmap driver instead of integrator-flash
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/mach-integrator/integrator_ap.c | 46 ++++++++++-------------------
1 files changed, 16 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index 2774df8..f5b22a3 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -31,6 +31,7 @@
#include <linux/clockchips.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/mtd/physmap.h>
#include <mach/hardware.h>
#include <mach/platform.h>
@@ -43,7 +44,6 @@
#include <mach/lm.h>
#include <asm/mach/arch.h>
-#include <asm/mach/flash.h>
#include <asm/mach/irq.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
@@ -247,51 +247,37 @@ device_initcall(irq_init_sysfs);
#define EBI_CSR1 (VA_EBI_BASE + INTEGRATOR_EBI_CSR1_OFFSET)
#define EBI_LOCK (VA_EBI_BASE + INTEGRATOR_EBI_LOCK_OFFSET)
-static int ap_flash_init(void)
+static void ap_flash_set_vpp(struct map_info *map, int on)
{
+ unsigned long reg;
+ int needs_lock;
u32 tmp;
writel(INTEGRATOR_SC_CTRL_nFLVPPEN | INTEGRATOR_SC_CTRL_nFLWP, SC_CTRLC);
-
- tmp = readl(EBI_CSR1) | INTEGRATOR_EBI_WRITE_ENABLE;
- writel(tmp, EBI_CSR1);
-
- if (!(readl(EBI_CSR1) & INTEGRATOR_EBI_WRITE_ENABLE)) {
- writel(0xa05f, EBI_LOCK);
- writel(tmp, EBI_CSR1);
- writel(0, EBI_LOCK);
+ tmp = readl(EBI_CSR1);
+
+ if (on) {
+ reg = SC_CTRLS;
+ tmp |= INTEGRATOR_EBI_WRITE_ENABLE;
+ } else {
+ reg = SC_CTRLC;
+ tmp &= ~INTEGRATOR_EBI_WRITE_ENABLE;
}
- return 0;
-}
-static void ap_flash_exit(void)
-{
- u32 tmp;
-
- writel(INTEGRATOR_SC_CTRL_nFLVPPEN | INTEGRATOR_SC_CTRL_nFLWP, SC_CTRLC);
-
- tmp = readl(EBI_CSR1) & ~INTEGRATOR_EBI_WRITE_ENABLE;
writel(tmp, EBI_CSR1);
- if (readl(EBI_CSR1) & INTEGRATOR_EBI_WRITE_ENABLE) {
+ needs_lock = !!on ^ !!(readl(EBI_CSR1) & INTEGRATOR_EBI_WRITE_ENABLE);
+ if (needs_lock) {
writel(0xa05f, EBI_LOCK);
writel(tmp, EBI_CSR1);
writel(0, EBI_LOCK);
}
-}
-
-static void ap_flash_set_vpp(int on)
-{
- unsigned long reg = on ? SC_CTRLS : SC_CTRLC;
writel(INTEGRATOR_SC_CTRL_nFLVPPEN, reg);
}
-static struct flash_platform_data ap_flash_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data ap_flash_data = {
.width = 4,
- .init = ap_flash_init,
- .exit = ap_flash_exit,
.set_vpp = ap_flash_set_vpp,
};
@@ -302,7 +288,7 @@ static struct resource cfi_flash_resource = {
};
static struct platform_device cfi_flash_device = {
- .name = "armflash",
+ .name = "physmap-flash",
.id = 0,
.dev = {
.platform_data = &ap_flash_data,
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 4/8] ARM: VExpress: Use physmap driver instead of integrator-flash
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/mach-vexpress/v2m.c | 22 ++++------------------
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index a9ed342..af96624 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -12,9 +12,9 @@
#include <linux/sysdev.h>
#include <linux/usb/isp1760.h>
#include <linux/clkdev.h>
+#include <linux/mtd/physmap.h>
#include <asm/sizes.h>
-#include <asm/mach/flash.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
#include <asm/hardware/arm_timer.h>
@@ -196,27 +196,13 @@ static struct platform_device v2m_usb_device = {
.dev.platform_data = &v2m_usb_config,
};
-static int v2m_flash_init(void)
-{
- writel(0, MMIO_P2V(V2M_SYS_FLASH));
- return 0;
-}
-
-static void v2m_flash_exit(void)
-{
- writel(0, MMIO_P2V(V2M_SYS_FLASH));
-}
-
-static void v2m_flash_set_vpp(int on)
+static void v2m_flash_set_vpp(struct map_info *map, int on)
{
writel(on != 0, MMIO_P2V(V2M_SYS_FLASH));
}
-static struct flash_platform_data v2m_flash_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data v2m_flash_data = {
.width = 4,
- .init = v2m_flash_init,
- .exit = v2m_flash_exit,
.set_vpp = v2m_flash_set_vpp,
};
@@ -233,7 +219,7 @@ static struct resource v2m_flash_resources[] = {
};
static struct platform_device v2m_flash_device = {
- .name = "armflash",
+ .name = "physmap-flash",
.id = -1,
.resource = v2m_flash_resources,
.num_resources = ARRAY_SIZE(v2m_flash_resources),
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 3/8] ARM: Versatile: Use physmap driver instead of integrator-flash
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/configs/versatile_defconfig | 2 +-
arch/arm/mach-versatile/core.c | 31 ++++---------------------------
2 files changed, 5 insertions(+), 28 deletions(-)
diff --git a/arch/arm/configs/versatile_defconfig b/arch/arm/configs/versatile_defconfig
index 0ce710f..cdd4d2b 100644
--- a/arch/arm/configs/versatile_defconfig
+++ b/arch/arm/configs/versatile_defconfig
@@ -32,7 +32,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_INTELEXT=y
-CONFIG_MTD_ARM_INTEGRATOR=y
+CONFIG_MTD_PHYSMAP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_EEPROM_LEGACY=m
CONFIG_NETDEVICES=y
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 13a83e4..925c08f 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -32,6 +32,7 @@
#include <linux/io.h>
#include <linux/gfp.h>
#include <linux/clkdev.h>
+#include <linux/mtd/physmap.h>
#include <asm/system.h>
#include <asm/irq.h>
@@ -42,7 +43,6 @@
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
-#include <asm/mach/flash.h>
#include <asm/mach/irq.h>
#include <asm/mach/time.h>
#include <asm/mach/map.h>
@@ -232,27 +232,7 @@ void __init versatile_map_io(void)
#define VERSATILE_FLASHCTRL (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_FLASH_OFFSET)
-static int versatile_flash_init(void)
-{
- u32 val;
-
- val = __raw_readl(VERSATILE_FLASHCTRL);
- val &= ~VERSATILE_FLASHPROG_FLVPPEN;
- __raw_writel(val, VERSATILE_FLASHCTRL);
-
- return 0;
-}
-
-static void versatile_flash_exit(void)
-{
- u32 val;
-
- val = __raw_readl(VERSATILE_FLASHCTRL);
- val &= ~VERSATILE_FLASHPROG_FLVPPEN;
- __raw_writel(val, VERSATILE_FLASHCTRL);
-}
-
-static void versatile_flash_set_vpp(int on)
+static void versatile_flash_set_vpp(struct map_info *map, int on)
{
u32 val;
@@ -264,11 +244,8 @@ static void versatile_flash_set_vpp(int on)
__raw_writel(val, VERSATILE_FLASHCTRL);
}
-static struct flash_platform_data versatile_flash_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data versatile_flash_data = {
.width = 4,
- .init = versatile_flash_init,
- .exit = versatile_flash_exit,
.set_vpp = versatile_flash_set_vpp,
};
@@ -279,7 +256,7 @@ static struct resource versatile_flash_resource = {
};
static struct platform_device versatile_flash_device = {
- .name = "armflash",
+ .name = "physmap-flash",
.id = 0,
.dev = {
.platform_data = &versatile_flash_data,
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 2/8] ARM: Realview: Use physmap driver instead of integrator-flash
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
Tested on a PB11-MPCore.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/configs/realview-smp_defconfig | 2 +-
arch/arm/configs/realview_defconfig | 2 +-
arch/arm/mach-realview/core.c | 31 ++++---------------------------
3 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/arch/arm/configs/realview-smp_defconfig b/arch/arm/configs/realview-smp_defconfig
index 5ca7a61..abe61bf 100644
--- a/arch/arm/configs/realview-smp_defconfig
+++ b/arch/arm/configs/realview-smp_defconfig
@@ -38,7 +38,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_ARM_INTEGRATOR=y
+CONFIG_MTD_PHYSMAP=y
CONFIG_ARM_CHARLCD=y
CONFIG_NETDEVICES=y
CONFIG_SMSC_PHY=y
diff --git a/arch/arm/configs/realview_defconfig b/arch/arm/configs/realview_defconfig
index fcaa603..7079cbe 100644
--- a/arch/arm/configs/realview_defconfig
+++ b/arch/arm/configs/realview_defconfig
@@ -37,7 +37,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_ARM_INTEGRATOR=y
+CONFIG_MTD_PHYSMAP=y
CONFIG_ARM_CHARLCD=y
CONFIG_NETDEVICES=y
CONFIG_SMSC_PHY=y
diff --git a/arch/arm/mach-realview/core.c b/arch/arm/mach-realview/core.c
index 1c6602c..805cadd 100644
--- a/arch/arm/mach-realview/core.c
+++ b/arch/arm/mach-realview/core.c
@@ -31,6 +31,7 @@
#include <linux/amba/mmci.h>
#include <linux/gfp.h>
#include <linux/clkdev.h>
+#include <linux/mtd/physmap.h>
#include <asm/system.h>
#include <mach/hardware.h>
@@ -41,7 +42,6 @@
#include <asm/hardware/icst.h>
#include <asm/mach/arch.h>
-#include <asm/mach/flash.h>
#include <asm/mach/irq.h>
#include <asm/mach/map.h>
@@ -76,27 +76,7 @@ void __init realview_adjust_zones(unsigned long *size, unsigned long *hole)
#define REALVIEW_FLASHCTRL (__io_address(REALVIEW_SYS_BASE) + REALVIEW_SYS_FLASH_OFFSET)
-static int realview_flash_init(void)
-{
- u32 val;
-
- val = __raw_readl(REALVIEW_FLASHCTRL);
- val &= ~REALVIEW_FLASHPROG_FLVPPEN;
- __raw_writel(val, REALVIEW_FLASHCTRL);
-
- return 0;
-}
-
-static void realview_flash_exit(void)
-{
- u32 val;
-
- val = __raw_readl(REALVIEW_FLASHCTRL);
- val &= ~REALVIEW_FLASHPROG_FLVPPEN;
- __raw_writel(val, REALVIEW_FLASHCTRL);
-}
-
-static void realview_flash_set_vpp(int on)
+static void realview_flash_set_vpp(struct map_info *map, int on)
{
u32 val;
@@ -108,16 +88,13 @@ static void realview_flash_set_vpp(int on)
__raw_writel(val, REALVIEW_FLASHCTRL);
}
-static struct flash_platform_data realview_flash_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data realview_flash_data = {
.width = 4,
- .init = realview_flash_init,
- .exit = realview_flash_exit,
.set_vpp = realview_flash_set_vpp,
};
struct platform_device realview_flash_device = {
- .name = "armflash",
+ .name = "physmap-flash",
.id = 0,
.dev = {
.platform_data = &realview_flash_data,
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 1/8] MTD: Add integrator-flash feature to physmap
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294409399-19245-1-git-send-email-marc.zyngier@arm.com>
In the process of moving platforms away from integrator-flash
(aka armflash), add optionnal probing for the AFS partition type.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
---
drivers/mtd/maps/physmap.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/maps/physmap.c b/drivers/mtd/maps/physmap.c
index 4c18b98..221354d 100644
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -79,7 +79,11 @@ static const char *rom_probe_types[] = {
"map_rom",
NULL };
#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
+static const char *part_probe_types[] = { "cmdlinepart", "RedBoot",
+#ifdef CONFIG_MTD_AFS_PARTS
+ "afs",
+#endif
+ NULL };
#endif
static int physmap_flash_probe(struct platform_device *dev)
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 0/8] Switch ARM platforms from integrator-flash to physmap
From: Marc Zyngier @ 2011-01-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
As the integrator-flash driver is mostly a duplicate of physmap,
move all users of this driver to physmap and get rid of the
then unused driver.
Changes since initial revision:
- Rebased against linux-next (20110107). It should apply cleanly
on top of Linus' tree, except for a small conflict in the last
patch of the serie.
Marc Zyngier (8):
MTD: Add integrator-flash feature to physmap
ARM: Realview: Use physmap driver instead of integrator-flash
ARM: Versatile: Use physmap driver instead of integrator-flash
ARM: VExpress: Use physmap driver instead of integrator-flash
ARM: Integrator/AP: Use physmap driver instead of integrator-flash
ARM: Integrator/CP: Use physmap driver instead of integrator-flash
ARM: aaec2000: Use physmap driver instead of integrator-flash
MTD: Remove integrator-flash
arch/arm/configs/realview-smp_defconfig | 2 +-
arch/arm/configs/realview_defconfig | 2 +-
arch/arm/configs/versatile_defconfig | 2 +-
arch/arm/mach-aaec2000/core.c | 7 +-
arch/arm/mach-integrator/integrator_ap.c | 46 ++---
arch/arm/mach-integrator/integrator_cp.c | 35 +---
arch/arm/mach-realview/core.c | 31 +---
arch/arm/mach-versatile/core.c | 31 +---
arch/arm/mach-vexpress/v2m.c | 22 +--
drivers/mtd/Kconfig | 3 +-
drivers/mtd/maps/Kconfig | 4 -
drivers/mtd/maps/Makefile | 1 -
drivers/mtd/maps/integrator-flash.c | 319 ------------------------------
drivers/mtd/maps/physmap.c | 6 +-
14 files changed, 46 insertions(+), 465 deletions(-)
delete mode 100644 drivers/mtd/maps/integrator-flash.c
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Nishanth Menon @ 2011-01-07 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.1.10.1101071457540.18906@esdhcp041196.research.nokia.com>
Aaro Koskinen wrote, on 01/07/2011 07:04 AM:
> On Wed, 5 Jan 2011, Nishanth Menon wrote:
>> +static void __init beagle_opp_init(void)
>> +{
>> + int r = 0;
>> +
>> + /* Initialize the omap3 opp table */
>> + if (omap3_opp_init()) {
>> + pr_err("%s: opp default init failed\n", __func__);
>> + return;
>> + }
>> +
>> + /* Custom OPP enabled for XM */
>> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
>> + struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
>> + struct omap_hwmod *dh = omap_hwmod_lookup("iva");
>> + struct device *dev;
>> +
>> + if (!mh || !dh) {
>> + pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
>> + __func__, mh, dh);
>> + r = -EINVAL;
>> + } else {
>> + /* Enable MPU 1GHz and lower opps */
>> + dev = &mh->od->pdev.dev;
>> + r = opp_enable(dev, 800000000);
>> + /* TODO: MPU 1GHz needs SR and ABB */
>> +
>> + /* Enable IVA 800MHz and lower opps */
>> + dev = &dh->od->pdev.dev;
>> + r |= opp_enable(dev, 660000000);
>> + /* TODO: DSP 800MHz needs SR and ABB */
>> + }
>> + if (r) {
>> + pr_err("%s: failed to enable higher opp %d\n",
>> + __func__, r);
>> + /*
>> + * Cleanup - disable the higher freqs - we dont care
>> + * about the results
>> + */
>> + dev = &mh->od->pdev.dev;
>> + opp_disable(dev, 800000000);
>> + dev = &dh->od->pdev.dev;
>
> This branch will be reached also when !mh || !dh, so it won't work.
arrgh.. thanks for catching it - will fix and repost.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Bug in arch-mmp board selection
From: Eric Miao @ 2011-01-07 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=SX-KmcmP-cNN-59D+rSABQmSHEPQaYF0WFbGg@mail.gmail.com>
On Wed, Jan 5, 2011 at 12:57 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> Hi Eric,
>
> PXA168 and PXA910 are based on PJ1 which is an ARMv5 compatible architecture
> MMP2 is a based on PJ4 which configured as ARMv6 currently (there are
> ARMv7 versions as well)
>
> Currently all SoCs are selectable under the "PXA168/910/MMP2" menu
> option which allows you to then select PXA168, PXA910, and MMP2 boards
> for one image. If you build this configuration this error occurs:
>
> ?AS ? ? ?arch/arm/kernel/entry-armv.o
> arch/arm/kernel/entry-armv.S: Assembler messages:
> arch/arm/kernel/entry-armv.S:212: Error: selected processor does not
> support `clrex'
> arch/arm/kernel/entry-armv.S:244: Error: selected processor does not
> support `clrex'
> arch/arm/kernel/entry-armv.S:302: Error: selected processor does not
> support `clrex'
> arch/arm/kernel/entry-armv.S:338: Error: selected processor does not
> support `clrex'
> make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1
> make: *** [arch/arm/kernel] Error 2
>
> I am aware we can resolve this by adding KConfig rules to prevent this
> scenario, but it leads to a deeper question. Why does selecting the
> board in turn select the CPU type instead of the user enabling the CPU
> type and then providing a set of boards for selection?
>
Because the board knows which SoC it's using, and the logic behind
this is - if you select the board, the board select everything else applicable.
And you are right, it's not able to select all boards in mach-mmp/ to
make them built into a single image at this moment. However, that's
possible theoretically. And that's the reason I'm keeping two separate
_defconfig for pxa168_ and mmp2_.
> e.g.
> config MACH_ZYLONITE2
> ? ? ? ?bool "Marvell's PXA168 Zylonite2 Development Board"
> ? ? ? --> select CPU_PXA168
>
^ permalink raw reply
* Build breakage with omap2plus_defconfig
From: Felipe Balbi @ 2011-01-07 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <48d62e319848b713fc70a8298c32710d@mail.gmail.com>
Hi,
On Fri, Jan 07, 2011 at 06:35:39PM +0530, Santosh Shilimkar wrote:
> This patch is good but it does tell you that if
> you will V6 and v7 together, the feature can't be used.
>
> Like omap2plus_defconfig, and if booted on
> say omap3 or omap4(v7), swp emulation can't be used
> even though its supported.
Sure, I got that from the patch, but we don't have any other simpler
solution currently. And it's indeed a shame we can't support multi-omap
anymore :-(
--
balbi
^ permalink raw reply
* Build breakage with omap2plus_defconfig
From: Santosh Shilimkar @ 2011-01-07 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110107125929.GD9592@legolas.emea.dhcp.ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Felipe Balbi
> Sent: Friday, January 07, 2011 6:30 PM
> To: Santosh Shilimkar
> Cc: balbi at ti.com; Russell King; Tony Lindgren; Linux OMAP Mailing
> List; Linux ARM Kernel Mailing List
> Subject: Re: Build breakage with omap2plus_defconfig
>
> On Fri, Jan 07, 2011 at 06:18:51PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > > owner at vger.kernel.org] On Behalf Of Felipe Balbi
> > > Sent: Friday, January 07, 2011 6:09 PM
> > > To: Russell King; Tony Lindgren
> > > Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List
> > > Subject: Build breakage with omap2plus_defconfig
> > >
> > > Hi all,
> > >
> > > Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63)
> fails
> > > to
> > > build with omap2plus_defconfig:
> > >
> > > $ crossmake
> > > CHK include/linux/version.h
> > > CHK include/generated/utsrelease.h
> > > make[1]: `include/generated/mach-types.h' is up to date.
> > > CALL scripts/checksyscalls.sh
> > > CHK include/generated/compile.h
> > > CC arch/arm/kernel/swp_emulate.o
> > > /tmp/cc2V7p5j.s: Assembler messages:
> > > /tmp/cc2V7p5j.s:161: Error: selected processor does not support
> ARM
> > > mode `ldrexb r3,[r4]'
> > > /tmp/cc2V7p5j.s:162: Error: selected processor does not support
> ARM
> > > mode `strexb r0,r2,[r4]'
> >
> > Well it's not toolchain issue but the omap2plus_defconfig which
> > selects ARMv6 and ARMV7 together.
> >
> > If you remove ARCH_OMAP2 from build, it will go through.
>
> I like Catalin's approach:
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 49db8b3..0fe2389 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -644,7 +644,7 @@ config ARM_THUMBEE
>
> config SWP_EMULATE
> bool "Emulate SWP/SWPB instructions"
> - depends on CPU_V7
> + depends on CPU_V7 && !CPU_V6
> select HAVE_PROC_CPU if PROC_FS
> default y if SMP
> help
>
> Simple.
>
This patch is good but it does tell you that if
you will V6 and v7 together, the feature can't be used.
Like omap2plus_defconfig, and if booted on
say omap3 or omap4(v7), swp emulation can't be used
even though its supported.
Regards,
Santosh
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Aaro Koskinen @ 2011-01-07 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294260576-20237-3-git-send-email-nm@ti.com>
Hi,
On Wed, 5 Jan 2011, Nishanth Menon wrote:
> +static void __init beagle_opp_init(void)
> +{
> + int r = 0;
> +
> + /* Initialize the omap3 opp table */
> + if (omap3_opp_init()) {
> + pr_err("%s: opp default init failed\n", __func__);
> + return;
> + }
> +
> + /* Custom OPP enabled for XM */
> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> + struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
> + struct omap_hwmod *dh = omap_hwmod_lookup("iva");
> + struct device *dev;
> +
> + if (!mh || !dh) {
> + pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
> + __func__, mh, dh);
> + r = -EINVAL;
> + } else {
> + /* Enable MPU 1GHz and lower opps */
> + dev = &mh->od->pdev.dev;
> + r = opp_enable(dev, 800000000);
> + /* TODO: MPU 1GHz needs SR and ABB */
> +
> + /* Enable IVA 800MHz and lower opps */
> + dev = &dh->od->pdev.dev;
> + r |= opp_enable(dev, 660000000);
> + /* TODO: DSP 800MHz needs SR and ABB */
> + }
> + if (r) {
> + pr_err("%s: failed to enable higher opp %d\n",
> + __func__, r);
> + /*
> + * Cleanup - disable the higher freqs - we dont care
> + * about the results
> + */
> + dev = &mh->od->pdev.dev;
> + opp_disable(dev, 800000000);
> + dev = &dh->od->pdev.dev;
This branch will be reached also when !mh || !dh, so it won't work.
> + opp_disable(dev, 660000000);
> + }
> + }
> +}
A.
^ permalink raw reply
* Build breakage with omap2plus_defconfig
From: Felipe Balbi @ 2011-01-07 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8663c7bb00ba574693af177a10e24043@mail.gmail.com>
On Fri, Jan 07, 2011 at 06:18:51PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > owner at vger.kernel.org] On Behalf Of Felipe Balbi
> > Sent: Friday, January 07, 2011 6:09 PM
> > To: Russell King; Tony Lindgren
> > Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List
> > Subject: Build breakage with omap2plus_defconfig
> >
> > Hi all,
> >
> > Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails
> > to
> > build with omap2plus_defconfig:
> >
> > $ crossmake
> > CHK include/linux/version.h
> > CHK include/generated/utsrelease.h
> > make[1]: `include/generated/mach-types.h' is up to date.
> > CALL scripts/checksyscalls.sh
> > CHK include/generated/compile.h
> > CC arch/arm/kernel/swp_emulate.o
> > /tmp/cc2V7p5j.s: Assembler messages:
> > /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM
> > mode `ldrexb r3,[r4]'
> > /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM
> > mode `strexb r0,r2,[r4]'
>
> Well it's not toolchain issue but the omap2plus_defconfig which
> selects ARMv6 and ARMV7 together.
>
> If you remove ARCH_OMAP2 from build, it will go through.
I like Catalin's approach:
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 49db8b3..0fe2389 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -644,7 +644,7 @@ config ARM_THUMBEE
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions"
- depends on CPU_V7
+ depends on CPU_V7 && !CPU_V6
select HAVE_PROC_CPU if PROC_FS
default y if SMP
help
Simple.
--
balbi
^ permalink raw reply related
* Build breakage with omap2plus_defconfig
From: Felipe Balbi @ 2011-01-07 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d36c47cf71accc194040e98d74f768c0@mail.gmail.com>
On Fri, Jan 07, 2011 at 06:20:43PM +0530, Anand Gadiyar wrote:
> Felipe Balbi wrote:
> > Hi all,
> >
> > Today's Linus' tree
> > (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
> > build with omap2plus_defconfig:
> >
> > $ crossmake
> > CHK include/linux/version.h
> > CHK include/generated/utsrelease.h
> > make[1]: `include/generated/mach-types.h' is up to date.
> > CALL scripts/checksyscalls.sh
> > CHK include/generated/compile.h
> > CC arch/arm/kernel/swp_emulate.o
> > /tmp/cc2V7p5j.s: Assembler messages:
> > /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode
> `ldrexb r3,[r4]'
> > /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode
> `strexb r0,r2,[r4]'
> > make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> > make: *** [arch/arm/kernel] Error 2
>
> I haven't found a way around this other than to turn off
> CONFIG_SWP_EMULATE. Here's a patch doing that [1].
>
> The discussion thread is here [2].
Thanks a lot Anand :-)
--
balbi
^ permalink raw reply
* Build breakage with omap2plus_defconfig
From: Anand Gadiyar @ 2011-01-07 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110107123859.GA9592@legolas.emea.dhcp.ti.com>
Felipe Balbi wrote:
> Hi all,
>
> Today's Linus' tree
> (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
> build with omap2plus_defconfig:
>
> $ crossmake
> CHK include/linux/version.h
> CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> CC arch/arm/kernel/swp_emulate.o
> /tmp/cc2V7p5j.s: Assembler messages:
> /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode
`ldrexb r3,[r4]'
> /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode
`strexb r0,r2,[r4]'
> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel] Error 2
I haven't found a way around this other than to turn off
CONFIG_SWP_EMULATE. Here's a patch doing that [1].
The discussion thread is here [2].
- Anand
[1] http://marc.info/?l=linux-omap&m=129140165126953&w=2
[2] http://marc.info/?t=128748412500003&r=1&w=2
^ permalink raw reply
* Build breakage with omap2plus_defconfig
From: Santosh Shilimkar @ 2011-01-07 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110107123859.GA9592@legolas.emea.dhcp.ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Felipe Balbi
> Sent: Friday, January 07, 2011 6:09 PM
> To: Russell King; Tony Lindgren
> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List
> Subject: Build breakage with omap2plus_defconfig
>
> Hi all,
>
> Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails
> to
> build with omap2plus_defconfig:
>
> $ crossmake
> CHK include/linux/version.h
> CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> CC arch/arm/kernel/swp_emulate.o
> /tmp/cc2V7p5j.s: Assembler messages:
> /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM
> mode `ldrexb r3,[r4]'
> /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM
> mode `strexb r0,r2,[r4]'
Well it's not toolchain issue but the omap2plus_defconfig which
selects ARMv6 and ARMV7 together.
If you remove ARCH_OMAP2 from build, it will go through.
> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel] Error 2
>
> Compiler is:
>
> $ arm-linux-gcc --version
> arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to
> check
> if it's not a bug on the compiler.
Santosh
^ permalink raw reply
* Build breakage with omap2plus_defconfig
From: Felipe Balbi @ 2011-01-07 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110107123859.GA9592@legolas.emea.dhcp.ti.com>
Hi,
On Fri, Jan 07, 2011 at 02:38:59PM +0200, Felipe Balbi wrote:
> Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
> build with omap2plus_defconfig:
>
> $ crossmake
> CHK include/linux/version.h
> CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> CC arch/arm/kernel/swp_emulate.o
> /tmp/cc2V7p5j.s: Assembler messages:
> /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]'
> /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]'
> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel] Error 2
>
> Compiler is:
>
> $ arm-linux-gcc --version
> arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to check
> if it's not a bug on the compiler.
Just tested with newer compiler and it also fails to compile.
$ arm-linux-gcc --version
arm-linux-gcc (Sourcery G++ Lite 2010.09-50) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
balbi
^ permalink raw reply
* Build breakage with omap2plus_defconfig
From: Felipe Balbi @ 2011-01-07 12:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
build with omap2plus_defconfig:
$ crossmake
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC arch/arm/kernel/swp_emulate.o
/tmp/cc2V7p5j.s: Assembler messages:
/tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]'
/tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]'
make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
make: *** [arch/arm/kernel] Error 2
Compiler is:
$ arm-linux-gcc --version
arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to check
if it's not a bug on the compiler.
--
balbi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox