Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Op 2 mei 2012, om 10:47 heeft Russ Dill het volgende geschreven: [0.198272] omap-mcbsp.3: alias fck already exists [3.461212] clock: dpll1_ck failed transition to 'locked' What's happening in those 3.3 seconds? regards, Koen -- 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 v4-alt 0/6] GPMC driver migrate one
Hi Tony, As you would have already seen, v4 of GPMC driver conversion has been posted (this is v4-alt). I undertand the risk involved in converting all board files to use new interface in a single patch series. But to have a decent set of patches, I feel this is required. But this may bring us to a point where GPMC may not work on some boards. To resolve this and as per your earlier question on whether old along with new interface can be made to work parallely, here is suggestion from my end to deal with it. This series converts to driver, as an example provides new interface for smsc911x, while keeping the old interface. As an example omap3evm has been tested. With this patch series omap3evm will work with new interface, and if 6/6 is not included, it will work with old interface. But this necessitates some ugly patches which are present in this series. So the suggestion is, enhance v4-alt to handle new interface parallely for others (GPMC peripherals boards), hence creating vX-alt (I will do it if you feel is required, but have not proceeded too much in this dierction as of now as not sure whether you want to take this path), have vX-alt in one of your branches, also preferably merged to master, have the original series also in a separate branch. Let all the boards be tested, by those who have (I have only omap3evm, beagle board that is supported in mainline, in addition to beaglebone, am335x evm, but these won't boot on mainline), add fixes due to problems on boards (if), incorporate review comments onto vX-alt branch, once we are sure that all boards work, revert hacks in vX-alt branch and finally revise proper v4 to vX having decent set of patches such that, git diff vX-alt..vX is zero. If with v4 directly, all boards work properly, we may not have to go through all these, but I realize, that may not happen in the first try itself. But I am not so pessimistic though, as all the test were initially done on omap3evm (SMSC911x, NAND OneNAND, last two were tested using private patches on new old omap3evm), and upon adding board modification for beagleboard, NAND directly worked, in addition to the surprise that HWMOD on OMAP3 did work properly first time. I would prefer directly using single patch series for converting all the boards, but if you prefer an alternative path to be on safer side, above is my suggestion, or if you have any other plans, let me know. Please let me know whether you are fine in taking patch series as in v4 (that converts all boards at once, with further revisions based on review comments). Both v4 v4-alt series are available as tags gpmc-v4 gpmc-v4-alt, repectively @git://gitorious.org/x0148406-public/linux-kernel.git Regards Afzal Afzal Mohammed (6): ARM: OMAP2+: gpmc: driver conversion ARM: OMAP2+: gpmc: Adapt to HWMOD ARM: OMAP3: hwmod data: add gpmc ARM: OMAP2+: gpmc: driver migration hack ARM: OMAP2+: gpmc-smsc911x: Add helper for driver conversion ARM: OMAP2+: board omap3evm: gpmc driver adaptation arch/arm/mach-omap2/board-omap3evm.c| 14 +- arch/arm/mach-omap2/gpmc-smsc911x.c | 70 ++ arch/arm/mach-omap2/gpmc.c | 951 --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 52 ++ arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |9 + arch/arm/plat-omap/include/plat/gpmc.h | 94 ++- 6 files changed, 1078 insertions(+), 112 deletions(-) -- 1.7.10 -- 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 v4-alt 1/6] ARM: OMAP2+: gpmc: driver conversion
Convert GPMC code to driver. Boards using GPMC should provide driver with type of configuration, timing, CS. Platform devices would then be created for each connected peripheral (details also to be passed by board so that it reaches respective driver). And GPMC driver would populate memory resource details for the connected peripheral driver. Boards should inform gpmc driver with platform data destined for peripheral driver. gpmc driver will provide the same information to peripheral driver. A peripheral connected to GPMC can have multiple address spaces using different chip select. Hence GPMC driver has been provided capability to create platform device for peripheral using mutiple CS. The peripheral that made it necessary was tusb6010. Interrupts of GPMC are presented to drivers of connected peripherals as resource. A fictitious interrupt controller chip handles these interrupts at GPMC hardware level. Clients can use normal interrupt APIs. Platform information of peripheral passed to GPMC driver should indicate interrupts to be used via flags. Driver is capable of configuring waitpin, waitpin details has to be provided per CS. Wait pin has been considered as exclusive resource as multiple peripherals should not using the same pin, at the same it is valid for mutiple CS to use same waitpin provided they are a part of single peripheral (eg. tusb6010) An exported symbol for reconfiguring GPMC settings has been provided. OneNAND is the one that neccessitated 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. Modifications has been made keeping in mind that the driver would have to move to driver folder. This explains requirement of clk_prd field; even though clk_prd variable is not necessary as gpmc_get_fclk_period is present in the same file as of now, this will help in moving the driver easily to drivers folder. Code related to GPMC clock may have to continue live in platform folders as input clock is beyond the control of GPMC and calculating timing for the peripheral may need other helpers. This explains presence of 'gpmc_cs_calc_divider' along with 'gpmc_calc_divider', both doing same work, latter meant to go with driver, former for calculation in platform code. Thanks to Vaibhav Hiremath Jonathan Hunter on their various good suggestions which resulted in improving the code. Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Jon Hunter jon-hun...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/gpmc.c | 877 arch/arm/plat-omap/include/plat/gpmc.h | 93 +++- 2 files changed, 872 insertions(+), 98 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 580e684..12916f3 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 @@ -53,6 +56,45 @@ #define GPMC_CS0_OFFSET0x60 #define GPMC_CS_SIZE 0x30 +/* GPMC register bits */ +#defineGPMC_CONFIG1_TIMEPARAGRANULARITYBIT(4) +#defineGPMC_CONFIG1_DEVICETYPE_NAND GPMC_CONFIG1_DEVICETYPE(0x2) +#defineGPMC_CONFIG1_WAIT_PIN_SEL_MASK GPMC_CONFIG1_WAIT_PIN_SEL(0x3) +#defineGPMC_CONFIG1_WAIT_MON_TIME(val) ((val 0x3) 18) +#defineGPMC_CONFIG1_WRITEMULTIPLE BIT(28) +#defineGPMC_CONFIG1_READMULTIPLE BIT(30) +#defineGPMC_CONFIG1_WRAPBURST BIT(31) +#defineGPMC_CONFIG_WAITPIN_POLARITY_SHIFT 0x8 +#defineGPMC_CONFIG1_WAITPIN_MONITOR_TIME(val) ((val 0x3) 18) +#defineGPMC_CONFIG1_WAITPIN_MONITOR_TIME_1 \ + GPMC_CONFIG1_WAITPIN_MONITOR_TIME(0x1) +#defineGPMC_CONFIG1_WAITPIN_MONITOR_TIME_2 \ + GPMC_CONFIG1_WAITPIN_MONITOR_TIME(0x2) +#defineGPMC_CONFIG1_CLOCKACTIVATION_TIME(val) ((val 0x3) 25) +#defineGPMC_CONFIG1_CLOCKACTIVATION_TIME_1 \ + GPMC_CONFIG1_CLOCKACTIVATION_TIME(0x1) +#defineGPMC_CONFIG1_CLOCKACTIVATION_TIME_2 \ + GPMC_CONFIG1_CLOCKACTIVATION_TIME(0x2) + +#defineGPMC_CONFIG2_CSEXTRADELAY BIT(7) + +#defineGPMC_CONFIG3_ADVEXTRADELAY BIT(7) + +#defineGPMC_CONFIG4_OEEXTRADELAY BIT(7) +#defineGPMC_CONFIG4_WEEXTRADELAY BIT(23) + +#defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6) +#defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7) + +#define
[PATCH v4-alt 2/6] ARM: OMAP2+: gpmc: Adapt to HWMOD
Create API for platforms to adapt gpmc to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 52 +++-
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 12916f3..c8d07bb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -33,6 +33,8 @@
#include plat/sdrc.h
+#include plat/omap_device.h
+
/* GPMC register offsets */
#define GPMC_REVISION 0x00
#define GPMC_SYSCONFIG 0x10
@@ -276,6 +278,31 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
return ticks * gpmc_get_fclk_period() / 1000;
}
+int __init omap_init_gpmc(struct gpmc_pdata *pdata)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *name = omap-gpmc;
+ char *oh_name = gpmc;
+
+ pdata-clk_prd = gpmc_get_fclk_period();
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(name, -1, oh, pdata,
+ sizeof(*pdata), NULL, 0, 0);
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
@@ -843,24 +870,19 @@ static __devinit void gpmc_mem_init(void)
static int __init gpmc_init(void)
{
- int ret = -EINVAL;
- 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;
- }
+ char *oh_name = gpmc;
+ struct omap_hwmod *oh;
- if (WARN_ON(!ck))
- return ret;
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
- gpmc_l3_clk = clk_get(NULL, ck);
+ gpmc_l3_clk = clk_get(NULL, oh-main_clk);
if (IS_ERR(gpmc_l3_clk)) {
- printk(KERN_ERR Could not get GPMC clock %s\n, ck);
- BUG();
+ pr_err(error: clk_get on %s\n, oh-main_clk);
+ return -EINVAL;
}
clk_enable(gpmc_l3_clk);
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2eedd99..c5cf020 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -217,6 +217,7 @@ struct gpmc_pdata {
};
extern int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *cs);
+extern int omap_init_gpmc(struct gpmc_pdata *pdata);
extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
--
1.7.10
--
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 v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Add gpmc hwmod and associated interconnect data
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0c65079..4da8394 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1981,6 +1981,40 @@ static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod = {
};
/*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_gpmc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_gpmc_hwmod_class = {
+ .name = gpmc,
+ .sysc = omap3xxx_gpmc_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_gpmc_irqs[] = {
+ { .irq = 20 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap3xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap3xxx_gpmc_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap3xxx_gpmc_irqs,
+ .main_clk = gpmc_fck,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+};
+
+/*
* interfaces
*/
@@ -3059,6 +3093,23 @@ static struct omap_hwmod_ocp_if
omap3xxx_l4_core__usb_tll_hs = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap3xxx_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6E00,
+ .pa_end = 0x6E000FFF,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__gpmc = {
+ .master = omap3xxx_l3_main_hwmod,
+ .slave = omap3xxx_gpmc_hwmod,
+ .clk= core_l3_ick,
+ .addr = omap3xxx_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l3_main__l4_core,
omap3xxx_l3_main__l4_per,
@@ -3103,6 +3154,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[]
__initdata = {
omap34xx_l4_core__mcspi2,
omap34xx_l4_core__mcspi3,
omap34xx_l4_core__mcspi4,
+ omap3xxx_l3_main__gpmc,
NULL,
};
--
1.7.10
--
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 v4-alt 4/6] ARM: OMAP2+: gpmc: driver migration hack
This has been made for migrating boards one by one so that
old new interface can coexist. As a board is migrated to
new interface, return from gpmc_driver_migration w/o doing
anything; add a machine_is_ check for that board to return
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c8d07bb..4dcc141 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,6 +868,18 @@ static __devinit void gpmc_mem_init(void)
}
}
+static void gpmc_driver_migration(void)
+{
+ static struct gpmc_device_pdata *gpmc_device_data[1];
+ static struct gpmc_pdata gpmc_data = {
+ .device_pdata = gpmc_device_data,
+ };
+
+ omap_init_gpmc(gpmc_data);
+}
+
+static int gpmc_module_init(void);
+
static int __init gpmc_init(void)
{
char *oh_name = gpmc;
@@ -887,7 +899,9 @@ static int __init gpmc_init(void)
clk_enable(gpmc_l3_clk);
- return 0;
+ gpmc_driver_migration();
+
+ return gpmc_module_init();
}
postcore_initcall(gpmc_init);
@@ -1484,7 +1498,16 @@ static struct platform_driver gpmc_driver = {
},
};
-module_platform_driver(gpmc_driver);
+static __init int gpmc_module_init(void)
+{
+ return platform_driver_register(gpmc_driver);
+}
+
+static __exit void gpmc_tmp_exit(void)
+{
+ platform_driver_unregister(gpmc_driver);
+}
+module_exit(gpmc_tmp_exit);
#ifdef CONFIG_ARCH_OMAP3
static struct omap3_gpmc_regs gpmc_context;
--
1.7.10
--
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 v4-alt 5/6] ARM: OMAP2+: gpmc-smsc911x: Add helper for driver conversion
New interface for working with gpmc driver has been added
without modifying the existing interface. Latter has been kept
for migrating boards one by one, once all boards are migrated
to use the new interace, old interface to be deleted along with
renaming of new interface to old one
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 70 +++
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |9 +++
2 files changed, 79 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index b6c77be..3b33b48 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -99,3 +99,73 @@ free1:
pr_err(Could not initialize smsc911x device\n);
}
+
+static struct resource gpmc_smsc911x_resources_new = {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+};
+
+__init struct gpmc_device_pdata *
+gpmc_smsc911x_init_new(struct omap_smsc911x_platform_data *gpmc_cfg)
+{
+ int ret;
+ struct gpmc_device_pdata *gpmc_pdev;
+ struct gpmc_cs_data *gpmc_cs;
+
+ gpmc_pdev = kzalloc(sizeof(*gpmc_pdev), GFP_KERNEL);
+ if (gpmc_pdev == NULL)
+ return gpmc_pdev;
+
+ gpmc_cs = kzalloc(sizeof(*gpmc_cs), GFP_KERNEL);
+ if (gpmc_pdev == NULL) {
+ kfree(gpmc_pdev);
+ return NULL;
+ }
+
+ gpmc_pdev-cs_data = gpmc_cs;
+ gpmc_pdev-num_cs = 1;
+ gpmc_pdev-name = smsc911x;
+ gpmc_pdev-id = gpmc_cfg-id;
+ gpmc_pdev-pdata = gpmc_smsc911x_config;
+ gpmc_pdev-pdata_size = sizeof(gpmc_smsc911x_config);
+
+ gpmc_cs-cs = gpmc_cfg-cs;
+ gpmc_cs-mem_size = 0x100;
+
+ gpmc_pdev-per_res = gpmc_smsc911x_resources_new;
+ gpmc_pdev-per_res_cnt = 1;
+
+ if (gpio_request_one(gpmc_cfg-gpio_irq, GPIOF_IN, smsc911x irq)) {
+ pr_err(Failed to request IRQ GPIO%d\n, gpmc_cfg-gpio_irq);
+ goto free1;
+ }
+
+ gpmc_smsc911x_resources_new.start = gpio_to_irq(gpmc_cfg-gpio_irq);
+
+ if (gpio_is_valid(gpmc_cfg-gpio_reset)) {
+ ret = gpio_request_one(gpmc_cfg-gpio_reset,
+ GPIOF_OUT_INIT_HIGH, smsc911x reset);
+ if (ret) {
+ pr_err(Failed to request reset GPIO%d\n,
+ gpmc_cfg-gpio_reset);
+ goto free2;
+ }
+
+ gpio_set_value(gpmc_cfg-gpio_reset, 0);
+ msleep(100);
+ gpio_set_value(gpmc_cfg-gpio_reset, 1);
+ }
+
+ gpmc_smsc911x_config.flags = gpmc_cfg-flags ? : SMSC911X_USE_16BIT;
+
+ return gpmc_pdev;
+
+free2:
+ gpio_free(gpmc_cfg-gpio_irq);
+free1:
+ kfree(gpmc_cs);
+ kfree(gpmc_pdev);
+
+ pr_err(Could not initialize smsc911x device\n);
+
+ return NULL;
+}
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index ea6c9c8..2e28e52 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -25,11 +25,20 @@ struct omap_smsc911x_platform_data {
extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
+extern struct gpmc_device_pdata *
+gpmc_smsc911x_init_new(struct omap_smsc911x_platform_data *d);
+
#else
static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
{
}
+static inline struct gpmc_device_pdata *
+gpmc_smsc911x_init_new(struct omap_smsc911x_platform_data *d)
+{
+ return NULL;
+}
+
#endif
#endif
--
1.7.10
--
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 v4-alt 6/6] ARM: OMAP2+: board omap3evm: gpmc driver adaptation
gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information
Note: This uses new interface for initializing smsc911x,
old interface should be removed once all boards are
converted to use new interface. So also machine_is_
check in gpmc.c as well as the patch,
ARM: OMAP2+: gpmc: driver migration hack
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 14 +-
arch/arm/mach-omap2/gpmc.c |3 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index fd1b481..7c83c45 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -43,6 +43,7 @@
#include plat/board.h
#include plat/usb.h
+#include plat/gpmc.h
#include common.h
#include plat/mcspi.h
#include video/omapdss.h
@@ -102,6 +103,12 @@ static void __init omap3_evm_get_revision(void)
}
}
+static struct gpmc_device_pdata *gpmc_device_data[1];
+
+static struct gpmc_pdata gpmc_data = {
+ .device_pdata = gpmc_device_data,
+};
+
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include plat/gpmc-smsc911x.h
@@ -122,7 +129,11 @@ static inline void __init omap3evm_init_smsc911x(void)
smsc911x_cfg.gpio_reset = OMAP3EVM_GEN2_ETHR_GPIO_RST;
}
- gpmc_smsc911x_init(smsc911x_cfg);
+ *gpmc_device_data = gpmc_smsc911x_init_new(smsc911x_cfg);
+ if (*gpmc_device_data)
+ gpmc_data.num_device++;
+ else
+ pr_err(error: unable to initilaize gpmc smsc911x\n);
}
#else
@@ -679,6 +690,7 @@ static void __init omap3_evm_init(void)
usbhs_init(usbhs_bdata);
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
+ omap_init_gpmc(gpmc_data);
omap3_evm_display_init();
omap3_evm_wl12xx_init();
}
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4dcc141..eb7580d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -875,6 +875,9 @@ static void gpmc_driver_migration(void)
.device_pdata = gpmc_device_data,
};
+ if (machine_is_omap3evm())
+ return;
+
omap_init_gpmc(gpmc_data);
}
--
1.7.10
--
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-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: I will be waiting for your comment and conformation on, which family AM33xx device should fall in? Please refer to the mail-chain - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html This decision turns out to be pretty important; it certainly affects the AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. Here is my suggestion, based on our previous practice. I am not so sure that it is the best way, but it seems pretty reasonable Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as far as I can tell. The main area of similarity between the other CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU subsystem is quite different between, say, the 3430/3630 and the AM33xx. Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM interface, OMAP4-style interconnect, etc. Plus, most of the CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like the PM code. This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, PL310, etc. None of that is true for AM335x. So first we have to decide whether the CONFIG_ARCH_OMAP* options should have a strong dependency on the MPU type, as they currently do; or whether they should focus on the way the SoC is integrated. If we take the former option, then we should add a new CONFIG_ARCH_OMAPAM33XX Kconfig option to arch/arm/Makefile, at the same level as CONFIG_ARCH_OMAP1/2/3/4. Similarly, we should add a CONFIG_ARCH_OMAPTI81XX Kconfig option. However, if we take the second option, then we can probably shoehorn the AM33XX and the TI81xx chips into CONFIG_ARCH_OMAP4. Either way, it would be good to get AM33xx and TI81xx out of CONFIG_ARCH_OMAP3, since keeping them there will require lots of changes across the codebase to stop using CONFIG_ARCH_OMAP3 and use the CONFIG_SOC_* Kconfig options instead. - Paul -- 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: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote: Hi Tero, On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote: From: Axel Haslam axelhas...@gmail.com On OMAP4, there is no support to read previous logic state or previous memory state achieved when a power domain transitions to RET. Instead there are module level context registers. In order to support the powerdomain level logic/mem_off_counters on OMAP4, instead use the previous power state achieved (RET) and the *programmed* logic/mem RET state to derive if a powerdomain lost logic or did not. If the powerdomain is programmed to enter RET state and lose logic in RET state, knowing that the powerdomain entered RET is good enough to derive that the logic was lost as well, in such cases. Unfortunately this won't scale for AM33xx devices :( It neither has module level context registers nor previous logic/memory state registers in PRCM. At a top level, there's a Cortex-M3 (CM3) to assist the low power state transitions and the indication of successful transition to a low power states is handled as part of the IPC mechanism between the MPU (A8) and CM3 which is s/w defined. Since the various APIs like omap_hwmod_get_context_loss_context() and friends are necessary to have correct context saves and restores in drivers we'll need to add another API for AM33xx which basically builds on the IPC mechanism and updates the counters. So, instead of the fallback mechanism that is currently in place, can the implementation for updating the logic/mem counters be converted to make use of function pointers. When AM33xx PM support comes in, we can just define a custom function and not pollute the code with cpu_is_* checks. I think that should be fine. We can add arch_hwmod struct or such (similar to arch_clkdm / arch_pwrdm) if need be. However, I think we should just expand the support towards that way once we can implement the am33xx support properly with a separate patch. I guess this doesn't break anything on am33xx currently, right? -Tero -- 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-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
I realize people may not necessarily like this, but I think that the
AM33xx EVM needs its own board file. This is because it really has
nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
So the following modification of this patch opts for the former Kconfig
option, CONFIG_ARCH_OMAPAM33XX. It also adds a new, minimal board file
for the AM33xx EVM.
If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for
the AM33xx, then we could potentially add the new machine record into
board-omap4panda.c. Although even then, if political considerations were
set aside, the best technical decision would probably be to create a
separate board file, since the boards don't have much in common.
- Paul
From: Afzal Mohammed af...@ti.com
Date: Fri, 2 Dec 2011 12:13:23 +0530
Subject: [PATCH] ARM: OMAP: AM33xx: Add AM335XEVM machine support
This patch adds minimal support for AM335X EVM.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
[p...@pwsan.com: created new board file for AM33xx; moved am33xx_init_early()
outside of CONFIG_ARCH_OMAP3; modified commit message]
---
arch/arm/mach-omap2/Kconfig |5
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-am335xevm.c | 46 +
arch/arm/mach-omap2/common.h |2 ++
arch/arm/mach-omap2/io.c |8 ++
arch/arm/mach-omap2/timer.c |2 ++
6 files changed, 64 insertions(+)
create mode 100644 arch/arm/mach-omap2/board-am335xevm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5ae756a..d5aa936 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -335,6 +335,11 @@ config MACH_TI8148EVM
depends on SOC_OMAPTI81XX
default y
+config MACH_AM335XEVM
+ bool AM335X Evaluation Module
+ depends on SOC_OMAPAM33XX
+ default y
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c538b3e..d3c33df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -241,6 +241,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=
board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM) += board-am335xevm.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am335xevm.c
b/arch/arm/mach-omap2/board-am335xevm.c
new file mode 100644
index 000..324752e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -0,0 +1,46 @@
+/*
+ * board-am335xevm.c - support the TI AM335x EVM board
+ *
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include common.h
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+ omap_serial_init();
+ omap_sdrc_init(NULL, NULL);
+ omap_board_config = am335x_evm_config;
+ omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+MACHINE_START(AM335XEVM, am335xevm)
+ /* Maintainer: Texas Instruments */
+ .atag_offset= 0x100,
+ .map_io = am33xx_map_io,
+ .init_early = am33xx_init_early,
+ .init_irq = ti81xx_init_irq,
+ .timer = omap3_am33xx_timer,
+ .init_machine = am335x_evm_init,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 57da7f4..dae39a3 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@
RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
Hello Vaibhav, I've reworked these patches somewhat to separate the PRM and CM changes into their own patches. Also, the omap_hwmod changes have been separated and moved into a different series, as have the clock tree changes. So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, powerdomain, and clockdomain changes. Under the (probably incorrect) assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of git://git.pwsan.com/linux-2.6. It is based on four patches, not yet upstream, which create the appropriate board file, Kconfig options, etc. Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* options the AM33xx belongs under, this branch will be updated and reposted, and if everyone is happy with it, proposed for pulling. - Paul -- 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-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
I realize people may not necessarily like this, but I think that the
AM33xx EVM needs its own board file. This is because it really has
nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
So the following modification of this patch opts for the former Kconfig
option, CONFIG_ARCH_OMAPAM33XX. It also adds a new, minimal board file
for the AM33xx EVM.
If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for
the AM33xx, then we could potentially add the new machine record into
board-omap4panda.c. Although even then, if political considerations were
set aside, the best technical decision would probably be to create a
separate board file, since the boards don't have much in common.
Paul,
I completely agree with all of your comments, let Tony comment and conform
on this.
If you go back to history, that was our initial proposal, to create
separate Kconfig option for AM33XX.
Tony,
Can you please comment on this discussion? This is very important, since
lots of patches (accepted or about to accept) are dependent on this. The
early we can conclude on this, early I can rework on the patches and
resubmit them.
Thanks,
Vaibhav
- Paul
From: Afzal Mohammed af...@ti.com
Date: Fri, 2 Dec 2011 12:13:23 +0530
Subject: [PATCH] ARM: OMAP: AM33xx: Add AM335XEVM machine support
This patch adds minimal support for AM335X EVM.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
[p...@pwsan.com: created new board file for AM33xx; moved am33xx_init_early()
outside of CONFIG_ARCH_OMAP3; modified commit message]
---
arch/arm/mach-omap2/Kconfig |5
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-am335xevm.c | 46
+
arch/arm/mach-omap2/common.h |2 ++
arch/arm/mach-omap2/io.c |8 ++
arch/arm/mach-omap2/timer.c |2 ++
6 files changed, 64 insertions(+)
create mode 100644 arch/arm/mach-omap2/board-am335xevm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5ae756a..d5aa936 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -335,6 +335,11 @@ config MACH_TI8148EVM
depends on SOC_OMAPTI81XX
default y
+config MACH_AM335XEVM
+ bool AM335X Evaluation Module
+ depends on SOC_OMAPAM33XX
+ default y
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c538b3e..d3c33df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -241,6 +241,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=
board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM) += board-am335xevm.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am335xevm.c
b/arch/arm/mach-omap2/board-am335xevm.c
new file mode 100644
index 000..324752e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -0,0 +1,46 @@
+/*
+ * board-am335xevm.c - support the TI AM335x EVM board
+ *
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include common.h
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+ omap_serial_init();
+ omap_sdrc_init(NULL, NULL);
+ omap_board_config =
RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote: Hello Vaibhav, I've reworked these patches somewhat to separate the PRM and CM changes into their own patches. Also, the omap_hwmod changes have been separated and moved into a different series, as have the clock tree changes. So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, powerdomain, and clockdomain changes. Under the (probably incorrect) assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of git://git.pwsan.com/linux-2.6. It is based on four patches, not yet upstream, which create the appropriate board file, Kconfig options, etc. Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* options the AM33xx belongs under, this branch will be updated and reposted, and if everyone is happy with it, proposed for pulling. Sounds Great and Thanks a lot Paul. I will look at the above branch and update you if I find something wrong/missing. Thanks, Vaibhav -- 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 0/7] ARM: OMAP2+: Misc cleanup
This series has some miscellianeous clean up patches which help to add future OMAP2+ device support with bit less changes. It is a preparatory series for adding minimal OMAP5 support. Boot tested on below platforms: - OMAP2430 SDP - OMAP3430 SDP - OMAP4430 SDP Thanks for Tony and Benoit for these suggestions. The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: Linux 3.4-rc5 (2012-04-29 15:19:10 -0700) are available in the git repository at: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap_misc_cleanup R Sricharan (1): ARM: OMAP4+: Add prm and cm base init function. Santosh Shilimkar (6): ARM: OMAP4: Don't compile cm2xxx_3xxx.c for OMAP4 only builds. ARM: OMAP2+: Clean up wrapping multiple objects in Makefile ARM: OMAP4: Remove un-used WakeupGen register defines. ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching. ARM: All OMAP2PLUS machines use omap2 directory so just add one entry ARM: OMAP4: Reduce the static IO mapping arch/arm/Makefile |4 +- arch/arm/mach-omap2/Makefile | 163 ++--- arch/arm/mach-omap2/cminst44xx.c | 28 +++-- arch/arm/mach-omap2/common.c |1 + arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/dma.c |2 +- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |8 - arch/arm/mach-omap2/io.c | 30 arch/arm/mach-omap2/iomap.h | 28 arch/arm/mach-omap2/prcm-common.h | 13 ++ arch/arm/mach-omap2/prcm.c|8 + arch/arm/mach-omap2/prminst44xx.c | 27 ++-- arch/arm/plat-omap/dma.c |4 +- 13 files changed, 139 insertions(+), 178 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 1/7] ARM: OMAP4: Don't compile cm2xxx_3xxx.c for OMAP4 only builds.
Since OMAP4 code base now makes use of OMAP4 specific PRCM functions, cm2xxx_3xxx.c need not be compiled for OMAP4 only builds. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/Makefile |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 49f92bc..56ed62e 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -86,10 +86,7 @@ obj-y+= prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o \ vc3xxx_data.o vp3xxx_data.o -# XXX The presence of cm2xxx_3xxx.o on the line below is temporary and -# will be removed once the OMAP4 part of the codebase is converted to -# use OMAP4-specific PRCM functions. -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \ +obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o \ cm44xx.o prcm_mpu44xx.o \ prminst44xx.o vc44xx_data.o \ vp44xx_data.o prm44xx.o -- 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/7] ARM: OMAP4: Remove un-used WakeupGen register defines.
Current OMAP code doesn't use any of the OMAP_WKG_ENB_SECURE_* registers. So remove those defines. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h index d79321b..548de90b 100644 --- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -16,18 +16,10 @@ #define OMAP_WKG_ENB_B_0 0x14 #define OMAP_WKG_ENB_C_0 0x18 #define OMAP_WKG_ENB_D_0 0x1c -#define OMAP_WKG_ENB_SECURE_A_00x20 -#define OMAP_WKG_ENB_SECURE_B_00x24 -#define OMAP_WKG_ENB_SECURE_C_00x28 -#define OMAP_WKG_ENB_SECURE_D_00x2c #define OMAP_WKG_ENB_A_1 0x410 #define OMAP_WKG_ENB_B_1 0x414 #define OMAP_WKG_ENB_C_1 0x418 #define OMAP_WKG_ENB_D_1 0x41c -#define OMAP_WKG_ENB_SECURE_A_10x420 -#define OMAP_WKG_ENB_SECURE_B_10x424 -#define OMAP_WKG_ENB_SECURE_C_10x428 -#define OMAP_WKG_ENB_SECURE_D_10x42c #define OMAP_AUX_CORE_BOOT_0 0x800 #define OMAP_AUX_CORE_BOOT_1 0x804 #define OMAP_PTMSYNCREQ_MASK 0xc00 -- 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/7] ARM: OMAP2+: Clean up wrapping multiple objects in Makefile
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 160 - 1 files changed, 78 insertions(+), 82 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 56ed62e..669e2b1 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -24,10 +24,11 @@ endif obj-$(CONFIG_TWL4030_CORE) += omap_twl.o # SMP support ONLY available for OMAP4 + obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \ - sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) @@ -64,10 +65,10 @@ 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_OMAP3) += cpuidle34xx.o +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.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 @@ -84,85 +85,84 @@ endif # PRCM obj-y += prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o -obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o \ - vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o \ - cm44xx.o prcm_mpu44xx.o \ - prminst44xx.o vc44xx_data.o \ - vp44xx_data.o prm44xx.o +obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o +obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o +obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o +obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o -obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \ - voltagedomains2xxx_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \ - voltagedomains3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ - voltagedomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) +obj-$(CONFIG_ARCH_OMAP2) += voltagedomains2xxx_data.o +obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) +obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o +obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) +obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o -obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) \ - powerdomain2xxx_3xxx.o \ - powerdomains2xxx_data.o \ - powerdomains2xxx_3xxx_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) \ - powerdomain2xxx_3xxx.o \ - powerdomains3xxx_data.o \ - powerdomains2xxx_3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \ - powerdomain44xx.o \ - powerdomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) +obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_data.o +obj-$(CONFIG_ARCH_OMAP2) += powerdomain2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_3xxx_data.o +obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) +obj-$(CONFIG_ARCH_OMAP3) += powerdomain2xxx_3xxx.o
[PATCH 4/7] ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching.
cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code cpu checks accordingly so that there is no need to patch the file for any future OMAP2+ devices. In long run, all these attributes should come from hwmod dev_attr based on DMA IP version. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/dma.c |2 +- arch/arm/plat-omap/dma.c |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c index b19d849..2750bb9 100644 --- a/arch/arm/mach-omap2/dma.c +++ b/arch/arm/mach-omap2/dma.c @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) dma_stride = OMAP2_DMA_STRIDE; dma_common_ch_start = CSDP; - if (cpu_is_omap3630() || cpu_is_omap44xx()) + if (omap_rev() = OMAP3630_REV_ES1_0) dma_common_ch_end = CCDN; else dma_common_ch_end = CCFN; diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ecdb3da..c046a19 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -843,7 +843,7 @@ omap_dma_set_prio_lch(int lch, unsigned char read_prio, } l = p-dma_read(CCR, lch); l = ~((1 6) | (1 26)); - if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) + if (cpu_class_is_omap2() !cpu_is_omap242x()) l |= ((read_prio 0x1) 6) | ((write_prio 0x1) 26); else l |= ((read_prio 0x1) 6); @@ -2057,7 +2057,7 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev) } } - if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) + if (cpu_class_is_omap2() !cpu_is_omap242x()) omap_dma_set_global_params(DMA_DEFAULT_ARB_RATE, DMA_DEFAULT_FIFO_DEPTH, 0); -- 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/7] ARM: OMAP4: Reduce the static IO mapping
EMIF, GMPC and DMM driver can ioremap() the address
space as part of driver intialisation and there is
no need to have static IO mapping for them.
Hence remove the un-used static IP space and let
the respective drivers manage it as part if driver
init.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/io.c| 30 --
arch/arm/mach-omap2/iomap.h | 28
2 files changed, 0 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 065bd76..595a5dd 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -215,41 +215,11 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.type = MT_DEVICE,
},
{
- .virtual= OMAP44XX_GPMC_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_GPMC_PHYS),
- .length = OMAP44XX_GPMC_SIZE,
- .type = MT_DEVICE,
- },
- {
- .virtual= OMAP44XX_EMIF1_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_EMIF1_PHYS),
- .length = OMAP44XX_EMIF1_SIZE,
- .type = MT_DEVICE,
- },
- {
- .virtual= OMAP44XX_EMIF2_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_EMIF2_PHYS),
- .length = OMAP44XX_EMIF2_SIZE,
- .type = MT_DEVICE,
- },
- {
- .virtual= OMAP44XX_DMM_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_DMM_PHYS),
- .length = OMAP44XX_DMM_SIZE,
- .type = MT_DEVICE,
- },
- {
.virtual= L4_PER_44XX_VIRT,
.pfn= __phys_to_pfn(L4_PER_44XX_PHYS),
.length = L4_PER_44XX_SIZE,
.type = MT_DEVICE,
},
- {
- .virtual= L4_EMU_44XX_VIRT,
- .pfn= __phys_to_pfn(L4_EMU_44XX_PHYS),
- .length = L4_EMU_44XX_SIZE,
- .type = MT_DEVICE,
- },
#ifdef CONFIG_OMAP4_ERRATA_I688
{
.virtual= OMAP4_SRAM_VA,
diff --git a/arch/arm/mach-omap2/iomap.h b/arch/arm/mach-omap2/iomap.h
index 0812b15..80b8892 100644
--- a/arch/arm/mach-omap2/iomap.h
+++ b/arch/arm/mach-omap2/iomap.h
@@ -37,9 +37,6 @@
#define OMAP4_L3_PER_IO_OFFSET 0xb110
#define OMAP4_L3_PER_IO_ADDRESS(pa)IOMEM((pa) + OMAP4_L3_PER_IO_OFFSET)
-#define OMAP4_GPMC_IO_OFFSET 0xa900
-#define OMAP4_GPMC_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_GPMC_IO_OFFSET)
-
#define OMAP2_EMU_IO_OFFSET0xaa80 /* Emulation */
#define OMAP2_EMU_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_EMU_IO_OFFSET)
@@ -170,28 +167,3 @@
#define L4_ABE_44XX_VIRT (L4_ABE_44XX_PHYS + OMAP2_L4_IO_OFFSET)
#define L4_ABE_44XX_SIZE SZ_1M
-#define L4_EMU_44XX_PHYS L4_EMU_44XX_BASE
- /* 0x5400 -- 0xfe80 */
-#define L4_EMU_44XX_VIRT (L4_EMU_44XX_PHYS + OMAP2_EMU_IO_OFFSET)
-#define L4_EMU_44XX_SIZE SZ_8M
-
-#define OMAP44XX_GPMC_PHYS OMAP44XX_GPMC_BASE
- /* 0x5000 -- 0xf900 */
-#define OMAP44XX_GPMC_VIRT (OMAP44XX_GPMC_PHYS + OMAP4_GPMC_IO_OFFSET)
-#define OMAP44XX_GPMC_SIZE SZ_1M
-
-
-#define OMAP44XX_EMIF1_PHYSOMAP44XX_EMIF1_BASE
- /* 0x4c00 -- 0xfd10 */
-#define OMAP44XX_EMIF1_VIRT(OMAP44XX_EMIF1_PHYS + OMAP4_L3_PER_IO_OFFSET)
-#define OMAP44XX_EMIF1_SIZESZ_1M
-
-#define OMAP44XX_EMIF2_PHYSOMAP44XX_EMIF2_BASE
- /* 0x4d00 -- 0xfd20 */
-#define OMAP44XX_EMIF2_SIZESZ_1M
-#define OMAP44XX_EMIF2_VIRT(OMAP44XX_EMIF1_VIRT + OMAP44XX_EMIF1_SIZE)
-
-#define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE
- /* 0x4e00 -- 0xfd30 */
-#define OMAP44XX_DMM_SIZE SZ_1M
-#define OMAP44XX_DMM_VIRT (OMAP44XX_EMIF2_VIRT + OMAP44XX_EMIF2_SIZE)
--
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/7] ARM: All OMAP2PLUS machines use omap2 directory so just add one entry
All OMAP2PLUS arch based machines makes use of mach-omap2 directory. So just add one entry so that there is no need to patch this file for any OMAP2+ devices. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 047a207..7a6bde0 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -164,9 +164,7 @@ machine-$(CONFIG_ARCH_MXS) := mxs machine-$(CONFIG_ARCH_NETX):= netx machine-$(CONFIG_ARCH_NOMADIK) := nomadik machine-$(CONFIG_ARCH_OMAP1) := omap1 -machine-$(CONFIG_ARCH_OMAP2) := omap2 -machine-$(CONFIG_ARCH_OMAP3) := omap2 -machine-$(CONFIG_ARCH_OMAP4) := omap2 +machine-$(CONFIG_ARCH_OMAP2PLUS) := omap2 machine-$(CONFIG_ARCH_ORION5X) := orion5x machine-$(CONFIG_ARCH_PICOXCELL) := picoxcell machine-$(CONFIG_ARCH_PNX4008) := pnx4008 -- 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/7] ARM: OMAP4+: Add prm and cm base init function.
From: R Sricharan r.sricha...@ti.com
Instead of statically defining seperate arrays for every OMAP4+ archs,
have a generic init function to populate the arrays. This avoids the
need for creating new array for every arch added in the future that
reuses the prm and cm registers read/write code.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cminst44xx.c | 28 ++--
arch/arm/mach-omap2/common.c |1 +
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/prcm-common.h | 13 +
arch/arm/mach-omap2/prcm.c|8
arch/arm/mach-omap2/prminst44xx.c | 27 ---
6 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index bd8810c..8c86d29 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -32,6 +32,7 @@
#include prcm44xx.h
#include prm44xx.h
#include prcm_mpu44xx.h
+#include prcm-common.h
/*
* CLKCTRL_IDLEST_*: possible values for the CM_*_CLKCTRL.IDLEST bitfield:
@@ -49,14 +50,21 @@
#define CLKCTRL_IDLEST_INTERFACE_IDLE 0x2
#define CLKCTRL_IDLEST_DISABLED0x3
-static u32 _cm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
- [OMAP4430_INVALID_PRCM_PARTITION] = 0,
- [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE,
- [OMAP4430_CM1_PARTITION]= OMAP4430_CM1_BASE,
- [OMAP4430_CM2_PARTITION]= OMAP4430_CM2_BASE,
- [OMAP4430_SCRM_PARTITION] = 0,
- [OMAP4430_PRCM_MPU_PARTITION] = OMAP4430_PRCM_MPU_BASE,
-};
+static void __iomem *_cm_bases[OMAP4_MAX_PRCM_PARTITIONS];
+
+/**
+ * omap_cm_base_init - Populates the cm partitions
+ *
+ * Populates the base addresses of the _cm_bases
+ * array used for read/write of cm module registers.
+ */
+void omap_cm_base_init(void)
+{
+ _cm_bases[OMAP4430_PRM_PARTITION] = prm_base;
+ _cm_bases[OMAP4430_CM1_PARTITION] = cm_base;
+ _cm_bases[OMAP4430_CM2_PARTITION] = cm2_base;
+ _cm_bases[OMAP4430_PRCM_MPU_PARTITION] = prcm_mpu_base;
+}
/* Private functions */
@@ -106,7 +114,7 @@ u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx)
BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
part == OMAP4430_INVALID_PRCM_PARTITION ||
!_cm_bases[part]);
- return __raw_readl(OMAP2_L4_IO_ADDRESS(_cm_bases[part] + inst + idx));
+ return __raw_readl(_cm_bases[part] + inst + idx);
}
/* Write into a register in a CM instance */
@@ -115,7 +123,7 @@ void omap4_cminst_write_inst_reg(u32 val, u8 part, s16
inst, u16 idx)
BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
part == OMAP4430_INVALID_PRCM_PARTITION ||
!_cm_bases[part]);
- __raw_writel(val, OMAP2_L4_IO_ADDRESS(_cm_bases[part] + inst + idx));
+ __raw_writel(val, _cm_bases[part] + inst + idx);
}
/* Read-modify-write a register in CM1. Caller must lock */
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 1549c11..8a6953a 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -166,6 +166,7 @@ static struct omap_globals omap4_globals = {
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
.cm2= OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
+ .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
};
void __init omap2_set_globals_443x(void)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 57da7f4..0672fc5 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -111,6 +111,7 @@ struct omap_globals {
void __iomem*prm;/* Power and Reset Management */
void __iomem*cm; /* Clock Management */
void __iomem*cm2;
+ void __iomem*prcm_mpu;
};
void omap2_set_globals_242x(void);
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 5aa5435..0b42143 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -410,6 +410,19 @@
extern void __iomem *prm_base;
extern void __iomem *cm_base;
extern void __iomem *cm2_base;
+extern void __iomem *prcm_mpu_base;
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_OMAP5)
+extern void omap_prm_base_init(void);
+extern void omap_cm_base_init(void);
+#else
+static inline void omap_prm_base_init(void)
+{
+}
+static inline void omap_cm_base_init(void)
+{
+}
+#endif
/**
* struct omap_prcm_irq - describes a PRCM interrupt bit
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 626acfa..480f40a 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -42,6 +42,7 @@
void
RE: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Wed, May 02, 2012 at 14:50:21, Kristo, Tero wrote:
On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
From: Axel Haslam axelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Unfortunately this won't scale for AM33xx devices :(
It neither has module level context registers nor previous logic/memory
state
registers in PRCM.
At a top level, there's a Cortex-M3 (CM3) to assist the low power state
transitions
and the indication of successful transition to a low power states is
handled as part
of the IPC mechanism between the MPU (A8) and CM3 which is s/w defined.
Since the various APIs like omap_hwmod_get_context_loss_context() and
friends are
necessary to have correct context saves and restores in drivers we'll need
to add another API for AM33xx which basically builds on the IPC mechanism
and updates the counters.
So, instead of the fallback mechanism that is currently in place, can the
implementation for updating the logic/mem counters be converted to make use
of
function pointers. When AM33xx PM support comes in, we can just define
a custom function and not pollute the code with cpu_is_* checks.
I think that should be fine. We can add arch_hwmod struct or such
(similar to arch_clkdm / arch_pwrdm) if need be. However, I think we
should just expand the support towards that way once we can implement
the am33xx support properly with a separate patch. I guess this doesn't
break anything on am33xx currently, right?
It doesn't break anything right now but since we know this doesn't scale
that would be save some additional round of validation on OMAP3/4
later on.
-Vaibhav
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH 2/7] ARM: OMAP2+: Clean up wrapping multiple objects in Makefile
On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote: Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 160 - 1 files changed, 78 insertions(+), 82 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 56ed62e..669e2b1 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -24,10 +24,11 @@ endif obj-$(CONFIG_TWL4030_CORE) += omap_twl.o # SMP support ONLY available for OMAP4 + obj-$(CONFIG_SMP)+= omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \ -sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o Using \ in makefiles really isn't a problem. I don't think this is something which we need to do, and it just creates additional changes where none is required. -- 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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from OFF mode.
The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
are saved and restored here during an OFF transition.
Most of the registers being saved and restored in the various
patches look to be contiguous. So, instead of a long list of these
contiguous registers how about having a generic API for backup and
restore of the registers contents based on the memory address range?
Most of the registers which require save and restore are either part
of PRM, CM or Control. The PRM or CM instance could be passed as the
base and the save/restore API could work around that.
One downside is that there are some read-only registers in between but
I don't see any simple way of avoiding save and restore of those. BTW,
as per the TRM that I have, this patch is also doing save and restore
of some read-only registers.
[n...@ti.com: minor cleanups]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm44xx.h |5 +
arch/arm/mach-omap2/dpll44xx.c | 271
2 files changed, 276 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h
index 3380bee..5fba0fa 100644
--- a/arch/arm/mach-omap2/cm44xx.h
+++ b/arch/arm/mach-omap2/cm44xx.h
@@ -23,4 +23,9 @@
#define OMAP4_CM_CLKSTCTRL 0x
#define OMAP4_CM_STATICDEP 0x0004
+#ifndef __ASSEMBLER__
+extern void omap4_dpll_prepare_off(void);
+extern void omap4_dpll_resume_off(void);
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 9c6a296..b411d3b 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -14,6 +14,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/bitops.h
+#include linux/delay.h
#include plat/cpu.h
#include plat/clock.h
@@ -21,6 +22,96 @@
#include clock.h
#include clock44xx.h
#include cm-regbits-44xx.h
+#include cm1_44xx.h
+#include cm2_44xx.h
+#include prcm44xx.h
+#include cminst44xx.h
+#include cm44xx.h
+
+#define MAX_DPLL_WAIT_TRIES 100
+
+struct dpll_reg {
+ u16 offset;
+ u32 val;
+};
+
+struct omap4_dpll_regs {
+ char *name;
+ u32 mod_partition;
+ u32 mod_inst;
+ struct dpll_reg clkmode;
+ struct dpll_reg autoidle;
+ struct dpll_reg idlest;
+ struct dpll_reg clksel;
+ struct dpll_reg div_m2;
+ struct dpll_reg div_m3;
+ struct dpll_reg div_m4;
+ struct dpll_reg div_m5;
+ struct dpll_reg div_m6;
+ struct dpll_reg div_m7;
+ struct dpll_reg clkdcoldo;
+};
+
+static struct omap4_dpll_regs dpll_regs[] = {
+ /* MPU DPLL */
+ { .name = mpu,
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_MPU_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_MPU_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_MPU_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_MPU_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_MPU_OFFSET},
+ },
+ /* IVA DPLL */
+ { .name = iva,
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_IVA_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_IVA_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_IVA_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_IVA_OFFSET},
+ .div_m4 = {.offset = OMAP4_CM_DIV_M4_DPLL_IVA_OFFSET},
+ .div_m5 = {.offset = OMAP4_CM_DIV_M5_DPLL_IVA_OFFSET},
+ },
+ /* ABE DPLL */
+ { .name = abe,
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_ABE_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_ABE_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_ABE_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_ABE_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_ABE_OFFSET},
+ .div_m3 = {.offset = OMAP4_CM_DIV_M3_DPLL_ABE_OFFSET},
+ },
+ /* USB DPLL */
+ { .name = usb,
+ .mod_partition = OMAP4430_CM2_PARTITION,
+ .mod_inst = OMAP4430_CM2_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_USB_OFFSET},
+ .autoidle = {.offset =
Re: [PATCH 2/7] ARM: OMAP2+: Clean up wrapping multiple objects in Makefile
On Wed, May 2, 2012 at 3:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote: Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 160 - 1 files changed, 78 insertions(+), 82 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 56ed62e..669e2b1 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -24,10 +24,11 @@ endif obj-$(CONFIG_TWL4030_CORE) += omap_twl.o # SMP support ONLY available for OMAP4 + obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \ - sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o Using \ in makefiles really isn't a problem. I don't think this is something which we need to do, and it just creates additional changes where none is required. Tony might give better reasoning for this change since he suggested it. 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: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from OFF mode.
The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
are saved and restored here during an OFF transition.
Most of the registers being saved and restored in the various
patches look to be contiguous. So, instead of a long list of these
contiguous registers how about having a generic API for backup and
restore of the registers contents based on the memory address range?
Most of the registers which require save and restore are either part
of PRM, CM or Control. The PRM or CM instance could be passed as the
base and the save/restore API could work around that.
One downside is that there are some read-only registers in between but
I don't see any simple way of avoiding save and restore of those. BTW,
as per the TRM that I have, this patch is also doing save and restore
of some read-only registers.
You should never write to read-only registers since the behavior is
undefined.
[...]
+void omap4_dpll_resume_off(void)
+{
+ u32 i;
+ struct omap4_dpll_regs *dpll_reg = dpll_regs;
+
+ for (i = 0; i ARRAY_SIZE(dpll_regs); i++, dpll_reg++) {
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clksel);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m2);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m3);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m4);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m5);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m6);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m7);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clkdcoldo);
+
+ /* Restore clkmode after the above registers are restored */
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clkmode);
+
+ omap4_wait_dpll_lock(dpll_reg);
+
+ /* Restore autoidle settings after the dpll is locked */
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-autoidle);
+ }
+}
If this function is placed in SRAM and PER PLL restored just after MPU
won't the exit latency be further optimized?
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
--
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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. -- Thanks, Govindraj.R [1]: http://pastebin.pandaboard.org/index.php/view/20343533 -- 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. From your log: [1.705291] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [3.726593] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Why is the ehci stuff taking more than 2 seconds? regards, Koen-- 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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from OFF mode.
The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
are saved and restored here during an OFF transition.
Most of the registers being saved and restored in the various
patches look to be contiguous. So, instead of a long list of these
contiguous registers how about having a generic API for backup and
restore of the registers contents based on the memory address range?
Most of the registers which require save and restore are either part
of PRM, CM or Control. The PRM or CM instance could be passed as the
base and the save/restore API could work around that.
One downside is that there are some read-only registers in between but
I don't see any simple way of avoiding save and restore of those. BTW,
as per the TRM that I have, this patch is also doing save and restore
of some read-only registers.
You should never write to read-only registers since the behavior is
undefined.
I was afraid of that. If all the read-only registers were clubbed together
a lot of code could have been removed. Looking more closely at the TRM
I guess we can't really ask design folks to club those read-only registers
in the future. So scratch this.
[...]
+void omap4_dpll_resume_off(void)
+{
+ u32 i;
+ struct omap4_dpll_regs *dpll_reg = dpll_regs;
+
+ for (i = 0; i ARRAY_SIZE(dpll_regs); i++, dpll_reg++) {
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clksel);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m2);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m3);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m4);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m5);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m6);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m7);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clkdcoldo);
+
+ /* Restore clkmode after the above registers are restored */
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clkmode);
+
+ omap4_wait_dpll_lock(dpll_reg);
+
+ /* Restore autoidle settings after the dpll is locked */
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-autoidle);
+ }
+}
If this function is placed in SRAM and PER PLL restored just after MPU
won't the exit latency be further optimized?
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
I am just guessing if that's indeed the case ;)
Haven't done any measurements to really check if that's indeed the case though.
--
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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 4:25 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
[...]
[...]
+void omap4_dpll_resume_off(void)
+{
+ u32 i;
+ struct omap4_dpll_regs *dpll_reg = dpll_regs;
+
+ for (i = 0; i ARRAY_SIZE(dpll_regs); i++, dpll_reg++) {
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clksel);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m2);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m3);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m4);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m5);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m6);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-div_m7);
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clkdcoldo);
+
+ /* Restore clkmode after the above registers are restored */
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-clkmode);
+
+ omap4_wait_dpll_lock(dpll_reg);
+
+ /* Restore autoidle settings after the dpll is locked */
+ omap4_dpll_restore_reg(dpll_reg, dpll_reg-autoidle);
+ }
+}
If this function is placed in SRAM and PER PLL restored just after MPU
won't the exit latency be further optimized?
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
I am just guessing if that's indeed the case ;)
Haven't done any measurements to really check if that's indeed the case
though.
You don't have to do any real measurements at least on OMAP.
OCMC RAM is interfaced over L4 and MPU has to cross two interconnect
bridges to reach to SRAM. DDR is more of direct path and much faster.
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: OMAP3 previewer bayer pattern selection
Hi Jean-Philippe, On Monday 30 April 2012 12:23:27 jean-philippe francois wrote: Hi, I am trying to get a working preview from a CMOS sensor with a CFA bayer pattern. Does the CCDC_COLPTN register have any effect on previewer CFA interpolation ? No it doesn't. The CCDC COLPTN register only affects CCDC operation. From my experience it does not. I can set BGGR or GRBG, but the output is always the same. When doing raw capture, I get nice image if I use a BGGR pattern for my software bayer to rgb interpolation. When using previewer, the output looks like BGGR interpreted as GRBG, ie blue and red are green, and green turns into purple. Looking at the driver code (mainline), there is nothing about bayer order in the previewer code. Looking at the TRM, theres is also nothing in the previewer part about bayer order. How are we supposed to debayer something different from GRBG ? By modifying the cfa_coef_table table ? Cropping at the previewer output to start on an odd line ? Selecting the CFA pattern requires modifying several registers: - PCR:CFA_FMT 0x0: Mode 0: conventional Bayer. 0x1: Mode 1: horizontal 2x downsample. 0x2: Mode 2: bypass CFA stage (RGB Foveon X3) 0x3: Mode 3: horizontal and vertical 2x downsample. 0x4: Mode 4: Super CCD Honeycom movie mode sensor. 0x5: Mode5: bypass CFA stage ( Foveon X3). The default value is Bayer, you won't need to change that. - WBSEL This register selects which white balance coefficient is applied to which pixel. This needs to match the Bayer pattern. - CFA table That's where the bulk of the work will be. The CFA coefficients table needs to be adjusted based on the Bayer pattern. Unfortunately the publicly available TRM doesn't document how the table should be computed. Thank you for any pointer on this issue. -- Regards, Laurent Pinchart -- 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 4:20 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. From your log: [ 1.705291] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.726593] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Why is the ehci stuff taking more than 2 seconds? phy reset operation in omap_ehci_soft_phy_reset failing and timing out. -- 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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Maybe there's a extra low latency path for DDR that I am missing. -- 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: smsc911x on Gumstix Overo/Tobi doesn't work
Am 01.04.2012 21:20, schrieb Javier Martinez Canillas: On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Hi, I finally had some time to do more tests on this problem. Findings below. Great, I guess we are close to find the issue :) Am 20.03.2012 20:47, schrieb Javier Martinez Canillas: On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Am 19.03.2012 23:51, schrieb Tony Lindgren: * Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]: Am 16.03.2012 20:33, schrieb Tony Lindgren: Hi, * Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]: Hi, I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows: du14:~# modprobe smsc911x [ 254.843811] smsc911x: Driver version 2008-10-21 [ 254.854553] smsc911x: Driver version 2008-10-21 [ 254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator [ 254.868377] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator ip link show does not show any available Ethernet port. The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3. The Tobi board has only one Ethernet port. I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case. The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed. Care to test the following patch by passing a fixed regulator from board-overo.c? After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you! Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted? You're right, during further tests I found that the problem lies elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after # modprobe -r smsc911x [attach cable] # modprobe smsc911x it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem. Hi Thomas, I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode. The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful. I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset. The commit is: commit 6386994e03ebbe60338ded3d586308a41e81c0dc Author: Javier Martinez Canillas jav...@dowhile0.org Date: Tue Jan 3 13:36:19 2012 + net/smsc911x: Check if PHY is in operational mode before software reset When I fix the issue I only guarded against generation 4 chips (i.e: pdata-generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets). Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode. After looking at the code I set USE_DEBUG to 3 to get as much information as possible and tested with and without the SMSC PHY driver. Results: With the Ethernet cable attached, the device is properly initialized with and without the PHY driver (as before). Without the cable, the smsc911x driver can initialize the card only if the smsc PHY driver had not been loaded previously. Unloading the PHY driver is not enough, even a reboot doesn't help. I have to do a cold boot (or attach the cable). This makes sense since is the PHY driver who enables the auto energy detect mode. I guess this confirms Javier's guess, but there's one catch: If you take a
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Nope. It's on L4 and it is same for all OMAPs including OMAP5 Maybe there's a extra low latency path for DDR that I am missing. Even OMAP3 DDR is faster than OCMC RAM. 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: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Maybe there's a extra low latency path for DDR that I am missing. have you folks considered the possibility that SRAM may be reprogrammed by Security code to almost nothing if PA/PPA size needs to be increased? it would be rather dumb not to support HS devices on which real products are made, no? rule of thumb has been to avoid usage of SRAM as it constraints security folks as well (yep, I know they should share code with all of us etc.. but they have a different sets of challenges that may deny them such luxury). Regards, Nishanth Menon -- 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
Problems with 3.4-rc5
I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and have noticed a couple of issues... Firstly, it fails to build drivers/mfd/omap-usb-host.c if you have: CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_HCD_OMAP=y drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init': drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'cpu_is_omap3430' drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'omap_rev' drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' undeclared (first use in this function) drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier is reported only once for each function it appears in I'm assuming this has been spotted and I've missed the fix (just a missing include?). Secondly, I get the following when booted: ... [4.701232] devtmpfs: mounted [4.704772] Freeing init memory: 168K [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay ... Which means that the display doesn't work. I am currently running 3.3, which works just fine and doesn't give an underflow. So was wondering what changes have been made that may affect this? There were problems in the 3.2-era due to runtime- PM causing a similar issue, has anything changed around here again? (as a side not: the panel I use is a custom 800x480 added to panel-generic-dpi.c, with board-overo.c updated to use it). Cheers, Joe Woodward -- 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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 17:16:19, Shilimkar, Santosh wrote: On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Nope. It's on L4 and it is same for all OMAPs including OMAP5 Maybe there's a extra low latency path for DDR that I am missing. Even OMAP3 DDR is faster than OCMC RAM. Ok. I guess I need to come up with some data for AM33x then. Thanks for the clarification. Regards, Vaibhav -- 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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote: On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Maybe there's a extra low latency path for DDR that I am missing. have you folks considered the possibility that SRAM may be reprogrammed by Security code to almost nothing if PA/PPA size needs to be increased? it would be rather dumb not to support HS devices on which real products are made, no? rule of thumb has been to avoid usage of SRAM as it constraints security folks as well (yep, I know they should share code with all of us etc.. but they have a different sets of challenges that may deny them such luxury). Even I would like to avoid the usage of MPUSS SRAM for this very reason. But AFAIK the whole PPA stuff isn't applicable for OCMC RAM (not SRAM inside MPUSS). -- 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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote: On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Maybe there's a extra low latency path for DDR that I am missing. have you folks considered the possibility that SRAM may be reprogrammed by Security code to almost nothing if PA/PPA size needs to be increased? it would be rather dumb not to support HS devices on which real products are made, no? rule of thumb has been to avoid usage of SRAM as it constraints security folks as well (yep, I know they should share code with all of us etc.. but they have a different sets of challenges that may deny them such luxury). Even I would like to avoid the usage of MPUSS SRAM for this very reason. But AFAIK the whole PPA stuff isn't applicable for OCMC RAM (not SRAM inside MPUSS). On OMAP, even OCMC RAM can be used by security middle-ware apart from reserved SRAM for HS/EMU devices. That's what Nishant meant. 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: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 17:28:17, Shilimkar, Santosh wrote: On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote: On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Maybe there's a extra low latency path for DDR that I am missing. have you folks considered the possibility that SRAM may be reprogrammed by Security code to almost nothing if PA/PPA size needs to be increased? it would be rather dumb not to support HS devices on which real products are made, no? rule of thumb has been to avoid usage of SRAM as it constraints security folks as well (yep, I know they should share code with all of us etc.. but they have a different sets of challenges that may deny them such luxury). Even I would like to avoid the usage of MPUSS SRAM for this very reason. But AFAIK the whole PPA stuff isn't applicable for OCMC RAM (not SRAM inside MPUSS). On OMAP, even OCMC RAM can be used by security middle-ware apart from reserved SRAM for HS/EMU devices. That's what Nishant meant. Oh ok. I wasn't aware of this aspect. Thanks, Vaibhav -- 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/2] OMAP4: devices: Do not create dmic device if the dtb has been provided
From: Peter Ujfalusi peter.ujfal...@ti.com
If dtb is provided the needed device will be created dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 98cab3a..df2f45a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -702,12 +702,13 @@ static int __init omap2_init_devices(void)
*/
omap_init_audio();
omap_init_mcpdm();
- omap_init_dmic();
omap_init_camera();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
- if (!of_have_populated_dt())
+ if (!of_have_populated_dt()) {
+ omap_init_dmic();
omap_init_mcspi();
+ }
omap_init_pmu();
omap_hdq_init();
omap_init_sti();
--
1.7.8.6
--
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/2] OMAP4: devices: Do not create mcpdm device if the dtb has been provided
From: Peter Ujfalusi peter.ujfal...@ti.com
If dtb is provided the needed device will be created dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index df2f45a..b61c365 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -701,12 +701,12 @@ static int __init omap2_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
omap_init_audio();
- omap_init_mcpdm();
omap_init_camera();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
omap_init_dmic();
+ omap_init_mcpdm();
omap_init_mcspi();
}
omap_init_pmu();
--
1.7.8.6
--
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: Problems with 3.4-rc5
Hi, On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote: I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and have noticed a couple of issues... Firstly, it fails to build drivers/mfd/omap-usb-host.c if you have: CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_HCD_OMAP=y drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init': drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'cpu_is_omap3430' drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'omap_rev' drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' undeclared (first use in this function) drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier is reported only once for each function it appears in I'm assuming this has been spotted and I've missed the fix (just a missing include?). Secondly, I get the following when booted: ... [4.701232] devtmpfs: mounted [4.704772] Freeing init memory: 168K [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay ... Could you add some dss debug prints? You can add omapdss.debug=1 debug in the bootargs to get that. There was a feature called fifo merge added in 3.4, this might lead to underflow, we had tested this using a DVI monitor on beagle but didn't see any underflows. Are you trying this out on 3.4 for the first time? What was the last kernel revision on which you tested this and didn't see any issues? Thanks, Archit Which means that the display doesn't work. I am currently running 3.3, which works just fine and doesn't give an underflow. So was wondering what changes have been made that may affect this? There were problems in the 3.2-era due to runtime- PM causing a similar issue, has anything changed around here again? (as a side not: the panel I use is a custom 800x480 added to panel-generic-dpi.c, with board-overo.c updated to use it). Cheers, Joe Woodward -- 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 -- 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: Problems with 3.4-rc5
-Original Message- From: Archit Taneja a0393...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: linux-omap@vger.kernel.org Date: Wed, 2 May 2012 17:54:21 +0530 Subject: Re: Problems with 3.4-rc5 Hi, On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote: I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and have noticed a couple of issues... Firstly, it fails to build drivers/mfd/omap-usb-host.c if you have: CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_HCD_OMAP=y drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init': drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'cpu_is_omap3430' drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'omap_rev' drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' undeclared (first use in this function) drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier is reported only once for each function it appears in I'm assuming this has been spotted and I've missed the fix (just a missing include?). Secondly, I get the following when booted: ... [4.701232] devtmpfs: mounted [4.704772] Freeing init memory: 168K [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay ... Could you add some dss debug prints? You can add omapdss.debug=1 debug in the bootargs to get that. There was a feature called fifo merge added in 3.4, this might lead to underflow, we had tested this using a DVI monitor on beagle but didn't see any underflows. Are you trying this out on 3.4 for the first time? What was the last kernel revision on which you tested this and didn't see any issues? See below for a more complete trace with debug enabled. I have been using 3.3.0, which doesn't give me any DSS underflow problems at all. And yes, this is the first time I've tried anything 3.4-based. For reference, I'm running from a RAM-based file system which is the same as I use on 3.3.0. Cheers, Joe Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc5 (joe@joe-VirtualBox) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #4 SMP Wed May 2 12:43:38 BST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] Reserving 8388608 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 128768 [0.00] free_area_init_node: node 0, pgdat c06f4740, node_mem_map c700 [0.00] Normal zone: 1024 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 127744 pages, LIFO batch:31 [0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c7408000 s11520 r8192 d13056 u32768 [0.00] pcpu-alloc: s11520 r8192 d13056 u32768 alloc=8*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 127744 [0.00] Kernel command line: console=ttyO2,115200 omapfb.rotate=0 omapdss.debug=1 debug root=/dev/ram0 rw ramdisk_size=98304 initrd=0x8100,96M rootfstype=squashfs [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 503MB = 503MB total [0.00] Memory: 399616k/399616k available, 124672k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc0614f30 (6196 kB) [0.00] .init : 0xc0615000 - 0xc0662d00 ( 312 kB) [0.00] .data : 0xc0664000 - 0xc06f63d8 ( 585 kB) [0.00].bss : 0xc06f63fc - 0xc0c4c020 (5464 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red
[PATCH 0/3] ARM: OMAP4: register V1V8, V2V1 regulators
Hello, This series adds common configuration for the V1V8, V2V1 regulators from twl6030. These regulators are commonly used to feed the twl6040 audio IC on OMAP4 based boards (SDP4430, PandaBoards). The regulator support for the twl6040 MFD driver will be going via MFD tree to avoid cross tree issues. Regards, Peter --- Peter Ujfalusi (3): OMAP4: twl-common: Add twl6030 V1V8, V2V1 SMPS common configuration OMAP: 4430SDP: Use common configuration for V1V8, V2V1 supplies OMAP: omap4panda: Use common configuration for V1V8, V2V1 supplies arch/arm/mach-omap2/board-4430sdp.c|4 ++- arch/arm/mach-omap2/board-omap4panda.c |4 ++- arch/arm/mach-omap2/twl-common.c | 42 arch/arm/mach-omap2/twl-common.h |2 + 4 files changed, 50 insertions(+), 2 deletions(-) -- 1.7.8.6 -- 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/3] OMAP: omap4panda: Use common configuration for V1V8, V2V1 supplies
These supplies going to be needed for the twl6040 driver. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/board-omap4panda.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 1b782ba..c47feed 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -323,7 +323,9 @@ static int __init omap4_panda_i2c_init(void) TWL_COMMON_REGULATOR_VANA | TWL_COMMON_REGULATOR_VCXIO | TWL_COMMON_REGULATOR_VUSB | - TWL_COMMON_REGULATOR_CLK32KG); + TWL_COMMON_REGULATOR_CLK32KG | + TWL_COMMON_REGULATOR_V1V8 | + TWL_COMMON_REGULATOR_V2V1); omap4_pmic_init(twl6030, omap4_panda_twldata, twl6040_data, OMAP44XX_IRQ_SYS_2N); omap_register_i2c_bus(2, 400, NULL, 0); -- 1.7.8.6 -- 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/3] OMAP: 4430SDP: Use common configuration for V1V8, V2V1 supplies
These supplies going to be needed for the twl6040 driver. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/board-4430sdp.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 130ab00..c8d38bd 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -615,7 +615,9 @@ static int __init omap4_i2c_init(void) TWL_COMMON_REGULATOR_VANA | TWL_COMMON_REGULATOR_VCXIO | TWL_COMMON_REGULATOR_VUSB | - TWL_COMMON_REGULATOR_CLK32KG); + TWL_COMMON_REGULATOR_CLK32KG | + TWL_COMMON_REGULATOR_V1V8 | + TWL_COMMON_REGULATOR_V2V1); omap4_pmic_init(twl6030, sdp4430_twldata, twl6040_data, OMAP44XX_IRQ_SYS_2N); omap_register_i2c_bus(2, 400, NULL, 0); -- 1.7.8.6 -- 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/3] OMAP4: twl-common: Add twl6030 V1V8, V2V1 SMPS common configuration
V1V8 supply from twl6030 commonly used as VIO for the machine.
V2V1 is adviced to supply the twl6040, and also to feed the twl6030's
VCXIO_IN, and VDAC_IN inputs.
Create the common regulator configurations for these regulators:
Make the V2V1 as supply_regulator for VCXIO, VDAC.
Add twl6040 (1-004b) as consumer for V1V8, and V2V1.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 42 ++
arch/arm/mach-omap2/twl-common.h |2 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index ee6596b..531a4f9 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -266,6 +266,7 @@ static struct regulator_init_data omap4_vdac_idata = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .supply_regulator = V2V1,
};
static struct regulator_init_data omap4_vaux2_idata = {
@@ -356,6 +357,7 @@ static struct regulator_init_data omap4_vcxio_idata = {
},
.num_consumer_supplies = ARRAY_SIZE(omap4_vcxio_supply),
.consumer_supplies = omap4_vcxio_supply,
+ .supply_regulator = V2V1,
};
static struct regulator_init_data omap4_vusb_idata = {
@@ -423,6 +425,40 @@ static struct regulator_init_data omap4_vdd3 = {
.consumer_supplies = omap4_vdd3_supply,
};
+static struct regulator_consumer_supply omap4_v1v8_supply[] = {
+ REGULATOR_SUPPLY(vio, 1-004b),
+};
+
+static struct regulator_init_data omap4_v1v8_idata = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap4_v1v8_supply),
+ .consumer_supplies = omap4_v1v8_supply,
+};
+
+static struct regulator_consumer_supply omap4_v2v1_supply[] = {
+ REGULATOR_SUPPLY(v2v1, 1-004b),
+};
+
+static struct regulator_init_data omap4_v2v1_idata = {
+ .constraints = {
+ .min_uV = 210,
+ .max_uV = 210,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap4_v2v1_supply),
+ .consumer_supplies = omap4_v2v1_supply,
+};
static struct twl_regulator_driver_data omap4_vdd1_drvdata = {
.get_voltage = twl_get_voltage,
@@ -497,5 +533,11 @@ void __init omap4_pmic_get_config(struct
twl4030_platform_data *pmic_data,
if (regulators_flags TWL_COMMON_REGULATOR_CLK32KG
!pmic_data-clk32kg)
pmic_data-clk32kg = omap4_clk32kg_idata;
+
+ if (regulators_flags TWL_COMMON_REGULATOR_V1V8 !pmic_data-v1v8)
+ pmic_data-v1v8 = omap4_v1v8_idata;
+
+ if (regulators_flags TWL_COMMON_REGULATOR_V2V1 !pmic_data-v2v1)
+ pmic_data-v2v1 = omap4_v2v1_idata;
}
#endif /* CONFIG_ARCH_OMAP4 */
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 0962748..8fe71cf 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -22,6 +22,8 @@
#define TWL_COMMON_REGULATOR_VCXIO (1 8)
#define TWL_COMMON_REGULATOR_VUSB (1 9)
#define TWL_COMMON_REGULATOR_CLK32KG (1 10)
+#define TWL_COMMON_REGULATOR_V1V8 (1 11)
+#define TWL_COMMON_REGULATOR_V2V1 (1 12)
/* TWL4030 LDO regulators */
#define TWL_COMMON_REGULATOR_VPLL1 (1 4)
--
1.7.8.6
--
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] MFD: twl6040: Add regulator support for VIO, V2V1 supplies
twl6040 has three power supply source:
VBAT needs to be connected to VBAT, VIO, and V2V1.
Add regulator support for the VIO, V2V1 supplies.
Initially handle the two supply together with bulk commands.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mfd/twl6040-core.c | 33 +
include/linux/mfd/twl6040.h |2 ++
2 files changed, 31 insertions(+), 4 deletions(-)
Hi Samuel,
The runtime dependencies for this patch has been sent to linux-omap list:
http://marc.info/?l=linux-omapm=133596645010228w=2
http://marc.info/?l=linux-omapm=133596645610232w=2
http://marc.info/?l=linux-omapm=133596644310224w=2
http://marc.info/?l=linux-omapm=133596643310220w=2
Alone this patch does not cause compile time regression but in runtime it needs
the arch/arm/mach-omap2 patches.
I try to avoid cross tree issues as much as I can and I'm happy if these will
come together in linux-next (and finally in 3.5).
Regards,
Peter
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
index 493f4a6..7a92d95 100644
--- a/drivers/mfd/twl6040-core.c
+++ b/drivers/mfd/twl6040-core.c
@@ -27,6 +27,7 @@
#include linux/types.h
#include linux/slab.h
#include linux/kernel.h
+#include linux/err.h
#include linux/platform_device.h
#include linux/gpio.h
#include linux/delay.h
@@ -35,8 +36,10 @@
#include linux/err.h
#include linux/mfd/core.h
#include linux/mfd/twl6040.h
+#include linux/regulator/consumer.h
#define VIBRACTRL_MEMBER(reg) ((reg == TWL6040_REG_VIBCTLL) ? 0 : 1)
+#define TWL6040_NUM_SUPPLIES (2)
int twl6040_reg_read(struct twl6040 *twl6040, unsigned int reg)
{
@@ -532,6 +535,21 @@ static int __devinit twl6040_probe(struct i2c_client
*client,
i2c_set_clientdata(client, twl6040);
+ twl6040-supplies[0].supply = vio;
+ twl6040-supplies[1].supply = v2v1;
+ ret = regulator_bulk_get(client-dev, TWL6040_NUM_SUPPLIES,
+twl6040-supplies);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to get supplies: %d\n, ret);
+ goto regulator_get_err;
+ }
+
+ ret = regulator_bulk_enable(TWL6040_NUM_SUPPLIES, twl6040-supplies);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable supplies: %d\n, ret);
+ goto power_err;
+ }
+
twl6040-dev = client-dev;
twl6040-irq = client-irq;
twl6040-irq_base = pdata-irq_base;
@@ -552,13 +570,13 @@ static int __devinit twl6040_probe(struct i2c_client
*client,
ret = gpio_request_one(twl6040-audpwron, GPIOF_OUT_INIT_LOW,
audpwron);
if (ret)
- goto gpio1_err;
+ goto gpio_err;
}
/* codec interrupt */
ret = twl6040_irq_init(twl6040);
if (ret)
- goto gpio2_err;
+ goto irq_init_err;
ret = request_threaded_irq(twl6040-irq_base + TWL6040_IRQ_READY,
NULL, twl6040_naudint_handler, 0,
@@ -618,10 +636,14 @@ mfd_err:
free_irq(twl6040-irq_base + TWL6040_IRQ_READY, twl6040);
irq_err:
twl6040_irq_exit(twl6040);
-gpio2_err:
+irq_init_err:
if (gpio_is_valid(twl6040-audpwron))
gpio_free(twl6040-audpwron);
-gpio1_err:
+gpio_err:
+ regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040-supplies);
+power_err:
+ regulator_bulk_free(TWL6040_NUM_SUPPLIES, twl6040-supplies);
+regulator_get_err:
i2c_set_clientdata(client, NULL);
err:
return ret;
@@ -643,6 +665,9 @@ static int __devexit twl6040_remove(struct i2c_client
*client)
mfd_remove_devices(client-dev);
i2c_set_clientdata(client, NULL);
+ regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040-supplies);
+ regulator_bulk_free(TWL6040_NUM_SUPPLIES, twl6040-supplies);
+
return 0;
}
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index b15b5f0..6659487 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -27,6 +27,7 @@
#include linux/interrupt.h
#include linux/mfd/core.h
+#include linux/regulator/consumer.h
#define TWL6040_REG_ASICID 0x01
#define TWL6040_REG_ASICREV0x02
@@ -203,6 +204,7 @@ struct regmap;
struct twl6040 {
struct device *dev;
struct regmap *regmap;
+ struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */
struct mutex mutex;
struct mutex io_mutex;
struct mutex irq_mutex;
--
1.7.8.6
--
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-V6 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. The patches are also available at (based on linux-omap/master) - https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup History: Changes from V5: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67163.html - 2 of the original patch-series (1/3 and 2/3) has already been accepted and queued by Paul, so removing them. Also, add 2 new patches, - OMAP2 timer32k cleanup, check for return values. - Changed name of system timers, gp timer = gp_timer. - Moved SoC specific init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) Changes from V4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67019.html - Fix the possible bug, leftover the cnt addr argument to clocksource_mmio_init(). Changes from V3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66462.html - Fixed all review comments from Kevin H * Moved counter_32k CR register offset handling to counter_32k.c file, so now, calling funtion don't have to maintain or add offset to base addr. * Added comment for function omap_init_clocksource_32k() * Used resource_size() for calculate size * Convert WARN_ON to pr_warn Changes from V2: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/092037.html - Added early_param support to read clocksource selection from user through kernel parameter (clocksource=) - Converted to ocp_if changes from Paul Changes from V1: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081037.html - Based on Tony's comment, added pbase size argument to omap_init_clocksource_32k(), to avoid cpu_is_xxx() check. - Added commit description based on discussion on list (Thanks to Santosh here) - Reorder patch sequence Vaibhav Hiremath (3): ARM: OMAP1: FIX: check possible error condition in timer_init ARM: OMAP2+: Replace space=underscore in the name field of system timers ARM: OMAP: Make OMAP clocksource source selection using kernel param arch/arm/mach-omap1/common.h | 10 ++- arch/arm/mach-omap1/time.c | 16 + arch/arm/mach-omap1/timer32k.c | 28 ++- arch/arm/mach-omap2/timer.c | 118 +++-- arch/arm/plat-omap/counter_32k.c | 91 ++- arch/arm/plat-omap/include/plat/common.h |2 +- 6 files changed, 167 insertions(+), 98 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-V6 1/3] ARM: OMAP1: FIX: check possible error condition in timer_init
OMAP1, omap_32k_timer_init() function always returns true,
irrespective of whether error occurred while initializing 32k sync
counter as a kernel clocksource or not and execution will never
fallback to mpu_timer clocksource init code.
This patch adds check for return value from function
omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init()
in case of failure/error from omap_init_clocksource_32k().
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
This is new patch addition compared to original series (=V5).
Also, note that, this patch is only compile tested, since
I do not have omap1 board with me to validate it.
Kevin, can you help me to validate it.
arch/arm/mach-omap1/common.h | 10 +-
arch/arm/mach-omap1/time.c | 16 +---
arch/arm/mach-omap1/timer32k.c | 13 +
3 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index 8cc616e..e8c9ad3 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -63,7 +63,15 @@ extern void omap1_nand_cmd_ctl(struct mtd_info *mtd, int cmd,
unsigned int ctrl);
extern struct sys_timer omap1_timer;
-extern bool omap_32k_timer_init(void);
+
+#ifdef CONFIG_OMAP_32K_TIMER
+extern int omap_32k_timer_init(void);
+#else
+static int __init omap_32k_timer_init(void)
+{
+ return -ENODEV;
+}
+#endif
extern u32 omap_irq_flags;
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 4d8dd9a..4062480 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -232,20 +232,6 @@ static inline void omap_mpu_timer_init(void)
}
#endif /* CONFIG_OMAP_MPU_TIMER */
-static inline int omap_32k_timer_usable(void)
-{
- int res = false;
-
- if (cpu_is_omap730() || cpu_is_omap15xx())
- return res;
-
-#ifdef CONFIG_OMAP_32K_TIMER
- res = omap_32k_timer_init();
-#endif
-
- return res;
-}
-
/*
* ---
* Timer initialization
@@ -253,7 +239,7 @@ static inline int omap_32k_timer_usable(void)
*/
static void __init omap1_timer_init(void)
{
- if (!omap_32k_timer_usable())
+ if (omap_32k_timer_init() != 0)
omap_mpu_timer_init();
}
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 325b9a0..e3613a8 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -182,10 +182,15 @@ static __init void omap_init_32k_timer(void)
* Timer initialization
* ---
*/
-bool __init omap_32k_timer_init(void)
+int __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
- omap_init_32k_timer();
+ int ret = -ENODEV;
- return true;
+ if (cpu_is_omap16xx())
+ ret = omap_init_clocksource_32k();
+
+ if (!ret)
+ omap_init_32k_timer();
+
+ return ret;
}
--
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
[PATCH-V6 2/3] ARM: OMAP2+: Replace space=underscore in the name field of system timers
Depending on the bootloader, passing command-line arguments
with spaces may have issues. Some bootloaders doesn't seem
to pass along the quotes, passing only 'gp' part of the string,
which leads to wrong clocksource override configuration.
So this patch changes gp timer = gp_timer, for clockevent,
clocksource and timer irq_handler.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
This is new patch addition compared to original series (=V5).
arch/arm/mach-omap2/timer.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ecec873..777f84b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -90,7 +90,7 @@ static irqreturn_t omap2_gp_timer_interrupt(int irq, void
*dev_id)
}
static struct irqaction omap2_gp_timer_irq = {
- .name = gp timer,
+ .name = gp_timer,
.flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
.handler= omap2_gp_timer_interrupt,
};
@@ -132,7 +132,7 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
static struct clock_event_device clockevent_gpt = {
- .name = gp timer,
+ .name = gp_timer,
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.shift = 32,
.set_next_event = omap2_gp_timer_set_next_event,
@@ -269,7 +269,7 @@ static cycle_t clocksource_read_cycles(struct clocksource
*cs)
}
static struct clocksource clocksource_gpt = {
- .name = gp timer,
+ .name = gp_timer,
.rating = 300,
.read = clocksource_read_cycles,
.mask = CLOCKSOURCE_MASK(32),
--
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
[PATCH-V6 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter (clocksource=) to override
default 32k_sync-timer, in addition to this, we also use hwmod database
lookup mechanism, through which at run-time we can identify availability
of 32k-sync timer on the device, else fall back to gptimer.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
Two of the original patch-series (1/3 and 2/3) has already been
accepted and queued by Paul, so removing them.
New 2 patches have been added to the series,
- OMAP2 timer32k cleanup, check for return values.
- Changed name of system timers, gp timer = gp_timer.
arch/arm/mach-omap1/timer32k.c | 19 +-
arch/arm/mach-omap2/timer.c | 112 --
arch/arm/plat-omap/counter_32k.c | 91 ++--
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 147 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index e3613a8..eae49c3 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -71,6 +71,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc400
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR0x00
#define OMAP1_32K_TIMER_TCR0x04
@@ -186,8 +187,22 @@ int __init omap_32k_timer_init(void)
{
int ret = -ENODEV;
- if (cpu_is_omap16xx())
- ret = omap_init_clocksource_32k();
+ if (cpu_is_omap16xx()) {
+ void __iomem *base;
+ struct clk *sync32k_ick;
+
+ base = ioremap(OMAP1_32KSYNC_TIMER_BASE, SZ_1K);
+ if (!base) {
+ pr_err(32k_counter: failed to map base addr\n);
+ return -ENODEV;
+ }
+
+ sync32k_ick = clk_get(NULL, omap_32ksync_ick);
+ if (!IS_ERR(sync32k_ick))
+ clk_enable(sync32k_ick);
+
+ ret = omap_init_clocksource_32k(base);
+ }
if (!ret)
omap_init_32k_timer();
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 777f84b..30824b5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -243,22 +243,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
+static bool use_gptimer_clksrc;
/*
* clocksource
@@ -285,7 +271,46 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static int __init omap2_sync32k_clocksource_init(void)
+{
+ int ret;
+ struct omap_hwmod *oh;
+ void __iomem *vbase;
+ const char
Re: OMAP3EVM not booting on l-o master
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
Afzal, care to give this one a test as well? It should have the same
result but is a more targetted fix. With and ack from Tero and a
Tested-by from you, I'll post this to the list and and queue it up for
v3.5.
just checking on this one to discuss how we should handle the
io_chain_devel_3.5 branch on my git tree, which would depend on this
patch... this is a tricky series since it touches PM, PRM, and hwmod
code...
Right, you should probably take this patch along with the
io_chain_devel_3.5 branch. Below is a version that applies on top of
io_chain_devel_3.5 with an ack from Tero and Tested-by from Mohammed.
Kevin
From 22726db6fc514cc5110db43fdf05d5afda8e4a59 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 1 May 2012 07:06:42 -0700
Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until
explicitly enabled.
By default, request_irq() will auto-enable the requested IRQ.
For PRCM interrupts, we may want to avoid that until the PM core code
is fully ready to handle the interrupts. This is particularily true
for IO pad interrupts on OMAP3, which are shared between the hwmod
core and the PRM core.
In order to avoid PRCM IO-chain interrupts until the PM core is ready
to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain
interrupt, which means it will remain disabled after request_irq().
Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)
Special thanks to Tero Kristo for suggesting to isolate the fix to
only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts.
Tested-by: Afzal Mohammed af...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |1 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3e6b564..745a151 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -685,6 +685,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(io),
_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
omap3_pm_init);
+ enable_irq(omap_prcm_event_to_irq(io));
if (ret) {
pr_err(pm: Failed to request pm_io irq\n);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 1471a33..a0309de 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -15,6 +15,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include linux/irq.h
#include common.h
#include plat/cpu.h
@@ -350,10 +351,16 @@ static void __init omap3xxx_prm_enable_io_wakeup(void)
static int __init omap3xxx_prcm_init(void)
{
+ int ret = 0;
+
if (cpu_is_omap34xx()) {
omap3xxx_prm_enable_io_wakeup();
- return omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ ret = omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ if (!ret)
+ irq_set_status_flags(omap_prcm_event_to_irq(io),
+IRQ_NOAUTOEN);
}
- return 0;
+
+ return ret;
}
subsys_initcall(omap3xxx_prcm_init);
--
1.7.9.2
--
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
[PATCHv9 09/10] I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF(Transmit underflow) flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 43b0efb..c0aa16b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -730,7 +730,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- *err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
@@ -743,6 +742,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
return 0;
}
+ *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
--
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
[PATCHv9 05/10] I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the wait_for_completion_timeout returns long.
Original patch is
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7bbc736e60c4188a11aaa74bc6e6
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 1777d79..fec8d5c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -473,7 +473,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg, int stop)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
- int r;
+ unsigned long timeout;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -541,12 +541,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ timeout = wait_for_completion_timeout(dev-cmd_complete,
+ OMAP_I2C_TIMEOUT);
dev-buf_len = 0;
- if (r 0)
- return r;
- if (r == 0) {
+ if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
return -ETIMEDOUT;
--
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
[PATCHv9 04/10] I2C: OMAP: Prevent the register access after pm_runtime_put in probe
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto err_free_irq;
}
...
return 0;
err_free_irq:
free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
This may access the i2c registers without the clocks in the error cases.
Fix the same by moving the pm_runtime_put after the error check.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index bf07ffd..1777d79 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1061,8 +1061,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id,
dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed);
- pm_runtime_put(dev-dev);
-
adap = dev-adapter;
i2c_set_adapdata(adap, dev);
adap-owner = THIS_MODULE;
@@ -1082,6 +1080,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
+ pm_runtime_put(dev-dev);
+
return 0;
err_free_irq:
--
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
[PATCHv9 02/10] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 4f4188d..c851672 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1090,6 +1090,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1110,6 +,7 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 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
[PATCHv9 08/10] I2C: OMAP: prevent the overwrite of the errata flags
From: Tasslehoff Kjappfot tasskj...@gmail.com i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Prevent the overwrite of the errata flags.Move the errata handling to a unified place in probe to prevent such errors. Thus preventing the overwrite of erratum 1p153. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index a72874e..43b0efb 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -427,11 +427,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1019,6 +1014,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 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
[PATCHv9 03/10] I2C: OMAP: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c851672..bf07ffd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1127,10 +1127,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
u16 iv;
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
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
[PATCHv9 00/10] I2C fixes
The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - In case of i2c remove register access was done without any get_sync fix the same. - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. v9: Fix the comments from Wolfram Sang [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. The following changes since commit b821861b905a79f71746945237968c3382d99adc: Merge tag 'ktest-for-v3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest (2012-05-01 19:43:34 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-fixes Shubhrajyoti D (9): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Prevent the register access after pm_runtime_put in probe I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: prevent the overwrite of the errata flags drivers/i2c/busses/i2c-omap.c | 127 - 1 files changed, 62 insertions(+), 65 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
[PATCHv9 06/10] I2C: OMAP: Fix the crash in i2c remove
In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index fec8d5c..44e8cfa 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1108,7 +1108,9 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(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
[PATCHv9 10/10] I2C: OMAP: Rename the 1p153 to the erratum id i462
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c0aa16b..0f536b2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -173,7 +173,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
-#define I2C_OMAP3_1P153(1 1)
+#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
struct device *dev;
@@ -718,11 +718,11 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
#endif
/*
- * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * OMAP3430 Errata i462: When an XRDY/XDR is hit, wait for XUDF before writing
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
unsigned long timeout = 1;
@@ -881,8 +881,8 @@ complete:
break;
}
- if ((dev-errata I2C_OMAP3_1P153)
- errata_omap3_1p153(dev, stat, err))
+ if ((dev-errata I2C_OMAP_ERRATA_I462)
+ errata_omap3_i462(dev, stat, err))
goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
@@ -1020,7 +1020,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-errata |= I2C_OMAP_ERRATA_I207;
if (dev-rev = OMAP_I2C_REV_ON_3430)
- dev-errata |= I2C_OMAP3_1P153;
+ dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
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
[PATCHv9 07/10] I2C: OMAP: Handle error check for pm runtime
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 44e8cfa..a72874e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -585,7 +585,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
int i;
int r;
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ return r;
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1011,7 +1013,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ goto err_free_mem;
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1103,12 +1107,16 @@ omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
+ int ret;
platform_set_drvdata(pdev, NULL);
free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
- pm_runtime_get_sync(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0)
+ return ret;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-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
[PATCHv9 01/10] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..4f4188d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
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
[PATCH] omap-usb-host: include plat/cpu.h
omap-usb-host calls cpu_is_omap3430, which is defined in plat/cpu.h. Reported-by: Guillaume GARDET guillaume.gar...@opensuse.org Signed-off-by: Jeff Mahoney je...@suse.com --- drivers/mfd/omap-usb-host.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -26,6 +26,7 @@ #include linux/dma-mapping.h #include linux/spinlock.h #include plat/usb.h +#include plat/cpu.h #include linux/pm_runtime.h #define USBHS_DRIVER_NAME usbhs_omap -- Jeff Mahoney SUSE Labs -- 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 v3 01/10] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
The define should be the result of 1 Bit number. Bit number for GPOCTL.GPO3 field is 2, which results in 0x4 value. Signed-off-by: Sergio Aguirre saagui...@ti.com --- include/linux/mfd/twl6040.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index b15b5f0..df86c14 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -142,7 +142,7 @@ #define TWL6040_GPO1 0x01 #define TWL6040_GPO2 0x02 -#define TWL6040_GPO3 0x03 +#define TWL6040_GPO3 0x04 /* ACCCTL (0x2D) fields */ -- 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 v3 02/10] OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections
In memory, They are in this particular order:
- CSI2A
- CSIPHY1
- CSI2B
- CSIPHY2
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6abc757..a7b2380 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2641,6 +2641,26 @@ static struct omap_hwmod_addr_space omap44xx_iss_addrs[]
= {
.pa_end = 0x52ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x52001000,
+ .pa_end = 0x5200116f,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = 0x52001170,
+ .pa_end = 0x5200118f,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = 0x52001400,
+ .pa_end = 0x5200156f,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = 0x52001570,
+ .pa_end = 0x5200158f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
@@ -5605,7 +5625,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_ipu_c1_hwmod,
/* iss class */
-/* omap44xx_iss_hwmod, */
+ omap44xx_iss_hwmod,
/* iva class */
omap44xx_iva_hwmod,
--
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 v3 03/10] OMAP4: Add base addresses for ISS
NOTE: This isn't the whole list of features that the
ISS supports, but the only ones supported at the moment.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/devices.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e433603..2b8cf73 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/platform_data/omap4-keypad.h
+#include media/omap4iss.h
+
#include mach/hardware.h
#include mach/irqs.h
#include asm/mach-types.h
@@ -236,6 +238,36 @@ int omap3_init_camera(struct isp_platform_data *pdata)
#endif
+int omap4_init_camera(struct iss_platform_data *pdata, struct omap_board_data
*bdata)
+{
+ struct platform_device *pdev;
+ struct omap_hwmod *oh;
+ struct iss_platform_data *omap4iss_pdata;
+ const char *oh_name = iss;
+ const char *name = omap4iss;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ omap4iss_pdata = pdata;
+
+ pdev = omap_device_build(name, -1, oh, omap4iss_pdata,
+ sizeof(struct iss_platform_data), NULL, 0, 0);
+
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
+
+ return 0;
+}
+
static inline void omap_init_camera(void)
{
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_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 v3 06/10] v4l: Add support for ov5650 sensor
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/ov5650.c | 733 ++
include/media/ov5650.h | 10 +
4 files changed, 750 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5650.c
create mode 100644 include/media/ov5650.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index cc76652..e4d1875 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -486,6 +486,12 @@ config VIDEO_OV5640
help
This is a ov5640 camera driver
+config VIDEO_OV5650
+ tristate OmniVision OV5650 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5650 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index da40ab3..01945c1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
+obj-$(CONFIG_VIDEO_OV5650) += ov5650.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5650.c b/drivers/media/video/ov5650.c
new file mode 100644
index 000..33ab148
--- /dev/null
+++ b/drivers/media/video/ov5650.c
@@ -0,0 +1,733 @@
+/*
+ * OmniVision OV5650 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5650.h
+
+/* OV5650 has only one fixed colorspace per pixelcode */
+struct ov5650_datafmt {
+ enum v4l2_mbus_pixelcodecode;
+ enum v4l2_colorspacecolorspace;
+};
+
+enum ov5650_size {
+ OV5650_SIZE_5MP,
+ OV5650_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5650_frmsizes[OV5650_SIZE_LAST] = {
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5650_find_framesize(u32 width, u32 height)
+{
+ int i;
+
+ for (i = 0; i OV5650_SIZE_LAST; i++) {
+ if ((ov5650_frmsizes[i].width = width)
+ (ov5650_frmsizes[i].height = height))
+ break;
+ }
+
+ /* If not found, select biggest */
+ if (i = OV5650_SIZE_LAST)
+ i = OV5650_SIZE_LAST - 1;
+
+ return i;
+}
+
+struct ov5650 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+
+ struct v4l2_mbus_framefmt format;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov5650_platform_data *pdata;
+
+ struct v4l2_ctrl *pixel_rate;
+};
+
+static inline struct ov5650 *to_ov5650(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov5650, subdev);
+}
+
+/**
+ * struct ov5650_reg - ov5650 register format
+ * @reg: 16-bit offset to register
+ * @val: 8/16/32-bit register value
+ * @length: length of the register
+ *
+ * Define a structure for OV5650 register initialization values
+ */
+struct ov5650_reg {
+ u16 reg;
+ u8 val;
+};
+
+static const struct ov5650_reg configscript_common1[] = {
+ { 0x3103, 0x93 },
+ { 0x3b07, 0x0c },
+ { 0x3017, 0xff },
+ { 0x3018, 0xfc },
+ { 0x3706, 0x41 },
+ { 0x3703, 0xe6 },
+ { 0x3613, 0x44 },
+ { 0x3630, 0x22 },
+ { 0x3605, 0x04 },
+ { 0x3606, 0x3f },
+ { 0x3712, 0x13 },
+ { 0x370e, 0x00 },
+ { 0x370b, 0x40 },
+ { 0x3600, 0x54 },
+ { 0x3601, 0x05 },
+ { 0x3713, 0x22 },
+ { 0x3714, 0x27 },
+ { 0x3631, 0x22 },
+ { 0x3612, 0x1a },
+ { 0x3604, 0x40 },
+ { 0x3705, 0xda },
+ { 0x370a, 0x80 },
+ { 0x370c, 0x00 },
+ { 0x3710, 0x28 },
+ { 0x3702, 0x3a },
+ { 0x3704, 0x18 },
+ { 0x3a18, 0x00 },
+ { 0x3a19, 0xf8 },
+ { 0x3a00, 0x38 },
+};
+
+static const struct ov5650_reg configscript_common2[] = {
+ { 0x3a08, 0x12 },
+ { 0x3a09, 0x70 },
+ { 0x3a0a, 0x0f },
+ {
[PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig| 16 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-4430sdp-camera.c | 415
arch/arm/mach-omap2/board-4430sdp.c| 20 ++
4 files changed, 453 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..54645aa 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -335,6 +335,22 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+config MACH_OMAP_4430SDP_CAMERA_SUPPORT
+ bool OMAP 4430 SDP board Camera support
+ depends on MACH_OMAP_4430SDP
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select V4L_PLATFORM_DRIVERS
+ select VIDEO_OMAP4
+ select VIDEO_OV5640
+ select VIDEO_OV5650
+ help
+ Enable Camera HW support for OMAP 4430 SDP board
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..ebd8f63 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -239,6 +239,8 @@ obj-$(CONFIG_MACH_TI8148EVM)+=
board-ti8168evm.o
# Platform specific device init code
+obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) += board-4430sdp-camera.o
+
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
obj-y += $(omap-flash-y) $(omap-flash-m)
diff --git a/arch/arm/mach-omap2/board-4430sdp-camera.c
b/arch/arm/mach-omap2/board-4430sdp-camera.c
new file mode 100644
index 000..9a8881f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-4430sdp-camera.c
@@ -0,0 +1,415 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
+#include linux/regulator/consumer.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
+#include control.h
+#include mux.h
+
+#define OMAP4430SDP_GPIO_CAM_PDN_B 38
+#define OMAP4430SDP_GPIO_CAM_PDN_C 39
+
+static struct clk *sdp4430_cam1_aux_clk;
+static struct clk *sdp4430_cam2_aux_clk;
+static struct regulator *sdp4430_cam2pwr_reg;
+
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ u8 gpoctl = 0;
+
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power regulator
'cam2pwr'\n);
+ return ret;
+ }
+
+
[PATCH v3 08/10] arm: omap4panda: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig | 16 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda-camera.c | 209 +
3 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 54645aa..4b267a6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -359,6 +359,22 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+config MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ bool OMAP4 Panda Board Camera support
+ depends on MACH_OMAP4_PANDA
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select V4L_PLATFORM_DRIVERS
+ select VIDEO_OMAP4
+ select VIDEO_OV5640
+ select VIDEO_OV5650
+ help
+ Enable Camera HW support for PandaBoard.
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ebd8f63..e6724c4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -240,6 +240,7 @@ obj-$(CONFIG_MACH_TI8148EVM)+=
board-ti8168evm.o
# Platform specific device init code
obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) += board-4430sdp-camera.o
+obj-$(CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT) += board-omap4panda-camera.o
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
diff --git a/arch/arm/mach-omap2/board-omap4panda-camera.c
b/arch/arm/mach-omap2/board-omap4panda-camera.c
new file mode 100644
index 000..a5f7863
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda-camera.c
@@ -0,0 +1,209 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
+#include control.h
+#include mux.h
+
+#define PANDA_GPIO_CAM_PWRDN 45
+#define PANDA_GPIO_CAM_RESET 83
+
+static struct clk *panda_cam_aux_clk;
+
+static int panda_ov_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+
+ if (on) {
+ int ret;
+
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 0);
+ ret = clk_enable(panda_cam_aux_clk);
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 1);
+ return ret;
+ }
+ mdelay(2);
+ } else {
+ clk_disable(panda_cam_aux_clk);
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 1);
+ }
+
+ return 0;
+}
+
+#define OV5640_I2C_ADDRESS (0x3C)
+
+static struct ov5640_platform_data ov5640_platform_data = {
+ .s_power = panda_ov_power,
+};
+
+static struct i2c_board_info ov5640_camera_i2c_device = {
+ I2C_BOARD_INFO(ov5640, OV5640_I2C_ADDRESS),
+ .platform_data = ov5640_platform_data,
+};
+
+#define OV5650_I2C_ADDRESS (0x36)
+
+static struct ov5650_platform_data ov5650_platform_data = {
+ .s_power = panda_ov_power,
+};
+
+static struct i2c_board_info ov5650_camera_i2c_device = {
+ I2C_BOARD_INFO(ov5650, OV5650_I2C_ADDRESS),
+ .platform_data = ov5650_platform_data,
+};
+
+static struct iss_subdev_i2c_board_info ov5640_camera_subdevs[] = {
+ {
+ .board_info = ov5640_camera_i2c_device,
+ .i2c_adapter_id = 3,
+ },
+ { NULL, 0, },
+};
+
+static struct iss_subdev_i2c_board_info ov5650_camera_subdevs[] = {
+ {
+ .board_info = ov5650_camera_i2c_device,
+ .i2c_adapter_id = 3,
+ },
+ { NULL, 0, },
+};
+
+static struct iss_v4l2_subdevs_group panda_camera_subdevs[] = {
+ {
+ .subdevs = ov5640_camera_subdevs,
+ .interface = ISS_INTERFACE_CSI2A_PHY1,
+ .bus = { .csi2 = {
+ .lanecfg= {
+ .clk = {
+ .pol = 0,
+ .pos = 1,
+ },
+ .data[0] = {
+ .pol = 0,
+ .pos = 2,
+
[PATCH v3 09/10] omap2plus: Add support for omap4iss camera
Also add support for following sensors: - OV5640 - OV5650 Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..ea7e8e9 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -23,6 +23,8 @@ CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y +CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT=y +CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y CONFIG_NO_HZ=y -- 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 v3 10/10] arm: Add support for CMA for omap4iss driver
Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/mach-omap2/devices.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 2b8cf73..5259691 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -18,6 +18,9 @@ #include linux/slab.h #include linux/of.h #include linux/platform_data/omap4-keypad.h +#ifdef CONFIG_CMA +#include linux/dma-contiguous.h +#endif #include media/omap4iss.h @@ -265,6 +268,11 @@ int omap4_init_camera(struct iss_platform_data *pdata, struct omap_board_data *b oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt); +#ifdef CONFIG_CMA + /* Create private 32MiB contiguous memory area for omap4iss device */ + dma_declare_contiguous(pdev-dev, 32*SZ_1M, 0, 0); +#endif + return 0; } -- 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 v3 05/10] v4l: Add support for ov5640 sensor
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/ov5640.c | 948 ++
include/media/ov5640.h | 10 +
4 files changed, 965 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5640.c
create mode 100644 include/media/ov5640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4482ac4..cc76652 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -480,6 +480,12 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_OV5640
+ tristate OmniVision OV5640 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5640 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c95cc0d..da40ab3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
new file mode 100644
index 000..2a64d50
--- /dev/null
+++ b/drivers/media/video/ov5640.c
@@ -0,0 +1,948 @@
+/*
+ * OmniVision OV5640 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5640.h
+
+/* OV5640 has only one fixed colorspace per pixelcode */
+struct ov5640_datafmt {
+ enum v4l2_mbus_pixelcodecode;
+ enum v4l2_colorspacecolorspace;
+};
+
+struct ov5640_timing_cfg {
+ u16 x_addr_start;
+ u16 y_addr_start;
+ u16 x_addr_end;
+ u16 y_addr_end;
+ u16 h_output_size;
+ u16 v_output_size;
+ u16 h_total_size;
+ u16 v_total_size;
+ u16 isp_h_offset;
+ u16 isp_v_offset;
+ u8 h_odd_ss_inc;
+ u8 h_even_ss_inc;
+ u8 v_odd_ss_inc;
+ u8 v_even_ss_inc;
+};
+
+enum ov5640_size {
+ OV5640_SIZE_QVGA,
+ OV5640_SIZE_VGA,
+ OV5640_SIZE_720P,
+ OV5640_SIZE_1080P,
+ OV5640_SIZE_5MP,
+ OV5640_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST] = {
+ { 320, 240 },
+ { 640, 480 },
+ { 1280, 720 },
+ { 1920, 1080 },
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5640_find_framesize(u32 width, u32 height)
+{
+ int i;
+
+ for (i = 0; i OV5640_SIZE_LAST; i++) {
+ if ((ov5640_frmsizes[i].width = width)
+ (ov5640_frmsizes[i].height = height))
+ break;
+ }
+
+ /* If not found, select biggest */
+ if (i = OV5640_SIZE_LAST)
+ i = OV5640_SIZE_LAST - 1;
+
+ return i;
+}
+
+struct ov5640 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov5640_platform_data *pdata;
+
+ struct v4l2_ctrl *pixel_rate;
+};
+
+static inline struct ov5640 *to_ov5640(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov5640, subdev);
+}
+
+/**
+ * struct ov5640_reg - ov5640 register format
+ * @reg: 16-bit offset to register
+ * @val: 8/16/32-bit register value
+ * @length: length of the register
+ *
+ * Define a structure for OV5640 register initialization values
+ */
+struct ov5640_reg {
+ u16 reg;
+ u8 val;
+};
+
+/* TODO: Divide this properly */
+static const struct ov5640_reg configscript_common1[] = {
+
[PATCH v3 00/10] v4l2: OMAP4 ISS driver + Sensor + Board support
Hi everyone, It's been a long time since last version (5 months)! :) This is the third version of the OMAP4 ISS driver, which uses Media Controller and videobuf2 frameworks. This patchset should apply cleanly on top of v3.4-rc5 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A/B interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Changes since v2: - Supports CSI2B now! - Add support for RAW8. - Usage of V4L2_CID_PIXEL_RATE, instead of dphy configuration in boardfile (similar to omap3isp) - Removes save/restore support for now, as it is broken. - Attend several comments form Sakari Ailus (Thanks Sakari!) - Populate hw_revision in media_dev struct. - Ported several fixes pushed for omap3isp (Thanks Laurent!) - Use module_platform_driver. - Use proposed generic v4l2_subdev_link_validate. - Move OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX handle to omap4iss code, instead of board file. Changes since v1: - Simplification of auxclk handlign in board files - Use of HWMOD declaration for assisted platform_device creation. - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) Regards, Sergio Sergio Aguirre (10): mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera omap2plus: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Documentation/video4linux/omap4_camera.txt| 64 ++ arch/arm/configs/omap2plus_defconfig |2 + arch/arm/mach-omap2/Kconfig | 32 + arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-4430sdp-camera.c| 415 arch/arm/mach-omap2/board-4430sdp.c | 20 + arch/arm/mach-omap2/board-omap4panda-camera.c | 209 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/devices.h |4 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 22 +- drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile |3 + drivers/media/video/omap4iss/Makefile |6 + drivers/media/video/omap4iss/iss.c| 1159 + drivers/media/video/omap4iss/iss.h| 121 +++ drivers/media/video/omap4iss/iss_csi2.c | 1368 + drivers/media/video/omap4iss/iss_csi2.h | 155 +++ drivers/media/video/omap4iss/iss_csiphy.c | 281 + drivers/media/video/omap4iss/iss_csiphy.h | 51 + drivers/media/video/omap4iss/iss_regs.h | 244 + drivers/media/video/omap4iss/iss_video.c | 1123 drivers/media/video/omap4iss/iss_video.h | 201 drivers/media/video/ov5640.c | 948 + drivers/media/video/ov5650.c | 733 + include/linux/mfd/twl6040.h |2 +- include/media/omap4iss.h | 65 ++ include/media/ov5640.h| 10 + include/media/ov5650.h| 10 + 28 files changed, 7314 insertions(+), 2 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode 100644 include/media/omap4iss.h create mode 100644 include/media/ov5640.h create mode 100644 include/media/ov5650.h -- 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 v3 00/10] v4l2: OMAP4 ISS driver + Sensor + Board support
On Wed, May 2, 2012 at 10:15 AM, Sergio Aguirre saagui...@ti.com wrote: Hi everyone, It's been a long time since last version (5 months)! :) This is the third version of the OMAP4 ISS driver, which uses Media Controller and videobuf2 frameworks. This patchset should apply cleanly on top of v3.4-rc5 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A/B interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Apologies, forgot to mention this: Tested with these patchsets: - Sakari's patches for N9 and some v4l2 changes: http://www.spinics.net/lists/linux-media/msg45052.html - CMA v24: http://www.spinics.net/lists/linux-media/msg46106.html Both rebased to v3.4-rc5. Regards, Sergio Changes since v2: - Supports CSI2B now! - Add support for RAW8. - Usage of V4L2_CID_PIXEL_RATE, instead of dphy configuration in boardfile (similar to omap3isp) - Removes save/restore support for now, as it is broken. - Attend several comments form Sakari Ailus (Thanks Sakari!) - Populate hw_revision in media_dev struct. - Ported several fixes pushed for omap3isp (Thanks Laurent!) - Use module_platform_driver. - Use proposed generic v4l2_subdev_link_validate. - Move OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX handle to omap4iss code, instead of board file. Changes since v1: - Simplification of auxclk handlign in board files - Use of HWMOD declaration for assisted platform_device creation. - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) Regards, Sergio Sergio Aguirre (10): mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera omap2plus: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Documentation/video4linux/omap4_camera.txt | 64 ++ arch/arm/configs/omap2plus_defconfig | 2 + arch/arm/mach-omap2/Kconfig | 32 + arch/arm/mach-omap2/Makefile | 3 + arch/arm/mach-omap2/board-4430sdp-camera.c | 415 arch/arm/mach-omap2/board-4430sdp.c | 20 + arch/arm/mach-omap2/board-omap4panda-camera.c | 209 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/devices.h | 4 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 22 +- drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile | 3 + drivers/media/video/omap4iss/Makefile | 6 + drivers/media/video/omap4iss/iss.c | 1159 + drivers/media/video/omap4iss/iss.h | 121 +++ drivers/media/video/omap4iss/iss_csi2.c | 1368 + drivers/media/video/omap4iss/iss_csi2.h | 155 +++ drivers/media/video/omap4iss/iss_csiphy.c | 281 + drivers/media/video/omap4iss/iss_csiphy.h | 51 + drivers/media/video/omap4iss/iss_regs.h | 244 + drivers/media/video/omap4iss/iss_video.c | 1123 drivers/media/video/omap4iss/iss_video.h | 201 drivers/media/video/ov5640.c | 948 + drivers/media/video/ov5650.c | 733 + include/linux/mfd/twl6040.h | 2 +- include/media/omap4iss.h | 65 ++ include/media/ov5640.h | 10 + include/media/ov5650.h | 10 + 28 files changed, 7314 insertions(+), 2 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode
Re: [PATCH] W1: OMAP HDQ1W: allow driver to be built on all OMAP2+
On Wed, May 02, 2012 at 02:08:36AM -0600, Paul Walmsley (p...@pwsan.com) wrote: Allow the OMAP HDQ1W driver to be built for all OMAP2+ SoCs by adjusting KConfig dependencies. The previous dependency required either SOC_OMAP2430 or ARCH_OMAP3 to be set, but the HDQ IP block is present on OMAP2420 and OMAP44xx SoCs. The driver was still selectable on multi-OMAP kernel configurations, however; so the previous prohibition was rather pointless. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Evgeniy Polyakov z...@ioremap.net Well, looks good, although I know nothing about build deps for OMAP platform :) -- Evgeniy Polyakov -- 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/7] ARM: OMAP2+: Clean up wrapping multiple objects in Makefile
* Shilimkar, Santosh santosh.shilim...@ti.com [120502 03:18]: On Wed, May 2, 2012 at 3:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote: Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 160 - 1 files changed, 78 insertions(+), 82 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 56ed62e..669e2b1 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -24,10 +24,11 @@ endif obj-$(CONFIG_TWL4030_CORE) += omap_twl.o # SMP support ONLY available for OMAP4 + obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \ - sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o Using \ in makefiles really isn't a problem. I don't think this is something which we need to do, and it just creates additional changes where none is required. Tony might give better reasoning for this change since he suggested it. Mostly for making it cleaner to build shared objects between omap4 and omap5 without adding things like: +obj-$(CONFIG_ARCH_OMAP5)+= omap4-common.o omap-wakeupgen.o \ + sleep44xx.o But of course more localized changes will do there too to prepare adding omap5. 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 v5 0/7] Add TI EMIF SDRAM controller driver
On Wed, May 02, 2012 at 12:20:24PM +0530, Santosh Shilimkar wrote: Greg, On Wednesday 02 May 2012 10:46 AM, Greg KH wrote: On Fri, Apr 27, 2012 at 05:54:02PM +0530, Santosh Shilimkar wrote: Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. - Tested the driver as a module Cc: Greg KH g...@kroah.com This all looks good to me now, thanks for reworking this. So, do you want me to take this through my driver tree to get to Linus for 3.5, or do you want it to go through somewhere else? If somewhere else, that's fine with me, consider this an: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org If you want me to take it, just let me know, whichever you prefer is fine with me. Can you take this one through your 3.5 driver tree please ? Thanks for help. Ok, all now applied. greg k-h -- 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: OMAP2PLUS: Enable HIGHMEM
From: Santosh Shilimkar santosh.shilim...@ti.com HIGMEM support in kernel is quite mature now and we have boards like ZOOM, PANDA, SDP where 1 GB memories are installed. With HIGHMEM disabled not all of the 1GB of RAM (only ~700MB) can be accessed. Hence, enable HIGMEM to make use of the entire memory. On the boards which doesn't have more than 768 MB memory, all the memory is directly mapped in lowmem and highmem isn't exercised. Hence, there should be no impact by enabling HIGHMEM for boards that do not need it. Tested on OMAP4460 Panda-ES. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Tested-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8141b76..964ee67 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS_TYPICAL select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 + select HIGHMEM help Compile a kernel suitable for booting most boards -- 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: PM related performance degradation on OMAP3
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
I posted the patches for the power domains registers cache, cf.
http://marc.info/?l=linux-omapm=133587781712039w=2.
All the details are at
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
I updated the page with the measurements results with Kevin's patches
and the registers cache patches.
The results are showing that:
- the registers cache optimizes the low power mode transitions, but is
not sufficient to obtain a big gain. A few unused domains are
transitioning, which causes a big penalty in the idle path.
PER is the one that seems to be causing the most latency.
Can you try do your measurements using hack below which makes sure that
PER isn't any deeper than CORE?
Indeed your patch brings significant improvements, cf. wiki page at
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
for detailed information.
Here below is the reworked patch, more suited for inclusion in mainline [1]
I have another optimisation -in proof of concept state- that brings
another significant improvement. It is about allowing/disabling idle
for only 1 clkdm in a pwrdm and not iterate through all the clkdms.
This still needs some rework though. Cf. patch [2]
Patches [1] and [2] on top of the registers cache and the
optimisations in pre/post_transition bring the performance close to
the performance for the non cpuidle case (3.0MB/s compared to 3.1MB/s
on Beagleboard).
What do you think?
Regards,
Jean
---
[1]
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index e406d7b..572b605 100644
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -279,32 +279,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
int ret;
/*
-* Prevent idle completely if CAM is active.
+* Use only C1 if CAM is active.
* CAM does not have wakeup capability in OMAP3.
*/
- if (pwrdm_read_func_pwrst(cam_pd) == PWRDM_FUNC_PWRST_ON) {
+ if (pwrdm_read_func_pwrst(cam_pd) == PWRDM_FUNC_PWRST_ON)
new_state_idx = drv-safe_state_index;
- goto select_state;
- }
-
- new_state_idx = next_valid_state(dev, drv, index);
+ else
+ new_state_idx = next_valid_state(dev, drv, index);
- /*
-* Prevent PER off if CORE is not in retention or off as this
-* would disable PER wakeups completely.
-*/
+ /* Program PER state */
cx = cpuidle_get_statedata(dev-states_usage[new_state_idx]);
core_next_state = cx-core_state;
- per_next_state = per_saved_state = pwrdm_read_next_func_pwrst(per_pd);
- if ((per_next_state == PWRDM_FUNC_PWRST_OFF)
- (core_next_state PWRDM_FUNC_PWRST_CSWR))
- per_next_state = PWRDM_FUNC_PWRST_CSWR;
+ if (new_state_idx == 0) {
+ /* In C1 do not allow PER state lower than CORE state */
+ per_next_state = core_next_state;
+ } else {
+ /*
+* Prevent PER off if CORE is not in RETention or OFF as this
+* would disable PER wakeups completely.
+*/
+ per_next_state = per_saved_state =
+ pwrdm_read_next_func_pwrst(per_pd);
+ if ((per_next_state == PWRDM_FUNC_PWRST_OFF)
+ (core_next_state PWRDM_FUNC_PWRST_CSWR))
+ per_next_state = PWRDM_FUNC_PWRST_CSWR;
+ }
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
omap_set_pwrdm_state(per_pd, per_next_state);
-select_state:
ret = omap3_enter_idle(dev, drv, new_state_idx);
/* Restore original PER state if it was modified */
@@ -390,7 +394,6 @@ int __init omap3_idle_init(void)
/* 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 */
[2]
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index e406d7b..6aa3c75 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -118,8 +118,10 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd,
Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
Isn't this something that should be part of the sensor driver? There's
nothing in the above code that would be board specific, except the names of
the clocks, regulators and GPIOs. The sensor driver could hold the names
instead; this would be also compatible with the device tree.
It should be possible to have s_power() callback NULL, too.
+static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ u8 gpoctl = 0;
+
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power regulator
'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+
+ if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, gpoctl,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
+ if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
+ gpoctl | TWL6040_GPO3,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
The above piece of code looks quite interesting. What does it do?
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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-V6 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Hi Vaibhav,
On 05/02/2012 08:56 AM, Vaibhav Hiremath wrote:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
This patch series cleans up the existing 32k-sync timer implementation,
movind SoC init code to respective files (mach-omap1/timer32k.c and
mach-omap2/timer.c) and uses kernel parameter to override the default
clocksource of counter_32k, also in order to support some OMAP based
derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP,
adds hwmod lookup for omap2+ devices, and if lookup fails then
fall back to gp-timer.
if(use_gptimer_clksrc == true)
gptimer clocksource init;
else if (counter_32 init == false)
/* Fallback to gptimer */
gptimer clocksource init(;
With this, we should be able to support multi-omap boot
including devices with/without 32k-sync timer.
This patch-series has been boot tested on AM37xEVM platform, it
would be helpful if somebody help me to validate it on OMAP1/2
platforms.
The patches are also available at (based on linux-omap/master) -
https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup
I was testing on OMAP4 and I found that the gptimer was always being set by
default. I noticed that currently the HWMOD for counter_32k on OMAP4 is
commented and hence was not being found. Please can you include the following
with your series?
Cheers
Jon
From 2a213a6d5f5894bc1c5262f2724508eaef21c7a5 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Wed, 2 May 2012 14:45:03 -0500
Subject: [PATCH] ARM: OMAP4: Enable counter_32k HWMOD for OMAP4 devices
HWMOD is being used to determine if the 32k sync timer is present in order
to use the timer as the clocksource for the kernel. Enable the counter_32k
HWMOD for OMAP4 devices so that the 32k sync timer will be used by default.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6abc757..f0455d0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5561,7 +5561,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_bandgap_hwmod,
/* counter class */
-/* omap44xx_counter_32k_hwmod, */
+ omap44xx_counter_32k_hwmod,
/* dma class */
omap44xx_dma_system_hwmod,
--
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-V6 1/3] ARM: OMAP1: FIX: check possible error condition in timer_init
Vaibhav Hiremath hvaib...@ti.com writes:
OMAP1, omap_32k_timer_init() function always returns true,
irrespective of whether error occurred while initializing 32k sync
counter as a kernel clocksource or not and execution will never
fallback to mpu_timer clocksource init code.
This patch adds check for return value from function
omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init()
in case of failure/error from omap_init_clocksource_32k().
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
This is new patch addition compared to original series (=V5).
Also, note that, this patch is only compile tested, since
I do not have omap1 board with me to validate it.
Kevin, can you help me to validate it.
I boot tested on OMAP1 (5912/OSK) with 32k timer and MPU timer
Kconfigs. Works fine, but needs small change below for compile warnings.
Otherwise, looks good.
Acked-by: Kevin Hilman khil...@ti.com
arch/arm/mach-omap1/common.h | 10 +-
arch/arm/mach-omap1/time.c | 16 +---
arch/arm/mach-omap1/timer32k.c | 13 +
3 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index 8cc616e..e8c9ad3 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -63,7 +63,15 @@ extern void omap1_nand_cmd_ctl(struct mtd_info *mtd, int
cmd,
unsigned int ctrl);
extern struct sys_timer omap1_timer;
-extern bool omap_32k_timer_init(void);
+
+#ifdef CONFIG_OMAP_32K_TIMER
+extern int omap_32k_timer_init(void);
+#else
+static int __init omap_32k_timer_init(void)
This needs to be inline. Compile test on OMAP1 with
CONFIG_OMAP_32K_TIMER=n to see why.
+{
+ return -ENODEV;
+}
+#endif
extern u32 omap_irq_flags;
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 4d8dd9a..4062480 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -232,20 +232,6 @@ static inline void omap_mpu_timer_init(void)
}
#endif /* CONFIG_OMAP_MPU_TIMER */
-static inline int omap_32k_timer_usable(void)
-{
- int res = false;
-
- if (cpu_is_omap730() || cpu_is_omap15xx())
- return res;
-
-#ifdef CONFIG_OMAP_32K_TIMER
- res = omap_32k_timer_init();
-#endif
-
- return res;
-}
-
/*
*
---
* Timer initialization
@@ -253,7 +239,7 @@ static inline int omap_32k_timer_usable(void)
*/
static void __init omap1_timer_init(void)
{
- if (!omap_32k_timer_usable())
+ if (omap_32k_timer_init() != 0)
omap_mpu_timer_init();
}
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 325b9a0..e3613a8 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -182,10 +182,15 @@ static __init void omap_init_32k_timer(void)
* Timer initialization
*
---
*/
-bool __init omap_32k_timer_init(void)
+int __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
- omap_init_32k_timer();
+ int ret = -ENODEV;
- return true;
+ if (cpu_is_omap16xx())
+ ret = omap_init_clocksource_32k();
+
+ if (!ret)
+ omap_init_32k_timer();
+
+ return ret;
}
--
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
--
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-V6 2/3] ARM: OMAP2+: Replace space=underscore in the name field of system timers
Vaibhav Hiremath hvaib...@ti.com writes: Depending on the bootloader, passing command-line arguments with spaces may have issues. Some bootloaders doesn't seem to pass along the quotes, passing only 'gp' part of the string, which leads to wrong clocksource override configuration. For clarity, it would help to specify which command-line options this affects So this patch changes gp timer = gp_timer, for clockevent, clocksource and timer irq_handler. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com With the change above, Acked-by: Kevin Hilman khil...@ti.com -- 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-V6 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Vaibhav Hiremath hvaib...@ti.com writes: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options - 1. 32KHz sync-timer 2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer 3. 32KHz based gptimer. The optional gptimer based clocksource was added so that it can give the high precision than sync-timer, so expected usage was 2 and not 3. Unfortunately option 2, clocksource doesn't meet the requirement of free-running clock as per clocksource need. It stops in low power states when sys_clock is cut. That makes gptimer based clocksource option useless for OMAP2/3/4 devices with sys_clock as a clock input. So, in order to use option 2, deeper idle state MUST be disabled. Option 3 will still work but it is no better than 32K sync-timer based clocksource. We must support both sync timer and gptimer based clocksource as some OMAP based derivative SoCs like AM33XX does not have the sync timer. Considering above, make sync-timer and gptimer clocksource runtime selectable so that both OMAP and AM continue to use the same code. And, in order to precisely configure/setup sched_clock for given clocksource, decision has to be made early enough in boot sequence. So, the solution is, Use standard kernel parameter (clocksource=) to override default 32k_sync-timer, in addition to this, we also use hwmod database lookup mechanism, through which at run-time we can identify availability of 32k-sync timer on the device, else fall back to gptimer. Also, moved low-level SoC specific init code to respective files, (mach-omap1/timer32k.c and mach-omap2/timer.c) Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com tested on OMAP3530/Overo with default 32k timer and cmdline override for GPtimer. Kevin -- 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] arm: omap: Use only valid power domain states
On Tue, May 01, 2012 at 10:47:35AM +0200, Jean Pihet wrote:
Hi Mark,
Hi Jean. Thanks for the review.
On Mon, Apr 30, 2012 at 11:25 PM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer mgr...@animalcreek.com
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 5358664..2c91711 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -175,19 +175,25 @@ static int next_valid_state(struct cpuidle_device
*dev,
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;
+ u32 mpu_deepest_state, mpu_deepest_possible;
+ u32 core_deepest_state, core_deepest_possible;
int next_index = -1;
+ mpu_deepest_possible = pwrdm_get_deepest_state(mpu_pd);
+ mpu_deepest_state = max_t(u32, mpu_deepest_possible,
PWRDM_POWER_RET);
I do not think you need to change the pwrdm API and the cpuidle code for that.
Instead you should use the pwrst* fields in the power domains data
files, which allow to specify the allowed states.
After reading the rest of your patches it seems you are addressing the
issue in a subsequent patch 'arm: omap3: am35x: Set proper powerdomain
states'.
That patch sets the allowable power domain states for the am35x; the intent
of this patch was to make the code respect what is set in the pwrst* fields.
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..9c80c19 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1078,3 +1078,28 @@ bool pwrdm_can_ever_lose_context(struct powerdomain
*pwrdm)
return 0;
}
+
+/**
+ * pwrdm_get_deepest_state - Get deepest valid state domain can enter
+ * @pwrdm: struct powerdomain *
+ *
+ * Find and return the deepest valid state a power domain can be in.
+ * Returns the deepest state that @pwrdm can enter.
+ */
+u32 pwrdm_get_deepest_state(struct powerdomain *pwrdm)
+{
+ u32 valid_states, deepest_state;
+
+ valid_states = pwrdm-pwrsts;
+
+ if (valid_states PWRSTS_OFF)
+ deepest_state = PWRDM_POWER_OFF;
+ else if (valid_states PWRSTS_RET)
+ deepest_state = PWRDM_POWER_RET;
+ else if (valid_states PWRSTS_INACTIVE)
+ deepest_state = PWRDM_POWER_INACTIVE;
+ else
+ deepest_state = PWRDM_POWER_ON;
+
+ return deepest_state;
+}
The pwrdm API already performs those checks on pwrst*, cf.
pwrdm_set_next_pwrst for example.
Well, sort of. pwrdm_set_next_pwrst() fails if its an invalid state
returning -EINVAL. Very few of the callers actually check to see if
it failed so they don't try the next-one-up power state. The net
result is that the next state doesn't change even though it could
move to a lower state (just not the one that was asked for).
Is that acceptable?
Another sort of strange one is omap3_pm_off_mode_enable(). If its
called with 'enable' set and PWRDM_POWER_OFF isn't a valid state,
omap_set_pwrdm_state() will return 0 and leave the next state alone.
When omap3_pm_off_mode_enable() is called again with 'enable' set,
omap_set_pwrdm_state() will find the lowest valid state = RET.
So, if you had a device where OFF wasn't valid but RET was and
its currently ON, when the user enables OFF mode, it stays ON
and when they disable OFF mode, it moves to RET.
Is that acceptable?
If the things above are acceptable, then I think you're right, we can
forget this patch. FYI, the am35x appears to work okay and no invalid
states are entered (according to /sys/kernel/debug/pm_debug/count)
without this patch.
Mark
--
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] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Mark A. Greer mgr...@animalcreek.com
The davinci EMAC driver has been incorporated into the am35x
family of SoC's which is OMAP-based. The incorporation is
incomplete in that the EMAC cannot unblock the [ARM] core if
its blocked on a 'wfi' instruction. This is an issue with
the cpu_idle code because it has the core execute a 'wfi'
instruction.
To work around this issue, add platform data callbacks which
are called at the beginning of the open routine and at the
end of the stop routine of the davinci_emac driver. The
callbacks allow the platform code to issue disable_hlt() and
enable_hlt() calls appropriately. Calling disable_hlt()
prevents cpu_idle from issuing the 'wfi' instruction.
It is not sufficient to simply call disable_hlt() when
there is an EMAC present because it could be present but
not actually used in which case, we do want the 'wfi' to
be executed.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
I know adding platform_data callbacks are frowned upon
and I really don't want to add them but I don't see
any other way to accomplish what needs to be accomplished.
Any suggestions?
Thanks, Mark.
drivers/net/ethernet/ti/davinci_emac.c | 14 ++
include/linux/davinci_emac.h |2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index 174a334..141a888 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -344,6 +344,8 @@ struct emac_priv {
/*platform specific members*/
void (*int_enable) (void);
void (*int_disable) (void);
+ void (*pre_open) (struct net_device *ndev);
+ void (*post_stop) (struct net_device *ndev);
};
/* clock frequency for EMAC */
@@ -1534,6 +1536,9 @@ static int emac_dev_open(struct net_device *ndev)
int k = 0;
struct emac_priv *priv = netdev_priv(ndev);
+ if (priv-pre_open)
+ priv-pre_open(ndev);
+
netif_carrier_off(ndev);
for (cnt = 0; cnt ETH_ALEN; cnt++)
ndev-dev_addr[cnt] = priv-mac_addr[cnt];
@@ -1644,6 +1649,10 @@ rollback:
res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k-1);
m = res-end;
}
+
+ if (priv-post_stop)
+ priv-post_stop(ndev);
+
return -EBUSY;
}
@@ -1686,6 +1695,9 @@ static int emac_dev_stop(struct net_device *ndev)
if (netif_msg_drv(priv))
dev_notice(emac_dev, DaVinci EMAC: %s stopped\n, ndev-name);
+ if (priv-post_stop)
+ priv-post_stop(ndev);
+
return 0;
}
@@ -1817,6 +1829,8 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
priv-version = pdata-version;
priv-int_enable = pdata-interrupt_enable;
priv-int_disable = pdata-interrupt_disable;
+ priv-pre_open = pdata-pre_open;
+ priv-post_stop = pdata-post_stop;
priv-coal_intvl = 0;
priv-bus_freq_mhz = (u32)(emac_bus_frequency / 100);
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 5428885..b61e6de 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -39,6 +39,8 @@ struct emac_platform_data {
bool no_bd_ram;
void (*interrupt_enable) (void);
void (*interrupt_disable) (void);
+ void (*pre_open) (struct net_device *ndev);
+ void (*post_stop) (struct net_device *ndev);
};
enum {
--
1.7.9.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/7] ARM: OMAP2: Add MMC hwmod data for 2420
Hi Tony, On Mon, 23 Apr 2012, Tony Lindgren wrote: Add MMC for 2420 so we can pass the DMA request lines the same way as we already do on omap2430 and later. Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Tony Lindgren t...@atomide.com Made a few changes here so that it applies on the omap-devel-a-for-3.5 tag that you pulled in. Also changed the 2420 MMC class name to msdi and the hwmod name to msdi1 -- this is the IP block name that is listed in the 2420 TRM Rev. X Table 26-9 Instance Summary. It also is convenient for us, because the 2420 MMC driver is different than the 2430+ HSMMC driver, so we can just probe all of the hwmods of class msdi to register the 2420 MMC :-) - Paul -- 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/7] ARM: OMAP2: Add MMC hwmod data for 2420
On Wed, 2 May 2012, Paul Walmsley wrote:
Hi Tony,
On Mon, 23 Apr 2012, Tony Lindgren wrote:
Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
Made a few changes here so that it applies on the omap-devel-a-for-3.5 tag
that you pulled in. Also changed the 2420 MMC class name to msdi and
the hwmod name to msdi1 -- this is the IP block name that is listed in
the 2420 TRM Rev. X Table 26-9 Instance Summary. It also is convenient
for us, because the 2420 MMC driver is different than the 2430+ HSMMC
driver, so we can just probe all of the hwmods of class msdi to register
the 2420 MMC :-)
Also, forgot to mention that a struct omap_hwmod_class_sysconfig record
was added here too, based on the info in the 2420 TRM.
The updated patch is below. Have queued it in a hwmod data update branch
here along with some other hwmod data updates. Will send a pull request
after testing is finished here...
- Paul
From: Tony Lindgren t...@atomide.com
Date: Mon, 23 Apr 2012 17:08:32 -0700
Subject: [PATCH] ARM: OMAP2: hwmod data: Add MMC hwmod data for 2420
Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
[p...@pwsan.com: updated to apply on top of the 3.5 hwmod cleanup;
changed mmc hwmod name/class to msdi as documented in the 2420 TRM Rev X;
added sysconfig register information]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 61
1 file changed, 61 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2c087ff..8698819 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -239,6 +239,48 @@ static struct omap_hwmod omap2420_mcbsp2_hwmod = {
},
};
+static struct omap_hwmod_class_sysconfig omap2420_msdi_sysc = {
+ .rev_offs = 0x3c,
+ .sysc_offs = 0x64,
+ .syss_offs = 0x68,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_msdi_hwmod_class = {
+ .name = msdi,
+ .sysc = omap2420_msdi_sysc,
+};
+
+/* msdi1 */
+static struct omap_hwmod_irq_info omap2420_msdi1_irqs[] = {
+ { .irq = 83 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap2420_msdi1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 61 }, /* OMAP24XX_DMA_MMC1_TX */
+ { .name = rx, .dma_req = 62 }, /* OMAP24XX_DMA_MMC1_RX */
+ { .dma_req = -1 }
+};
+
+static struct omap_hwmod omap2420_msdi1_hwmod = {
+ .name = msdi1,
+ .class = omap2420_msdi_hwmod_class,
+ .mpu_irqs = omap2420_msdi1_irqs,
+ .sdma_reqs = omap2420_msdi1_sdma_reqs,
+ .main_clk = mmc_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP2420_EN_MMC_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP2420_ST_MMC_SHIFT,
+ },
+ },
+};
+
/*
* interfaces
*/
@@ -428,6 +470,24 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+struct omap_hwmod_addr_space omap2420_msdi1_addrs[] = {
+ {
+ .pa_start = 0x4809c000,
+ .pa_end = 0x4809c000 + SZ_128 - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_core - msdi1 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__msdi1 = {
+ .master = omap2xxx_l4_core_hwmod,
+ .slave = omap2420_msdi1_hwmod,
+ .clk= mmc_ick,
+ .addr = omap2420_msdi1_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -468,6 +528,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__mailbox,
omap2420_l4_core__mcbsp1,
omap2420_l4_core__mcbsp2,
+ omap2420_l4_core__msdi1,
NULL,
};
--
1.7.10
--
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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. I've compared the boot logs and modified some configuration options and command line parameters to make them match, but still no dice. Can you send me your .config? -- 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 0/3] OMAP: control: bootaddr and bootmod APIs
Recently a patch went in for tidspbridge code, to ioremap SCM registers and solve a build break[1]. However it has been pointed out before that this is a layer violation given that control module should handle its own registers, this series is an attempt to create APIs for the users of these registers. With some adaptations this patch might also make use of it: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66491.html Patch: staging: tidspbridge: use scm functions to set boot address and mode, will be sent separately to staging tree. Tested on OMAP3 Beagleboard. [1] http://www.mail-archive.com/devel@linuxdriverproject.org/msg18762.html Omar Ramirez Luna (3): OMAP2+: control: new APIs to configure boot address and mode OMAP: dsp: interface to control module functions staging: tidspbridge: use scm functions to set boot address and mode arch/arm/mach-omap2/control.c | 43 arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/dsp.c |4 ++ .../include/mach/ctrl_module_core_44xx.h |1 + arch/arm/plat-omap/include/plat/dsp.h |3 + drivers/staging/tidspbridge/core/tiomap3430.c | 32 +++--- 6 files changed, 60 insertions(+), 25 deletions(-) -- 1.7.4.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 1/3] OMAP2+: control: new APIs to configure boot address and mode
SCM contains boot addr and boot mode registers to control
other processors on different OMAP versions. It controls the
boot address and mode for DSP based subsystems like: IVA 2.1
(OMAP2430), IVA 2.2 (OMAP3) and DSP (OMAP4).
If contained within SCM registers, when a processor is
booting it uses BOOTADDR to start running the code at that
location. BOOTMOD register specifies a different set of
modes for the processor to execute when booting (from direct,
idle, self-loop, user and default).
Since there was no offset associated with OMAP4, this patch
defines it.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/control.c | 43
arch/arm/mach-omap2/control.h |2 +
.../include/mach/ctrl_module_core_44xx.h |1 +
3 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 08e674b..3223b81 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -241,6 +241,49 @@ void omap3_ctrl_write_boot_mode(u8 bootmode)
#endif
+/**
+ * omap_ctrl_write_dsp_boot_addr - set boot address for a remote processor
+ * @bootaddr: physical address of the boot loader
+ *
+ * Set boot address for the boot loader of a supported processor
+ * when a power ON sequence occurs.
+ */
+void omap_ctrl_write_dsp_boot_addr(u32 bootaddr)
+{
+ u32 offset = cpu_is_omap243x() ? OMAP243X_CONTROL_IVA2_BOOTADDR :
+cpu_is_omap34xx() ? OMAP343X_CONTROL_IVA2_BOOTADDR :
+cpu_is_omap44xx() ? OMAP4_CTRL_MODULE_CORE_DSP_BOOTADDR :
+0;
+
+ if (!offset) {
+ pr_err(%s: unsupported omap type\n, __func__);
+ return;
+ }
+
+ omap_ctrl_writel(bootaddr, offset);
+}
+
+/**
+ * omap_ctrl_write_dsp_boot_mode - set boot mode for a remote processor
+ * @bootmode: 8-bit value to pass to some boot code
+ *
+ * Sets boot mode for the boot loader of a supported processor
+ * when a power ON sequence occurs.
+ */
+void omap_ctrl_write_dsp_boot_mode(u8 bootmode)
+{
+ u32 offset = cpu_is_omap243x() ? OMAP243X_CONTROL_IVA2_BOOTMOD :
+cpu_is_omap34xx() ? OMAP343X_CONTROL_IVA2_BOOTMOD :
+0;
+
+ if (!offset) {
+ pr_err(%s: unsupported omap type\n, __func__);
+ return;
+ }
+
+ omap_ctrl_writel(bootmode, offset);
+}
+
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
/*
* Clears the scratchpad contents in case of cold boot-
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a406fd0..fcc98f8 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -397,6 +397,8 @@ extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
extern void omap3_ctrl_write_boot_mode(u8 bootmode);
+extern void omap_ctrl_write_dsp_boot_addr(u32 bootaddr);
+extern void omap_ctrl_write_dsp_boot_mode(u8 bootmode);
extern void omap3630_ctrl_disable_rta(void);
extern int omap3_ctrl_save_padconf(void);
#else
diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h
b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h
index 2f7ac70..0197082 100644
--- a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h
+++ b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h
@@ -42,6 +42,7 @@
#define OMAP4_CTRL_MODULE_CORE_STD_FUSE_OPP_DPLL_1 0x0268
#define OMAP4_CTRL_MODULE_CORE_STATUS 0x02c4
#define OMAP4_CTRL_MODULE_CORE_DEV_CONF0x0300
+#define OMAP4_CTRL_MODULE_CORE_DSP_BOOTADDR0x0304
#define OMAP4_CTRL_MODULE_CORE_LDOVBB_IVA_VOLTAGE_CTRL 0x0314
#define OMAP4_CTRL_MODULE_CORE_LDOVBB_MPU_VOLTAGE_CTRL 0x0318
#define OMAP4_CTRL_MODULE_CORE_LDOSRAM_IVA_VOLTAGE_CTRL0x0320
--
1.7.4.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 2/3] OMAP: dsp: interface to control module functions
Provide an interface for a driver to call SCM functions to
set a boot address and boot mode.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/dsp.c |4
arch/arm/plat-omap/include/plat/dsp.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index 74f18f2..6d37d3c 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -20,6 +20,7 @@
#include linux/module.h
#include linux/platform_device.h
+#include control.h
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
#ifdef CONFIG_BRIDGE_DVFS
@@ -45,6 +46,9 @@ static struct omap_dsp_platform_data omap_dsp_pdata
__initdata = {
.dsp_cm_read = omap2_cm_read_mod_reg,
.dsp_cm_write = omap2_cm_write_mod_reg,
.dsp_cm_rmw_bits = omap2_cm_rmw_mod_reg_bits,
+
+ .set_bootaddr = omap_ctrl_write_dsp_boot_addr,
+ .set_bootmode = omap_ctrl_write_dsp_boot_mode,
};
static int __init omap_dsp_init(void)
diff --git a/arch/arm/plat-omap/include/plat/dsp.h
b/arch/arm/plat-omap/include/plat/dsp.h
index 9c604b3..5927709 100644
--- a/arch/arm/plat-omap/include/plat/dsp.h
+++ b/arch/arm/plat-omap/include/plat/dsp.h
@@ -18,6 +18,9 @@ struct omap_dsp_platform_data {
u32 (*dsp_cm_read)(s16 , u16);
u32 (*dsp_cm_rmw_bits)(u32, u32, s16, s16);
+ void (*set_bootaddr)(u32);
+ void (*set_bootmode)(u8);
+
phys_addr_t phys_mempool_base;
phys_addr_t phys_mempool_size;
};
--
1.7.4.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 3/3] staging: tidspbridge: use scm functions to set boot address and mode
Instead of ioremapping SCM registers, use the correspondent layer
to write into them.
This allows us to get rid of a layer violation, since the registers
are no longer touched by driver code.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/staging/tidspbridge/core/tiomap3430.c | 32 +---
1 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 9cf29fc..40b35ca 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -70,14 +70,9 @@
#define PAGES_II_LVL_TABLE 512
#define PHYS_TO_PAGE(phys) pfn_to_page((phys) PAGE_SHIFT)
-/*
- * This is a totally ugly layer violation, but needed until
- * omap_ctrl_set_dsp_boot*() are provided.
- */
-#define OMAP3_IVA2_BOOTMOD_IDLE 1
-#define OMAP2_CONTROL_GENERAL 0x270
-#define OMAP343X_CONTROL_IVA2_BOOTADDR (OMAP2_CONTROL_GENERAL + 0x0190)
-#define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194)
+/* IVA Boot modes */
+#define DIRECT 0
+#define IDLE 1
/* Forward Declarations: */
static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt);
@@ -414,27 +409,14 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
/* Assert RST1 i.e only the RST only for DSP megacell */
if (!status) {
- /*
-* XXX: ioremapping MUST be removed once ctrl
-* function is made available.
-*/
- void __iomem *ctrl = ioremap(OMAP343X_CTRL_BASE, SZ_4K);
- if (!ctrl)
- return -ENOMEM;
-
(*pdata-dsp_prm_rmw_bits)(OMAP3430_RST1_IVA2_MASK,
OMAP3430_RST1_IVA2_MASK,
OMAP3430_IVA2_MOD,
OMAP2_RM_RSTCTRL);
- /* Mask address with 1K for compatibility */
- __raw_writel(dsp_addr OMAP3_IVA2_BOOTADDR_MASK,
- ctrl + OMAP343X_CONTROL_IVA2_BOOTADDR);
- /*
-* Set bootmode to self loop if dsp_debug flag is true
-*/
- __raw_writel((dsp_debug) ? OMAP3_IVA2_BOOTMOD_IDLE : 0,
- ctrl + OMAP343X_CONTROL_IVA2_BOOTMOD);
- iounmap(ctrl);
+ /* Mask address with 1K for compatibility */
+ pdata-set_bootaddr(dsp_addr
+ OMAP3_IVA2_BOOTADDR_MASK);
+ pdata-set_bootmode(dsp_debug ? IDLE : DIRECT);
}
}
if (!status) {
--
1.7.4.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
RE: [PATCH-V6 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Thu, May 03, 2012 at 01:26:18, Hunter, Jon wrote: Hi Vaibhav, On 05/02/2012 08:56 AM, Vaibhav Hiremath wrote: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. The patches are also available at (based on linux-omap/master) - https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup I was testing on OMAP4 and I found that the gptimer was always being set by default. I noticed that currently the HWMOD for counter_32k on OMAP4 is commented and hence was not being found. Please can you include the following with your series? The 32kcounter hwmod entry is already enabled in linux-omap/master branch. Your baseline looks pretty old to me, are you not using linux-omap/master? The hwmod data registration has now changed to ocp_if, and your patch still use hwmod data entry. Can you please use linux-omap/master and test it? Thanks, Vaibhav -- 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 00/18][V3] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups
On Tue, May 1, 2012 at 3:50 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 05/01/2012 11:55 AM, Shilimkar, Santosh wrote: On May 1, 2012 1:46 PM, Daniel Lezcanodaniel.lezc...@linaro.org wrote: On 05/01/2012 12:58 AM, Kevin Hilman wrote: Daniel Lezcanodaniel.lezc...@linaro.org writes: On 04/24/2012 04:05 PM, Daniel Lezcano wrote: This patchset makes some cleanup on these cpuidle drivers and consolidate the code across both architecture. Tested on OMAP3 (igepV2). Partially tested on OMAP4 (pandaboard), without offlining the cpu1. Without offlining CPU1, none of this code is executed. Can you test with CPU1 offlined? Unfortunately my OMAP4 board burned :/ I am waiting for a new one. Rob tested the series but when he unplugged the cpu1, the kernel panics for another reason. I guess the problem should have been fixed since the last testing. Rob ? Do you mind the test the series again, the problem you were facing when unplugging the cpu1 may have been fixed. Have already tested this series on omap4 with cpu offline as well as with couple idle series on top of it. I haven't finished omap3 testing and hence not reported yet. Omap4 continies to work with subject series. Great ! I tested it on omap3 igepv2 board and it works fine too. Finished OMAP3 testing too. have already reviewed the series before. For entire series, Reviewed-tested-by: Santosh Shilimkar santosh.shilim...@ti.com 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
