[RFC][PATCH 0/5] Convert GPMC to driver
Hi, Convert GPCM code to be a driver. Existing GPMC NAND platform handling has been modified to work with the new GPMC driver (patches 2 3). Patch 5 is to test the driver in OMAP3EVM. Once all the users has been converted to use this driver, would be converted to MFD type. TODO: 1. Let OMAP NAND driver deal with GPMC NAND block 2. Remove struct gpmc * stored as static 3. Convert all peripherals to use GPMC driver 4. Devise method to handle OneNAND cleanly 5. Handle acquiring CS# cases 6. Convert to MFD driver Regards Afzal Afzal Mohammed (5): ARM: OMAP2+: gpmc: driver conversion ARM: OMAP2+: nand: create platform data structure ARM: OMAP2+: gpmc-nand: populate gpmc configs mtd: nand: omap2: obtain memory from resource OMAP3EVM: Test gpmc-nand arch/arm/mach-omap2/board-devkit8000.c |6 +- arch/arm/mach-omap2/board-flash.c | 63 +- arch/arm/mach-omap2/board-flash.h | 13 +- arch/arm/mach-omap2/board-ldp.c|4 +- arch/arm/mach-omap2/board-omap3beagle.c|6 +- arch/arm/mach-omap2/board-omap3evm.c | 82 +++ arch/arm/mach-omap2/board-omap3touchbook.c |6 +- arch/arm/mach-omap2/board-overo.c |5 +- arch/arm/mach-omap2/board-zoom.c |5 +- arch/arm/mach-omap2/common-board-devices.c | 46 -- arch/arm/mach-omap2/common-board-devices.h |1 - arch/arm/mach-omap2/gpmc-nand.c| 88 +-- arch/arm/mach-omap2/gpmc.c | 1083 arch/arm/plat-omap/include/plat/gpmc.h | 34 +- arch/arm/plat-omap/include/plat/nand.h |9 +- drivers/mtd/nand/omap2.c | 19 +- 16 files changed, 869 insertions(+), 601 deletions(-) -- 1.7.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/5] ARM: OMAP2+: gpmc: driver conversion
Convert GPMC code to driver. Boards using GPMC
should provide driver with type of configuration,
timing, GPMC address space details (if already
configured, driver will retrieve, as is existing).
Platform devices would the be created for each
connected peripheral (peripheral details also to
be passed by board so that it reaches respective
driver). And GPMC driver would populate memory
resource details for the driver of connected
peripheral.
A peripheral connected to GPMC can have multiple
address spaces using different chip select. Hence
GPMC driver has been provided capability to
distinguish this scenario, i.e. create platform
devices only once for each connected peripheral,
and not for each configured chip select. The
peripheral that made it necessary was tusb6010.
Final destination aimed for this driver is MFD.
But before that all existing GPMC users has to be
converted to work with this driver. This would
likely result in removal of gpmc_create_child
and probably use MFD APIs instead.
NAND driver for GPMC is tightly coupled with GPMC
driver (GPMC has few blocks exclusively for NAND),
while that is not the case for most of the other
users (they need GPMCs help only for initial
configuration). Currently NAND driver manage using
exported GPMC symbols. This is being planned to
remove later would need informing NAND driver
about GPMC NAND registers. This would help to have
export symbol free GPMC driver, and probably
mv omap2.c gpmc-nand.c for OMAP NAND driver.
Thanks to Vaibhav Hiremath for his ideas on this.
Acquiring CS# for NAND is done on a few boards.
It means, depending on bootloader to embed this
information. Probably CS# being used can be set
in the Kernel, and acquiring it can be removed.
If ever this capbility is needed, GPMC driver
has to be made aware of handling it.
OneNAND - as it may involve reconfiguring GPMC for
synchronous may need a quirk to handle or driver
has to be made more intelligent to handle it.
Code below comment GPMC CLK related may have
to continue live in platform folders (even if the
driver is moved to MFD) as input clock is beyond
the control of GPMC and calculating timing for
the peripheral may need other helpers.
TODO (or not?)
1. NAND driver deal with GPMC NAND block
2. Remove struct gpmc * stored as static
3. Convert all peripherals to use GPMC driver
4. Devise method to handle OneNAND cleanly
5. Handle acquiring CS# cases
6. Convert to MFD driver
Signed-off-by: Afzal Mohammed af...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 1083 +++-
arch/arm/plat-omap/include/plat/gpmc.h | 34 +-
2 files changed, 672 insertions(+), 445 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..954fa22 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,8 +14,11 @@
*/
#undef DEBUG
+#include linux/platform_device.h
+
#include linux/irq.h
#include linux/kernel.h
+#include linux/slab.h
#include linux/init.h
#include linux/err.h
#include linux/clk.h
@@ -64,248 +67,99 @@
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
-/* Structure to save gpmc cs context */
-struct gpmc_cs_config {
- u32 config1;
- u32 config2;
- u32 config3;
- u32 config4;
- u32 config5;
- u32 config6;
- u32 config7;
- int is_valid;
-};
-
-/*
- * Structure to save/restore gpmc context
- * to support core off on OMAP3
- */
-struct omap3_gpmc_regs {
- u32 sysconfig;
- u32 irqenable;
- u32 timeout_ctrl;
- u32 config;
- u32 prefetch_config1;
- u32 prefetch_config2;
- u32 prefetch_control;
- struct gpmc_cs_config cs_context[GPMC_CS_NUM];
-};
-
-static struct resource gpmc_mem_root;
-static struct resource gpmc_cs_mem[GPMC_CS_NUM];
-static DEFINE_SPINLOCK(gpmc_mem_lock);
-static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
-static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
-
-static void __iomem *gpmc_base;
-
-static struct clk *gpmc_l3_clk;
-
-static irqreturn_t gpmc_handle_irq(int irq, void *dev);
-static void gpmc_write_reg(int idx, u32 val)
-{
- __raw_writel(val, gpmc_base + idx);
-}
-
-static u32 gpmc_read_reg(int idx)
-{
- return __raw_readl(gpmc_base + idx);
-}
-
-static void gpmc_cs_write_byte(int cs, int idx, u8 val)
-{
- void __iomem *reg_addr;
+#defineDRIVER_NAME omap-gpmc
- reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
- __raw_writeb(val, reg_addr);
-}
+struct gpmc_child {
+ char*name;
+ int id;
+ struct resource *res;
+ unsignednum_res;
+ struct resource gpmc_res[GPMC_CS_NUM];
+ unsignedgpmc_num_res;
+ void*pdata;
+ unsignedpdata_size;
+};
[RFC][PATCH 2/5] ARM: OMAP2+: nand: create platform data structure
New API for updating nand platform data. This has
been created by unifying the two existing ones and
taking out gpmc hardware handling.
From now on, platforms can call omap_nand_init to
initialize platform nand structures, it's fields.
Or can statically create the same.
Acquiring gpmc CS has been removed. Acquiring CS
probably should be avoided, if ever required, do
in GPMC driver.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c |6 ++-
arch/arm/mach-omap2/board-flash.c | 63 ++--
arch/arm/mach-omap2/board-flash.h | 13 --
arch/arm/mach-omap2/board-ldp.c|4 +-
arch/arm/mach-omap2/board-omap3beagle.c|6 ++-
arch/arm/mach-omap2/board-omap3touchbook.c |6 ++-
arch/arm/mach-omap2/board-overo.c |5 ++-
arch/arm/mach-omap2/board-zoom.c |5 ++-
arch/arm/mach-omap2/common-board-devices.c | 46
arch/arm/mach-omap2/common-board-devices.h |1 -
10 files changed, 61 insertions(+), 94 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 11cd2a8..1a9ce9d 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -59,6 +59,7 @@
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
#define OMAP_DM9000_GPIO_IRQ 25
@@ -648,8 +649,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
-ARRAY_SIZE(devkit8000_nand_partitions));
+ omap_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), GPMC_CS_NUM + 1,
+ NAND_BUSWIDTH_16, NULL);
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0349fd2..26c70b8 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -108,45 +108,45 @@ __init board_onenand_init(struct mtd_partition
*nor_parts, u8 nr_parts, u8 cs)
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
+static struct omap_nand_platform_data omap_nand_data = {
+ .gpmc_t = nand_default_timings,
};
-void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+struct omap_nand_platform_data *
+__init omap_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
- board_nand_data.cs = cs;
- board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
- board_nand_data.devsize = nand_type;
-
- board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
- board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
- gpmc_nand_init(board_nand_data);
+ omap_nand_data.cs = cs;
+ omap_nand_data.parts= nand_parts;
+ omap_nand_data.nr_parts = nr_parts;
+ omap_nand_data.devsize = nand_type;
+ omap_nand_data.gpmc_t = gpmc_t;
+
+ return omap_nand_data;
}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
@@ -242,6 +242,7 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
if (nandcs GPMC_CS_NUM)
pr_err(NAND: Unable to find configuration in GPMC\n);
else
- board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ omap_nand_init(partition_info[2].parts,
+
[RFC][PATCH 3/5] ARM: OMAP2+: gpmc-nand: populate gpmc configs
Currently gpmc is configured in platform for nand.
As configuring gpmc has been moved to gpmc driver,
populate details needed for the driver to configure
gpmc. gpmc driver would configure based on this
information.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c| 88
arch/arm/plat-omap/include/plat/nand.h |8 +--
2 files changed, 39 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 386dec8..acec0ea 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -21,24 +21,29 @@
#include plat/board.h
#include plat/gpmc.h
-static struct resource gpmc_nand_resource = {
- .flags = IORESOURCE_MEM,
+
+#defineGPMC_NAND_CONFIG_NUM3
+
+static struct gpmc_config gpmc_nand_config[GPMC_NAND_CONFIG_NUM] = {
+ { GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND},
};
-static struct platform_device gpmc_nand_device = {
+static struct gpmc_device_pdata gpmc_nand_info = {
.name = omap2-nand,
.id = 0,
- .num_resources = 1,
- .resource = gpmc_nand_resource,
+ .config = gpmc_nand_config,
+ .num_config = ARRAY_SIZE(gpmc_nand_config),
};
-static int omap2_nand_gpmc_retime(struct omap_nand_platform_data
*gpmc_nand_data)
-{
- struct gpmc_timings t;
- int err;
+static struct gpmc_timings t;
- if (!gpmc_nand_data-gpmc_t)
+static struct gpmc_timings *
+gpmc_nand_retime(struct omap_nand_platform_data *gpmc_nand_data)
+{
+ if (!gpmc_nand_data-gpmc_t) {
+ pr_warn(gpmc timings not provided\n);
return 0;
+ }
memset(t, 0, sizeof(t));
t.sync_clk = gpmc_nand_data-gpmc_t-sync_clk;
@@ -68,56 +73,31 @@ static int omap2_nand_gpmc_retime(struct
omap_nand_platform_data *gpmc_nand_data
t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
- /* Configure GPMC */
- if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 1);
- else
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 0);
- gpmc_cs_configure(gpmc_nand_data-cs,
- GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND);
- err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
- if (err)
- return err;
-
- return 0;
+ return t;
}
-int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data)
+struct gpmc_device_pdata *
+__init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data)
{
- int err = 0;
- struct device *dev = gpmc_nand_device.dev;
+ gpmc_nand_info.pdata = gpmc_nand_data;
+ gpmc_nand_info.pdata_size = sizeof(*gpmc_nand_data);
- gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+ gpmc_nand_info.cs = gpmc_nand_data-cs;
+ gpmc_nand_info.mem_size = NAND_IO_SIZE;
- err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
- gpmc_nand_data-phys_base);
- if (err 0) {
- dev_err(dev, Cannot request GPMC CS\n);
- return err;
- }
+ gpmc_nand_info.timing = gpmc_nand_retime(gpmc_nand_data);
-/* Set timings in GPMC */
- err = omap2_nand_gpmc_retime(gpmc_nand_data);
- if (err 0) {
- dev_err(dev, Unable to set gpmc timings: %d\n, err);
- return err;
- }
-
- /* Enable RD PIN Monitoring Reg */
- if (gpmc_nand_data-dev_ready) {
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_RDY_BSY, 1);
- }
-
- err = platform_device_register(gpmc_nand_device);
- if (err 0) {
- dev_err(dev, Unable to register NAND device\n);
- goto out_free_cs;
- }
-
- return 0;
+ gpmc_nand_config[1].cmd = GPMC_CONFIG_DEV_SIZE;
+ if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
+ gpmc_nand_config[1].val = 1;
+ else
+ gpmc_nand_config[1].val = 0;
-out_free_cs:
- gpmc_cs_free(gpmc_nand_data-cs);
+ gpmc_nand_config[2].cmd = GPMC_CONFIG_RDY_BSY;
+ if (gpmc_nand_data-dev_ready)
+ gpmc_nand_config[2].val = 1;
+ else
+ gpmc_nand_config[2].val = 0;
- return err;
+ return gpmc_nand_info;
}
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 67fc506..d2daeba 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -35,10 +35,12 @@ struct omap_nand_platform_data {
#defineNAND_IO_SIZE4
#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
-extern int gpmc_nand_init(struct omap_nand_platform_data
[RFC][PATCH 4/5] mtd: nand: omap2: obtain memory from resource
gpmc being converted to driver, provides drivers
of peripheral connected memory space used by the
peripheral as memory resource.
Modify nand omap driver to obtain memory detials
from resource structure.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |1 -
drivers/mtd/nand/omap2.c | 19 +++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index d2daeba..fa49fc4 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -26,7 +26,6 @@ struct omap_nand_platform_data {
booldev_ready;
int gpmc_irq;
enum nand_ioxfer_type;
- unsigned long phys_base;
int devsize;
enum omap_ecc ecc_opt;
};
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index b3a883e..f6c018e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -118,6 +118,7 @@ struct omap_nand_info {
int gpmc_cs;
unsigned long phys_base;
+ unsigned long mem_size;
struct completion comp;
int dma_ch;
int gpmc_irq;
@@ -931,6 +932,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_platform_data *pdata;
int err;
int i, offset;
+ struct resource *res;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -950,7 +952,6 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
info-pdev = pdev;
info-gpmc_cs = pdata-cs;
- info-phys_base = pdata-phys_base;
info-mtd.priv = info-nand;
info-mtd.name = dev_name(pdev-dev);
@@ -962,13 +963,23 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* NAND write protect off */
gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_WP, 0);
- if (!request_mem_region(info-phys_base, NAND_IO_SIZE,
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL) {
+ err = -EINVAL;
+ dev_err(pdev-dev, error getting memory resource\n);
+ goto out_free_info;
+ }
+
+ info-phys_base = res-start;
+ info-mem_size = resource_size(res);
+
+ if (!request_mem_region(info-phys_base, info-mem_size,
pdev-dev.driver-name)) {
err = -EBUSY;
goto out_free_info;
}
- info-nand.IO_ADDR_R = ioremap(info-phys_base, NAND_IO_SIZE);
+ info-nand.IO_ADDR_R = ioremap(info-phys_base, info-mem_size);
if (!info-nand.IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
@@ -1109,7 +1120,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
return 0;
out_release_mem_region:
- release_mem_region(info-phys_base, NAND_IO_SIZE);
+ release_mem_region(info-phys_base, info-mem_size);
out_free_info:
kfree(info);
--
1.7.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[TMP][PATCH 5/5] OMAP3EVM: Test gpmc-nand
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 82 ++
1 file changed, 82 insertions(+)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a659e19..9ed48d4 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -23,6 +23,7 @@
#include linux/input/matrix_keypad.h
#include linux/leds.h
#include linux/interrupt.h
+#include linux/mtd/nand.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
@@ -41,6 +42,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
+#include plat/nand.h
#include plat/board.h
#include plat/usb.h
#include common.h
@@ -52,6 +54,7 @@
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
#include common-board-devices.h
+#include board-flash.h
#define OMAP3_EVM_TS_GPIO 175
#define OMAP3_EVM_EHCI_VBUS22
@@ -102,6 +105,9 @@ static void __init omap3_evm_get_revision(void)
}
}
+#undef CONFIG_SMSC911X
+#undef CONFIG_SMSC911X_MODULE
+
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include plat/gpmc-smsc911x.h
@@ -533,6 +539,41 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata
= {
.reset_gpio_port[2] = -EINVAL
};
+/*
+ * NAND
+ */
+static struct mtd_partition omap3_evm_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 40 * (64 * 2048),
+ },
+ {
+ .name = File System - NAND,
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x78 */
+ },
+};
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux omap35x_board_mux[] __initdata = {
OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
@@ -632,8 +673,30 @@ static void __init omap3_evm_wl12xx_init(void)
#endif
}
+static struct gpmc_pdata gpmc_data;
+
+static struct resource gpmc_resources[] = {
+ {
+ .start = OMAP34XX_GPMC_BASE,
+ .end = OMAP34XX_GPMC_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device gpmc_device = {
+ .name = omap-gpmc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(gpmc_resources),
+ .resource = gpmc_resources,
+ .dev= {
+ .platform_data = gpmc_data,
+ }
+};
+
static void __init omap3_evm_init(void)
{
+ struct omap_nand_platform_data *nand_data;
+
omap3_evm_get_revision();
if (cpu_is_omap3630())
@@ -684,6 +747,25 @@ static void __init omap3_evm_init(void)
omap3evm_init_smsc911x();
omap3_evm_display_init();
omap3_evm_wl12xx_init();
+ /* NAND */
+ nand_data = omap_nand_init(omap3_evm_nand_partitions,
+ ARRAY_SIZE(omap3_evm_nand_partitions),
+ 0, NAND_BUSWIDTH_16, nand_default_timings);
+ if (nand_data == NULL) {
+ pr_err(omap_nand_init() failed\n);
+ return;
+ }
+
+ gpmc_data.device_pdata = gpmc_nand_init(nand_data);
+ if (gpmc_data.device_pdata == NULL) {
+ pr_err(gpmc_nand_init() failed\n);
+ return;
+ }
+
+ gpmc_data.num_device++;
+ gpmc_data.fclk_rate = gpmc_get_fclk_period();
+
+ platform_device_register(gpmc_device);
}
MACHINE_START(OMAP3EVM, OMAP3 EVM)
--
1.7.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
Hi Paul, On Fri, Mar 23, 2012 at 5:10 AM, Paul Walmsley p...@pwsan.com wrote: Hi On Thu, 22 Mar 2012, Raja, Govindraj wrote: Sorry I for got to add that, here are details on what was tested. 1.) OMAP2430 SDP : Boot tested with uart1 as console. 2.) OMAP3430 SDP: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 3.) OMAP3630 - Beagle XM: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 4.) OMAP4430 - PANDA: Boot test, suspend/resume tests 5.) OMAP4460 - PANDA: Boot test. What kernel .config was used for these tests? omap2plus_defconfig was used. the same kernel image was tested with all these boards. (kernel image was built along with initramfs support using minimal busybox filesystem) -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Mar 21, 2012 at 7:29 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Mon, Mar 19, 2012 at 17:14:30, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: I think you made very good point here. With the above patch, we are almost missing the capability of registering dmtimer as a clocksource for OMAP. It will always use 32k-counter, and never fall back to dmtimer. Then the only options we have here is, 1) Register both the timers, 32k-counter and dmtimer for clocksource; let Kernel pick up best rating clocksource out of these two. In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better Rating. User can choose the 32k-counter clocksource via bootargs. Impact: without bootargs for clocksource selection, kernel will choose dmtimer, impacting loss of time during suspend/resume. 2) Let the current code be as is, means, the clocksource registration will Happened based on #ifdef CONFIG_OMAP_32K_TIMER and this option selection will be Controlled by Kconfig rules. How about the 3rd option? 3), take the way in your patch 1) at default, but will switch to register dmtimer directly and bypass 32k-counter if user need it via kernel parameter. As far as I can think of, the situations required for dmtimer are high-frequency perf sample and high precision trace points, so looks it is OK to take 32k-counter at default. But if you register both the timers (dmtimer 32ksync), then initially kernel will only pick up dmtimer, as this has better rating. And late in Looks not so, I found that 32ksync is always selected as the default clocksource if both are registered. the boot sequence clocksource switch will happen, base on kernel parameter (clocksource=). So logically dmtimer will be always used as a default here. Not so at least on my Pandaboard. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/13] Add dummy smsc911x regulators to zoom-debugboard.
Hi Russ, Mark,
On 03/22/12 20:29, Russ Dill wrote:
On Thu, Mar 22, 2012 at 4:37 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Wed, Mar 21, 2012 at 10:19:54PM -0700, Russ Dill wrote:
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
Why do none of these boards use -1 as the ID for the device?
Commit 21b42731 (omap: convert boards that use SMSC911x to use
gpmc-smsc911x) changed several board files to use the gpmc-smsc911x.c
common code rather than register the device themselves, in the process
it changed many of the id's from -1 to 0. This happened in the 3.0
merge window. I can certainly change it back.
IIRC, everybody were very sensible to each new l-o-f back then,
so making the id = 0 (leaving it uninitialized) helped with
reducing some ~10 lines more...
Of course we can change this now, but what is the real problem
with having device id = 0 and not -1?
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: more fixes for v3.4
On Thu, Mar 22, 2012 at 8:49 PM, Kevin Hilman khil...@ti.com wrote: Hi Grant, Please pull these OMAP GPIO fixes for v3.4. These fix some rather serious regressions introduced by the cleanup and runtime PM conversion series which is also queued for v3.4. This branch is based on your gpio/next branch. This version is functionally the same as the version you previously merged (and I asked you to back it out), but this version has some better changlogs, and I added reviewed-by and s-o-b from me as well. Thanks, Kevin Merged, thanks. g. The following changes since commit 81b279d80a63628e580c71a31d30a8c3b3047ad4: gpio/davinci: fix enabling unbanked GPIO IRQs (2012-03-12 11:53:33 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/fixes/gpio-2 for you to fetch changes up to 7fcca715de3438b8fc3c8a144702f3a95c8ff63c: gpio/omap: fix redundant decoding of gpio offset (2012-03-21 10:21:24 +0530) Tarun Kanti DebBarma (7): gpio/omap: fix wakeup_en register update in _set_gpio_wakeup() gpio/omap: fix trigger type to unsigned gpio/omap: fix _set_gpio_irqenable implementation gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_* gpio/omap: fix incorrect update to context.irqenable1 gpio/omap: fix redundant decoding of gpio offset drivers/gpio/gpio-omap.c | 47 -- 1 file changed, 25 insertions(+), 22 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/5] Convert GPMC to driver
Hi Mohammed, On 3/23/2012 7:36 AM, Afzal Mohammed wrote: Hi, Convert GPCM code to be a driver. Existing GPMC NAND platform handling has been modified to work with the new GPMC driver (patches 2 3). Patch 5 is to test the driver in OMAP3EVM. Hehe, cool, thanks for that series, Benoit Once all the users has been converted to use this driver, would be converted to MFD type. TODO: 1. Let OMAP NAND driver deal with GPMC NAND block 2. Remove struct gpmc * stored as static 3. Convert all peripherals to use GPMC driver 4. Devise method to handle OneNAND cleanly 5. Handle acquiring CS# cases 6. Convert to MFD driver Regards Afzal Afzal Mohammed (5): ARM: OMAP2+: gpmc: driver conversion ARM: OMAP2+: nand: create platform data structure ARM: OMAP2+: gpmc-nand: populate gpmc configs mtd: nand: omap2: obtain memory from resource OMAP3EVM: Test gpmc-nand arch/arm/mach-omap2/board-devkit8000.c |6 +- arch/arm/mach-omap2/board-flash.c | 63 +- arch/arm/mach-omap2/board-flash.h | 13 +- arch/arm/mach-omap2/board-ldp.c|4 +- arch/arm/mach-omap2/board-omap3beagle.c|6 +- arch/arm/mach-omap2/board-omap3evm.c | 82 +++ arch/arm/mach-omap2/board-omap3touchbook.c |6 +- arch/arm/mach-omap2/board-overo.c |5 +- arch/arm/mach-omap2/board-zoom.c |5 +- arch/arm/mach-omap2/common-board-devices.c | 46 -- arch/arm/mach-omap2/common-board-devices.h |1 - arch/arm/mach-omap2/gpmc-nand.c| 88 +-- arch/arm/mach-omap2/gpmc.c | 1083 arch/arm/plat-omap/include/plat/gpmc.h | 34 +- arch/arm/plat-omap/include/plat/nand.h |9 +- drivers/mtd/nand/omap2.c | 19 +- 16 files changed, 869 insertions(+), 601 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/12] Fixup gmpc smsc911x regulator handling
This patchset cleans up some problems with gpmc connected smsc911x chips. Commit c7e963f616 (net/smsc911x: Add regulator support) broke registration of gpmc connected smcs911x devices on machines with regulator support, but without dummy regulator support by requiring regulators. This version fixes a rebase problem and drops the fixed-helper.c kernel doc cleanup as Mark Brown is picking that up. There was some discussion as whether or not to undo the ID change that happened on several boards due to 21b42731 (omap: convert boards that use SMSC911x to use gpmc-smsc911x), that can likely be changed in a subsequent patch if necessary. Commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators) fixed the issue for boards with single smsc911x devices, but attempted to register the fixed voltage regulator twice for boards with 2 devices which fails. bb60424af5 (ARM: OMAP2+: gpmc-smsc911x: only register regulator for first instance) cleaned this up a little bit by only automatically registering regulators for the first device, but still did not allow the second device to function because it lacked regulators. The new patchset pushes register regulation back to where it belongs, in the board files. It eliminates a lot of boilerplate by utilizing the new regulator_register_fixed function. Additionally, there are 3 cleanup patches in this patch series. One is a fix for potential stale data usage in gpmc-smsc911x, another removes dead code, and the final one eliminates an unneeded static variable in gpmc-smsc911x. These patches have been compile tested on next-20120322 and have been tested on omap3evm (am37x-evm) hardware. Russ Dill (12): Remove odd gpmc_cfg/board_data redirection. Fix possible stale smsc911x flags. Remove unused rate calculation. Remove regulator support from gmpc-smsc911x Add dummy smsc911x regulators to cm-t35. Add dummy smsc911x regulators to igep0020. Add dummy smsc911x regulators to ldp. Add dummy smsc911x regulators to omap3evm. Add dummy smsc911x regulators to omap3logic. Add dummy smsc911x regulators to omap3stalker. Add dummy smsc911x regulators to overo. Add dummy smsc911x regulators to zoom-debugboard. arch/arm/mach-omap2/board-cm-t35.c |9 arch/arm/mach-omap2/board-igep0020.c|6 +++ arch/arm/mach-omap2/board-ldp.c |7 +++ arch/arm/mach-omap2/board-omap3evm.c| 15 +++ arch/arm/mach-omap2/board-omap3logic.c |7 +++ arch/arm/mach-omap2/board-omap3stalker.c| 16 +++ arch/arm/mach-omap2/board-overo.c |8 +++ arch/arm/mach-omap2/board-zoom-debugboard.c |9 arch/arm/mach-omap2/gpmc-smsc911x.c | 65 +-- 9 files changed, 61 insertions(+), 81 deletions(-) -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] Remove odd gpmc_cfg/board_data redirection.
This seems to be a leftover from when gpmc-smsc911x.c was copied
from gpmc-smc91x.c.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 5e5880d..aa0c296 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -26,8 +26,6 @@
#include plat/gpmc.h
#include plat/gpmc-smsc911x.h
-static struct omap_smsc911x_platform_data *gpmc_cfg;
-
static struct resource gpmc_smsc911x_resources[] = {
[0] = {
.flags = IORESOURCE_MEM,
@@ -93,14 +91,12 @@ static struct platform_device gpmc_smsc911x_regulator = {
* assume that pin multiplexing is done in the board-*.c file,
* or in the bootloader.
*/
-void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *board_data)
+void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
{
struct platform_device *pdev;
unsigned long cs_mem_base;
int ret;
- gpmc_cfg = board_data;
-
if (!gpmc_cfg-id) {
ret = platform_device_register(gpmc_smsc911x_regulator);
if (ret 0) {
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/12] Fix possible stale smsc911x flags.
If this function is called the first time with flags set, and the
second time without flags set then the leftover flags from the first
called will be used rather than the desired default flags.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index aa0c296..f9446ea 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -39,7 +39,6 @@ static struct smsc911x_platform_config gpmc_smsc911x_config =
{
.phy_interface = PHY_INTERFACE_MODE_MII,
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
.irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
- .flags = SMSC911X_USE_16BIT,
};
static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
@@ -135,8 +134,7 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *gpmc_cfg)
gpio_set_value(gpmc_cfg-gpio_reset, 1);
}
- if (gpmc_cfg-flags)
- gpmc_smsc911x_config.flags = gpmc_cfg-flags;
+ gpmc_smsc911x_config.flags = gpmc_cfg-flags ? : SMSC911X_USE_16BIT;
pdev = platform_device_register_resndata(NULL, smsc911x, gpmc_cfg-id,
gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] Remove unused rate calculation.
Looking back into git history, this code was never used and was
probably left over from a copy/paste.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |9 -
arch/arm/mach-omap2/board-omap3stalker.c |9 -
2 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a659e19..548e1ef 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,15 +114,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
static inline void __init omap3evm_init_smsc911x(void)
{
- struct clk *l3ck;
- unsigned int rate;
-
- l3ck = clk_get(NULL, l3_ck);
- if (IS_ERR(l3ck))
- rate = 1;
- else
- rate = clk_get_rate(l3ck);
-
/* Configure ethernet controller reset gpio */
if (cpu_is_omap3430()) {
if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 6410043..de95352 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -72,15 +72,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
static inline void __init omap3stalker_init_eth(void)
{
- struct clk *l3ck;
- unsigned int rate;
-
- l3ck = clk_get(NULL, l3_ck);
- if (IS_ERR(l3ck))
- rate = 1;
- else
- rate = clk_get_rate(l3ck);
-
omap_mux_init_gpio(19, OMAP_PIN_INPUT_PULLUP);
gpmc_smsc911x_init(smsc911x_cfg);
}
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] Remove regulator support from gmpc-smsc911x
Adding in support for regulators here creates several headaches.
- Boards that declare their own regulator cannot use this function.
- Multiple calls to this function require special handling.
- Boards that declare id's other than '0' need special handling.
Now that there is a simple regulator_register_fixed, we can push
this registration back into the board files.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 55 ---
1 files changed, 0 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index f9446ea..b6c77be 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,8 +19,6 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/smsc911x.h
-#include linux/regulator/fixed.h
-#include linux/regulator/machine.h
#include plat/board.h
#include plat/gpmc.h
@@ -41,50 +39,6 @@ static struct smsc911x_platform_config gpmc_smsc911x_config
= {
.irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
};
-static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
- REGULATOR_SUPPLY(vddvario, smsc911x.0),
- REGULATOR_SUPPLY(vdd33a, smsc911x.0),
-};
-
-/* Generic regulator definition to satisfy smsc911x */
-static struct regulator_init_data gpmc_smsc911x_reg_init_data = {
- .constraints = {
- .min_uV = 330,
- .max_uV = 330,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(gpmc_smsc911x_supply),
- .consumer_supplies = gpmc_smsc911x_supply,
-};
-
-static struct fixed_voltage_config gpmc_smsc911x_fixed_reg_data = {
- .supply_name= gpmc_smsc911x,
- .microvolts = 330,
- .gpio = -EINVAL,
- .startup_delay = 0,
- .enable_high= 0,
- .enabled_at_boot= 1,
- .init_data = gpmc_smsc911x_reg_init_data,
-};
-
-/*
- * Platform device id of 42 is a temporary fix to avoid conflicts
- * with other reg-fixed-voltage devices. The real fix should
- * involve the driver core providing a way of dynamically
- * assigning a unique id on registration for platform devices
- * in the same name space.
- */
-static struct platform_device gpmc_smsc911x_regulator = {
- .name = reg-fixed-voltage,
- .id = 42,
- .dev = {
- .platform_data = gpmc_smsc911x_fixed_reg_data,
- },
-};
-
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -96,15 +50,6 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *gpmc_cfg)
unsigned long cs_mem_base;
int ret;
- if (!gpmc_cfg-id) {
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n,
- ret);
- return;
- }
- }
-
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
pr_err(Failed to request GPMC mem region\n);
return;
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/12] Add dummy smsc911x regulators to cm-t35.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 41b0a2f..289ded3 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -26,6 +26,7 @@
#include linux/i2c/at24.h
#include linux/i2c/twl.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/mmc/host.h
@@ -630,10 +631,18 @@ static inline void cm_t3730_init_mux(void) {}
static struct omap_board_config_kernel cm_t35_config[] __initdata = {
};
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+ REGULATOR_SUPPLY(vddvario, smsc911x.1),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.1),
+};
+
static void __init cm_t3x_common_init(void)
{
omap_board_config = cm_t35_config;
omap_board_config_size = ARRAY_SIZE(cm_t35_config);
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/12] Add dummy smsc911x regulators to igep0020.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-igep0020.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index e558800..930c0d3 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -634,8 +634,14 @@ static void __init igep_wlan_bt_init(void)
static inline void __init igep_wlan_bt_init(void) { }
#endif
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init igep_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
/* Get IGEP2 hardware revision */
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] Add dummy smsc911x regulators to ldp.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-ldp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d50a562a..1b60495 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/spi/spi.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
#include linux/io.h
@@ -410,8 +411,14 @@ static struct mtd_partition ldp_nand_partitions[] = {
};
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap_ldp_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
ldp_init_smsc911x();
omap_i2c_init();
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/12] Add dummy smsc911x regulators to omap3evm.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 548e1ef..6a5e57c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -623,9 +623,15 @@ static void __init omap3_evm_wl12xx_init(void)
#endif
}
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap3_evm_init(void)
{
omap3_evm_get_revision();
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
if (cpu_is_omap3630())
omap3_mux_init(omap36x_board_mux, OMAP_PACKAGE_CBB);
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] Add dummy smsc911x regulators to omap3logic.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3logic.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 4a7d8c8..9b3c141 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -23,6 +23,7 @@
#include linux/io.h
#include linux/gpio.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -188,8 +189,14 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap3logic_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3torpedo_fix_pbias_voltage();
omap3logic_i2c_init();
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] Add dummy smsc911x regulators to omap3stalker.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3stalker.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index de95352..4dffc95 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -24,6 +24,7 @@
#include linux/input.h
#include linux/gpio_keys.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
@@ -410,8 +411,14 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap3_stalker_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
omap_board_config = omap3_stalker_config;
omap_board_config_size = ARRAY_SIZE(omap3_stalker_config);
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] Add dummy smsc911x regulators to overo.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-overo.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 668533e..33aa391 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -498,10 +498,18 @@ static struct gpio overo_bt_gpios[] __initdata = {
{ OVERO_GPIO_BT_NRESET, GPIOF_OUT_INIT_HIGH,lcd bl enable },
};
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+ REGULATOR_SUPPLY(vddvario, smsc911x.1),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.1),
+};
+
static void __init overo_init(void)
{
int ret;
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_hsmmc_init(mmc);
overo_i2c_init();
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/9] ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table
As suggested, this table is an optimized version for rx51 and we
remove it in order to consolidate the cpuidle code between omap3
and omap4, we remove this specific data definition which is used
to override the default omap3 latencies but at the cost of extra
code and complexity.
In order to not lose the values which probably took time to be
measured, the table is converted into a comment with an array
description.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/board-rx51.c | 38 +---
arch/arm/mach-omap2/cpuidle34xx.c | 17
arch/arm/mach-omap2/pm.h |9
3 files changed, 18 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 27f01f0..2da92a6 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -59,25 +59,24 @@ static struct platform_device leds_gpio = {
};
/*
- * cpuidle C-states definition override from the default values.
- * The 'exit_latency' field is the sum of sleep and wake-up latencies.
- */
-static struct cpuidle_params rx51_cpuidle_params[] = {
- /* C1 */
- {110 + 162, 5 , 1},
- /* C2 */
- {106 + 180, 309, 1},
- /* C3 */
- {107 + 410, 46057, 0},
- /* C4 */
- {121 + 3374, 46057, 0},
- /* C5 */
- {855 + 1146, 46057, 1},
- /* C6 */
- {7580 + 4134, 484329, 0},
- /* C7 */
- {7505 + 15274, 484329, 1},
-};
+ * cpuidle C-states definition for rx51.
+ *
+ * The 'exit_latency' field is the sum of sleep
+ * and wake-up latencies.
+
+-
+ | state | exit_latency | target_residency |
+-
+ | C1 |110 + 162 |5 |
+ | C2 |106 + 180 | 309 |
+ | C3 |107 + 410 |46057 |
+ | C4 |121 + 3374 |46057 |
+ | C5 |855 + 1146 |46057 |
+ | C6 | 7580 + 4134 | 484329 |
+ | C7 | 7505 + 15274 | 484329 |
+-
+
+*/
extern void __init rx51_peripherals_init(void);
@@ -98,7 +97,6 @@ static void __init rx51_init(void)
struct omap_sdrc_params *sdrc_params;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
- omap3_pm_init_cpuidle(rx51_cpuidle_params);
omap_serial_init();
sdrc_params = nokia_get_sdram_timings();
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 464cffd..d67431a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -306,23 +306,6 @@ select_state:
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
-void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
-{
- int i;
-
- if (!cpuidle_board_params)
- return;
-
- for (i = 0; i OMAP3_NUM_STATES; i++) {
- cpuidle_params_table[i].valid = cpuidle_board_params[i].valid;
- cpuidle_params_table[i].exit_latency =
- cpuidle_board_params[i].exit_latency;
- cpuidle_params_table[i].target_residency =
- cpuidle_board_params[i].target_residency;
- }
- return;
-}
-
struct cpuidle_driver omap3_idle_driver = {
.name = omap3_idle,
.owner =THIS_MODULE,
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index a051431..af73a86 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -51,15 +51,6 @@ struct cpuidle_params {
u8 valid; /* validates the C-state */
};
-#if defined(CONFIG_PM) defined(CONFIG_CPU_IDLE)
-extern void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params);
-#else
-static
-inline void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
-{
-}
-#endif
-
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 3/9] ARM: OMAP3: cpuidle - set enable_off_mode as static
This variable is only used in the pm-debug.c file.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/pm-debug.c |2 +-
arch/arm/mach-omap2/pm.h | 30 --
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..86aa398 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -38,7 +38,7 @@
#include prm2xxx_3xxx.h
#include pm.h
-u32 enable_off_mode;
+static u32 enable_off_mode;
#ifdef CONFIG_DEBUG_FS
#include linux/debugfs.h
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index af73a86..f5c3072 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -25,6 +25,18 @@ extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
+/*
+ * cpuidle mach specific parameters
+ *
+ * The board code can override the default C-states definition using
+ * omap3_pm_init_cpuidle
+ */
+struct cpuidle_params {
+ u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
+ u32 target_residency;
+ u8 valid; /* validates the C-state */
+};
+
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
extern int omap4_opp_init(void);
@@ -39,27 +51,9 @@ static inline int omap4_opp_init(void)
}
#endif
-/*
- * cpuidle mach specific parameters
- *
- * The board code can override the default C-states definition using
- * omap3_pm_init_cpuidle
- */
-struct cpuidle_params {
- u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
- u32 target_residency;
- u8 valid; /* validates the C-state */
-};
-
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
-#ifdef CONFIG_PM_DEBUG
-extern u32 enable_off_mode;
-#else
-#define enable_off_mode 0
-#endif
-
#if defined(CONFIG_PM_DEBUG) defined(CONFIG_DEBUG_FS)
extern void pm_dbg_update_time(struct powerdomain *pwrdm, int prev);
#else
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 4/9] ARM: OMAP3: define cpuidle statically
Use the new cpuidle API and define in the driver the states.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 85 +---
1 files changed, 59 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 65b4e7aa..62e3cfd 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -228,23 +228,67 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
struct cpuidle_driver omap3_idle_driver = {
.name = omap3_idle,
.owner =THIS_MODULE,
+ .states = {
+ {
+ .enter= omap3_enter_idle,
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = MPU ON + CORE ON,
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 10 + 10,
+ .target_residency = 30,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = C2,
+ .desc = MPU ON + CORE ON,
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 50 + 50,
+ .target_residency = 300,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = C3,
+ .desc = MPU RET + CORE ON,
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 1500 + 1800,
+ .target_residency = 4000,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = C4,
+ .desc = MPU OFF + CORE ON,
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 2500 + 7500,
+ .target_residency = 12000,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = C5,
+ .desc = MPU RET + CORE RET,
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 3000 + 8500,
+ .target_residency = 15000,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = C6,
+ .desc = MPU OFF + CORE RET,
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 1 + 3,
+ .target_residency = 3,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = C7,
+ .desc = MPU OFF + CORE OFF,
+ },
+ },
+ .state_count = OMAP3_NUM_STATES,
};
-/* Helper to fill the C-state common data*/
-static inline void _fill_cstate(struct cpuidle_driver *drv,
- int idx, const char *descr)
-{
- struct cpuidle_state *state = drv-states[idx];
-
- state-exit_latency = cpuidle_params_table[idx].exit_latency;
- state-target_residency = cpuidle_params_table[idx].target_residency;
- state-flags= CPUIDLE_FLAG_TIME_VALID;
- state-enter= omap3_enter_idle_bm;
- sprintf(state-name, C%d, idx + 1);
- strncpy(state-desc, descr, CPUIDLE_DESC_LEN);
-
-}
-
/* Helper to register the driver_data */
static inline struct omap3_idle_statedata *_fill_cstate_usage(
struct cpuidle_device *dev,
@@ -277,50 +321,40 @@ int __init omap3_idle_init(void)
cam_pd = pwrdm_lookup(cam_pwrdm);
- drv-safe_state_index = -1;
dev = per_cpu(omap3_idle_dev, smp_processor_id());
/* C1 . MPU WFI + Core active */
- _fill_cstate(drv, 0, MPU ON + CORE ON);
- (drv-states[0])-enter = omap3_enter_idle;
- drv-safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
cx-valid = 1; /* C1 is always valid */
cx-mpu_state = PWRDM_POWER_ON;
cx-core_state = PWRDM_POWER_ON;
/* C2 . MPU WFI + Core inactive */
- _fill_cstate(drv, 1, MPU ON + CORE ON);
cx = _fill_cstate_usage(dev, 1);
cx-mpu_state = PWRDM_POWER_ON;
cx-core_state = PWRDM_POWER_ON;
/* C3 . MPU CSWR + Core inactive */
[RFC][PATCH 5/9] ARM: OMAP3: cpuidle - remove the 'valid' field
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 62e3cfd..39aa1b8 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -67,7 +67,6 @@ static struct cpuidle_params cpuidle_params_table[] = {
struct omap3_idle_statedata {
u32 mpu_state;
u32 core_state;
- u8 valid;
};
struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
@@ -297,7 +296,6 @@ static inline struct omap3_idle_statedata
*_fill_cstate_usage(
struct omap3_idle_statedata *cx = omap3_idle_data[idx];
struct cpuidle_state_usage *state_usage = dev-states_usage[idx];
- cx-valid = cpuidle_params_table[idx].valid;
cpuidle_set_statedata(state_usage, cx);
return cx;
@@ -325,7 +323,6 @@ int __init omap3_idle_init(void)
/* C1 . MPU WFI + Core active */
cx = _fill_cstate_usage(dev, 0);
- cx-valid = 1; /* C1 is always valid */
cx-mpu_state = PWRDM_POWER_ON;
cx-core_state = PWRDM_POWER_ON;
@@ -362,14 +359,13 @@ int __init omap3_idle_init(void)
* We disable C7 state as a result.
*/
if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
- cx-valid = 0;
+ drv-state_count = OMAP3_NUM_STATES - 1;
pr_warn(%s: core off state C7 disabled due to i583\n,
__func__);
}
cx-mpu_state = PWRDM_POWER_OFF;
cx-core_state = PWRDM_POWER_OFF;
- drv-state_count = OMAP3_NUM_STATES;
cpuidle_register_driver(omap3_idle_driver);
if (cpuidle_register_device(dev)) {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 2/9] ARM: OMAP3: cpuidle - remove next_valid_state function
As we will be able to remove C-states from userspace with the sysfs
API, this function is no longer needed. We remove it and that simplifies
the code for more consolidation.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 85 +
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index d67431a..65b4e7aa 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -164,84 +164,6 @@ return_sleep_time:
}
/**
- * next_valid_state - Find next valid C-state
- * @dev: cpuidle device
- * @drv: cpuidle driver
- * @index: Index of currently selected c-state
- *
- * If the state corresponding to index is valid, index is returned back
- * to the caller. Else, this function searches for a lower c-state which is
- * still valid (as defined in omap3_power_states[]) and returns its index.
- *
- * A state is valid if the 'valid' field is enabled and
- * if it satisfies the enable_off_mode condition.
- */
-static int next_valid_state(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
- struct cpuidle_state *curr = drv-states[index];
- struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
- u32 mpu_deepest_state = PWRDM_POWER_RET;
- u32 core_deepest_state = PWRDM_POWER_RET;
- int next_index = -1;
-
- if (enable_off_mode) {
- mpu_deepest_state = PWRDM_POWER_OFF;
- /*
-* Erratum i583: valable for ES rev Es1.2 on 3630.
-* CORE OFF mode is not supported in a stable form, restrict
-* instead the CORE state to RET.
-*/
- if (!IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583))
- core_deepest_state = PWRDM_POWER_OFF;
- }
-
- /* Check if current state is valid */
- if ((cx-valid)
- (cx-mpu_state = mpu_deepest_state)
- (cx-core_state = core_deepest_state)) {
- return index;
- } else {
- int idx = OMAP3_NUM_STATES - 1;
-
- /* Reach the current state starting at highest C-state */
- for (; idx = 0; idx--) {
- if (drv-states[idx] == curr) {
- next_index = idx;
- break;
- }
- }
-
- /* Should never hit this condition */
- WARN_ON(next_index == -1);
-
- /*
-* Drop to next valid state.
-* Start search from the next (lower) state.
-*/
- idx--;
- for (; idx = 0; idx--) {
- cx = cpuidle_get_statedata(dev-states_usage[idx]);
- if ((cx-valid)
- (cx-mpu_state = mpu_deepest_state)
- (cx-core_state = core_deepest_state)) {
- next_index = idx;
- break;
- }
- }
- /*
-* C1 is always valid.
-* So, no need to check for 'next_index == -1' outside
-* this loop.
-*/
- }
-
- return next_index;
-}
-
-/**
* omap3_enter_idle_bm - Checks for any bus activity
* @dev: cpuidle device
* @drv: cpuidle driver
@@ -254,7 +176,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- int new_state_idx;
u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
struct omap3_idle_statedata *cx;
int ret;
@@ -265,7 +186,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
*/
cam_state = pwrdm_read_pwrst(cam_pd);
if (cam_state == PWRDM_POWER_ON) {
- new_state_idx = drv-safe_state_index;
+ index = drv-safe_state_index;
goto select_state;
}
@@ -292,10 +213,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_next_state);
- new_state_idx = next_valid_state(dev, drv, index);
-
select_state:
- ret = omap3_enter_idle(dev, drv, new_state_idx);
+ ret = omap3_enter_idle(dev, drv, index);
/* Restore original PER state if it was modified */
if (per_next_state != per_saved_state)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[RFC][PATCH 6/9] ARM: OMAP3: cpuidle - remove cpuidle_params_table
We do not longer need the ''cpuidle_params_table' array as
we defined the states in the driver and we checked they are
all valid.
We also remove the structure definition as it is no longer used.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 28 +++-
arch/arm/mach-omap2/pm.h | 12
2 files changed, 3 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 39aa1b8..877a7e1 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -38,36 +38,14 @@
#ifdef CONFIG_CPU_IDLE
-/*
- * The latencies/thresholds for various C states have
- * to be configured from the respective board files.
- * These are some default values (which might not provide
- * the best power savings) used on boards which do not
- * pass these details from the board file.
- */
-static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
- {2 + 2, 5, 1},
- /* C2 */
- {10 + 10, 30, 1},
- /* C3 */
- {50 + 50, 300, 1},
- /* C4 */
- {1500 + 1800, 4000, 1},
- /* C5 */
- {2500 + 7500, 12000, 1},
- /* C6 */
- {3000 + 8500, 15000, 1},
- /* C7 */
- {1 + 3, 30, 1},
-};
-#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
-
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
u32 core_state;
};
+
+#define OMAP3_NUM_STATES 7
+
struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f5c3072..a41c8dd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -25,18 +25,6 @@ extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
-/*
- * cpuidle mach specific parameters
- *
- * The board code can override the default C-states definition using
- * omap3_pm_init_cpuidle
- */
-struct cpuidle_params {
- u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
- u32 target_residency;
- u8 valid; /* validates the C-state */
-};
-
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
extern int omap4_opp_init(void);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 7/9] ARM: OMAP3: define statically the omap3_idle_data
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 877a7e1..34e1e34 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -46,7 +46,36 @@ struct omap3_idle_statedata {
#define OMAP3_NUM_STATES 7
-struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
+struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES] = {
+ {
+ .mpu_state = PWRDM_POWER_ON,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_ON,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_RET,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_OFF,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_RET,
+ .core_state = PWRDM_POWER_RET,
+ },
+ {
+ .mpu_state = PWRDM_POWER_OFF,
+ .core_state = PWRDM_POWER_RET,
+ },
+ {
+ .mpu_state = PWRDM_POWER_OFF,
+ .core_state = PWRDM_POWER_OFF,
+ },
+};
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 8/9] ARM: OMAP3: cpuidle - use omap3_idle_data directly
We are storing the 'omap3_idle_data' in the private data field
if the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly
instead dereferencing pointers in an idle critical loop.
As the table is initialized statically, let's remove the initialization at
startup too.
Also, that simplfies the code.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 60 -
1 files changed, 6 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 34e1e34..726f0bf 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -106,8 +106,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap3_idle_statedata *cx =
- cpuidle_get_statedata(dev-states_usage[index]);
+ struct omap3_idle_statedata *cx = omap3_idle_data[index];
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
int idle_time;
@@ -208,7 +207,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
* Prevent PER off if CORE is not in retention or off as this
* would disable PER wakeups completely.
*/
- cx = cpuidle_get_statedata(dev-states_usage[index]);
+ cx = omap3_idle_data[index];
core_next_state = cx-core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
if ((per_next_state == PWRDM_POWER_OFF)
@@ -295,19 +294,6 @@ struct cpuidle_driver omap3_idle_driver = {
.state_count = OMAP3_NUM_STATES,
};
-/* Helper to register the driver_data */
-static inline struct omap3_idle_statedata *_fill_cstate_usage(
- struct cpuidle_device *dev,
- int idx)
-{
- struct omap3_idle_statedata *cx = omap3_idle_data[idx];
- struct cpuidle_state_usage *state_usage = dev-states_usage[idx];
-
- cpuidle_set_statedata(state_usage, cx);
-
- return cx;
-}
-
/**
* omap3_idle_init - Init routine for OMAP3 idle
*
@@ -318,48 +304,12 @@ int __init omap3_idle_init(void)
{
struct cpuidle_device *dev;
struct cpuidle_driver *drv = omap3_idle_driver;
- struct omap3_idle_statedata *cx;
mpu_pd = pwrdm_lookup(mpu_pwrdm);
core_pd = pwrdm_lookup(core_pwrdm);
per_pd = pwrdm_lookup(per_pwrdm);
cam_pd = pwrdm_lookup(cam_pwrdm);
-
- dev = per_cpu(omap3_idle_dev, smp_processor_id());
-
- /* C1 . MPU WFI + Core active */
- cx = _fill_cstate_usage(dev, 0);
- cx-mpu_state = PWRDM_POWER_ON;
- cx-core_state = PWRDM_POWER_ON;
-
- /* C2 . MPU WFI + Core inactive */
- cx = _fill_cstate_usage(dev, 1);
- cx-mpu_state = PWRDM_POWER_ON;
- cx-core_state = PWRDM_POWER_ON;
-
- /* C3 . MPU CSWR + Core inactive */
- cx = _fill_cstate_usage(dev, 2);
- cx-mpu_state = PWRDM_POWER_RET;
- cx-core_state = PWRDM_POWER_ON;
-
- /* C4 . MPU OFF + Core inactive */
- cx = _fill_cstate_usage(dev, 3);
- cx-mpu_state = PWRDM_POWER_OFF;
- cx-core_state = PWRDM_POWER_ON;
-
- /* C5 . MPU RET + Core RET */
- cx = _fill_cstate_usage(dev, 4);
- cx-mpu_state = PWRDM_POWER_RET;
- cx-core_state = PWRDM_POWER_RET;
-
- /* C6 . MPU OFF + Core RET */
- cx = _fill_cstate_usage(dev, 5);
- cx-mpu_state = PWRDM_POWER_OFF;
- cx-core_state = PWRDM_POWER_RET;
-
- /* C7 . MPU OFF + Core OFF */
- cx = _fill_cstate_usage(dev, 6);
/*
* Erratum i583: implementation for ES rev Es1.2 on 3630. We cannot
* enable OFF mode in a stable form for previous revisions.
@@ -370,11 +320,13 @@ int __init omap3_idle_init(void)
pr_warn(%s: core off state C7 disabled due to i583\n,
__func__);
}
- cx-mpu_state = PWRDM_POWER_OFF;
- cx-core_state = PWRDM_POWER_OFF;
cpuidle_register_driver(omap3_idle_driver);
+ dev = per_cpu(omap3_idle_dev, smp_processor_id());
+ dev-cpu = 0;
+ dev-state_count = drv-state_count;
+
if (cpuidle_register_device(dev)) {
printk(KERN_ERR %s: CPUidle register device failed\n,
__func__);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 9/9] ARM: OMAP3/4: consolidate cpuidle Makefile
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/Makefile | 11 +++
arch/arm/mach-omap2/cpuidle34xx.c |8
arch/arm/mach-omap2/cpuidle44xx.c |8
arch/arm/mach-omap2/pm.h | 17 +++--
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index bd76394..93819c4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,10 +63,8 @@ endif
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
- cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
- cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
@@ -80,6 +78,11 @@ endif
endif
+ifeq ($(CONFIG_CPU_IDLE),y)
+obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
+endif
+
# PRCM
obj-y += prm_common.o
obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 726f0bf..579424c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,8 +36,6 @@
#include control.h
#include common.h
-#ifdef CONFIG_CPU_IDLE
-
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
@@ -335,9 +333,3 @@ int __init omap3_idle_init(void)
return 0;
}
-#else
-int __init omap3_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index f6a6194..d251187 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,8 +22,6 @@
#include pm.h
#include prm.h
-#ifdef CONFIG_CPU_IDLE
-
/* Machine specific information */
struct omap4_idle_statedata {
u32 cpu_state;
@@ -219,9 +217,3 @@ int __init omap4_idle_init(void)
return 0;
}
-#else
-int __init omap4_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index a41c8dd..d9a97e8 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -15,13 +15,26 @@
#include powerdomain.h
+#ifdef CONFIG_CPU_IDLE
+extern int omap3_idle_init(void);
+extern int omap4_idle_init(void);
+#else
+static inline int omap3_idle_init(void)
+{
+ return 0;
+}
+
+static inline int omap4_idle_init(void)
+{
+ return 0;
+}
+#endif
+
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
-extern int omap3_idle_init(void);
-extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/5] ARM: OMAP2+: gpmc: driver conversion
On 3/23/2012 7:36 AM, Afzal Mohammed wrote:
Convert GPMC code to driver. Boards using GPMC
should provide driver with type of configuration,
timing, GPMC address space details (if already
configured, driver will retrieve, as is existing).
Platform devices would the be created for each
connected peripheral (peripheral details also to
be passed by board so that it reaches respective
driver). And GPMC driver would populate memory
resource details for the driver of connected
peripheral.
A peripheral connected to GPMC can have multiple
address spaces using different chip select. Hence
GPMC driver has been provided capability to
distinguish this scenario, i.e. create platform
devices only once for each connected peripheral,
and not for each configured chip select. The
peripheral that made it necessary was tusb6010.
Final destination aimed for this driver is MFD.
Why? Are you sure this is appropriate? This is not really a
multifunction device but rather a bus device that can manage multiple
kind of devices.
But before that all existing GPMC users has to be
converted to work with this driver. This would
likely result in removal of gpmc_create_child
and probably use MFD APIs instead.
NAND driver for GPMC is tightly coupled with GPMC
driver (GPMC has few blocks exclusively for NAND),
while that is not the case for most of the other
users (they need GPMCs help only for initial
configuration). Currently NAND driver manage using
exported GPMC symbols. This is being planned to
remove later would need informing NAND driver
about GPMC NAND registers. This would help to have
export symbol free GPMC driver, and probably
mv omap2.c gpmc-nand.c for OMAP NAND driver.
Thanks to Vaibhav Hiremath for his ideas on this.
Acquiring CS# for NAND is done on a few boards.
It means, depending on bootloader to embed this
information. Probably CS# being used can be set
in the Kernel, and acquiring it can be removed.
If ever this capbility is needed, GPMC driver
has to be made aware of handling it.
OneNAND - as it may involve reconfiguring GPMC for
synchronous may need a quirk to handle or driver
has to be made more intelligent to handle it.
Code below comment GPMC CLK related may have
to continue live in platform folders (even if the
driver is moved to MFD) as input clock is beyond
the control of GPMC and calculating timing for
the peripheral may need other helpers.
TODO (or not?)
1. NAND driver deal with GPMC NAND block
2. Remove struct gpmc * stored as static
3. Convert all peripherals to use GPMC driver
4. Devise method to handle OneNAND cleanly
5. Handle acquiring CS# cases
6. Convert to MFD driver
Signed-off-by: Afzal Mohammedaf...@ti.com
Cc: Vaibhav Hiremathhvaib...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 1083 +++-
You should probably find the proper location first, move the code and
convert to driver.
I will let Tony comment but this is the strategy today for all this
pseudo driver that should not be in OMAP arch directory anymore.
arch/arm/plat-omap/include/plat/gpmc.h | 34 +-
2 files changed, 672 insertions(+), 445 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..954fa22 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,8 +14,11 @@
*/
#undef DEBUG
+#includelinux/platform_device.h
+
#includelinux/irq.h
#includelinux/kernel.h
+#includelinux/slab.h
#includelinux/init.h
#includelinux/err.h
#includelinux/clk.h
@@ -64,248 +67,99 @@
#define ENABLE_PREFETCH (0x1 7)
#define DMA_MPU_MODE 2
-/* Structure to save gpmc cs context */
-struct gpmc_cs_config {
- u32 config1;
- u32 config2;
- u32 config3;
- u32 config4;
- u32 config5;
- u32 config6;
- u32 config7;
- int is_valid;
-};
-
-/*
- * Structure to save/restore gpmc context
- * to support core off on OMAP3
- */
-struct omap3_gpmc_regs {
- u32 sysconfig;
- u32 irqenable;
- u32 timeout_ctrl;
- u32 config;
- u32 prefetch_config1;
- u32 prefetch_config2;
- u32 prefetch_control;
- struct gpmc_cs_config cs_context[GPMC_CS_NUM];
-};
-
-static struct resource gpmc_mem_root;
-static struct resource gpmc_cs_mem[GPMC_CS_NUM];
-static DEFINE_SPINLOCK(gpmc_mem_lock);
-static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
-static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
-
-static void __iomem *gpmc_base;
-
-static struct clk *gpmc_l3_clk;
-
-static irqreturn_t gpmc_handle_irq(int irq, void *dev);
-static void gpmc_write_reg(int idx, u32 val)
-{
- __raw_writel(val, gpmc_base + idx);
-}
-
-static u32 gpmc_read_reg(int idx)
-{
- return __raw_readl(gpmc_base + idx);
-}
-
-static void gpmc_cs_write_byte(int cs, int idx, u8 val)
-{
- void __iomem *reg_addr;
+#defineDRIVER_NAME omap-gpmc
- reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs *
RE: [RFC][PATCH 1/5] ARM: OMAP2+: gpmc: driver conversion
Hi Benoit,
On Fri, Mar 23, 2012 at 15:07:30, Cousson, Benoit wrote:
Final destination aimed for this driver is MFD.
Why? Are you sure this is appropriate? This is not really a
multifunction device but rather a bus device that can manage multiple
kind of devices.
Agree, this not an MFD, but can we call this a bus?, as there is
nothing like GPMC protocol. We considered it logically as MFD
proceeded and there was a similar attempt for davinci EMIF [1,2].
arch/arm/mach-omap2/gpmc.c | 1083
+++-
You should probably find the proper location first, move the code and
convert to driver.
I will let Tony comment but this is the strategy today for all this
pseudo driver that should not be in OMAP arch directory anymore.
Please let me know whether you have any suggestions on where GPMC driver
should live.
+ printk(KERN_DEBUG GPMC CS%d: %-10s* %3d ns, %3d ticks= %d\n,
Nit, but since you are cleaning extensively this code, you should use
pr_ macros instead or even dev_ macros since you do have a real driver
now with real devices now.
Sure, this was overlooked
+struct gpmc_cs_config {
+ u32 config1;
+ u32 config2;
+ u32 config3;
+ u32 config4;
+ u32 config5;
+ u32 config6;
+ u32 config7;
+ int is_valid;
+};
OK, so this code was just moved and not removed. Becasue of these big
code move, the patch is not super readable. We cannot really see what
part is new and what was changed.
Maybe you should try to split that in sevarl patches or minized the move.
Yes, I was really in two minds before the coding started. Lot of code in
this patch has been moved from one place to other, this was done to put
codes that handle similar things together, so that trees can be made
visible easily in the forest. And once the patch is applied, as similar
sections are together, it may be easy to make further changes
If an initial patch just to rearrange the code to have similar section
together then new changes in a another patch, would that be fine?
+static int __init gpmc_clk_init(void)
+{
+ char *ck = NULL;
+
+ if (cpu_is_omap24xx())
+ ck = core_l3_ck;
+ else if (cpu_is_omap34xx())
+ ck = gpmc_fck;
+ else if (cpu_is_omap44xx())
+ ck = gpmc_ck;
Please don't do that anymore. The CLKDEV array is done to create alias
and avoid this kind of hacks. Moreover you should rely on hwmod for
device creation and thus main clock alias will already be populated for
free.
There are not added, they are existing code, result of rearranging the
code. These sections were given not given much importance as these won't
go into driver. But noted the point you are making.
Thanks for your quick comments.
Regards
Afzal
[1] http://lkml.indiana.edu/hypermail/linux/kernel/1202.2/03228.html
[2]
http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/5] Convert GPMC to driver
On Fri, Mar 23, 2012 at 12:06 PM, Afzal Mohammed af...@ti.com wrote: Hi, Convert GPCM code to be a driver. Existing GPMC NAND platform handling has been modified to work with the new GPMC driver (patches 2 3). Patch 5 is to test the driver in OMAP3EVM. Once all the users has been converted to use this driver, would be converted to MFD type. Much needed series. Thanks Afzal for doing it. TODO: 1. Let OMAP NAND driver deal with GPMC NAND block 2. Remove struct gpmc * stored as static 3. Convert all peripherals to use GPMC driver 4. Devise method to handle OneNAND cleanly 5. Handle acquiring CS# cases 6. Convert to MFD driver Afzal Mohammed (5): ARM: OMAP2+: gpmc: driver conversion ARM: OMAP2+: nand: create platform data structure ARM: OMAP2+: gpmc-nand: populate gpmc configs mtd: nand: omap2: obtain memory from resource OMAP3EVM: Test gpmc-nand Will have a look at your series next week. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] ARM: OMAP3: cpuidle - remove next_valid_state function
Hi Daniel,
On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
As we will be able to remove C-states from userspace with the sysfs
API, this function is no longer needed. We remove it and that simplifies
the code for more consolidation.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 85
+
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index d67431a..65b4e7aa 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -164,84 +164,6 @@ return_sleep_time:
}
/**
- * next_valid_state - Find next valid C-state
- * @dev: cpuidle device
- * @drv: cpuidle driver
- * @index: Index of currently selected c-state
- *
- * If the state corresponding to index is valid, index is returned back
- * to the caller. Else, this function searches for a lower c-state which is
- * still valid (as defined in omap3_power_states[]) and returns its index.
- *
- * A state is valid if the 'valid' field is enabled and
- * if it satisfies the enable_off_mode condition.
- */
-static int next_valid_state(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
- struct cpuidle_state *curr = drv-states[index];
- struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
- u32 mpu_deepest_state = PWRDM_POWER_RET;
- u32 core_deepest_state = PWRDM_POWER_RET;
- int next_index = -1;
-
- if (enable_off_mode) {
- mpu_deepest_state = PWRDM_POWER_OFF;
- /*
- * Erratum i583: valable for ES rev Es1.2 on 3630.
- * CORE OFF mode is not supported in a stable form, restrict
- * instead the CORE state to RET.
- */
- if (!IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583))
- core_deepest_state = PWRDM_POWER_OFF;
- }
I am OK to remove the function but some of the code needs to stay (can
be moved into enter_idle_bm).
The errata code is needed.
-
- /* Check if current state is valid */
- if ((cx-valid)
- (cx-mpu_state = mpu_deepest_state)
- (cx-core_state = core_deepest_state)) {
- return index;
- } else {
- int idx = OMAP3_NUM_STATES - 1;
On OMAP3 not all the power states combinations are allowed, so this
code looks for a C-state which satisfies the enable_off_mode flag.
I am planning to remove the enable_off_mode flag but this has to come
with the per-device PM QoS constraints code.
-
- /* Reach the current state starting at highest C-state */
- for (; idx = 0; idx--) {
- if (drv-states[idx] == curr) {
- next_index = idx;
- break;
- }
- }
-
- /* Should never hit this condition */
- WARN_ON(next_index == -1);
-
- /*
- * Drop to next valid state.
- * Start search from the next (lower) state.
- */
- idx--;
- for (; idx = 0; idx--) {
- cx = cpuidle_get_statedata(dev-states_usage[idx]);
- if ((cx-valid)
- (cx-mpu_state = mpu_deepest_state)
- (cx-core_state = core_deepest_state)) {
- next_index = idx;
- break;
- }
- }
- /*
- * C1 is always valid.
- * So, no need to check for 'next_index == -1' outside
- * this loop.
- */
- }
-
- return next_index;
-}
-
-/**
* omap3_enter_idle_bm - Checks for any bus activity
* @dev: cpuidle device
* @drv: cpuidle driver
@@ -254,7 +176,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- int new_state_idx;
u32 core_next_state, per_next_state = 0, per_saved_state = 0,
cam_state;
struct omap3_idle_statedata *cx;
int ret;
@@ -265,7 +186,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
*/
cam_state = pwrdm_read_pwrst(cam_pd);
if (cam_state == PWRDM_POWER_ON) {
- new_state_idx = drv-safe_state_index;
+ index = drv-safe_state_index;
goto select_state;
}
@@ -292,10 +213,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device
*dev,
if
Re: [RFC][PATCH 3/9] ARM: OMAP3: cpuidle - set enable_off_mode as static
On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
This variable is only used in the pm-debug.c file.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/pm-debug.c | 2 +-
arch/arm/mach-omap2/pm.h | 30 --
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..86aa398 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -38,7 +38,7 @@
#include prm2xxx_3xxx.h
#include pm.h
-u32 enable_off_mode;
+static u32 enable_off_mode;
It is stil needed in cpuidle34xx.c.
#ifdef CONFIG_DEBUG_FS
#include linux/debugfs.h
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index af73a86..f5c3072 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -25,6 +25,18 @@ extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
+/*
+ * cpuidle mach specific parameters
+ *
+ * The board code can override the default C-states definition using
+ * omap3_pm_init_cpuidle
+ */
+struct cpuidle_params {
+ u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
+ u32 target_residency;
+ u8 valid; /* validates the C-state */
+};
+
Is this move needed? This will be removed in a later patch.
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
extern int omap4_opp_init(void);
@@ -39,27 +51,9 @@ static inline int omap4_opp_init(void)
}
#endif
-/*
- * cpuidle mach specific parameters
- *
- * The board code can override the default C-states definition using
- * omap3_pm_init_cpuidle
- */
-struct cpuidle_params {
- u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
- u32 target_residency;
- u8 valid; /* validates the C-state */
-};
-
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
-#ifdef CONFIG_PM_DEBUG
-extern u32 enable_off_mode;
-#else
-#define enable_off_mode 0
-#endif
-
#if defined(CONFIG_PM_DEBUG) defined(CONFIG_DEBUG_FS)
extern void pm_dbg_update_time(struct powerdomain *pwrdm, int prev);
#else
--
1.7.5.4
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/9] ARM: OMAP3: define cpuidle statically
On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
Use the new cpuidle API and define in the driver the states.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 85 +---
1 files changed, 59 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 65b4e7aa..62e3cfd 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -228,23 +228,67 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
struct cpuidle_driver omap3_idle_driver = {
.name = omap3_idle,
.owner = THIS_MODULE,
+ .states = {
+ {
+ .enter = omap3_enter_idle,
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = MPU ON + CORE ON,
+ },
+ {
+ .enter = omap3_enter_idle_bm,
+ .exit_latency = 10 + 10,
+ .target_residency = 30,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C2,
+ .desc = MPU ON + CORE ON,
+ },
+ {
+ .enter = omap3_enter_idle_bm,
+ .exit_latency = 50 + 50,
+ .target_residency = 300,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C3,
+ .desc = MPU RET + CORE ON,
+ },
+ {
+ .enter = omap3_enter_idle_bm,
+ .exit_latency = 1500 + 1800,
+ .target_residency = 4000,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C4,
+ .desc = MPU OFF + CORE ON,
+ },
+ {
+ .enter = omap3_enter_idle_bm,
+ .exit_latency = 2500 + 7500,
+ .target_residency = 12000,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C5,
+ .desc = MPU RET + CORE RET,
+ },
+ {
+ .enter = omap3_enter_idle_bm,
+ .exit_latency = 3000 + 8500,
+ .target_residency = 15000,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C6,
+ .desc = MPU OFF + CORE RET,
+ },
+ {
+ .enter = omap3_enter_idle_bm,
+ .exit_latency = 1 + 3,
+ .target_residency = 3,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C7,
+ .desc = MPU OFF + CORE OFF,
+ },
C7 is enabled depending on the errata i583, cf. below.
+ },
+ .state_count = OMAP3_NUM_STATES,
};
-/* Helper to fill the C-state common data*/
-static inline void _fill_cstate(struct cpuidle_driver *drv,
- int idx, const char *descr)
-{
- struct cpuidle_state *state = drv-states[idx];
-
- state-exit_latency = cpuidle_params_table[idx].exit_latency;
- state-target_residency = cpuidle_params_table[idx].target_residency;
- state-flags = CPUIDLE_FLAG_TIME_VALID;
- state-enter = omap3_enter_idle_bm;
- sprintf(state-name, C%d, idx + 1);
- strncpy(state-desc, descr, CPUIDLE_DESC_LEN);
-
-}
-
/* Helper to register the driver_data */
static inline struct omap3_idle_statedata *_fill_cstate_usage(
struct cpuidle_device *dev,
@@ -277,50 +321,40 @@ int __init omap3_idle_init(void)
cam_pd = pwrdm_lookup(cam_pwrdm);
- drv-safe_state_index = -1;
dev = per_cpu(omap3_idle_dev, smp_processor_id());
/* C1 . MPU WFI + Core active */
- _fill_cstate(drv, 0, MPU ON + CORE ON);
- (drv-states[0])-enter = omap3_enter_idle;
- drv-safe_state_index = 0;
Same minor remark about the safe_state_index as in the previous series.
cx = _fill_cstate_usage(dev, 0);
cx-valid = 1; /* C1 is always valid */
cx-mpu_state =
Re: [RFC][PATCH 4/9] ARM: OMAP3: define cpuidle statically
On 03/23/2012 01:35 PM, Jean Pihet wrote:
On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
Use the new cpuidle API and define in the driver the states.
Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org
---
[ ... ]
/*
* Erratum i583: implementation for ES rev Es1.2 on 3630. We cannot
C7 is enabled only if the errata does not apply.
This causes a problem with the statically defined C-states and also
with the per C-state sysfs disable knob. A consistency check should be
performed before trying to enter a state.
In the patch 5/9, I decrement the state_count if the errata applies. I
believe it is still compatible with the static C-states.
@@ -338,7 +372,6 @@ int __init omap3_idle_init(void)
drv-state_count = OMAP3_NUM_STATES;
cpuidle_register_driver(omap3_idle_driver);
- dev-state_count = OMAP3_NUM_STATES;
if (cpuidle_register_device(dev)) {
printk(KERN_ERR %s: CPUidle register device failed\n,
__func__);
--
1.7.5.4
Thanks!
Jean
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+ Add Primview displays to panel-generic
Add displays to panel-generic-dpi.c
Prime View PD050VL1 (640 x 480)
Prime View PD104SLF (800 x 600)
Prime View PM070WL4 (800 x 480)
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
drivers/video/omap2/displays/panel-generic-dpi.c | 63 ++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 28b9a6d..85ee8d3 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -363,6 +363,69 @@ static struct panel_config generic_dpi_panels[] = {
.name = ortustech_com43h4m10xtc,
},
+
+ /* Prime-View PD050VL1 */
+ {
+ {
+ .x_res = 640,
+ .y_res = 480,
+
+ .pixel_clock= 25000,
+
+ .hsw= 96,
+ .hfp= 18,
+ .hbp= 46,
+
+ .vsw= 2,
+ .vfp= 10,
+ .vbp= 33,
+ },
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC,
+ .name = pd050vl1,
+ },
+
+ /* Prime-View PM070WL4 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock= 32000,
+
+ .hsw= 128,
+ .hfp= 42,
+ .hbp= 86,
+
+ .vsw= 2,
+ .vfp= 10,
+ .vbp= 33,
+ },
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC,
+ .name = pm070wl4,
+ },
+
+ /* Prime-View PD104SLF */
+ {
+ {
+ .x_res = 800,
+ .y_res = 600,
+
+ .pixel_clock= 4,
+
+ .hsw= 128,
+ .hfp= 42,
+ .hbp= 86,
+
+ .vsw= 4,
+ .vfp= 1,
+ .vbp= 23,
+ },
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC,
+ .name = pd104slf,
+ },
};
struct panel_drv_data {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/5] ARM: OMAP2+: gpmc: driver conversion
+ Felipe
On 3/23/2012 11:20 AM, Mohammed, Afzal wrote:
Hi Benoit,
On Fri, Mar 23, 2012 at 15:07:30, Cousson, Benoit wrote:
Final destination aimed for this driver is MFD.
Why? Are you sure this is appropriate? This is not really a
multifunction device but rather a bus device that can manage multiple
kind of devices.
Agree, this not an MFD, but can we call this a bus?, as there is
nothing like GPMC protocol. We considered it logically as MFD
proceeded and there was a similar attempt for davinci EMIF [1,2].
But EMIF does not have anything to do in MFD either :-)
What was the feedback for this series?
We discussed that at Linaro connect, but it looks like MFD is becoming
the place for miscellaneous drivers that we do not know where to put.
Maybe we should introduce a driver/memory/ directory for memory
controller. At least for EMIF.
In the case of GMPC, it is slightly different because it can handle
NOR/NAND memory but as well behave like an ISA bus controller for
Ethernet ISA chip.
But since it can control several devices thanks the chipselects lines it
has, it behaves like a multi-protocol bus controller.
But in anycase, it does not look like an MFD for my point of view. For
me a MFD is like a small soc, it does contain several completely
unrelated block (Power, Audio, GPIO...), but does share some memory
space / IRQ lines.
Is this the only controller doing that kind of stuff in the kernel so far?
arch/arm/mach-omap2/gpmc.c | 1083
+++-
You should probably find the proper location first, move the code and
convert to driver.
I will let Tony comment but this is the strategy today for all this
pseudo driver that should not be in OMAP arch directory anymore.
Please let me know whether you have any suggestions on where GPMC driver
should live.
+ printk(KERN_DEBUG GPMC CS%d: %-10s* %3d ns, %3d ticks= %d\n,
Nit, but since you are cleaning extensively this code, you should use
pr_ macros instead or even dev_ macros since you do have a real driver
now with real devices now.
Sure, this was overlooked
+struct gpmc_cs_config {
+ u32 config1;
+ u32 config2;
+ u32 config3;
+ u32 config4;
+ u32 config5;
+ u32 config6;
+ u32 config7;
+ int is_valid;
+};
OK, so this code was just moved and not removed. Becasue of these big
code move, the patch is not super readable. We cannot really see what
part is new and what was changed.
Maybe you should try to split that in sevarl patches or minized the move.
Yes, I was really in two minds before the coding started. Lot of code in
this patch has been moved from one place to other, this was done to put
codes that handle similar things together, so that trees can be made
visible easily in the forest. And once the patch is applied, as similar
sections are together, it may be easy to make further changes
If an initial patch just to rearrange the code to have similar section
together then new changes in a another patch, would that be fine?
Well, if this is just comestic, I will even do that after the driver
conversion. Because if you do that before you will move some piece of
code that you might completely delete later. So you should fix the code
first and then potentially, move some part if that will improve the
readability.
+static int __init gpmc_clk_init(void)
+{
+ char *ck = NULL;
+
+ if (cpu_is_omap24xx())
+ ck = core_l3_ck;
+ else if (cpu_is_omap34xx())
+ ck = gpmc_fck;
+ else if (cpu_is_omap44xx())
+ ck = gpmc_ck;
Please don't do that anymore. The CLKDEV array is done to create alias
and avoid this kind of hacks. Moreover you should rely on hwmod for
device creation and thus main clock alias will already be populated for
free.
There are not added, they are existing code, result of rearranging the
code. These sections were given not given much importance as these won't
go into driver. But noted the point you are making.
The issue is that the cpu_is_XXX should not be accessed from outside
mach-omap2 directory, so you should get rid of that before trying to
move the gpmc in the XXX location.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/5] ARM: OMAP2+: gpmc: driver conversion
Hi,
On Fri, Mar 23, 2012 at 04:39:21PM +0100, Cousson, Benoit wrote:
+ Felipe
On 3/23/2012 11:20 AM, Mohammed, Afzal wrote:
Hi Benoit,
On Fri, Mar 23, 2012 at 15:07:30, Cousson, Benoit wrote:
Final destination aimed for this driver is MFD.
Why? Are you sure this is appropriate? This is not really a
multifunction device but rather a bus device that can manage multiple
kind of devices.
Agree, this not an MFD, but can we call this a bus?, as there is
nothing like GPMC protocol. We considered it logically as MFD
proceeded and there was a similar attempt for davinci EMIF [1,2].
But EMIF does not have anything to do in MFD either :-)
What was the feedback for this series?
We discussed that at Linaro connect, but it looks like MFD is
becoming the place for miscellaneous drivers that we do not know
where to put.
Maybe we should introduce a driver/memory/ directory for memory
controller. At least for EMIF.
yeah, I was thinking about drivers/ocd (off-chip devices) or
drivers/mmio... and that should be flexible enough to hold gpmc, lli and
c2c (from OMAP's perspective).
In the case of GMPC, it is slightly different because it can handle
NOR/NAND memory but as well behave like an ISA bus controller for
Ethernet ISA chip.
But since it can control several devices thanks the chipselects lines
it has, it behaves like a multi-protocol bus controller.
indeed.
arch/arm/mach-omap2/gpmc.c | 1083
+++-
You should probably find the proper location first, move the code and
convert to driver.
I wouldn't do that. I would only move after the driver is cleaned up.
Are you concerned with the diffstat alone ? that'd be silly :-p
I will let Tony comment but this is the strategy today for all this
pseudo driver that should not be in OMAP arch directory anymore.
indeed, there are a bunch of those still:
$ git grep -e module_init arch/arm/*omap*
arch/arm/mach-omap1/mailbox.c:module_init(omap1_mbox_init);
arch/arm/mach-omap2/dsp.c:module_init(omap_dsp_init);
arch/arm/mach-omap2/iommu2.c:module_init(omap2_iommu_init);
arch/arm/mach-omap2/mailbox.c:module_init(omap2_mbox_init);
arch/arm/plat-omap/dmtimer.c:module_init(omap_dm_timer_driver_init);
arch/arm/plat-omap/ocpi.c:module_init(omap_ocpi_init);
Please let me know whether you have any suggestions on where GPMC driver
should live.
+ printk(KERN_DEBUG GPMC CS%d: %-10s* %3d ns, %3d ticks= %d\n,
Nit, but since you are cleaning extensively this code, you should use
pr_ macros instead or even dev_ macros since you do have a real driver
now with real devices now.
if we have a struct device pointer, don't use anything other than dev_*
Sure, this was overlooked
+struct gpmc_cs_config {
+ u32 config1;
+ u32 config2;
+ u32 config3;
+ u32 config4;
+ u32 config5;
+ u32 config6;
+ u32 config7;
+ int is_valid;
+};
OK, so this code was just moved and not removed. Becasue of these big
code move, the patch is not super readable. We cannot really see what
part is new and what was changed.
Maybe you should try to split that in sevarl patches or minized the move.
sounds plausible to me.
Yes, I was really in two minds before the coding started. Lot of code in
this patch has been moved from one place to other, this was done to put
codes that handle similar things together, so that trees can be made
visible easily in the forest. And once the patch is applied, as similar
sections are together, it may be easy to make further changes
If an initial patch just to rearrange the code to have similar section
together then new changes in a another patch, would that be fine?
Well, if this is just comestic, I will even do that after the driver
conversion. Because if you do that before you will move some piece of
code that you might completely delete later. So you should fix the
code first and then potentially, move some part if that will improve
the readability.
+static int __init gpmc_clk_init(void)
+{
+ char *ck = NULL;
+
+ if (cpu_is_omap24xx())
+ ck = core_l3_ck;
+ else if (cpu_is_omap34xx())
+ ck = gpmc_fck;
+ else if (cpu_is_omap44xx())
+ ck = gpmc_ck;
Please don't do that anymore. The CLKDEV array is done to create alias
and avoid this kind of hacks. Moreover you should rely on hwmod for
device creation and thus main clock alias will already be populated for
free.
There are not added, they are existing code, result of rearranging the
code. These sections were given not given much importance as these won't
go into driver. But noted the point you are making.
The issue is that the cpu_is_XXX should not be accessed from outside
mach-omap2 directory, so you should get rid of that before trying to
move the gpmc in the XXX location.
yes, that's right. But until he can move the code, there's still a lot
of work to be done, right ? This included.
ps: can someone bounce the thread to me ? I
[PATCH 0/9] omap randconfig fixes for v3.3
From: Arnd Bergmann a...@arndb.de The following is a set of patches that have been sent out during the 3.1 cycle that were not acked or merged. Sending again for completeness. Tony, please pull if there are no objections: The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7: Linux 3.3 (2012-03-18 16:15:34 -0700) are available in the git repository at: git://git.linaro.org/people/mpoirier/linux.git randconfig-omap Arnd Bergmann (8): arm/omap: enable building omap2 without omap2420/2430 omap: fix visibility of omap2_mbox_iva_priv ARM: omap2+: fix building without i2c tty/serial/omap: console can only be built-in omap2: select twl4030 support on boards that need it omap2plus: ensure that one of omap2/3/4 is selected arm: OMAP depends on MMU ARM: omap: select CPU_FREQ_TABLE where needed Russell King (1): ARM: omap2/n8x0: work around modular omap mmc arch/arm/Kconfig |1 + arch/arm/mach-omap2/Kconfig| 19 +++ arch/arm/mach-omap2/board-n8x0.c |6 -- arch/arm/mach-omap2/mailbox.c |2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/Kconfig |5 + arch/arm/plat-omap/include/plat/multi.h|5 + drivers/tty/serial/Kconfig |2 +- 11 files changed, 40 insertions(+), 8 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] omap: fix visibility of omap2_mbox_iva_priv
From: Arnd Bergmann a...@arndb.de
map2_mbox_iva_priv is used on multiple omap2 socs but is hidden
in an outdated #ifdef that is specific to a single soc.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/mailbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 415a6f1..ef01f6c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -258,7 +258,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP2)
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] omap2plus: ensure that one of omap2/3/4 is selected
From: Arnd Bergmann a...@arndb.de Random configurations can fail if none of the omap families in mach-omap2 is selected. This patch automatically selects omap2 if the user has not made any other choice. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 0279e9e..b244e80 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -55,6 +55,16 @@ config ARCH_OMAP4 select USB_ARCH_HAS_EHCI select ARM_CPU_SUSPEND if PM +config ARCH_OMAP2_AUTO + bool + depends on !ARCH_OMAP3 !ARCH_OMAP4 + select ARCH_OMAP2 + default y + help + At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this + selects OMAP2 if nothing else gets selected, to avoid non-building + configurations. + comment OMAP Core Type depends on ARCH_OMAP2 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] ARM: omap: select CPU_FREQ_TABLE where needed
From: Arnd Bergmann a...@arndb.de The omap platform requires CPU_FREQ_TABLE support to be enabled for its CPU_FREQ implementations, so automatically select that when CPU_FREQ is enabled. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org --- arch/arm/plat-omap/Kconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index aa59f42..1983d16 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -207,6 +207,11 @@ config OMAP_PM_NOOP endchoice +config OMAP_CPU_FREQ + def_bool y + depends on CPU_FREQ + select CPU_FREQ_TABLE + endmenu endif -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] arm: OMAP depends on MMU
From: Arnd Bergmann a...@arndb.de There is no way to build OMAP kernels without an MMU at this point because of dependencies on MMU-only functions. As long as nobody is interested in fixing this, let's just disable this platforms for nommu kernels. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dfb0312..8124ce0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -939,6 +939,7 @@ config ARCH_DAVINCI config ARCH_OMAP bool TI OMAP + depends on MMU select HAVE_CLK select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] omap2: select twl4030 support on boards that need it
From: Arnd Bergmann a...@arndb.de These three boards unconditionally use the twl4030 driver from the board-zoom-display.c file. Make sure that the driver is always there. We also need to select the I2C core so we are able to build that driver. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index e20c8ab..0279e9e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -265,6 +265,9 @@ config MACH_OMAP_ZOOM2 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE select REGULATOR_FIXED_VOLTAGE if REGULATOR + select TWL4030_CORE + select MFD_SUPPORT + select I2C config MACH_OMAP_ZOOM3 bool OMAP3630 Zoom3 board @@ -275,6 +278,9 @@ config MACH_OMAP_ZOOM3 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE select REGULATOR_FIXED_VOLTAGE if REGULATOR + select TWL4030_CORE + select MFD_SUPPORT + select I2C config MACH_CM_T35 bool CompuLab CM-T35/CM-T3730 modules @@ -316,6 +322,9 @@ config MACH_OMAP_3630SDP depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBP + select TWL4030_CORE + select MFD_SUPPORT + select I2C config MACH_TI8168EVM bool TI8168 Evaluation Module -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] tty/serial/omap: console can only be built-in
From: Arnd Bergmann a...@arndb.de When the omap serial driver is built as a module, we must not allow the console driver to be selected, because consoles can not be loadable modules. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Govindraj.R govindraj.r...@ti.com --- drivers/tty/serial/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 2de9924..bcf7e24 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1041,7 +1041,7 @@ config SERIAL_OMAP config SERIAL_OMAP_CONSOLE bool Console on OMAP serial port - depends on SERIAL_OMAP + depends on SERIAL_OMAP=y select SERIAL_CORE_CONSOLE help Select this option if you would like to use omap serial port as -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ARM: omap2+: fix building without i2c
From: Arnd Bergmann a...@arndb.de
A trivial typo causes build breakage when I2C is disabled
and omap_i2c_reset is set to NULL on OMAP:
omap_hwmod_44xx_data.c:2287:11: error: lvalue required as unary '' operand
Removing the '' character solves this.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Avinash.H.M avinas...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a5409ce..d74c76f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1038,7 +1038,7 @@ static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c4f56cb..69c91b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1088,7 +1088,7 @@ static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3c8dd92..d8eb79f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1367,7 +1367,7 @@ static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ef0524c..9adf749 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2258,7 +2258,7 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
.name = i2c,
.sysc = omap44xx_i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_2,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: omap2/n8x0: work around modular omap mmc
From: Russell King li...@arm.linux.org.uk
When the omap driver is built as a module for n8x0,
n8x0_mmc_set_power_menelaus cannot call into the driver:
arch/arm/mach-omap2/board-n8x0.c:374: undefined reference
to `omap_mmc_notify_cover_event'
As a workaround, do not provide that device in this case. This needs
to be fixed properly, e.g. by converting n8x0 to be probed through the
device tree and moving that code into the driver.
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
Suggested-by: Russell King li...@arm.linux.org.uk
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-n8x0.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 6722627..8529ca0 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -193,8 +193,10 @@ static struct omap_onenand_platform_data
board_onenand_data[] = {
};
#endif
-#if defined(CONFIG_MENELAUS)
\
- (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
+#ifdef CONFIG_MMC_OMAP_MODULE
+#warning FIXME: cannot call omap_mmc_notify_cover_event for
CONFIG_MMC_OMAP_MODULE
+#endif
+#if defined(CONFIG_MENELAUS) (defined(CONFIG_MMC_OMAP)
/*
* On both N800 and N810, only the first of the two MMC controllers is in use.
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] arm/omap: enable building omap2 without omap2420/2430
From: Arnd Bergmann a...@arndb.de Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options being omap2420 and omap2430, but that leads to a build error when omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is undefined. This adds another clause to plat/multi.h, mainly to allow all possible randconfig combinations to build cleanly. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/plat/multi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h index 999ffba..fb7f196 100644 --- a/arch/arm/plat-omap/include/plat/multi.h +++ b/arch/arm/plat-omap/include/plat/multi.h @@ -82,6 +82,11 @@ # define OMAP_NAME omap2430 # endif #endif +#ifdef CONFIG_ARCH_OMAP2 +# ifndef OMAP_NAME +# define OMAP_NAME omap2 +# endif +#endif #ifdef CONFIG_ARCH_OMAP3 # ifdef OMAP_NAME # undef MULTI_OMAP2 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] ARM: omap2+: fix building without i2c
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]: From: Arnd Bergmann a...@arndb.de A trivial typo causes build breakage when I2C is disabled and omap_i2c_reset is set to NULL on OMAP: omap_hwmod_44xx_data.c:2287:11: error: lvalue required as unary '' operand Removing the '' character solves this. We are now building in the omap_i2c_reset always, so this should be revalidated. We currently don't have NULL version of omap_i2c_reset any longer, so those '' for functions are mostly cosmetic right now. Anyways, at least the commit message should be changed to be current. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] omap2plus: ensure that one of omap2/3/4 is selected
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]: From: Arnd Bergmann a...@arndb.de Random configurations can fail if none of the omap families in mach-omap2 is selected. This patch automatically selects omap2 if the user has not made any other choice. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 0279e9e..b244e80 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -55,6 +55,16 @@ config ARCH_OMAP4 select USB_ARCH_HAS_EHCI select ARM_CPU_SUSPEND if PM +config ARCH_OMAP2_AUTO + bool + depends on !ARCH_OMAP3 !ARCH_OMAP4 + select ARCH_OMAP2 + default y + help + At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this + selects OMAP2 if nothing else gets selected, to avoid non-building + configurations. + comment OMAP Core Type depends on ARCH_OMAP2 Hmm yeah omap2 makes the smallest build, so randconfig builds faster than it would for omap3 or 4. But isn't there now still a chance that randconfig does not select ARCH_OMAP2_AUTO either? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] ARM: omap2/n8x0: work around modular omap mmc
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]: From: Russell King li...@arm.linux.org.uk When the omap driver is built as a module for n8x0, n8x0_mmc_set_power_menelaus cannot call into the driver: arch/arm/mach-omap2/board-n8x0.c:374: undefined reference to `omap_mmc_notify_cover_event' As a workaround, do not provide that device in this case. This needs to be fixed properly, e.g. by converting n8x0 to be probed through the device tree and moving that code into the driver. This too should be fixed now in a way where just the cover events won't work if compiled as a module. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] omap2plus: ensure that one of omap2/3/4 is selected
On Friday 23 March 2012, Tony Lindgren wrote: +config ARCH_OMAP2_AUTO + bool + depends on !ARCH_OMAP3 !ARCH_OMAP4 + select ARCH_OMAP2 + default y + help + At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this + selects OMAP2 if nothing else gets selected, to avoid non-building + configurations. + comment OMAP Core Type depends on ARCH_OMAP2 Hmm yeah omap2 makes the smallest build, so randconfig builds faster than it would for omap3 or 4. But isn't there now still a chance that randconfig does not select ARCH_OMAP2_AUTO either? No. ARCH_OMAP2_AUTO is only disabled if one of OMAP3 or OMAP4 are enabled. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] omap2plus: ensure that one of omap2/3/4 is selected
* Arnd Bergmann a...@arndb.de [120323 10:40]: On Friday 23 March 2012, Tony Lindgren wrote: +config ARCH_OMAP2_AUTO + bool + depends on !ARCH_OMAP3 !ARCH_OMAP4 + select ARCH_OMAP2 + default y + help + At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this + selects OMAP2 if nothing else gets selected, to avoid non-building + configurations. + comment OMAP Core Type depends on ARCH_OMAP2 Hmm yeah omap2 makes the smallest build, so randconfig builds faster than it would for omap3 or 4. But isn't there now still a chance that randconfig does not select ARCH_OMAP2_AUTO either? No. ARCH_OMAP2_AUTO is only disabled if one of OMAP3 or OMAP4 are enabled. And then no description in bool keeps it hidden from selection. Nice, this works. Too bad these got forgotten in your branch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] ARM: omap: select CPU_FREQ_TABLE where needed
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:17]: From: Arnd Bergmann a...@arndb.de The omap platform requires CPU_FREQ_TABLE support to be enabled for its CPU_FREQ implementations, so automatically select that when CPU_FREQ is enabled. I think this is also solved now, Kevin might be able to confirm this. Regards, Tony Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org --- arch/arm/plat-omap/Kconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index aa59f42..1983d16 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -207,6 +207,11 @@ config OMAP_PM_NOOP endchoice +config OMAP_CPU_FREQ + def_bool y + depends on CPU_FREQ + select CPU_FREQ_TABLE + endmenu endif -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] omap: fix visibility of omap2_mbox_iva_priv
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]: From: Arnd Bergmann a...@arndb.de map2_mbox_iva_priv is used on multiple omap2 socs but is hidden in an outdated #ifdef that is specific to a single soc. I think this got fixed with 655850ed (ARM: OMAP2: fix mailbox init code). Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] tty/serial/omap: console can only be built-in
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]: From: Arnd Bergmann a...@arndb.de When the omap serial driver is built as a module, we must not allow the console driver to be selected, because consoles can not be loadable modules. Looks valid to me, this should get posted and merged via linux-ser...@vger.kernel.org. Tony Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Govindraj.R govindraj.r...@ti.com --- drivers/tty/serial/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 2de9924..bcf7e24 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1041,7 +1041,7 @@ config SERIAL_OMAP config SERIAL_OMAP_CONSOLE bool Console on OMAP serial port - depends on SERIAL_OMAP + depends on SERIAL_OMAP=y select SERIAL_CORE_CONSOLE help Select this option if you would like to use omap serial port as -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/5] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 03/23/2012 01:36 AM, Afzal Mohammed wrote:
[snip]
+struct gpmc_child {
+ char*name;
+ int id;
+ struct resource *res;
+ unsignednum_res;
+ struct resource gpmc_res[GPMC_CS_NUM];
Does this imply a gpmc child device can use more than one chip-select? I
am trying to understand the link between number of resources and
GPMC_CS_NUM.
+ unsignedgpmc_num_res;
+ void*pdata;
+ unsignedpdata_size;
+};
Does pdata_size need to be stored? If pdata is always of type
gpmc_device_pdata then you could avoid using void * and elsewhere use
sizeof.
-static u8 gpmc_cs_read_byte(int cs, int idx)
-{
- void __iomem *reg_addr;
+struct gpmc {
+ struct device *dev;
+ unsigned long fclk_rate;
+ void __iomem*io_base;
+ unsigned long phys_base;
+ u32 memsize;
+ unsignedcs_map;
+ int ecc_used;
+ spinlock_t mem_lock;
+ struct resource mem_root;
+ struct resource cs_mem[GPMC_CS_NUM];
+ struct gpmc_child child_device[GPMC_CS_NUM];
+ unsignednum_child;
+ unsignednum_device;
+};
- reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
- return __raw_readb(reg_addr);
-}
+static struct gpmc *gpmc;
+/* Make function static */
void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
- __raw_writel(val, reg_addr);
+ reg_addr = gpmc-io_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ writel(val, reg_addr);
}
I understand this was inherited from the original code, but I think that
we should drop the GPMC_CS0_OFFSET. We are already passing an index
and so we should use this as an offset. This obviously implies changing
the defintion of the GPMC_CS_ registers in gpmc.h. This would save
one addition too.
+/* Make function static */
u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
- return __raw_readl(reg_addr);
+ reg_addr = gpmc-io_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ return readl(reg_addr);
}
Same as above.
-/* TODO: Add support for gpmc_fck to clock framework and use it */
-unsigned long gpmc_get_fclk_period(void)
+static void gpmc_write_reg(int idx, u32 val)
{
- unsigned long rate = clk_get_rate(gpmc_l3_clk);
-
- if (rate == 0) {
- printk(KERN_WARNING gpmc_l3_clk not enabled\n);
- return 0;
- }
-
- rate /= 1000;
- rate = 10 / rate; /* In picoseconds */
-
- return rate;
+ writel(val, gpmc-io_base + idx);
}
-unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+static u32 gpmc_read_reg(int idx)
{
- unsigned long tick_ps;
-
- /* Calculate in picosecs to yield more exact results */
- tick_ps = gpmc_get_fclk_period();
-
- return (time_ns * 1000 + tick_ps - 1) / tick_ps;
+ return readl(gpmc-io_base + idx);
}
-unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+static void gpmc_cs_write_byte(int cs, int idx, u8 val)
{
- unsigned long tick_ps;
-
- /* Calculate in picosecs to yield more exact results */
- tick_ps = gpmc_get_fclk_period();
-
- return (time_ps + tick_ps - 1) / tick_ps;
-}
+ void __iomem *reg_addr;
-unsigned int gpmc_ticks_to_ns(unsigned int ticks)
-{
- return ticks * gpmc_get_fclk_period() / 1000;
+ reg_addr = gpmc-io_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ writeb(val, reg_addr);
}
Again here, can we get rid of GPMC_CS0_OFFSET?
-unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
+static u8 gpmc_cs_read_byte(int cs, int idx)
{
- unsigned long ticks = gpmc_ns_to_ticks(time_ns);
+ void __iomem *reg_addr;
- return ticks * gpmc_get_fclk_period() / 1000;
+ reg_addr = gpmc-io_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ return readb(reg_addr);
}
And here, can we get rid of GPMC_CS0_OFFSET?
-#ifdef DEBUG
-static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
- int time, const char *name)
-#else
-static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
- int time)
-#endif
+static int gpmc_cs_set_reserved(int cs, int reserved)
{
- u32 l;
- int ticks, mask, nr_bits;
-
- if (time == 0)
- ticks = 0;
- else
- ticks = gpmc_ns_to_ticks(time);
- nr_bits = end_bit - st_bit + 1;
- if (ticks= 1 nr_bits) {
