[PATCH 1/2] ARM: OMAP4: PM: Only do static dependency configuration in omap4_init_static_deps
Commit 705814b5ea6f (ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
re-use it for OMAP5)
Moved logic generic for OMAP5+ as part of the init routine by
introducing omap4_pm_init. However, the patch left the powerdomain
initial setup, an unused omap4430 es1.0 check and a spurious log
Power Management for TI OMAP4. in the original code.
Remove the duplicate code which is already present in omap4_pm_init from
omap4_init_static_deps.
As part of this change, also move the u-boot version print out of the
static dependency function to the omap4_pm_init function.
Fixes: 705814b5ea6f (ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it
for OMAP5)
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 503097c..e7f823b 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -160,26 +160,6 @@ static inline int omap4_init_static_deps(void)
struct clockdomain *ducati_clkdm, *l3_2_clkdm;
int ret = 0;
- if (omap_rev() == OMAP4430_REV_ES1_0) {
- WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
- return -ENODEV;
- }
-
- pr_err(Power Management for TI OMAP4.\n);
- /*
-* OMAP4 chip PM currently works only with certain (newer)
-* versions of bootloaders. This is due to missing code in the
-* kernel to properly reset and initialize some devices.
-* http://www.spinics.net/lists/arm-kernel/msg218641.html
-*/
- pr_warn(OMAP4 PM: u-boot = v2012.07 is required for full PM
support\n);
-
- ret = pwrdm_for_each(pwrdms_setup, NULL);
- if (ret) {
- pr_err(Failed to setup powerdomains\n);
- return ret;
- }
-
/*
* The dynamic dependency between MPUSS - MEMIF and
* MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as
@@ -272,6 +252,15 @@ int __init omap4_pm_init(void)
pr_info(Power Management for TI OMAP4+ devices.\n);
+ /*
+* OMAP4 chip PM currently works only with certain (newer)
+* versions of bootloaders. This is due to missing code in the
+* kernel to properly reset and initialize some devices.
+* http://www.spinics.net/lists/arm-kernel/msg218641.html
+*/
+ if (cpu_is_omap44xx())
+ pr_warn(OMAP4 PM: u-boot = v2012.07 is required for full PM
support\n);
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains.\n);
--
1.7.9.5
--
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] ARM: OMAP4+: PM: Centralize static dependency mapping table
As we add more static dependency mapping for various errata, the logic
gets clunkier. Since it is a simple lookup and map logic, centralize the
same and provide the mapping as a simple list.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 117 --
1 file changed, 57 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index e7f823b..d697cec 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -37,6 +37,16 @@ struct power_state {
struct list_head node;
};
+/**
+ * struct static_dep_map - Static dependency map
+ * @from: from clockdomain
+ * @to:to clockdomain
+ */
+struct static_dep_map {
+ const char *from;
+ const char *to;
+};
+
static u32 cpu_suspend_state = PWRDM_POWER_OFF;
static LIST_HEAD(pwrst_list);
@@ -148,74 +158,61 @@ static void omap_default_idle(void)
omap_do_wfi();
}
-/**
- * omap4_init_static_deps - Add OMAP4 static dependencies
- *
- * Add needed static clockdomain dependencies on OMAP4 devices.
- * Return: 0 on success or 'err' on failures
+/*
+ * The dynamic dependency between MPUSS - MEMIF and
+ * MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as
+ * expected. The hardware recommendation is to enable static
+ * dependencies for these to avoid system lock ups or random crashes.
+ * The L4 wakeup depedency is added to workaround the OCP sync hardware
+ * BUG with 32K synctimer which lead to incorrect timer value read
+ * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+ * are part of L4 wakeup clockdomain.
*/
-static inline int omap4_init_static_deps(void)
-{
- struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
- struct clockdomain *ducati_clkdm, *l3_2_clkdm;
- int ret = 0;
-
- /*
-* The dynamic dependency between MPUSS - MEMIF and
-* MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as
-* expected. The hardware recommendation is to enable static
-* dependencies for these to avoid system lock ups or random crashes.
-* The L4 wakeup depedency is added to workaround the OCP sync hardware
-* BUG with 32K synctimer which lead to incorrect timer value read
-* from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
-* are part of L4 wakeup clockdomain.
-*/
- mpuss_clkdm = clkdm_lookup(mpuss_clkdm);
- emif_clkdm = clkdm_lookup(l3_emif_clkdm);
- l3_1_clkdm = clkdm_lookup(l3_1_clkdm);
- l3_2_clkdm = clkdm_lookup(l3_2_clkdm);
- ducati_clkdm = clkdm_lookup(ducati_clkdm);
- if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
- (!l3_2_clkdm) || (!ducati_clkdm))
- return -EINVAL;
-
- ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
- ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
- ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
- ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
- ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
- if (ret) {
- pr_err(Failed to add MPUSS - L3/EMIF/L4PER, DUCATI - L3
wakeup dependency\n);
- return -EINVAL;
- }
+static const struct static_dep_map omap4_static_dep_map[] = {
+ {.from = mpuss_clkdm, .to = l3_emif_clkdm},
+ {.from = mpuss_clkdm, .to = l3_1_clkdm},
+ {.from = mpuss_clkdm, .to = l3_2_clkdm},
+ {.from = ducati_clkdm, .to = l3_1_clkdm},
+ {.from = ducati_clkdm, .to = l3_2_clkdm},
+ {.from = NULL} /* TERMINATION */
+};
- return ret;
-}
+static const struct static_dep_map omap5_dra7_static_dep_map[] = {
+ {.from = mpu_clkdm, .to = emif_clkdm},
+ {.from = NULL} /* TERMINATION */
+};
/**
- * omap5_dra7_init_static_deps - Init static clkdm dependencies on OMAP5 and
- * DRA7
- *
- * The dynamic dependency between MPUSS - EMIF is broken and has
- * not worked as expected. The hardware recommendation is to
- * enable static dependencies for these to avoid system
- * lock ups or random crashes.
+ * omap4plus_init_static_deps() - Initialize a static dependency map
+ * @map: Mapping of clock domains
*/
-static inline int omap5_dra7_init_static_deps(void)
+static inline int omap4plus_init_static_deps(const struct static_dep_map *map)
{
- struct clockdomain *mpuss_clkdm, *emif_clkdm;
int ret;
+ struct clockdomain *from, *to;
- mpuss_clkdm = clkdm_lookup(mpu_clkdm);
- emif_clkdm = clkdm_lookup(emif_clkdm);
- if (!mpuss_clkdm || !emif_clkdm)
- return -EINVAL;
+ if (!map)
+ return 0;
+
+ while (map-from) {
+ from = clkdm_lookup(map-from);
+ to = clkdm_lookup(map-to);
+ if (!from || !to) {
+ pr_err(Failed lookup %s or %s for wakeup dependency\n
[PATCH 0/2] ARM: OMAP4+: PM: centralize static dependency mapping table
Hi, This is a small step towards getting rid of static dependency logic from mach-omap2. As part of this, we split the list of static dep map from the function implementing it. This should eventually aid in helping remove the tables from the kernel to the device tree at a later point in time of cleanup. Series based on v3.18-rc1 and could be a 3.19-rc1 material. Nishanth Menon (2): ARM: OMAP4: PM: Only do static dependency configuration in omap4_init_static_deps ARM: OMAP4+: PM: Centralize static dependency mapping table arch/arm/mach-omap2/pm44xx.c | 146 +++--- 1 file changed, 66 insertions(+), 80 deletions(-) -- 1.7.9.5 -- 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: OMAP4+: PM: Program CPU logic power state
CPU logic power state is never programmed in either the initialization
or the suspend/resume logic, instead, we depend on mpuss to program this
properly. However, this leaves CPU logic power state indeterminate and
most probably in reset configuration (If bootloader or other similar
software have'nt monkeyed with the register). This can make powerstate=
RET be either programmed for CSWR (logic=ret) or OSWR(logic = OFF) and
in OSWR, there can be context loss when the code does not expect it.
To prevent all these confusions, just support clearly ON, INA, CSWR,
OFF which is the intent of the existing code by explicitly programming
logic state.
NOTE: since this is a hot path (using in cpuidle), the exit path just
programs powerstate (logic state is immaterial when powerstate is ON).
Without doing this, we end up with lockups when CPUs enter OSWR and
multiple blocks loose context, when we expect them to hit CSWR.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 6944ae3..79f49d9 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -227,7 +227,7 @@ static void __init save_l2x0_context(void)
int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
{
struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu);
- unsigned int save_state = 0;
+ unsigned int save_state = 0, cpu_logic_state = PWRDM_POWER_RET;
unsigned int wakeup_cpu;
if (omap_rev() == OMAP4430_REV_ES1_0)
@@ -239,6 +239,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 0;
break;
case PWRDM_POWER_OFF:
+ cpu_logic_state = PWRDM_POWER_OFF;
save_state = 1;
break;
case PWRDM_POWER_RET:
@@ -270,6 +271,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
cpu_clear_prev_logic_pwrst(cpu);
pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
+ pwrdm_set_logic_retst(pm_info-pwrdm, cpu_logic_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
omap_pm_ops.scu_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
--
1.7.9.5
--
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: [REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working
On 10/17/2014 07:48 AM, Enric Balletbo Serra wrote: 2014-10-17 14:35 GMT+02:00 Tero Kristo t-kri...@ti.com: On 10/17/2014 02:55 PM, Enric Balletbo Serra wrote: 2014-10-17 7:55 GMT+02:00 Tero Kristo t-kri...@ti.com: On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote: Hi, 2014-10-10 16:06 GMT+02:00 Tero Kristo t-kri...@ti.com: Hi, Seems like MPU DVFS does not scale the voltages currently with DT boot, due to missing mapping between regulator - VCVP. Fixed this by adding support for platform data in the TWL regulator DT case + adding platform data quirk for the same. This same already works in the legacy boot, the platform data is passed fine. Tested on omap3-beagle by measuring the MPU voltage rail. OMAP4+ platforms do not currently register DVFS regulator, so this set by itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc. for OMAP4460.) -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 Tony proposed in the IRC apply this patch series in order to solve the following error messages with kernel 3.17 [2.522949] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva [2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva [2.541564] omap2_set_init_voltage: unable to find boot up OPP for vdd_core [2.551208] omap2_set_init_voltage: unable to set vdd_core I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but should these patches solve these errors ? Did you resolve these errors on your Beagleboard ? These prints are caused by something else: namely the fact that beagleboard rev C4+ boots up at 720MHz. This OPP is not supported by the kernel and quelches out the warning prints. This should be fixed by modifying the OPP tables under the dtsi files, however the nasty thing is not all beagleboards support 720MHz OPP. You either need to specify a dts file for beagle-revC4 or do some kernel magic to manually disable the 720MHz OPP on non-supported boards. Adding and modifying some printk looks the problem is because it can't find the device opp. [2.532836] cpu cpu0: dev_pm_opp_find_freq_ceil: can't find device opp [2.542755] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva (clk = dpll1_ck - freq = 6) [2.554931] omap2_set_init_voltage: unable to set vdd_mpu_iva [2.562957] platform 6800.ocp: dev_pm_opp_find_freq_ceil: can't find device opp [2.57] omap2_set_init_voltage: unable to find boot up OPP for vdd_core (clk = l3_ick - freq = 2) [2.584442] omap2_set_init_voltage: unable to set vdd_core The of_init_opp_table who reads the 'operating-points from dtb is called after. Should be called before? [2.592834] cpu cpu0: of_init_opp_table: init_opp_table What is the board revision you got? Looks like it boots up at 600/200MHz. Well, about board revision I'm using IGEPv2 not Beagleboard. And my board should be able to run up to 1GHz. Is 1GHz supported ? NO. 1GHz cannot not be supported by the chip until we have avs class1.5 and ABB integrated into a proper cpufreq/dvfs solution. we have tried multiple times in upstream to present a solution you are welcome to read up on https://bugzilla.kernel.org/show_bug.cgi?id=58541 to see why similar frequency was not enabled on omap4 (as an example). You can also try tweaking around the tables under opp3xxx_data.c, not sure if these are initialized in the correct order either. However, the lack of these tables and the warnings mentioned do not prevent cpufreq from working, cpufreq is dependant on the DT tables. That being said, I am not sure if the legacy OPP tables are even needed anymore on DT boot... Right, I've checked and cpufreq seems to work. Does this means that following call is not needed anymore ? arch/arm/mach-omap2/opp3xxx_data.c:171:omap_device_initcall(omap3_opp_init); only after we have pure DT only boot for OMAP3. we are supposed to support legacy mode for omap3 as well for now. -- 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
Re: [PATCH 2/2] regulator: twl: use platform data in the DT based boot also
On 16:40-20141010, Tero Kristo wrote:
This allows to pass platform information during a DT boot also, currently
this is completely ignored. Needed for supporting the platform specific
regulator set_voltage / get_voltage ops for the SMPS regulators.
Signed-off-by: Tero Kristo t-kri...@ti.com
To: Liam Girdwood lgirdw...@gmail.com
To: Mark Brown broo...@kernel.org
---
drivers/regulator/twl-regulator.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 0b4f866..2c4fa06 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1103,9 +1103,9 @@ static int twlreg_probe(struct platform_device *pdev)
if (match) {
template = match-data;
id = template-desc.id;
+ drvdata = dev_get_platdata(pdev-dev);
initdata = of_get_regulator_init_data(pdev-dev,
pdev-dev.of_node);
- drvdata = NULL;
} else {
id = pdev-id;
initdata = dev_get_platdata(pdev-dev);
--
1.7.9.5
please post this separately and liam, mark need to be in cc.
Unfortunately, I think we might be pushed back with pdata should'nt be
in of boot.
So a slightly longer commit message might be necessary.
--
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
Re: cpuidle - minimum time for sleep
On 10/09/2014 02:01 PM, valdis.kletni...@vt.edu wrote: On Thu, 09 Oct 2014 21:28:23 +0300, Ran Shalit said: Does anybody know what is the minimum expected time for sleep period with the cpuidle ? Both processor dependent and sleep level dependent. There's a certain amount of latency induced by the hardware waking up. Look at /sys/devices/system/cpu/cpu*/cpuidle/state*/latency Yes, that is correct. the sleep and wakeup time are dependent on the power state we attempt (may or maynot achieve) I personally toggle an unused pin using padmux register write with weak pull up/down in controlled tests (mostly using disable =1 for states I am not measuring), then capture pinctrl toggles using [1] into a csv for many thousands of iterations then use the conservative values. I usually do this at the slowest frequency to capture the worst case values that i feed into cpuidle_driver.states.exit_latency and appropriate value for target_residency - I usually ignore power_usage as the value is never a constant and depends on quiet a few factors that i cannot discuss in public domain. Here are some helpful links on OMAP specific strategies (these may be a little old, but just search for CPUIDLE latency measure in google) https://lwn.net/Articles/384146/ http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement http://lists.linaro.org/pipermail/linaro-dev/2010-August/000568.html [1] https://www.saleae.com/ -- 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
Re: [PATCH] ARM: OMAP2: Remove unnecessary KERN_* in omap_phy_internal.c
On 01:16-20141007, Masanari Iida wrote:
This patch remove unnecessary KERN_INFO and KERN_ERR from omap_phy_internal.c.
Signed-off-by: Masanari Iida standby2...@gmail.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 50640b3..f4d942a 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
With the cleanups, maybe add a
#define pr_fmt(fmt) %s: fmt, __func__
at the start to make the log info a little more relevant?
@@ -97,13 +97,13 @@ void am35x_musb_phy_power(u8 on)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
- pr_info(KERN_INFO Waiting for PHY clock good...\n);
+ pr_info(Waiting for PHY clock good...\n);
while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
CONF2_PHYCLKGD)) {
cpu_relax();
if (time_after(jiffies, timeout)) {
- pr_err(KERN_ERR musb PHY clock good timed
out\n);
+ pr_err(musb PHY clock good timed out\n);
break;
}
}
@@ -145,7 +145,7 @@ void am35x_set_mode(u8 musb_mode)
devconf2 |= CONF2_NO_OVERRIDE;
break;
default:
- pr_info(KERN_INFO Unsupported mode %u\n, musb_mode);
+ pr_info(Unsupported mode %u\n, musb_mode);
}
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
--
2.1.1.273.g97b8860
--
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
--
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
Re: [GIT PULL 2/5] omap soc changes for v3.18 merge window
On 22:07-20140923, Olof Johansson wrote: On Thu, Sep 11, 2014 at 04:28:55PM -0700, Tony Lindgren wrote: The following changes since commit d7eb67f7fef9c046f27a975118da2324de65a90c: Merge branch 'pull/v3.18/powerdomain-fixes' of https://github.com/nmenon/linux-2.6-playground into omap-for-v3.18/fixes-not-urgent (2014-09-08 15:04:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/soc-for-v3.18 for you to fetch changes up to 377fb3f5d9a34b2913939e0620c1c585b5913bab: ARM: OMAP5+: Reuse OMAP4 PM code for OMAP5 and DRA7 (2014-09-09 19:13:41 -0700) SoC related changes for omaps for v3.18 merge window: - PM changes to make the code easier to use on newer SoCs - PM changes for newer SoCs suspend and resume and wake-up events - Minor clean-up to remove dead Kconfig options Note that these have a dependency to the fixes-v3.18-not-urgent tag and is based on a commit in that series. Merged. Note that this also has a fresh conflict with the latest fixes, so please check that I resolved it correctly. Looks fine to me.. also, Used a couple of out of tree patches for testing and all looks good from test perspective: am335x-evm: Boot PASS: http://slexy.org/raw/s21ul7EaiK am335x-sk: Boot PASS: http://slexy.org/raw/s2xxG7b5t7 am3517-evm: Boot PASS: http://slexy.org/raw/s21we13Ebk am37x-evm: Boot PASS: http://slexy.org/raw/s209iOnepY am43xx-epos: Boot PASS: http://slexy.org/raw/s28GrriVvz am5728-evm: Boot PASS: http://slexy.org/raw/s2wRllyrn2 BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2JPCJPebZ beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s2n4Pum58s beaglebone-black: Boot PASS: http://slexy.org/raw/s20yDlR4eu craneboard: Boot PASS: http://slexy.org/raw/s21DECJfEs dra72x-evm: Boot PASS: http://slexy.org/raw/s2WgDuVxXj dra7xx-evm: Boot PASS: http://slexy.org/raw/s2wOi9Okyk OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s20qOiwY38 n900: Boot PASS: http://slexy.org/raw/s2j6hBxA2b omap5-evm: Boot PASS: http://slexy.org/raw/s20Of1TCt4 pandaboard-es: Boot PASS: http://slexy.org/raw/s20P0IWXJX pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s20QWs7BP9 sdp2430: Boot PASS: http://slexy.org/raw/s2fXgpekEa sdp3430: Boot PASS: http://slexy.org/raw/s21GW1utPn -- 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
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
On 09/18/2014 08:50 AM, Nishanth Menon wrote: On 09/18/2014 08:41 AM, Nishanth Menon wrote: On 09/17/2014 07:22 PM, Daniel Lezcano wrote: On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote: [...] Could you try a long run of this little program: https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c [Santosh] I am sure there will not be any issue with the long run test case here. Lets see if Nishant sees anything otherwise Ok. Make sure the cpu is effectively entering your C2 state with the sleep duration in the test program. Test kernel: https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume (I decided to merge in various send for pull branches from maintainers and apply cpuidle on top).. Controlled test run as follows on 4 different impacted platforms and 1 platform as legacy reference. What we are looking for is cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 RET:2677 indicated CPU1 hit C2 cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 RET:2677 indicated CPU0 hit C2 mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0 RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together, else by hardware constraints in place, MPU power domain will fail to transition. What I see in all cases below is that transitions do take place (C2 is successfully hit). Test #1: 120 seconds: CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep 1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just base test vector http://fpaste.org/134547/14110454/ OMAP5 uEVM: (2 a15) http://fpaste.org/134546/10454181/ DRA74x: (2 a15) http://fpaste.org/134543/11045286/ DRA72: (2 a15) ^^ Correction should have been 1 a15 http://fpaste.org/134544/11045335/ AM572x(DRA74x variant): (2 A15) http://fpaste.org/134545/10453761/ Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/) CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep 1;./cpuidle_killer_1200;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just base test vector http://fpaste.org/134563/41104728/ OMAP5 uEVM: (2 a15) http://fpaste.org/134562/47221141/ DRA74x EVM: (2 a15) http://fpaste.org/134559/11047098/ DRA72 EVM: (2 a15) ^^ Correction should have been 1 a15 http://fpaste.org/134560/11047151/ AM572x EVM: (2 A15) http://fpaste.org/134561/47189141/ Daniel, Santosh: Gentle ping: Any further comments? OR are we ok for this for being merged? --- 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
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
Daniel, On 08:02-20140922, Nishanth Menon wrote: [...] Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/) Santosh wanted me to make certain that the following is noted; ^^ - is around 20 mins. - So highlighting again.. I assume this is long enough test duration you requested for. CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep 1;./cpuidle_killer_1200;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just base test vector http://fpaste.org/134563/41104728/ OMAP5 uEVM: (2 a15) http://fpaste.org/134562/47221141/ DRA74x EVM: (2 a15) http://fpaste.org/134559/11047098/ DRA72 EVM: (2 a15) ^^ Correction should have been 1 a15 http://fpaste.org/134560/11047151/ AM572x EVM: (2 A15) http://fpaste.org/134561/47189141/ Daniel, Santosh: Gentle ping: Any further comments? OR are we ok for this for being merged? -- 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
Re: [PATCH] rtc: omap: Support regulator supply for RTC
On 09/19/2014 04:48 AM, Lokesh Vutla wrote:
+linux-omap, linux-arm-kernel, devicetree
On Friday 19 September 2014 03:16 PM, Lokesh Vutla wrote:
On some Soc's RTC is powered by an external power regulator.
e.g. RTC on DRA7 SoC. Make the OMAP RTC driver support a
power regulator.
And also making the driver as module_platform_driver to
support probe deferal.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Tested on DRA7. Logs here: http://fpaste.org/134804/11200041/
Is that the only platform using rtc-omap.c?
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 3 +++
drivers/rtc/rtc-omap.c | 28
--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 5a0f02d..c9f963a 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -10,6 +10,9 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional Properties:
+ - rtc-supply : phandle to the regulator device tree node if needed.
+
Example:
rtc@1c23000 {
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 21142e6..4473d1d 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -24,6 +24,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
#include linux/io.h
+#include linux/regulator/consumer.h
/* The OMAP1 RTC is a year/month/day/hours/minutes/seconds BCD clock
* with century-range alarm matching, driven by the 32kHz clock.
@@ -121,6 +122,7 @@
#define OMAP_RTC_HAS_32KCLK_EN BIT(2)
static void __iomem *rtc_base;
^^ this can easily be removed by allocating data in probe.
+static struct regulator *rtc_reg;
So, two instances cannot have different RTC supplies? we dont need to
do this.
#define rtc_read(addr) readb(rtc_base + (addr))
#define rtc_write(val, addr)writeb(val, rtc_base + (addr))
@@ -372,11 +374,12 @@ static const struct of_device_id omap_rtc_of_match[] =
{
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
-static int __init omap_rtc_probe(struct platform_device *pdev)
+static int omap_rtc_probe(struct platform_device *pdev)
{
struct resource *res;
struct rtc_device *rtc;
u8 reg, new_ctrl;
+int ret;
const struct platform_device_id *id_entry;
const struct of_device_id *of_id;
@@ -402,6 +405,23 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
return -ENOENT;
}
+rtc_reg = devm_regulator_get_optional(pdev-dev, rtc);
+if (IS_ERR(rtc_reg)) {
+if (PTR_ERR(rtc_reg) == -EPROBE_DEFER) {
+dev_err(pdev-dev, regulator not ready, retry\n);
+return -EPROBE_DEFER;
+}
+rtc_reg = NULL;
+}
+
+if (rtc_reg) {
+ret = regulator_enable(rtc_reg);
+if (ret) {
+dev_dbg(pdev-dev, regulator enable failed\n);
+return ret;
+}
+}
+
Do you have a specific voltage you need for your rtc device?
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
rtc_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(rtc_base))
@@ -517,6 +537,9 @@ static int __exit omap_rtc_remove(struct platform_device
*pdev)
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
+if (rtc_reg)
+regulator_disable(rtc_reg);
+
return 0;
}
@@ -565,6 +588,7 @@ static void omap_rtc_shutdown(struct platform_device
*pdev)
MODULE_ALIAS(platform:omap_rtc);
static struct platform_driver omap_rtc_driver = {
+.probe = omap_rtc_probe,
.remove = __exit_p(omap_rtc_remove),
.shutdown = omap_rtc_shutdown,
.driver = {
@@ -576,7 +600,7 @@ static struct platform_driver omap_rtc_driver = {
.id_table = omap_rtc_devtype,
};
-module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
+module_platform_driver(omap_rtc_driver);
MODULE_AUTHOR(George G. Davis (and others));
MODULE_LICENSE(GPL);
--
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
Re: [PATCH v3 1/5] clk: ti: add ti,gpio-gate-clock controlled clock
On 09/19/2014 08:07 AM, Tomi Valkeinen wrote: On 16/09/14 23:40, Jyri Sarha wrote: The added ti,gpio-gate-clock is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. Signed-off-by: Jyri Sarha jsa...@ti.com --- .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gpio.c | 202 3 files changed, 224 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt create mode 100644 drivers/clk/ti/gpio.c Why is this a TI clock? Sounds like a generic one to me. Like thread: https://lkml.org/lkml/2014/9/5/284 ? In any case, this should go through Mike. yep - should have been posted independent of this series :). -- 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
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
On 08:37-20140919, Thomas Gleixner wrote:
On Thu, 18 Sep 2014, Nishanth Menon wrote:
On 17:57-20140918, Thomas Gleixner wrote:
I suppose I can improve the commit message to elaborate this better?
Will that help?
You also want to improve the comment in the empty handler.
OK. will do the same. Thanks for suggesting.
+*/
+ return IRQ_NONE;
And it still does not explain WHY you think that returning IRQ_NONE is
the right thing to do here. You actually handle the interrupt, right?
Just because the handler is an NOP does not mean you did not handle
it.
Hmm.. My motivation for IRQ_NONE was because this specific handler does
not handle the interrupt. Now, from this discussion, I understand that I
should rather use IRQ_HANDLED since the event is indeed handled (just
not here).
Thank you for correcting my understanding. Will update in my next rev
(once we solve the following discussion)..
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t
mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(palmas-wakeirq);
+
+ return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ disable_irq_nosync(palmas-wakeirq);
Again, why nosync?
true - nosync is not necessary at here. disable_irq is however necessary
as we are not interested in wakeup events for level changes.
We just use the enable/disable to control when we'd want to arm the pin
for waking up from suspend state.
And what is issuing the call to enable/disable_irq_wake()?
So if that interrupt is not marked proper then you can bring your
device into a wont resume state easily
start suspend
enable wakeirq
disable_device_irqs()
if (!iswakeup_irq())
disable_irq() // does not mask due to lazy masking
wakeirq fires
if (irq_is_disabled())
mask_irq();
transition into suspend
Now your pinctrl irq is masked at the HW level and wont wake the
machine up ever again.
True.
So now looking at that pinctrl irq chip thing, which seems to be
designed to handle these kind of wakeups. That thing looks massivly
wrong as well, simply because it enforces to use
enable_irq/disable_irq().
So because the sole purpose of this chip is to handle the separate
wakeup style interrupt, it should actually NOT enable the interrupt in
the irq_unmask callback.
Simply because during normal operation nothing is interested in the
interrupt and any operation which might enable it (including request
irq) is just making the system handle completely pointless interrupts
and hoops and loops juggling with enable/disable irq.
So the right thing here is to have an empty unmask function and do the
actual unmask only in the irq_set_wake() callback. mask of course
needs to do what it says. The point is, that the following sequence of
code will just work w/o generating an interrupt on the wakeirq line
outside of the wake enabled context.
dev_init()
request_wakeirq();
suspend()
if (may_wake())
enable_irq_wake();
resume()
if (may_wake())
disable_irq_wake();
The other omap drivers using this have the same issue ... And of
course they are subtly different.
The uart one handles the actual device interrupt, which is violating
the general rule of possible interrupt reentrancy in the pm-runtime
case if the two interrupts are affine to two different cores. Yes,
it's protected by a lock and works by chance
The mmc one issues a disable_irq_nosync() in the wakeup irq handler
itself.
WHY does one driver need that and the other does not? You are not even
able to come up with a common scheme for OMAP. I don't want to see the
mess others are going to create when this stuff becomes more used.
Thanks,
tglx
I think I understand your concern - I request Tony to comment about
this. I mean, I can try and hook things like uart in other drivers
(like https://patchwork.kernel.org/patch/4759171/ ), but w.r.t overall
generic usage guideline wise, I would prefer Tony to comment.
--
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
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On 09/18/2014 02:16 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140918 10:17]: * Tero Kristo t-kri...@ti.com [140901 11:09]: Hi, This set contains PRCM related cleanups meant for 3.18 merge window. These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's set is used as basis to avoid merge issues. Purpose of this work is to eventually convert the PRCM code into a separate driver, but this is done in incremental parts as the amount of changes is substantial. Expected conclusion of this work is 3.19 if everything goes fine. This part of the work mostly moves some of the SoC specific PRCM driver calls under generic version of the same, and adds SoC-ops to support these on the driver level. Working branch posted here: tree: https://github.com/t-kristo/linux-pm.git branch: for-v3.18/prcm-cleanup Paul, any comments on this series? Just gave this branch a quick try, it seems to work with off-idle for me when merged with current linux-omap master branch. The following merge resolution is needed because of the recent pre es3.1 fix though. I've pushed out this merged with all the other pending patches into omap-for-v3.18/tmp-merge-2014-09-18. Nishant, care to give it a try and check your recent PM related changes work with it? Sure. Sorry about the delay.. needed to find some workarounds for working with my board farm.. Tested-by: Nishanth Menon n...@ti.com Based on: omap-for-v3.18/tmp-merge-2014-09-18 0164b2d Merge branch 'omap-for-v3.18/prcm' into omap-for-v3.18/tmp-merge Test #1: basic testing Added 69c6133 HACK: Makefile: Build a uImage with dtb already appended (for legacy boards) commit 0164b2dbe83e885a53b0c9a99a508bdbfdf7ee6d BASIC boot 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zy9OUOMM 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2t0JaiHYf 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2SRkMMQwp 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20T0sq5dp 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2AVYqDVBf 6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s213N14B9r 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21yyMkFRS 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s2SYJOHRwI 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s214QDgb06 10: beaglebone: Boot PASS: http://slexy.org/raw/s21SOLcjMD 11: craneboard: Boot PASS: http://slexy.org/raw/s218cXoYSl 12: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21BAnAW8N 13: dra7xx-evm: Boot PASS: http://slexy.org/raw/s21kf4G5Sh 14: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s21QIGwFOM 15: n900: Boot PASS: http://slexy.org/raw/s21T5xECo2 16: omap5-evm: Boot PASS: http://slexy.org/raw/s20qxa3iPw 17: pandaboard-es: Boot PASS: http://slexy.org/raw/s2Fh0hMW7n 18: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2vqUc528i 19:sdp2430: Boot PASS: http://slexy.org/raw/s21gAsEAeD 20:sdp3430: Boot PASS: http://slexy.org/raw/s2dvThSn5D TOTAL = 20 boards, Booted Boards = 19, No Boot boards = 1 Test #2: PM test (cpufreq/cpuidle/suspend-resume where applicable) Testing script: (http://slexy.org/view/s21SRQehwu) Added the following patches: 59bf40d ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support (discussion still going on https://patchwork.kernel.org/patch/4764661/ - but good to know if it still continues to work with PRM changes). 69c6133 HACK: Makefile: Build a uImage with dtb already appended (for legacy boards) b854ca8 gpio: omap: Fix interrupt names (https://patchwork.kernel.org/patch/4854511/) c50fc8b pinctrl: single: AM437x: Add pinctrl compatibility 37d17bf pinctrl: single: Add DRA7 pinctrl compatibility 74121c6 pinctrl: bindings: Add OMAP pinctrl binding (all of the above are in linux-next) efb2486 clk: prevent erronous parsing of children during rate change b92ac70 clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate 96e8b6b clk: ti: divider: Provide error check for incoming parameters in set_rate (all above picked up by mike) 92e5e74 ARM: OMAP2+ / pm_debug: add support for wakeup_timer configuration (wakeup timer for testing purposes - remote boards) with these: commit 0164b2dbe83e885a53b0c9a99a508bdbfdf7ee6d + Additional patches basic PM test 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2xRMuVHvj 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2qEHyI9Rs 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2Vptpboop 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21TKVsyet 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20KGye4N9 6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s201uuCOp2 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21ChQP74I 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20oagBAsl 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2VT200vL0 10: beaglebone: Boot PASS: http://slexy.org/raw/s20raoHSya 11: craneboard: Boot PASS: http://slexy.org/raw
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
On 09/17/2014 07:22 PM, Daniel Lezcano wrote: On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote: [...] Could you try a long run of this little program: https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c [Santosh] I am sure there will not be any issue with the long run test case here. Lets see if Nishant sees anything otherwise Ok. Make sure the cpu is effectively entering your C2 state with the sleep duration in the test program. Test kernel: https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume (I decided to merge in various send for pull branches from maintainers and apply cpuidle on top).. Controlled test run as follows on 4 different impacted platforms and 1 platform as legacy reference. What we are looking for is cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 RET:2677 indicated CPU1 hit C2 cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 RET:2677 indicated CPU0 hit C2 mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0 RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together, else by hardware constraints in place, MPU power domain will fail to transition. What I see in all cases below is that transitions do take place (C2 is successfully hit). Test #1: 120 seconds: CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep 1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just base test vector http://fpaste.org/134547/14110454/ OMAP5 uEVM: (2 a15) http://fpaste.org/134546/10454181/ DRA74x: (2 a15) http://fpaste.org/134543/11045286/ DRA72: (2 a15) http://fpaste.org/134544/11045335/ AM572x(DRA74x variant): (2 A15) http://fpaste.org/134545/10453761/ Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/) CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep 1;./cpuidle_killer_1200;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just base test vector http://fpaste.org/134563/41104728/ OMAP5 uEVM: (2 a15) http://fpaste.org/134562/47221141/ DRA74x EVM: (2 a15) http://fpaste.org/134559/11047098/ DRA72 EVM: (2 a15) http://fpaste.org/134560/11047151/ AM572x EVM: (2 A15) http://fpaste.org/134561/47189141/ -- 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
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
On 09/18/2014 08:41 AM, Nishanth Menon wrote: On 09/17/2014 07:22 PM, Daniel Lezcano wrote: On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote: [...] Could you try a long run of this little program: https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c [Santosh] I am sure there will not be any issue with the long run test case here. Lets see if Nishant sees anything otherwise Ok. Make sure the cpu is effectively entering your C2 state with the sleep duration in the test program. Test kernel: https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume (I decided to merge in various send for pull branches from maintainers and apply cpuidle on top).. Controlled test run as follows on 4 different impacted platforms and 1 platform as legacy reference. What we are looking for is cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 RET:2677 indicated CPU1 hit C2 cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 RET:2677 indicated CPU0 hit C2 mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0 RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together, else by hardware constraints in place, MPU power domain will fail to transition. What I see in all cases below is that transitions do take place (C2 is successfully hit). Test #1: 120 seconds: CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep 1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just base test vector http://fpaste.org/134547/14110454/ OMAP5 uEVM: (2 a15) http://fpaste.org/134546/10454181/ DRA74x: (2 a15) http://fpaste.org/134543/11045286/ DRA72: (2 a15) ^^ Correction should have been 1 a15 http://fpaste.org/134544/11045335/ AM572x(DRA74x variant): (2 A15) http://fpaste.org/134545/10453761/ Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/) CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep 1;./cpuidle_killer_1200;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just base test vector http://fpaste.org/134563/41104728/ OMAP5 uEVM: (2 a15) http://fpaste.org/134562/47221141/ DRA74x EVM: (2 a15) http://fpaste.org/134559/11047098/ DRA72 EVM: (2 a15) ^^ Correction should have been 1 a15 http://fpaste.org/134560/11047151/ AM572x EVM: (2 A15) http://fpaste.org/134561/47189141/ -- 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
Re: [PATCH V2 3/3] mfd: palmas: Add support for optional wakeup
On 09/08/2014 10:41 AM, Nishanth Menon wrote:
On 23:13-20140905, Thomas Gleixner wrote:
On Fri, 5 Sep 2014, Nishanth Menon wrote:
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+ palmas_wake_irq,
+ IRQF_ONESHOT | pdata-irq_flags,
Why is this marked IRQF_ONESHOT?
Uggh.. should have dropped it. my bad.. removed in the revision below.
Thanks for catching it.
+ dev_name(palmas-dev),
+ palmas);
+ if (ret 0)
+ goto err_i2c;
Why err and not doing the obvious clearing of palmas-wakeirq and
keep at least the i2c functional?
Hmmm.. true.. we can stay alive even though without wakeup capability if
someone messes up configuration..
Fixed version below. Let me know if you are ok with the following.
Gentle ping. Would you like me to repost this series over again?
8
From 6da58ac66eedea46cf7282c6644c76c8f328f5ee Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 12 Aug 2014 12:00:52 -0500
Subject: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power states as interrupts.
This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the actual event during
system active state). This is not the same as threaded interrupts as the
wakeup interrupt source is used only as part of deeper power saving
mode.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/mfd/palmas.c | 62
include/linux/mfd/palmas.h |2 ++
2 files changed, 64 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..de7d204 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] =
{
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+ * Return Not handled so that interrupt is disabled.
+ * Level event ensures that the event is eventually handled
+ * by the appropriate chip handler already registered
+ */
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+ pdata-wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+ palmas-wakeirq = pdata-wakeirq;
match = of_match_device(of_palmas_match_tbl, i2c-dev);
@@ -587,6 +600,25 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err_i2c;
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+palmas_wake_irq,
+pdata-irq_flags,
+dev_name(palmas-dev),
+palmas);
+ if (ret 0) {
+ dev_err(palmas-dev, Invalid wakeirq(%d) (res: %d), skiping\n,
+ palmas-wakeirq, ret);
+ palmas-wakeirq = 0;
+ } else {
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas-dev, true);
+ disable_irq_nosync(palmas-wakeirq);
+ }
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +738,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup
Re: [PATCH 09/12] ARM: omap2plus_defconfig: Add cpufreq to defconfig
On 20:12-20140915, Tony Lindgren wrote: Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0, so let's only enable that. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index fc63855..9d232a5 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -43,6 +43,13 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 CONFIG_KEXEC=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_GENERIC_CPUFREQ_CPU0=y +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set With this we get performace as the default governor. could we use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND as the default instead? on Many TI SoCs using Highest frequency is not really too nice of an idea for long periods of time. And not everything is upstream to support things optimially - example avs class 0, 1.5 ABB consolidation with cpufreq etc.. We definitely need thermal enabled as well for device safety needs. I propose the following instead: @@ -43,6 +43,14 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 CONFIG_KEXEC=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_STAT_DETAILS=y +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_GENERIC_CPUFREQ_CPU0=y +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set CONFIG_CPU_IDLE=y CONFIG_BINFMT_MISC=y CONFIG_PM_DEBUG=y @@ -162,7 +170,9 @@ CONFIG_SENSORS_LM75=m CONFIG_THERMAL=y CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_USER_SPACE=y +CONFIG_CPU_THERMAL=y CONFIG_TI_SOC_THERMAL=y +CONFIG_TI_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y CONFIG_DRA752_THERMAL=y -- 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
Re: [PATCH 09/12] ARM: omap2plus_defconfig: Add cpufreq to defconfig
On 09:20-20140918, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [140918 09:12]: On 20:12-20140915, Tony Lindgren wrote: Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0, so let's only enable that. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index fc63855..9d232a5 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -43,6 +43,13 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 CONFIG_KEXEC=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_GENERIC_CPUFREQ_CPU0=y +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set With this we get performace as the default governor. could we use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND as the default instead? on Many TI SoCs using Highest frequency is not really too nice of an idea for long periods of time. And not everything is upstream to support things optimially - example avs class 0, 1.5 ABB consolidation with cpufreq etc.. We definitely need thermal enabled as well for device safety needs. OK, sure. I've applied the following version with your changes folded in. Regards, Tony 8 --- From: Tony Lindgren t...@atomide.com Date: Thu, 18 Sep 2014 09:01:07 -0700 Subject: [PATCH] ARM: omap2plus_defconfig: Add cpufreq to defconfig Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0, so let's only enable that. Let's use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND as suggested by Nishant. And also let's enable thermal as explained by Nishant Menon: Many TI SoCs using Highest frequency is not really too nice of an idea for long periods of time. And not everything is upstream to support things optimially - example avs class 0, 1.5 ABB consolidation with cpufreq etc.. We definitely need thermal enabled as well for device safety needs. Cc: Nishanth Menon n...@ti.com [t...@atomide.com: updated per Nishant's suggestions] Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -43,6 +43,14 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 CONFIG_KEXEC=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_STAT_DETAILS=y +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_GENERIC_CPUFREQ_CPU0=y +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set CONFIG_CPU_IDLE=y CONFIG_BINFMT_MISC=y CONFIG_PM_DEBUG=y @@ -162,7 +170,9 @@ CONFIG_SENSORS_LM75=m CONFIG_THERMAL=y CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_USER_SPACE=y +CONFIG_CPU_THERMAL=y CONFIG_TI_SOC_THERMAL=y +CONFIG_TI_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y CONFIG_DRA752_THERMAL=y Acked-by: Nishanth Menon n...@ti.com -- 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
[PATCH V3 0/3] mfd: palmas: add optional wakeup irq
Hi, V3 update for the previous series: Changes in V3 (from review updates): - Allow driver to function even if wakeirq fails - Fix irq flags V2: http://marc.info/?l=linux-kernelm=140995041418575w=2 v1: https://patchwork.kernel.org/patch/4743321/ Nishanth Menon (3): Documentation: dt-bindings: mfd: palmas: Fix example style of i2c peripheral Documentation: dt-bindings: mfd: palmas: document optional wakeup IRQ mfd: palmas: Add support for optional wakeup Documentation/devicetree/bindings/mfd/palmas.txt | 22 +++- drivers/mfd/palmas.c | 62 ++ include/linux/mfd/palmas.h |2 + 3 files changed, 85 insertions(+), 1 deletion(-) -- 1.7.9.5 -- 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 2/3] Documentation: dt-bindings: mfd: palmas: document optional wakeup IRQ
With the recent pinctrl-single changes, SoCs such as OMAP family can
treat wake-up events from deeper low power states as interrupts.
This is usable when the wakeup from deeper low power states is
triggered by a different hardware mechanism tied to pinctrl compared
to the routine interrupt handling generating the reqular interrupt
events. This is usually done on SoCs where the routine interrupt
sources such as GPIO need to be disabled to be actually achieve low
power state and wakeup is triggered from pinctrl interrupt source.
Provide documentation example for the case where the system needs two
interrupt sources when SoC is in deep sleep(1 to exit from deep sleep,
and other from the module handling the actual event).
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: no change
V2: http://marc.info/?l=linux-kernelm=140995036418561w=2
Documentation/devicetree/bindings/mfd/palmas.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index d193859..1c821d6 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -51,3 +51,23 @@ palmas@48 {
};
}
+
+Example: With interrupts extended
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ Use pinmux 0x418 as wakeup interrupt and gpio1_0 as interrupt source
+
+palmas@48 {
+ compatible = ti,twl6035, ti,palmas;
+ reg = 0x48
+ interrupt-parent = intc;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts-extended = gpio1 0 IRQ_TYPE_LEVEL_HIGH,
+ pinmux 0x418;
+ pmic {
+ compatible = ti,twl6035-pmic, ti,palmas-pmic;
+
+ };
+}
--
1.7.9.5
--
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 1/3] Documentation: dt-bindings: mfd: palmas: Fix example style of i2c peripheral
Use device@address as name for device nodes.
Suggested-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: no change
V2: http://marc.info/?l=linux-kernelm=140995036518562w=2
Documentation/devicetree/bindings/mfd/palmas.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..d193859 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -33,7 +33,7 @@ Optional properties:
Example:
-palmas {
+palmas@48 {
compatible = ti,twl6035, ti,palmas;
reg = 0x48
interrupt-parent = intc;
--
1.7.9.5
--
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 3/3] mfd: palmas: Add support for optional wakeup
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power states as interrupts.
This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the actual event during
system active state). This is not the same as threaded interrupts as the
wakeup interrupt source is used only as part of deeper power saving
mode.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: updates based on Thomas's comments.
V2: http://marc.info/?t=14099504503r=1w=2
drivers/mfd/palmas.c | 62
include/linux/mfd/palmas.h |2 ++
2 files changed, 64 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..de7d204 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+* Return Not handled so that interrupt is disabled.
+* Level event ensures that the event is eventually handled
+* by the appropriate chip handler already registered
+*/
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+ pdata-wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+ palmas-wakeirq = pdata-wakeirq;
match = of_match_device(of_palmas_match_tbl, i2c-dev);
@@ -587,6 +600,25 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err_i2c;
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+ palmas_wake_irq,
+ pdata-irq_flags,
+ dev_name(palmas-dev),
+ palmas);
+ if (ret 0) {
+ dev_err(palmas-dev, Invalid wakeirq(%d) (res: %d), skiping\n,
+ palmas-wakeirq, ret);
+ palmas-wakeirq = 0;
+ } else {
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas-dev, true);
+ disable_irq_nosync(palmas-wakeirq);
+ }
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +738,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(palmas-wakeirq);
+
+ return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ disable_irq_nosync(palmas-wakeirq);
+
+ return 0;
+}
+
static const struct i2c_device_id palmas_i2c_id[] = {
{ palmas, },
{ twl6035, },
@@ -721,6 +781,8 @@ static struct i2c_driver palmas_i2c_driver = {
.of_match_table = of_palmas_match_tbl,
.owner = THIS_MODULE,
},
+ .suspend = palmas_i2c_suspend,
+ .resume = palmas_i2c_resume,
.probe = palmas_i2c_probe,
.remove = palmas_i2c_remove,
.id_table = palmas_i2c_id,
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index fb0390a..e8cf4c2 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -75,6 +75,7 @@ struct palmas {
/* IRQ Data */
int irq;
u32 irq_mask
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
On 17:57-20140918, Thomas Gleixner wrote:
On Thu, 18 Sep 2014, Nishanth Menon wrote:
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+* Return Not handled so that interrupt is disabled.
And how is that interrupt disabled by returning IRQ_NONE? You mean it
gets disabled after it got reraised 10 times and the spurious
detector kills it?
No, that does not happen due to the hardware involved:
http://fpaste.org/134757/09428214/ (there are still fixes needed to
various drivers to completely achieve low power states).
Explanation below:
+* Level event ensures that the event is eventually handled
+* by the appropriate chip handler already registered
Eventually handled? So eventually it's not handled?
I had previously tried explaining this in v1:
https://patchwork.kernel.org/patch/4743321/
I agree it is a little convoluted, so will try again: mainly because
of the hardware entities involved. Two different hardware generate
interrupt. A GPIO hardware block handles palmas interrupts when SoC
is ON, However with GPIO block active, we cannot achieve low power
suspend (deep sleep) for the SoC, so, we switch off all GPIOs and SoC
hardware blocks OFF as part of the sequence of going to low power
suspend (mem), and depend on the hardware controlling the pins of the
SoC to generate wakeup event (wakeirq).
wakeirq is provided by drivers/pinctrl/pinctrl-single.c (implementation
to handle pad generated interrupt source).
wakeirq is generated by the hardware at the pin (we call it control
module in TI SoC), this generates an interrupt on level change. Palmas
generates level interrupt, and the level is cleared when interrupt
source is cleared.
At suspend - we enable_irq(wakeirq) - this arms the pin for palmas
interrupt to generate an interrupt when level changes.
We start the wake sequence in deep sleep (only thing alive is that
control module, every thing else, including GPIO block is powered
off).
On generating a wakeup event (in the example log, I used palmas power
button), palmas generates a level event, the transition triggers two things:
a) control module generates wakeirq (detecting the level shift)
b) wakeirq causes wakeup of SoC from deep sleep.
wakeirq wont be generated again by the hardware because pinctrl handles
the wakeirq interrupt event in the control module.
At resume - we disable_irq wakeirq -which in turn disables the pin for
generating interrupts if level ever changes again.
GPIO block is restored as part of resume path, and we generate the
handler for palmas regular interrupt service which in turn goes and
detects the real event and handles it.
I suppose I can improve the commit message to elaborate this better?
Will that help?
+*/
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+ pdata-wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+ palmas-wakeirq = pdata-wakeirq;
match = of_match_device(of_palmas_match_tbl, i2c-dev);
@@ -587,6 +600,25 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err_i2c;
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+ palmas_wake_irq,
+ pdata-irq_flags,
+ dev_name(palmas-dev),
+ palmas);
+ if (ret 0) {
+ dev_err(palmas-dev, Invalid wakeirq(%d) (res: %d), skiping\n,
+ palmas-wakeirq, ret);
+ palmas-wakeirq = 0;
+ } else {
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas-dev, true);
+ disable_irq_nosync(palmas-wakeirq);
Urgh. Why nosysnc? And why do you want to do that at all?
irq_set_status_flags(irq, IRQ_NOAUTOEN);
Is what you want to set before requesting the irq.
Aaah, OK. thanks on the suggestion. will do that.
+ }
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +738,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas
Re: [PATCH 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off
On 16:05-20140916, Lee Jones wrote: On Mon, 08 Sep 2014, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [140903 12:07]: ti,system-power-controller is more or less the standard way of indicating that the PMIC is the system wide power controller and hence may be used to switch off the system. Almost ALL TI PMIC drivers and many Maxim PMIC drivers follow the same style. So support 'ti,system-power-controller' in addition to the usual 'ti,use_poweroff' to indicate that the PMIC instance has control for switching off the system. Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Tony Lindgren t...@atomide.com I assume you're going to resend this with the document modifications? When you do, don't forget to apply Tony's Ack, as it will ensure a faster merge. Thanks for the reminder, This did indeed slip through the cracks. Posting updated rev in a few mins.. -- 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
[PATCH V2 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control
ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.
So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: picked up documentation suggestion from Sebastien
V1: https://patchwork.kernel.org/patch/4836381/
.../devicetree/bindings/mfd/twl4030-power.txt |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b9ee7b9..a7390c7 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -23,8 +23,13 @@ down during off-idle. Note that this does not work on all
boards
depending on how the external oscillator is wired.
Optional properties:
-- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
- SLEEP-to-OFF transition when the system poweroffs.
+
+- ti,system-power-controller: This indicates that TWL4030 is the
+ power supply master of the system. With this flag, the chip will
+ initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
+ system poweroffs.
+
+- ti,use_poweroff: Deprecated name for ti,system-power-controller
Example:
i2c1 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off
ti,system-power-controller is more or less the standard way of indicating that the PMIC is the system wide power controller and hence may be used to switch off the system. Almost ALL TI PMIC drivers and many Maxim PMIC drivers follow the same style. So support 'ti,system-power-controller' in addition to the usual 'ti,use_poweroff' to indicate that the PMIC instance has control for switching off the system. Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- V2: no change, picked up Tony's ack. V1: https://patchwork.kernel.org/patch/4836371/ drivers/mfd/twl4030-power.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c index 3bc969a..1c129ba 100644 --- a/drivers/mfd/twl4030-power.c +++ b/drivers/mfd/twl4030-power.c @@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct twl4030_power_data *pdata, if (pdata pdata-use_poweroff) return true; + if (of_property_read_bool(node, ti,system-power-controller)) + return true; + if (of_property_read_bool(node, ti,use_poweroff)) return true; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/2] mfd: twl4030-power: support ti,system-power-controller
This series adds ti,system-power-controller to Documentation and the driver seperately as per maintainer preference. Based on v3.17-rc1 Changes since V1: update in documentation, picked up Tony's ack for patch #2. V1: http://marc.info/?l=devicetreem=140977126218800w=2 Nishanth Menon (2): Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off .../devicetree/bindings/mfd/twl4030-power.txt |9 +++-- drivers/mfd/twl4030-power.c|3 +++ 2 files changed, 10 insertions(+), 2 deletions(-) -- 1.7.9.5 -- 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] CLK: TI: consider the fact that of_clk_get() might return an error
On 09/11/2014 11:01 AM, Sebastian Andrzej Siewior wrote:
I forgot to update the dtb and the kernel crashed:
|Unable to handle kernel NULL pointer dereference at virtual address 002e
|PC is at __clk_get_flags+0x4/0xc
|LR is at ti_dt_clockdomains_setup+0x70/0xe8
because I did not have the clock nodes. of_clk_get() returns an error
pointer which is not checked here.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/clk/ti/clockdomain.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
index f1e0038d76ac..fdd458600c2c 100644
--- a/drivers/clk/ti/clockdomain.c
+++ b/drivers/clk/ti/clockdomain.c
@@ -36,6 +36,11 @@ static void __init of_ti_clockdomain_setup(struct
device_node *node)
for (i = 0; i num_clks; i++) {
clk = of_clk_get(node, i);
+ if (IS_ERR(clk)) {
+ pr_err(Failed get %s' clock nr %d (%ld)\n,
+ node-full_name, i, PTR_ERR(clk));
Could you add %s: __func__ as well - it kinda helps understand this is
part of clockdomain setup and not some driver cribbing that it did not
get some clock.
+ continue;
+ }
if (__clk_get_flags(clk) CLK_IS_BASIC) {
pr_warn(can't setup clkdm for basic clk %s\n,
__clk_get_name(clk));
--
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: dts: DRA7: Add PMU nodes
On 08:39-20140903, Nishanth Menon wrote:
On 08/19/2014 08:54 AM, Nishanth Menon wrote:
From: Lucas Weaver l-wea...@ti.com
DRA74x and DRA72x family of processors vary slightly in the number
of CPUs. So, add different instances of PMU for each of these processor
groups. Further, since the interrupts bypass crossbar and are directly
connected to GIC, mark the dts nodes with relevant information.
Tested with perf utility.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lucas Weaver l-wea...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Hi,
Gentle ping..
Tony,
I dont see this patch in omap-for-v3.18/dt
Is there anyway you might consider pulling this for 3.18?
Patchworks link:
https://patchwork.kernel.org/patch/4743121/
Regards,
Nishanth Menon
arch/arm/boot/dts/dra72x.dtsi |5 +
arch/arm/boot/dts/dra74x.dtsi |6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index f1ec22f..e5a3d23 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -22,4 +22,9 @@
reg = 0;
};
};
+
+ pmu {
+ compatible = arm,cortex-a15-pmu;
+ interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
+ };
};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index a4e8bb9..3be544c 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -38,4 +38,10 @@
reg = 1;
};
};
+
+ pmu {
+ compatible = arm,cortex-a15-pmu;
+ interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI DIRECT_IRQ(132) IRQ_TYPE_LEVEL_HIGH;
+ };
};
--
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
--
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
Re: [PATCH v2] CLK: TI: consider the fact that of_clk_get() might return an error
On 17:56-20140917, Sebastian Andrzej Siewior wrote:
I forgot to update the dtb and the kernel crashed:
|Unable to handle kernel NULL pointer dereference at virtual address 002e
|PC is at __clk_get_flags+0x4/0xc
|LR is at ti_dt_clockdomains_setup+0x70/0xe8
because I did not have the clock nodes. of_clk_get() returns an error
pointer which is not checked here.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
v1…v2:
add %s __func__ to the added pr_err
* Nishanth Menon | 2014-09-17 07:52:33 [-0500]:
Could you add %s: __func__ as well - it kinda helps understand this
is part of clockdomain setup and not some driver cribbing that it did
not get some clock.
As you wish.
drivers/clk/ti/clockdomain.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
index f1e0038d76ac..446481166ce9 100644
--- a/drivers/clk/ti/clockdomain.c
+++ b/drivers/clk/ti/clockdomain.c
@@ -36,6 +36,12 @@ static void __init of_ti_clockdomain_setup(struct
device_node *node)
for (i = 0; i num_clks; i++) {
clk = of_clk_get(node, i);
+ if (IS_ERR(clk)) {
+ pr_err(%s: Failed get %s' clock nr %d (%ld)\n,
+ __func__, node-full_name, i,
+ PTR_ERR(clk));
+ continue;
+ }
Once the following is fixed (checkpatch --strict) feel free to add:
Acked-by: Nishanth Menon n...@ti.com
#65: FILE: drivers/clk/ti/clockdomain.c:35:
_node *node)
CHECK: Alignment should match open parenthesis
#71: FILE: drivers/clk/ti/clockdomain.c:40:
+ pr_err(%s: Failed get %s' clock nr %d (%ld)\n,
+ __func__, node-full_name, i,
total: 1 errors, 0 warnings, 1 checks, 16 lines checked
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
--
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
Re: [PATCH V2 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control
On 18:55-20140917, Sebastian Reichel wrote:
On Wed, Sep 17, 2014 at 08:44:00AM -0700, Lee Jones wrote:
On Wed, 17 Sep 2014, Nishanth Menon wrote:
ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.
So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: picked up documentation suggestion from Sebastien
It would be good to get Sebastian's Ack.
Acked-By: Sebastian Reichel s...@kernel.org
Thanks.
[...]
+- ti,system-power-controller: This indicates that TWL4030 is the
+ power supply master of the system. With this flag, the chip will
+ initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
+ system poweroffs.
One minor thing: While the documentation is updated you may want to
fix the typo will initiates to will initiate (or just drop the
will).
Updated v3 patch with your ack and correction to drop will below. I
will assume I wont need to repost the following update. Do let me know
if you'd like me to.
---8---
From ae3bcfc74080b14f9fd0178f6526bf8f34a8c865 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 3 Sep 2014 13:55:02 -0500
Subject: [PATCH V3 1/2 ] Documentation: devicetree: mfd: twl4030-power: Use the
standard 'ti,system-power-controller' to mark power control
ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.
So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.
Signed-off-by: Nishanth Menon n...@ti.com
Acked-By: Sebastian Reichel s...@kernel.org
---
.../devicetree/bindings/mfd/twl4030-power.txt |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b9ee7b9..15a63e6 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -23,8 +23,13 @@ down during off-idle. Note that this does not work on all
boards
depending on how the external oscillator is wired.
Optional properties:
-- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
- SLEEP-to-OFF transition when the system poweroffs.
+
+- ti,system-power-controller: This indicates that TWL4030 is the
+ power supply master of the system. With this flag, the chip
+ initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
+ system poweroffs.
+
+- ti,use_poweroff: Deprecated name for ti,system-power-controller
Example:
i2c1 {
--
1.7.9.5
--
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
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
Daniel,
On 09/05/2014 04:18 PM, Nishanth Menon wrote:
Daniel,
On 13:22-20140827, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
+ Daniel (cpuidle maintainer)
[...]
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ return index;
+}
Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
Trying to understand benefit of MCPM here - at least without a deeper
understanding of mcpm infrastructure benefits (first look seemed a
little heavy for OMAP5/DRA7 needs).
Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
OFF of CPU1/0, we have mercury hardware to help with context and
sync issues.
Being able to reuse most of existing OMAP4 infrastructure code is
useful as well to leave the existing omap4 framework as being lighter
in complexity -esp in a cpuidle like hot path?
The spin_lock is only for the programming of MPU power domain in a
consistent manner - I suppose might have been the trigger for
proposing mcpm?
Mostly not
I think this is coming because last time Nicolas Pitre tried to convert
the OMAP CPUIdle into MCPM but because of various ordering requirements,
OMAP wasn't suitable and then the plan was dropped later.
Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
remains the same for deeper states. Its just the mercury retention state
which we are able to enter without ordering requirements and hence
the voting scheme.
Ah, OK. This is the part that I'm missing. So for deeper states you'll
need to be using omap_enter_idle_coupled()
Hope this clarifies to you as well as Kevin just in case he missed the
part of the deeper C-states requirements.
Yes, thanks for clarifying.
That being said, I think MCPM can now do essentially what the coupled
states code is doing. Even so, that's probably not a reason to hold up
this patch, but Daniel gets to make that call.
Gentle ping.. You can find the discussion and the patch here:
https://patchwork.kernel.org/patch/4764661/
Ping on this again.. we are pretty close to approaching v3.18 merge
window and this discussion has'nt gotten further.
--
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
Re: [PATCH 1/4] ARM: dts: cm-t54: add HDMI/DVI display data
*/
+ OMAP5_IOPAD(0x0120, PIN_OUTPUT | MUX_MODE3) /*
dispc_data1 */
+ OMAP5_IOPAD(0x0122, PIN_OUTPUT | MUX_MODE3) /*
dispc_data0 */
+ OMAP5_IOPAD(0x0124, PIN_OUTPUT | MUX_MODE3) /*
dispc_vsync */
+ OMAP5_IOPAD(0x0126, PIN_OUTPUT | MUX_MODE3) /*
dispc_hsync */
+ OMAP5_IOPAD(0x0128, PIN_OUTPUT | MUX_MODE3) /* dispc_de
*/
+ OMAP5_IOPAD(0x012a, PIN_OUTPUT | MUX_MODE3) /*
dispc_pclk */
+ OMAP5_IOPAD(0x012c, PIN_OUTPUT | MUX_MODE3) /*
dispc_data17 */
+ OMAP5_IOPAD(0x012e, PIN_OUTPUT | MUX_MODE3) /*
dispc_data16 */
+ OMAP5_IOPAD(0x0130, PIN_OUTPUT | MUX_MODE3) /*
dispc_data18 */
+ OMAP5_IOPAD(0x0132, PIN_OUTPUT | MUX_MODE3) /*
dispc_data19 */
+ OMAP5_IOPAD(0x0134, PIN_OUTPUT | MUX_MODE3) /*
dispc_data20 */
+ OMAP5_IOPAD(0x0136, PIN_OUTPUT | MUX_MODE3) /*
dispc_data21 */
+ OMAP5_IOPAD(0x0138, PIN_OUTPUT | MUX_MODE3) /*
dispc_data22 */
+ OMAP5_IOPAD(0x013a, PIN_OUTPUT | MUX_MODE3) /*
dispc_data23 */
+ ;
+ };
};
mmc1 {
@@ -398,6 +515,13 @@
};
};
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ clock-frequency = 10;
+};
+
usbhshost {
port2-mode = ehci-hsic;
port3-mode = ehci-hsic;
@@ -410,3 +534,37 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_dpi_pins;
+
+ port {
+ dpi_dvi_out: endpoint@0 {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+ };
+};
+
+dsi2 {
+ status = ok;
+ vdd-supply = ldo4_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo4_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ lanes = 1 0 3 2 5 4 7 6;
+ };
+ };
+};
--
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
[PATCH] Input: palmas-pwrbutton: Fix IRQ flags for using threaded handler alone.
make C=2 CHECK=scripts/coccicheck MODE=report
COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
./drivers/input/misc/palmas-pwrbutton.o
Reports:
drivers/input/misc/palmas-pwrbutton.c:213:9-29: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
Palmas powerbutton just needs threaded IRQ handler since I2C
operations are involved and there is nothing in non-threaded primary
handler we could do.
So mark the request with ONESHOT as it should have been done in these
cases.
Cc: Julia Lawal julia.law...@lip6.fr
Cc: Dan Carpenter dan.carpen...@oracle.com
Fixes: adff5962fdd2 (Input: introduce palmas-pwrbutton)
Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/input/misc/palmas-pwrbutton.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/palmas-pwrbutton.c
b/drivers/input/misc/palmas-pwrbutton.c
index 4ed6f78..c0c4636 100644
--- a/drivers/input/misc/palmas-pwrbutton.c
+++ b/drivers/input/misc/palmas-pwrbutton.c
@@ -211,8 +211,8 @@ static int palmas_pwron_probe(struct platform_device *pdev)
pwron-irq = platform_get_irq(pdev, 0);
error = request_threaded_irq(pwron-irq, NULL, pwron_irq,
-IRQF_TRIGGER_HIGH | IRQF_TRIGGER_LOW,
-dev_name(dev), pwron);
+IRQF_TRIGGER_HIGH | IRQF_TRIGGER_LOW |
+IRQF_ONESHOT, dev_name(dev), pwron);
if (error) {
dev_err(dev, Can't get IRQ for pwron: %d\n, error);
goto err_free_input;
--
1.7.9.5
--
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] Input: palmas-pwrbutton: Fix typo in License
Follow the license string convention indicated in include/linux/module.h (don't capitalize v). This fixes following randconfig warning: FATAL: modpost: GPL-incompatible module palmas-pwrbutton.ko uses GPL-only symbol 'platform_driver_unregister' Cc: Stephen Rothwell s...@canb.auug.org.au Reported-by: Jim Davis jim.ep...@gmail.com Signed-off-by: Nishanth Menon n...@ti.com --- Reported thread http://marc.info/?l=linux-inputm=141080223209150w=2 drivers/input/misc/palmas-pwrbutton.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/misc/palmas-pwrbutton.c b/drivers/input/misc/palmas-pwrbutton.c index 3f90211..4ed6f78 100644 --- a/drivers/input/misc/palmas-pwrbutton.c +++ b/drivers/input/misc/palmas-pwrbutton.c @@ -326,5 +326,5 @@ module_platform_driver(palmas_pwron_driver); MODULE_ALIAS(platform:palmas-pwrbutton); MODULE_DESCRIPTION(Palmas Power Button); -MODULE_LICENSE(GPL V2); +MODULE_LICENSE(GPL v2); MODULE_AUTHOR(Texas Instruments Inc.); -- 1.7.9.5 -- 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] Input: palmas-pwrbutton: Fix typo in License
On 09/15/2014 12:58 PM, Nishanth Menon wrote: Follow the license string convention indicated in include/linux/module.h (don't capitalize v). This fixes following randconfig warning: FATAL: modpost: GPL-incompatible module palmas-pwrbutton.ko uses GPL-only symbol 'platform_driver_unregister' Uggh.. forgot to add: Fixes: adff5962fdd2 (Input: introduce palmas-pwrbutton) Cc: Stephen Rothwell s...@canb.auug.org.au Reported-by: Jim Davis jim.ep...@gmail.com Signed-off-by: Nishanth Menon n...@ti.com --- Reported thread http://marc.info/?l=linux-inputm=141080223209150w=2 drivers/input/misc/palmas-pwrbutton.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/misc/palmas-pwrbutton.c b/drivers/input/misc/palmas-pwrbutton.c index 3f90211..4ed6f78 100644 --- a/drivers/input/misc/palmas-pwrbutton.c +++ b/drivers/input/misc/palmas-pwrbutton.c @@ -326,5 +326,5 @@ module_platform_driver(palmas_pwron_driver); MODULE_ALIAS(platform:palmas-pwrbutton); MODULE_DESCRIPTION(Palmas Power Button); -MODULE_LICENSE(GPL V2); +MODULE_LICENSE(GPL v2); MODULE_AUTHOR(Texas Instruments Inc.); -- 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
Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP completely
On Fri, Sep 12, 2014 at 3:38 AM, Paul Bolle pebo...@tiscali.nl wrote: The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit 049d595a4db3 (PM / OPP: Make OPP invisible to users in Kconfig) removed the only dependency that used it. Setting it had no effect anymore. So commit 78c5e0bb145d (PM / OPP: Remove ARCH_HAS_OPP) removed it. For some reason that commit did not remove all select statements for that symbol. These statements are useless. Remove them too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Done on top of next-20140912. Tested with git grep only! arch/arm/mach-omap2/Kconfig| 5 - there can be conflict here: https://patchwork.kernel.org/patch/4857231/ http://marc.info/?l=linux-omapm=141047815520894w=2 arch/arm/mach-shmobile/Kconfig | 1 - drivers/devfreq/Kconfig| 1 - 3 files changed, 7 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 5b103099626d..f138bd33a463 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -22,7 +22,6 @@ config ARCH_OMAP4 bool TI OMAP4 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP select ARM_CPU_SUSPEND if PM select ARM_ERRATA_720789 @@ -41,7 +40,6 @@ config SOC_OMAP5 bool TI OMAP5 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_SCU if SMP @@ -53,14 +51,12 @@ config SOC_AM33XX bool TI AM33XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM config SOC_AM43XX bool TI AM43x depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_GIC select MACH_OMAP_GENERIC select MIGHT_HAVE_CACHE_L2X0 @@ -69,7 +65,6 @@ config SOC_DRA7XX bool TI DRA7XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_ARCH_TIMER diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 21f457b56c01..f59019dd986e 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -36,7 +36,6 @@ menuconfig ARCH_SHMOBILE_MULTI select NO_IOPORT_MAP select PINCTRL select ARCH_REQUIRE_GPIOLIB - select ARCH_HAS_OPP if ARCH_SHMOBILE_MULTI diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index 3dced0a9eae3..2227e9bf3884 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -80,7 +80,6 @@ config ARM_EXYNOS4_BUS_DEVFREQ config ARM_EXYNOS5_BUS_DEVFREQ bool ARM Exynos5250 Bus DEVFREQ Driver depends on SOC_EXYNOS5250 - select ARCH_HAS_OPP select DEVFREQ_GOV_SIMPLE_ONDEMAND select PM_OPP help -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- --- 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
Re: [PATCH] ARM: OMAP3: Fix I/O chain clock line assertion timed out error
On 10:50-20140912, Tony Lindgren wrote: We are getting PRM: I/O chain clock line assertion timed out errors on early omaps for device tree based booting. This is because we are unconditionally calling reconfigure_io_chain while legacy booting has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c. For device tree based booting, we are calling reconfigure_io_chain unconditionally from pinctrl framework. So we need to add a check for omap3_has_io_chain_ctrl() to avoid the errors for trying to access a register that does not exist. For es3.0, the documentation in 4.11.2 Device Off-Mode Configuration just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in documentation for 4.11.2.2 I/O Wake-Up Mechanism that describes the PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get added until in es3.1 probaly to fix issues with flakey wake-up events. We are doing proper checks for ST_IO_CHAIN already in id.c and with omap3_has_io_chain_ctrl(). For more information, see also commit b02b917211d5 (ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection). Let's fix the issue by selecting the right function during init for reconfigure_io_chain depending on the omap revision. For es3.0 and earlier we need to just toggle EN_IO. By doing this, we can move the check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain. Thanks to Paul Walmsley and Nishanth Menon for help with debugging the issue. Fixes: 30a69ef785e8 (ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap) Cc: Kevin Hilman khil...@kernel.org Cc: Nishanth Menon n...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tero Kristo t-kri...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Reviewed-by: Nishanth Menon n...@ti.com -- 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
Re: [PATCH V2 2/2] Input: misc: introduce palmas-pwrbutton
Hi Dimtry, On 14:13-20140910, Dmitry Torokhov wrote: On Thu, Aug 21, 2014 at 02:01:43PM -0500, Nishanth Menon wrote: On 08/21/2014 01:03 PM, Dmitry Torokhov wrote: I believe I have taken care of other concerns on v2, but..Arrgh.. I did not reply to this comment.. BTW, I do not think you need to use of_node_get/put here, it's not going anywhere. It has been mentioned as a good practice to ensure we use get_put in to ensure reference count is appropriately maintained. So, I have'nt changed that in v3. You only need to maintain reference count if you pass the handle on. Otherwise you'd have to do get/put every time you dereference something. Anyway, I did a few changes to the driver (no need to store current state, do not fre einput device after unregister, etc.), could you please tell me if the version below still works for you? [...] Thanks for taking the time to do all the changes - they are awesome and the resultant driver does work. -- 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
OMAP4: suspend-resume broken when CPU_IDLE is disabled
Hi, This one is a little weird.. Thought I'd share before digging in case someone knew about this.. test scenario: use internal wakeup source like gptimer[1]. git checkout (tag) make distclean make omap2plus_defconfig sed -i -e s/CONFIG_CPU_IDLE=y/# CONFIG_CPU_IDLE is not set/g .config make oldconfig make zImage dtbs 3.17-rc4: (hangs on resume) (omap2plus CPUIDLE) pandaboard-es: http://paste.ubuntu.org.cn/1509229 pandaboard-vanilla: http://paste.ubuntu.org.cn/1509230 Purely with omap2plus_defconfig: (omap2plus no modification - works) pandaboard-es: http://paste.ubuntu.org.cn/1509613 pandaboard-vanilla: http://paste.ubuntu.org.cn/1509614 v3.16: pandaboard-es: http://paste.ubuntu.org.cn/1509291 pandaboard-vanilla: http://paste.ubuntu.org.cn/1509292 TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 v3.16-rc1: (first time CONFIG_CPU_IDLE was enabled by default in omapplus_defconfig): v3.15: same behavior. Have'nt stepped all the way to previous tags. I believe I see (I have to reconfirm) connecting once with JTAG while in suspend and letting the CPUs run lets the further runs work fine.. Did anyone see similar behavior or able to reproduce the behavior (and not just me)? [1] wget -O a.patch 'https://github.com/nmenon/linux-2.6-playground/commit/92e5e7407aa707ad6be8ae3b5bf21cfc741daab6.patch' ; git am a.patch -- 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
[PATCH] bus: omap_l3_noc: Fix connID for OMAP4
Commit d4d8819e205854c (bus: omap_l3_noc: fix masterid detection)
did the right thing in dropping the LSB 2 bits which is not part
of the ConnID for NTTP master address. However, as part of that
change, we should also have ensured that existing list of OMAP4 connID
codes are also shifted by 2 bits to ensure that connIDs map to Table
13-18. ConnID Values as provided in Technical Reference Manuals for
OMAP4430(Rev AP, April 2014, SWPU220AP) and OMAP4460(Rev AB, April
2014, SWPU234AB)
Fixes: d4d8819e205854c (bus: omap_l3_noc: fix masterid detection)
Reported-by: Kristian Otnes kot...@cisco.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on v3.17-rc1 - but might be 3.17 rc material
Quick links (seems to work on firefox):
4430:
http://www.ti.com/lit/ug/swpu231ap/swpu231ap.pdf#page=3030zoom=auto,0,699.5
4460:
http://www.ti.com/lit/ug/swpu235ab/swpu235ab.pdf#page=3073zoom=auto,0,699.5
NOTE: there are a few more cleanup patches that can follow these..
will leave those out for now.
drivers/bus/omap_l3_noc.h | 50 ++---
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 551e010..9525458 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -188,31 +188,31 @@ static struct l3_flagmux_data omap_l3_flagmux_clk3 = {
};
static struct l3_masters_data omap_l3_masters[] = {
- { 0x0 , MPU},
- { 0x10, CS_ADP},
- { 0x14, xxx},
- { 0x20, DSP},
- { 0x30, IVAHD},
- { 0x40, ISS},
- { 0x44, DucatiM3},
- { 0x48, FaceDetect},
- { 0x50, SDMA_Rd},
- { 0x54, SDMA_Wr},
- { 0x58, xxx},
- { 0x5C, xxx},
- { 0x60, SGX},
- { 0x70, DSS},
- { 0x80, C2C},
- { 0x88, xxx},
- { 0x8C, xxx},
- { 0x90, HSI},
- { 0xA0, MMC1},
- { 0xA4, MMC2},
- { 0xA8, MMC6},
- { 0xB0, UNIPRO1},
- { 0xC0, USBHOSTHS},
- { 0xC4, USBOTGHS},
- { 0xC8, USBHOSTFS}
+ { 0x00, MPU},
+ { 0x04, CS_ADP},
+ { 0x05, xxx},
+ { 0x08, DSP},
+ { 0x0C, IVAHD},
+ { 0x10, ISS},
+ { 0x11, DucatiM3},
+ { 0x12, FaceDetect},
+ { 0x14, SDMA_Rd},
+ { 0x15, SDMA_Wr},
+ { 0x16, xxx},
+ { 0x17, xxx},
+ { 0x18, SGX},
+ { 0x1C, DSS},
+ { 0x20, C2C},
+ { 0x22, xxx},
+ { 0x23, xxx},
+ { 0x24, HSI},
+ { 0x28, MMC1},
+ { 0x29, MMC2},
+ { 0x2A, MMC6},
+ { 0x2C, UNIPRO1},
+ { 0x30, USBHOSTHS},
+ { 0x31, USBOTGHS},
+ { 0x32, USBHOSTFS}
};
static struct l3_flagmux_data *omap_l3_flagmux[] = {
--
1.7.9.5
--
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 v2 1/2] ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7
On 09/10/2014 08:37 AM, Mugunthan V N wrote:
Add CPSW and MDIO related device tree data for DRA7XX and made as status
disabled. Phy-id, pinmux for active and sleep state needs to be added in
board dts files and enable the CPSW device.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 59
+
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152..8d79321 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ ethernet0 = cpsw_emac0;
+ ethernet1 = cpsw_emac1;
should this rather be in board dts?
};
timer {
@@ -1262,6 +1264,63 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ mac: ethernet@4a10 {
+ compatible = ti,cpsw;
+ ti,hwmods = gmac;
+ cpdma_channels = 8;
+ ale_entries = 1024;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
+ slaves = 2;
+ active_slave = 0;
+ cpts_clock_mult = 0x8000;
+ cpts_clock_shift = 29;
+ reg = 0x48484000 0x1000
+0x48485200 0x2E00;
+ #address-cells = 1;
+ #size-cells = 1;
+ /*
+ * rx_thresh_pend
+ * rx_pend
+ * tx_pend
+ * misc_pend
+ */
+ interrupts = GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH;
+ ranges;
+ status = disabled;
+
+ davinci_mdio: mdio@48485000 {
+ compatible = ti,davinci_mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = davinci_mdio;
+ bus_freq = 100;
+ reg = 0x48485000 0x100;
+ };
+
+ cpsw_emac0: slave@48480200 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
should be disabled? what about platforms that do not have both emac ports?
+ };
+
+ cpsw_emac1: slave@48480300 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
should be disabled? what about platforms that do not have both emac ports?
+ };
+
+ phy_sel: cpsw-phy-sel@4a002554 {
+ compatible = ti,dra7xx-cpsw-phy-sel;
+ reg= 0x4a002554 0x4;
+ reg-names = gmii-sel;
+ };
+ };
+
};
};
--
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
Re: [PATCH v2 2/2] ARM: dts: dra7-evm: Enable CPSW and MDIO for dra7xx EVM
; + pinctrl-0 = davinci_mdio_default; + pinctrl-1 = davinci_mdio_sleep; +}; -- 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
Re: [PATCH v2 0/2] Add DRA7xx CPSW Ethernet support in Device Tree
On 09/10/2014 08:37 AM, Mugunthan V N wrote: Adding device tree entry for CPSW to make it work in Dual EMAC mode. These patches were tested with DRA7 hwmod patches on top of linux-next. Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed my tree to [2]. Did a boot test with CPSW and ping test with suspend/resume, the boot logs on DRA7xx EVM are posted at [3] [1] git://github.com/nmenon/linux-2.6-playground.git testing/v3.17/cpu-idle-suspend-dra7-omap5-framework [2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git v3.17/dra7-evm-cpsw [3] http://pastebin.ubuntu.com/8309289/ Changes from initial version: * Dropped patch for pinoff states * Changed pinoff state to mode15 Mugunthan V N (2): ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7 ARM: dts: dra7-evm: Enable CPSW and MDIO for dra7xx EVM arch/arm/boot/dts/dra7-evm.dts | 107 + arch/arm/boot/dts/dra7.dtsi| 59 +++ 2 files changed, 166 insertions(+) I did apply these on Tony's omap-for-v3.18/dt 6e55426 Merge branch .. they do apply. However: why are we not sending dra72-evm.dts changes in the same series since we claim it to be dra7xx support? Also, in your tests (http://pastebin.ubuntu.com/8309289/) echo -n 20/sys/kernel/debug/pm_debug/wakeup_timer_seconds ping 172.24.188.1 (or even better do a transfer of large file in background) echo mem /sys/power/state transfer/ping should resume seamlessly. (only thing you should be careful is that the server should not timeout for 20 second inactivity).. It is a valid test to verify peripheral activity after resume, BUT, equally important is to verify suspend-resume in the middle of activity. -- 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
Re: 3.15+: omap4: mmc: multi_v7: can't boot off mmc
On 17:33-20140910, Paolo Pisati wrote: I'm having an hard time making the vanilla v7_defconfig boot off the mmc on my pandaboard: V3.15: https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-vanilla.txt https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-es.txt v3.16: https://github.com/nmenon/kernel-test-logs/blob/v3.16/multi_v7_defconfig/pandaboard-es.txt https://github.com/nmenon/kernel-test-logs/blob/v3.16/multi_v7_defconfig/pandaboard-vanilla.txt Latest tag: v3.17-rc4 https://github.com/nmenon/kernel-test-logs/blob/v3.17-rc4/multi_v7_defconfig/pandaboard-es.txt https://github.com/nmenon/kernel-test-logs/blob/v3.17-rc4/multi_v7_defconfig/pandaboard-vanilla.txt You might be interested in using partuuid to be careful about the probe order deltas that may take place. -- 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
Re: [PATCH v3 0/3] OMAP4+: Get rid of internal SRAM handling
On 11:04-20140910, Dave Gerlach wrote: v3: Fix minor issue in last patch to check for null sram_pool if no sram phandle is given in DT. Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) use drivers/misc/sram.c driver instead of the omap internal implementation for SRAM handling. Previous discussion can be found at [1]. Regards, Dave [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/195588.html Rajendra Nayak (3): ARM: AM335x: Get rid of unused sram init function ARM: OMAP4+: Move SRAM data to DT ARM: OMAP4+: Remove static iotable mappings for SRAM Documentation/devicetree/bindings/arm/omap/mpu.txt | 3 ++ arch/arm/boot/dts/am33xx.dtsi | 5 ++- arch/arm/boot/dts/am4372.dtsi | 5 +++ arch/arm/boot/dts/omap4.dtsi | 6 arch/arm/boot/dts/omap5.dtsi | 8 - arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-omap2/io.c | 17 -- arch/arm/mach-omap2/omap4-common.c | 22 +++- arch/arm/mach-omap2/sram.c | 39 +- arch/arm/mach-omap2/sram.h | 7 10 files changed, 46 insertions(+), 67 deletions(-) Could you please provide logs for the following: a) Low power transition tests for OMAP3,4 on all available platforms as well? b) provide bootlogs on all omap2plus platforms to ensure we have no regressions. -- 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
Re: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
On Tue, Sep 9, 2014 at 6:29 AM, Mugunthan V N mugunthan...@ti.com wrote: Sorry this is now blocked inside TI. could you explain the testing done for sleep state? did you attempt sleep mode before testing this? I have not tested sleep mode, just tested boot and ping test. I must NAK then for the reason that this is a patch that is just build tested and is not tested for the feature it claims to introduce. -- --- 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
Re: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
On 09/09/2014 07:56 AM, Mugunthan V N wrote: On Tuesday 09 September 2014 05:45 PM, Nishanth Menon wrote: On Tue, Sep 9, 2014 at 6:29 AM, Mugunthan V N mugunthan...@ti.com wrote: Sorry this is now blocked inside TI. could you explain the testing done for sleep state? did you attempt sleep mode before testing this? I have not tested sleep mode, just tested boot and ping test. I must NAK then for the reason that this is a patch that is just build tested and is not tested for the feature it claims to introduce. Is suspend/resume supported in mainline, i was not able to test it. root@dra7xx-evm:~# echo mem /sys/power/state -sh: echo: write error: Invalid argument I was not able to use rtc wake also as the rtc device is not created. Right.. that is why I was curious how you posted a patch that supposedly supports sleep pin configurations in a kernel that does not support suspend-resume? Hopefully we will have it supported in 3.18 kernel[1] - still need out of tree wakeup timer patch[2] for testing though.. If you have at least tested on relevant branch which has the feature expected for 3.18, I might still be OK with the patch. [1]http://marc.info/?l=linux-kernelm=141019565513129w=2 and http://marc.info/?l=linux-kernelm=141019566913133w=2 [2] details in http://marc.info/?l=linux-kernelm=140871637106555w=2 -- 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
[GIT PULL] ARM: dts: OMAP5 / DRA7: pinctrl updates
Hi Tony, Please pull this series was posted[1] and based on the previous pulls [2] [3], updating the dts to enable the relevant feature. NOTE: I have dropped patch #1 of the series based on [4]. These could go to your branch omap-for-v3.18/dt The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-dt-pinctrl-updates for you to fetch changes up to 66b0436977e2c62388d48836ff784f1fedb49c4f: ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable (2014-09-09 08:33:29 -0500) Nishanth Menon (5): ARM: dts: OMAP5: switch to compatible pinctrl ARM: dts: DRA7: switch to compatible pinctrl ARM: dts: AM437x: switch to compatible pinctrl ARM: dts: OMAP5 / DRA7: switch over to interrupts-extended property for UART ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable arch/arm/boot/dts/am4372.dtsi |4 +++- arch/arm/boot/dts/dra7-evm.dts |2 ++ arch/arm/boot/dts/dra7.dtsi| 24 +--- arch/arm/boot/dts/omap5.dtsi | 20 4 files changed, 30 insertions(+), 20 deletions(-) [1] http://marc.info/?l=linux-kernelm=140871681606779w=2 [2] http://marc.info/?l=linux-kernelm=141019565513129w=2 [3] http://marc.info/?l=linux-kernelm=141019566913133w=2 [4] http://marc.info/?l=linux-omapm=141022429924564w=2 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
Re: [PATCH v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 09:31 AM, Roger Quadros wrote:
Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti().
They seem to have been swapped in the usage instances.
TI's RAMINIT DONE mechanism is buggy and may not always be
set after the START bit is set. So add a timeout mechanism to
c_can_hw_raminit_wait_ti().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can_platform.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 109cb44..b144e71 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -75,10 +75,18 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
u32 val)
{
+ int timeout = 0;
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val)
+ while ((readl(priv-raminit_ctrlreg) mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
How did we come up with this number?
+ dev_err(priv-dev-dev, %s: time out\n, __func__);
+ break;
lets say we did timeout..
see below:
+ }
+ }
}
static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
@@ -97,14 +105,14 @@ static void c_can_hw_raminit_ti(const struct c_can_priv
*priv, bool enable)
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl = ~CAN_RAMINIT_DONE_MASK(priv-instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
if (enable) {
/* Set start bit and wait for the done bit. */
ctrl |= CAN_RAMINIT_START_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
is it possible for us to continue? does it make sense for us to change
that void to a int and handle error cascading?
}
spin_unlock(raminit_lock);
}
--
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
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
CONFIG_COMPILE_TEST
+extern int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch);
+extern void omap_free_dma(int ch);
+extern void omap_start_dma(int lch);
+extern void omap_stop_dma(int lch);
+extern void omap_set_dma_transfer_params(int lch, int data_type,
+ int elem_count, int frame_count,
+ int sync_mode,
+ int dma_trigger, int src_or_dst_synch);
+extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
+ unsigned long src_start,
+ int src_ei, int src_fi);
+extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
+ unsigned long dest_start,
+ int dst_ei, int dst_fi);
+extern void omap_set_dma_dest_burst_mode(int lch,
+ enum omap_dma_burst_mode burst_mode);
+extern void omap_dma_link_lch(int lch_head, int lch_queue);
+
+#ifndef CONFIG_ARCH_OMAP1
+extern int omap_request_dma_chain(int dev_id, const char *dev_name,
+ void (*callback) (int lch, u16 ch_status,
+ void *data),
+ int *chain_id, int no_of_chans,
+ int chain_mode,
+ struct omap_dma_channel_params params);
+extern int omap_free_dma_chain(int chain_id);
+extern int omap_start_dma_chain_transfers(int chain_id);
+extern int omap_stop_dma_chain_transfers(int chain_id);
+#endif /* CONFIG_ARCH_OMAP1 */
+#else
+ /* Stubs for compile testing some drivers on other archs */
+
+static inline
+int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch) { return 0; }
+
+static inline void omap_free_dma(int ch) {}
+static inline void omap_start_dma(int lch) {}
+static inline void omap_stop_dma(int lch) {}
+
+static inline
+void omap_set_dma_transfer_params(int lch, int data_type,
+ int elem_count, int frame_count,
+ int sync_mode,
+ int dma_trigger, int src_or_dst_synch) {}
+
+static inline
+void omap_set_dma_src_params(int lch, int src_port, int src_amode,
+ unsigned long src_start,
+ int src_ei, int src_fi) {}
+
+static inline
+void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
+ unsigned long dest_start,
+ int dst_ei, int dst_fi) {}
+
+static inline
+void omap_set_dma_dest_burst_mode(int lch,
+ enum omap_dma_burst_mode burst_mode) {}
+
+static inline
+void omap_dma_link_lch(int lch_head, int lch_queue) {}
+
+static inline
+int omap_request_dma_chain(int dev_id, const char *dev_name,
+void (*callback) (int lch, u16 ch_status,
+ void *data),
+int *chain_id, int no_of_chans,
+int chain_mode,
+struct omap_dma_channel_params params) { return 0; }
+
+static inline int omap_free_dma_chain(int chain_id) { return 0; }
+static inline int omap_start_dma_chain_transfers(int chain_id) { return 0; }
+static inline int omap_stop_dma_chain_transfers(int chain_id) { return 0; }
+
+#endif /* CONFIG_COMPILE_TEST */
+
#if defined(CONFIG_ARCH_OMAP1) IS_ENABLED(CONFIG_FB_OMAP)
#include mach/lcd_dma.h
#else
--
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
Re: [PATCH v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 09:45 AM, Roger Quadros wrote:
[...]
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val)
+ while ((readl(priv-raminit_ctrlreg) mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
How did we come up with this number?
wild guess ;), that it should be set in a few microseconds and the delay is
not too
large.
Till I don't hear from hardware guys, it will remain a guess.
in cases like these, I suggest using emperical data as point -
example doing some 10,000 iterations of the operation and picking up
the worse case number and double it.
Either way, you need to document the same, else a few years down the
line, when that number is in question, no one will know what it's
basis was..
--
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
[PATCH] ARM: OMAP5+: Reuse OMAP4 PM code for OMAP5 and DRA7
OMAP4, OMAP5 and DRA7 share a lot of common logic and data structures. These have been enabled in the previous patches, however, this also means that OMAP5 or DRA7 only builds also need to build OMAP4 logic. Update to reuse OMAP4 logic. This fixes the 'undefined reference to 'omap4_pm_init_early'' in OMAP5 or DRA7 only builds. Fixes: 6af16a1dac5465c (ARM: DRA7: Add hook in SoC initcalls to enable pm initialization) Fixes: 628ed4717000789 (ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization) Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- This fixes the regression with randconfig that Tony reported with omap-for-v3.18/soc branch. Tested with CONFIG_ARCH_OMAP2, CONFIG_ARCH_OMAP3, CONFIG_ARCH_OMAP4, CONFIG_SOC_OMAP5, CONFIG_SOC_AM33XX, CONFIG_SOC_AM43XX, CONFIG_SOC_DRA7XX only builds. arch/arm/mach-omap2/Makefile | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 69bbcba..d9dd99c 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -87,9 +87,10 @@ ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o -obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o -obj-$(CONFIG_SOC_DRA7XX) += omap-mpuss-lowpower.o +omap-4-5-pm-common = pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common) +obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-pm-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-pm-common) obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o @@ -102,7 +103,10 @@ endif ifeq ($(CONFIG_CPU_IDLE),y) obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o -obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o +omap-4-5-idle-common = cpuidle44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-idle-common) +obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-idle-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-idle-common) endif # PRCM -- 1.7.9.5 -- 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 V2 3/3] mfd: palmas: Add support for optional wakeup
On 23:13-20140905, Thomas Gleixner wrote:
On Fri, 5 Sep 2014, Nishanth Menon wrote:
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+ palmas_wake_irq,
+ IRQF_ONESHOT | pdata-irq_flags,
Why is this marked IRQF_ONESHOT?
Uggh.. should have dropped it. my bad.. removed in the revision below.
Thanks for catching it.
+ dev_name(palmas-dev),
+ palmas);
+ if (ret 0)
+ goto err_i2c;
Why err and not doing the obvious clearing of palmas-wakeirq and
keep at least the i2c functional?
Hmmm.. true.. we can stay alive even though without wakeup capability if
someone messes up configuration..
Fixed version below. Let me know if you are ok with the following.
8
From 6da58ac66eedea46cf7282c6644c76c8f328f5ee Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 12 Aug 2014 12:00:52 -0500
Subject: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power states as interrupts.
This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the actual event during
system active state). This is not the same as threaded interrupts as the
wakeup interrupt source is used only as part of deeper power saving
mode.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/mfd/palmas.c | 62
include/linux/mfd/palmas.h |2 ++
2 files changed, 64 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..de7d204 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+* Return Not handled so that interrupt is disabled.
+* Level event ensures that the event is eventually handled
+* by the appropriate chip handler already registered
+*/
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+ pdata-wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+ palmas-wakeirq = pdata-wakeirq;
match = of_match_device(of_palmas_match_tbl, i2c-dev);
@@ -587,6 +600,25 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err_i2c;
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+ palmas_wake_irq,
+ pdata-irq_flags,
+ dev_name(palmas-dev),
+ palmas);
+ if (ret 0) {
+ dev_err(palmas-dev, Invalid wakeirq(%d) (res: %d), skiping\n,
+ palmas-wakeirq, ret);
+ palmas-wakeirq = 0;
+ } else {
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas-dev, true);
+ disable_irq_nosync(palmas-wakeirq);
+ }
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +738,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(palmas-wakeirq);
+
+ return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c
Re: [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle
On 08/27/2014 02:15 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: The following series are various fixes and improvements for supporting suspend-to-ram. This depends on the following for basic functionality: series 1/6 where powerdomain fixes were involved. I had a look through this series, and it looks good overall. I think Daniel needs to weigh in on the CPUidle driver, otherwise. Reviewed-by: Kevin Hilman khil...@linaro.org I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch. Tested-by: Kevin Hilman khil...@linaro.org Kevin I am dropping cpuidle patch for the moment, and sending remaining stuff to Tony for merge with Kevin's Reviewed and Tested. we will send cpuidle once we have Daniel's response. -- 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
Re: [PATCH 0/3] ARM: OMAP5+: pdata quirks for pinctrl
On 08/22/2014 08:55 AM, Nishanth Menon wrote: The following series are various fixes and improvements for daisychain support in OMAP5+ using pinctrl framework similar to that done for OMAP3+ This is part 3/6 series which eventually enables framework for suspend-to-ram and cpuidle for OMAP5 and DRA7 Each of series is based on v3.17-rc1 and this specific series is available: weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/prm-pdata-quirks git repo: https://github.com/nmenon/linux-2.6-playground.git push/v3.17/prm-pdata-quirks An complete integrated branch is available here: https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework Minor note: thanks to existing style in pdata-quirks, new entries continue to possess 'over 80 character' checkpatch warnings Keerthy (1): ARM: AM437x: use pdata quirks for pinctrl information Nishanth Menon (2): ARM: OMAP5: use pdata quirks for pinctrl information ARM: DRA7: use pdata quirks for pinctrl information arch/arm/mach-omap2/pdata-quirks.c | 10 ++ 1 file changed, 10 insertions(+) Since there are no further comments (and the pinctrl side of the fixes were accepted by Linus W[1], will send this for merge to Tony. [1] http://marc.info/?l=linux-kernelm=140871666506706w=2 (acked by Tony, picked by Linus) -- 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
[GIT PULL 1/2] ARM: OMAP 4+: powerdomain fixes
Hi Tony, Please pull the following changes. Series discussed in: http://marc.info/?l=linux-kernelm=140871554106082w=2 Includes (v2 patch) https://patchwork.kernel.org/patch/4790541/ Status: Acked by Santosh and Reviewed-by Kevin These could go into your tree for the branch omap-for-v3.18/fixes-not-urgent The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/powerdomain-fixes for you to fetch changes up to 3e6a1c945950140926dd6e2cc667893de0a7fe3b: ARM: OMAP4+: PM: Use only valid low power state for CPU hotplug (2014-09-08 11:22:43 -0500) Nishanth Menon (7): ARM: OMAP: DRA7: powerdomain data: fix powerdomain powerstate ARM: OMAP5: powerdomain data: fix powerdomain powerstate ARM: OMAP2+: powerdomain: pwrdm_for_each_clkdm iterate only valid clkdms ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain ARM: OMAP4+: PM: Make logic state programmable ARM: OMAP4+: PM: use only valid low power state for suspend ARM: OMAP4+: PM: Use only valid low power state for CPU hotplug arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 ++ arch/arm/mach-omap2/pm44xx.c|9 ++- arch/arm/mach-omap2/powerdomain.c | 79 ++- arch/arm/mach-omap2/powerdomain.h |4 ++ arch/arm/mach-omap2/powerdomains54xx_data.c | 12 ++-- arch/arm/mach-omap2/powerdomains7xx_data.c | 14 ++--- 6 files changed, 106 insertions(+), 16 deletions(-) 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
[GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support
Hi Tony, Please pull the following changes. part 2: ARM: OMAP3+: PRM: fix up prm_handling http://marc.info/?l=linux-kernelm=140871580806186w=2 Status: Acked-by: Santosh Shilimkar santosh.shilim...@ti.com part 3: ARM: OMAP5+: pdata quirks for pinctrl http://marc.info/?l=linux-kernelm=140871598306262w=2 Status: Sending pull based on http://marc.info/?l=linux-kernelm=140871666506706w=2 (Acked by Tony, Pulled by Linus W) part 5: ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle http://marc.info/?l=linux-kernelm=140871637106555w=2 Status: picked up kevin's tested and reviewed-by, dropped cpuidle for this pull These could go into your tree for the branch omap-for-v3.18/soc The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-omap-soc for you to fetch changes up to 628ed4717000789bff827c5799d1aac4c1008541: ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization (2014-09-08 11:38:43 -0500) Keerthy (1): ARM: AM437x: use pdata quirks for pinctrl information Nishanth Menon (8): ARM: OMAP4+: prminst: provide function to find prm_dev instance offset ARM: OMAP4: PRM: use the generic prm_inst to allow logic to be abstracted ARM: OMAP4+: PRM: register interrupt information from DT ARM: OMAP4+: PRM: remove wkup event ARM: OMAP4+: PRM: Enable wakeup capability for OMAP5, DRA7 ARM: OMAP3+: PRM: register interrupt information from DT ARM: OMAP5: use pdata quirks for pinctrl information ARM: DRA7: use pdata quirks for pinctrl information Rajendra Nayak (2): ARM: OMAP5 / DRA7: PM: Avoid all SAR saves ARM: OMAP5 / DRA7: Enable CPU RET on suspend Santosh Shilimkar (6): ARM: OMAP5 / DRA7: PM: Update CPU context register offset ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx powerdomains ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU hotplug ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization arch/arm/mach-omap2/common.h |2 +- arch/arm/mach-omap2/io.c |3 + arch/arm/mach-omap2/omap-mpuss-lowpower.c | 102 - arch/arm/mach-omap2/omap-secure.h |1 + arch/arm/mach-omap2/omap-wakeupgen.c | 20 +- arch/arm/mach-omap2/omap-wakeupgen.h |1 + arch/arm/mach-omap2/pdata-quirks.c| 10 +++ arch/arm/mach-omap2/pm.h |1 + arch/arm/mach-omap2/pm44xx.c | 48 -- arch/arm/mach-omap2/prm3xxx.c | 18 + arch/arm/mach-omap2/prm44xx.c | 90 + arch/arm/mach-omap2/prminst44xx.c | 40 ++- arch/arm/mach-omap2/prminst44xx.h |3 + 13 files changed, 275 insertions(+), 64 deletions(-) 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
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On 20:23-20140908, Grazvydas Ignotas wrote: On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon n...@ti.com wrote: Hi, Updated patch below: Do let me know if this is ok with folks. ---8 From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001 From: Rajendra Nayak rna...@ti.com Date: Mon, 27 May 2013 15:46:44 +0530 Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR and instead attempt a CPU RET and side effect, MPU RET in suspend. NOTE: the hardware was originally designed to be capable of achieving deep power states such as OFF and OSWR, however due to various issues and risks, deepest valid state was determined to be CSWR - hence we use Would be great to have some more details here.. Sorry, I have no details that can be published publically. Lets say, TI refocus? So there is no hope for OFF mode on OMAP5? Yep, There is *NO* hope for OFF or OSWR on OMAP5/DRA7. -- 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
Re: [PATCH 6/6] ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable
On 09:03-20140822, Nishanth Menon wrote:
status = okay;
pinctrl-names = default;
pinctrl-0 = uart1_pins;
+ interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH
+dra7_pmx_core 0x3e0;
^^
Thanks to Lee Jones pointing this out to me in a different context[1]
I made the wrong usage. Fixing the syntax to stay in sync with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1] http://marc.info/?l=linux-omapm=140930980325273w=2
-8
From c3c284ebd2b8d5535abf297ef7537b2caa7fe67b Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Fri, 6 Jun 2014 20:53:22 -0500
Subject: [PATCH V2 6/6] ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable
Mark rxd as wakeupcapable for 115200n8 no hardware-flow control
configuration. If h/w flow control is being used, then rts/cts
appropriately should be used.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..08434c7 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -303,6 +303,8 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = uart1_pins;
+ interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH,
+ dra7_pmx_core 0x3e0;
};
uart2 {
--
1.7.9.5
--
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
Re: [resend PATCH 1/3] pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC
On 00:49-20140909, Mugunthan V N wrote: Add pin off modes for dra7 SoC so that during module disable or suspend state it can help saving power Signed-off-by: Mugunthan V N mugunthan...@ti.com --- include/dt-bindings/pinctrl/dra.h | 8 1 file changed, 8 insertions(+) diff --git a/include/dt-bindings/pinctrl/dra.h b/include/dt-bindings/pinctrl/dra.h index 002a285..a0ff2d0 100644 --- a/include/dt-bindings/pinctrl/dra.h +++ b/include/dt-bindings/pinctrl/dra.h @@ -46,5 +46,13 @@ #define PIN_INPUT_PULLUP (PULL_ENA | INPUT_EN | PULL_UP) #define PIN_INPUT_PULLDOWN (PULL_ENA | INPUT_EN) +/* Off mode states */ +#define PIN_OFF_NONE 0 +#define PIN_OFF_OUTPUT_HIGH (OFF_EN | OFFOUT_EN | OFFOUT_VAL) +#define PIN_OFF_OUTPUT_LOW (OFF_EN | OFFOUT_EN) +#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFF_PULL_EN | OFF_PULL_UP) +#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN) +#define PIN_OFF_WAKEUPENABLE WAKEUP_EN + #endif NAK for OFF_NONE, OFF_xyz etc. A) There is no OFF mode on DRA7. in sleep state use mode 15 (gated). B) when using this for wakeup - use pinctrl wakeup handling to do the wakeup. 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
Re: [resend PATCH 3/3] arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM
On 00:49-20140909, Mugunthan V N wrote:
Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active and
sleep states and enable them in board evm dts file.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 107
+
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index fd96ced..57e69c4 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,6 +151,87 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
;
};
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x250 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tclk */
+ 0x254 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tctl */
+ 0x258 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td3 */
+ 0x25c (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td2 */
+ 0x260 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td1 */
+ 0x264 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td0 */
+ 0x268 (PIN_INPUT | MUX_MODE0) /* rgmii1_rclk */
+ 0x26c (PIN_INPUT | MUX_MODE0) /* rgmii1_rctl */
+ 0x270 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd3 */
+ 0x274 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd2 */
+ 0x278 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd1 */
+ 0x27c (PIN_INPUT | MUX_MODE0) /* rgmii1_rd0 */
+
+ /* Slave 2 */
+ 0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
+ 0x19c (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tctl */
+ 0x1a0 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td3 */
+ 0x1a4 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td2 */
+ 0x1a8 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td1 */
+ 0x1ac (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td0 */
+ 0x1b0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rclk */
+ 0x1b4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rctl */
+ 0x1b8 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd3 */
+ 0x1bc (PIN_INPUT | MUX_MODE3) /* rgmii2_rd2 */
+ 0x1c0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd1 */
+ 0x1c4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd0 */
+ ;
+
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x250 (PIN_OFF_NONE)
+ 0x254 (PIN_OFF_NONE)
+ 0x258 (PIN_OFF_NONE)
+ 0x25c (PIN_OFF_NONE)
+ 0x260 (PIN_OFF_NONE)
+ 0x264 (PIN_OFF_NONE)
+ 0x268 (PIN_OFF_NONE)
+ 0x26c (PIN_OFF_NONE)
+ 0x270 (PIN_OFF_NONE)
+ 0x274 (PIN_OFF_NONE)
+ 0x278 (PIN_OFF_NONE)
+ 0x27c (PIN_OFF_NONE)
+
+ /* Slave 1 */
+ 0x198 (PIN_OFF_NONE)
+ 0x19c (PIN_OFF_NONE)
+ 0x1a0 (PIN_OFF_NONE)
+ 0x1a4 (PIN_OFF_NONE)
+ 0x1a8 (PIN_OFF_NONE)
+ 0x1ac (PIN_OFF_NONE)
+ 0x1b0 (PIN_OFF_NONE)
+ 0x1b4 (PIN_OFF_NONE)
+ 0x1b8 (PIN_OFF_NONE)
+ 0x1bc (PIN_OFF_NONE)
+ 0x1c0 (PIN_OFF_NONE)
+ 0x1c4 (PIN_OFF_NONE)
+ ;
+ };
NAK to sleep states - you should be using mode 15 if you really want to
save power.
--
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
Re: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
On 00:49-20140909, Mugunthan V N wrote: Adding device tree entry for CPSW to make it work in Dual EMAC mode. These patches were tested with DRA7 hwmod patches on top of linux-next. The patches were already reviewed [1] and has been waiting for cross bar and hwmod to be pulled in. Now since all dependent patches has already pulled in, so reposting the patches again. Patches are tested on linux-next, the boot logs on DRA7xx EVM [2] [1] https://lkml.org/lkml/2014/5/13/89 [2] http://slexy.org/view/s2YqO0Wj9b Sorry this is now blocked inside TI. could you explain the testing done for sleep state? did you attempt sleep mode before testing this? Mugunthan V N (3): pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM arch/arm/boot/dts/dra7-evm.dts| 107 ++ arch/arm/boot/dts/dra7.dtsi | 59 + include/dt-bindings/pinctrl/dra.h | 8 +++ 3 files changed, 174 insertions(+) -- 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
Re: [PATCH 0/2] ARM: dts: dra72-evm: Add i2c1 and tps65917 nodes
On 18:05-20140812, Keerthy wrote: On Monday 28 July 2014 02:52 PM, Keerthy wrote: On Monday 28 July 2014 12:00 PM, Lokesh Vutla wrote: On Monday 28 July 2014 11:48 AM, Keerthy wrote: The patch series adds i2c1 and tps65917 and related nodes. The patch series is boot tested on DRA72-EVM. Thanks to Lokesh lokeshvu...@ti.com for testing the series. Correcting the 'to' list. Hi Tony, If there are no comments could you please pull these two patches? With 3.17-rc4, I tested this series: dra72-evm-before: http://paste.ubuntu.org.cn/1496342 dra72-evm-after: http://paste.ubuntu.org.cn/1496341 Patches: https://patchwork.kernel.org/patch/4632391/ https://patchwork.kernel.org/patch/4632421/ Could we pick these with 3.18? Please free to add: Tested-by: Nishanth Menon n...@ti.com -- 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
Re: [GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support
On 15:32-20140908, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [140908 10:02]: Hi Tony, Please pull the following changes. part 2: ARM: OMAP3+: PRM: fix up prm_handling http://marc.info/?l=linux-kernelm=140871580806186w=2 Status: Acked-by: Santosh Shilimkar santosh.shilim...@ti.com part 3: ARM: OMAP5+: pdata quirks for pinctrl http://marc.info/?l=linux-kernelm=140871598306262w=2 Status: Sending pull based on http://marc.info/?l=linux-kernelm=140871666506706w=2 (Acked by Tony, Pulled by Linus W) part 5: ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle http://marc.info/?l=linux-kernelm=140871637106555w=2 Status: picked up kevin's tested and reviewed-by, dropped cpuidle for this pull These could go into your tree for the branch omap-for-v3.18/soc The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-omap-soc Thanks pulling into omap-for-v3.18/soc. Tony, Apologies, I missed the last patch in the series: https://patchwork.kernel.org/patch/4765011/ If you could cherry-pick the same with Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org based on Kevin's feedback: http://marc.info/?l=linux-arm-kernelm=140916701909122w=2 -- 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
Re: [GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support
On 15:51-20140908, Tony Lindgren wrote: [...] are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-omap-soc Thanks pulling into omap-for-v3.18/soc. Tony, Apologies, I missed the last patch in the series: https://patchwork.kernel.org/patch/4765011/ If you could cherry-pick the same with Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org based on Kevin's feedback: http://marc.info/?l=linux-arm-kernelm=140916701909122w=2 OK no problem, will apply into omap-for-v3.18/soc. Thanks Tony. Apologies on the trouble :( -- 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
Re: [PATCH] ARM: omap: Remove stray ARCH_HAS_OPP references
On 09/06/2014 05:14 AM, Mark Brown wrote: OPP is now a normal kernel library selected by its users rather than a feature that architectures need to enable so ARCH_HAS_OPP serves no function any more - remove the selects. Signed-off-by: Mark Brown broo...@kernel.org --- arch/arm/mach-omap2/Kconfig | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index e7189dcc9309..11ccf0b4e5c2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -25,7 +25,6 @@ config ARCH_OMAP4 bool TI OMAP4 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP select ARM_CPU_SUSPEND if PM select ARM_ERRATA_720789 @@ -44,7 +43,6 @@ config SOC_OMAP5 bool TI OMAP5 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_SCU if SMP @@ -56,14 +54,12 @@ config SOC_AM33XX bool TI AM33XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM config SOC_AM43XX bool TI AM43x depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_GIC select MACH_OMAP_GENERIC select MIGHT_HAVE_CACHE_L2X0 @@ -72,7 +68,6 @@ config SOC_DRA7XX bool TI DRA7XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_ARCH_TIMER Acked-by: Nishanth Menon n...@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 v2 1/2] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants
On 09/05/2014 01:08 PM, Paul Walmsley wrote: [...] In the meanwhile, we will try to provide test logs that you may desire for at least the platforms we have functioning and access to. please feel free to request specific test vectors if you feel our coverage is not good enough. Thanks. You've been showing a lot of great leadership in proactively posting test logs. What I'd suggest doing is to keep that up, and if possible, post one of the test reports for each patch series that's posted, if possible. I do have automated scripts verifying various defconfigs on a daily basis for linux-next and master tags.. https://github.com/nmenon/kernel-test-logs/ (based on each tag). Every TI engineer does have access to these platforms as well as I do. Realistically, few platforms do go offline and online as time goes on. we will try to post test reports for each series as much as our TI policies let us. -- 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
[RESEND PATCH] gpio: omap: Fix interrupt names
When viewing the /proc/interrupts, there is no information about which
GPIO bank a specific gpio interrupt is hooked on to. This is more than a
bit irritating as such information can esily be provided back to the
user and at times, can be crucial for debug.
So, instead of displaying something like:
31: 0 0 GPIO 0 palmas
32: 0 0 GPIO 27 mmc0
Display the following with appropriate device name:
31: 0 0 4ae1.gpio 0 palmas
32: 0 0 4805d000.gpio 27 mmc0
This requires that we create irq_chip instance specific for each GPIO
bank which is trivial to achieve.
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Kevin Hilman khil...@linaro.org
---
Requested to be resend by Javier with linux-gpio maintainers in CC.
Original V1 of the patch: https://patchwork.kernel.org/patch/4757891/
Probably belongs to 3.18 kernel series at this point in time.
Changes since v1: just picked up Acks.
V1: https://patchwork.kernel.org/patch/4757891/
based on v3.17-rc1
drivers/gpio/gpio-omap.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 1749321..aee25fa 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -857,16 +857,6 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
spin_unlock_irqrestore(bank-lock, flags);
}
-static struct irq_chip gpio_irq_chip = {
- .name = GPIO,
- .irq_shutdown = omap_gpio_irq_shutdown,
- .irq_ack= omap_gpio_ack_irq,
- .irq_mask = omap_gpio_mask_irq,
- .irq_unmask = omap_gpio_unmask_irq,
- .irq_set_type = omap_gpio_irq_type,
- .irq_set_wake = omap_gpio_wake_enable,
-};
-
/*-*/
static int omap_mpuio_suspend_noirq(struct device *dev)
@@ -1088,7 +1078,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int
irq_start,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
-static int omap_gpio_chip_init(struct gpio_bank *bank)
+static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc)
{
int j;
static int gpio;
@@ -1137,7 +1127,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
}
#endif
- ret = gpiochip_irqchip_add(bank-chip, gpio_irq_chip,
+ ret = gpiochip_irqchip_add(bank-chip, irqc,
irq_base, omap_gpio_irq_handler,
IRQ_TYPE_NONE);
@@ -1147,7 +1137,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
return -ENODEV;
}
- gpiochip_set_chained_irqchip(bank-chip, gpio_irq_chip,
+ gpiochip_set_chained_irqchip(bank-chip, irqc,
bank-irq, omap_gpio_irq_handler);
for (j = 0; j bank-width; j++) {
@@ -1172,6 +1162,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
const struct omap_gpio_platform_data *pdata;
struct resource *res;
struct gpio_bank *bank;
+ struct irq_chip *irqc;
int ret;
match = of_match_device(of_match_ptr(omap_gpio_match), dev);
@@ -1186,6 +1177,18 @@ static int omap_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ irqc = devm_kzalloc(dev, sizeof(*irqc), GFP_KERNEL);
+ if (!irqc)
+ return -ENOMEM;
+
+ irqc-irq_shutdown = omap_gpio_irq_shutdown,
+ irqc-irq_ack = omap_gpio_ack_irq,
+ irqc-irq_mask = omap_gpio_mask_irq,
+ irqc-irq_unmask = omap_gpio_unmask_irq,
+ irqc-irq_set_type = omap_gpio_irq_type,
+ irqc-irq_set_wake = omap_gpio_wake_enable,
+ irqc-name = dev_name(pdev-dev);
+
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
dev_err(dev, Invalid IRQ resource\n);
@@ -1241,7 +1244,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_gpio_mod_init(bank);
- ret = omap_gpio_chip_init(bank);
+ ret = omap_gpio_chip_init(bank, irqc);
if (ret)
return ret;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/3] Documentation: dt-bindings: mfd: palmas: document optional wakeup IRQ
With the recent pinctrl-single changes, SoCs such as OMAP family can
treat wake-up events from deeper low power states as interrupts.
This is usable when the wakeup from deeper low power states is
triggered by a different hardware mechanism tied to pinctrl compared
to the routine interrupt handling generating the reqular interrupt
events. This is usually done on SoCs where the routine interrupt
sources such as GPIO need to be disabled to be actually achieve low
power state and wakeup is triggered from pinctrl interrupt source.
Provide documentation example for the case where the system needs two
interrupt sources when SoC is in deep sleep(1 to exit from deep sleep,
and other from the module handling the actual event).
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index d193859..1c821d6 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -51,3 +51,23 @@ palmas@48 {
};
}
+
+Example: With interrupts extended
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ Use pinmux 0x418 as wakeup interrupt and gpio1_0 as interrupt source
+
+palmas@48 {
+ compatible = ti,twl6035, ti,palmas;
+ reg = 0x48
+ interrupt-parent = intc;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts-extended = gpio1 0 IRQ_TYPE_LEVEL_HIGH,
+ pinmux 0x418;
+ pmic {
+ compatible = ti,twl6035-pmic, ti,palmas-pmic;
+
+ };
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/3] Documentation: dt-bindings: mfd: palmas: Fix example style of i2c peripheral
Use device@address as name for device nodes.
Suggested-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..d193859 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -33,7 +33,7 @@ Optional properties:
Example:
-palmas {
+palmas@48 {
compatible = ti,twl6035, ti,palmas;
reg = 0x48
interrupt-parent = intc;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/3] mfd: palmas: add optional wakeup irq
Hi, V2 of the series based on review conclusion in https://patchwork.kernel.org/patch/4743321/ based on v3.17-rc1 Wakeup irq is a interrupt path which is provided by the pinctrl hardware of certain SoCs such as TI's OMAP family of processors that generates an interrupt for waking up from deep power saving modes. Nishanth Menon (3): Documentation: dt-bindings: mfd: palmas: Fix example style of i2c peripheral Documentation: dt-bindings: mfd: palmas: document optional wakeup IRQ mfd: palmas: Add support for optional wakeup Documentation/devicetree/bindings/mfd/palmas.txt | 22 +++- drivers/mfd/palmas.c | 59 ++ include/linux/mfd/palmas.h |2 + 3 files changed, 82 insertions(+), 1 deletion(-) Regards, Nishanth Menon -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/3] mfd: palmas: Add support for optional wakeup
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power states as interrupts.
This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the actual event during
system active state). This is not the same as threaded interrupts as the
wakeup interrupt source is used only as part of deeper power saving
mode.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/mfd/palmas.c | 59
include/linux/mfd/palmas.h |2 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..11186ab 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+* Return Not handled so that interrupt is disabled.
+* Level event ensures that the event is eventually handled
+* by the appropriate chip handler already registered
+*/
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+ pdata-wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+ palmas-wakeirq = pdata-wakeirq;
match = of_match_device(of_palmas_match_tbl, i2c-dev);
@@ -587,6 +600,22 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err_i2c;
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+ palmas_wake_irq,
+ IRQF_ONESHOT | pdata-irq_flags,
+ dev_name(palmas-dev),
+ palmas);
+ if (ret 0)
+ goto err_i2c;
+
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas-dev, true);
+ disable_irq_nosync(palmas-wakeirq);
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +735,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(palmas-wakeirq);
+
+ return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ disable_irq_nosync(palmas-wakeirq);
+
+ return 0;
+}
+
static const struct i2c_device_id palmas_i2c_id[] = {
{ palmas, },
{ twl6035, },
@@ -721,6 +778,8 @@ static struct i2c_driver palmas_i2c_driver = {
.of_match_table = of_palmas_match_tbl,
.owner = THIS_MODULE,
},
+ .suspend = palmas_i2c_suspend,
+ .resume = palmas_i2c_resume,
.probe = palmas_i2c_probe,
.remove = palmas_i2c_remove,
.id_table = palmas_i2c_id,
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index fb0390a..e8cf4c2 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -75,6 +75,7 @@ struct palmas {
/* IRQ Data */
int irq;
u32 irq_mask;
+ int wakeirq;
struct mutex irq_lock;
struct regmap_irq_chip_data *irq_data;
@@ -377,6 +378,7 @@ struct palmas_clk_platform_data {
struct palmas_platform_data {
int irq_flags;
+ int wakeirq;
int gpio_base
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On 14:45-20140827, Nishanth Menon wrote:
On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.
OK. will try something along that line in the next rev.
Hi,
Updated patch below:
Do let me know if this is ok with folks.
---8
From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Mon, 27 May 2013 15:46:44 +0530
Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
NOTE: the hardware was originally designed to be capable of achieving
deep power states such as OFF and OSWR, however due to various issues
and risks, deepest valid state was determined to be CSWR - hence we use
the errata framework to handle this case.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: updates]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |3 ++-
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 12 ++--
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..297352f 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE)) {
+ save_state = 0;
+ break;
+ }
default:
/*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index e844e16..f961c46 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -32,6 +32,7 @@
#include soc.h
#include omap4-sar-layout.h
#include common.h
+#include pm.h
#define AM43XX_NR_REG_BANKS7
#define AM43XX_IRQS224
@@ -381,7 +382,7 @@ static struct notifier_block irq_notifier_block = {
static void __init irq_pm_init(void)
{
/* FIXME: Remove this when MPU OSWR support is added */
- if (!soc_is_omap54xx())
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
cpu_pm_register_notifier(irq_notifier_block);
}
#else
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index e150102..425bfcd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -101,6 +101,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
Daniel,
On 13:22-20140827, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
+ Daniel (cpuidle maintainer)
[...]
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ return index;
+}
Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
Trying to understand benefit of MCPM here - at least without a deeper
understanding of mcpm infrastructure benefits (first look seemed a
little heavy for OMAP5/DRA7 needs).
Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
OFF of CPU1/0, we have mercury hardware to help with context and
sync issues.
Being able to reuse most of existing OMAP4 infrastructure code is
useful as well to leave the existing omap4 framework as being lighter
in complexity -esp in a cpuidle like hot path?
The spin_lock is only for the programming of MPU power domain in a
consistent manner - I suppose might have been the trigger for
proposing mcpm?
Mostly not
I think this is coming because last time Nicolas Pitre tried to convert
the OMAP CPUIdle into MCPM but because of various ordering requirements,
OMAP wasn't suitable and then the plan was dropped later.
Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
remains the same for deeper states. Its just the mercury retention state
which we are able to enter without ordering requirements and hence
the voting scheme.
Ah, OK. This is the part that I'm missing. So for deeper states you'll
need to be using omap_enter_idle_coupled()
Hope this clarifies to you as well as Kevin just in case he missed the
part of the deeper C-states requirements.
Yes, thanks for clarifying.
That being said, I think MCPM can now do essentially what the coupled
states code is doing. Even so, that's probably not a reason to hold up
this patch, but Daniel gets to make that call.
Gentle ping.. You can find the discussion and the patch here:
https://patchwork.kernel.org/patch/4764661/
--
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
[PATCH 0/2] ARM: dts: dra7-evm: fixes for mux and VTT control
Hi, The following series was inspired in part by http://marc.info/?l=linux-omapm=140974309205295w=2 causing me to try and do an audit of pinctrl configurations on the platform. Further, failures on latest board updates in the automated farm also caused identification of a fix which was yet to be send to upstream from product kernel. Slightly unrelated patches in this series. So here they are.. based on v3.17-rc1: before-dra7xx-evm: Boot FAIL: http://paste.ubuntu.org.cn/1477597 (fails can be at different times though.. random crashes without VTT is usual).. after-dra7xx-evm: Boot PASS: http://paste.ubuntu.org.cn/1477596 Lokesh Vutla (1): ARM: dts: dra7-evm: Add vtt regulator support Nishanth Menon (1): ARM: dts: dra7-evm: Fix spi1 mux documentation arch/arm/boot/dts/dra7-evm.dts | 39 --- 1 file changed, 32 insertions(+), 7 deletions(-) -- 1.7.9.5 -- 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] ARM: dts: dra7-evm: Add vtt regulator support
From: Lokesh Vutla lokeshvu...@ti.com
DRA7 evm REV G and later boards uses a vtt regulator for DDR3
termination and this is controlled by gpio7_11. This gpio is
configured in boot loader. gpio7_11, which is only available only on
Pad A22, in previous boards, is connected only to an unused pad on
expansion connector EXP_P3 and is safe to be muxed as GPIO on all
DRA7-evm versions (without a need to spin off another dts file).
Since gpio7_11 is used to control VTT and should not be reset or kept
in idle state during boot up else VTT will be disconnected and DDR
gets corrupted. So, as part of this change, mark gpio7 as no-reset and
no-idle on init.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index e120fca..71f0f10 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include dra74x.dtsi
+#include dt-bindings/gpio/gpio.h
/ {
model = TI DRA742;
@@ -24,9 +25,29 @@
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
};
+
+ vtt_fixed: fixedregulator-vtt {
+ compatible = regulator-fixed;
+ regulator-name = vtt_fixed;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = gpio7 11 GPIO_ACTIVE_HIGH;
+ };
};
dra7_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 = vtt_pin;
+
+ vtt_pin: pinmux_vtt_pin {
+ pinctrl-single,pins =
+ 0x3b4 (PIN_OUTPUT | MUX_MODE14) /* spi1_cs1.gpio7_11 */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0x400 (PIN_INPUT | MUX_MODE0) /* i2c1_sda */
@@ -54,7 +75,6 @@
0x3a8 (PIN_INPUT | MUX_MODE0) /* spi1_d1 */
0x3ac (PIN_INPUT | MUX_MODE0) /* spi1_d0 */
0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs0 */
- 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs1 */
0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs2.hdmi1_hpd */
0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs3.hdmi1_cec */
;
@@ -504,3 +524,8 @@
usb2_phy2 {
phy-supply = ldousb_reg;
};
+
+gpio7 {
+ ti,no-reset-on-init;
+ ti,no-idle-on-init;
+};
--
1.7.9.5
--
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] ARM: dts: dra7-evm: Fix spi1 mux documentation
While auditing the various pin ctrl configurations using the following
command:
grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
do
v=`echo $line | sed -e s/\s\s*/|/g | cut -d '|' -f1 |
cut -d 'x' -f2|tr [a-z] [A-Z]`;
HEX=`echo obase=16;ibase=16;4A003400+$v| bc`;
echo $HEX === $line;
done)
against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
documentation errors were found for spi1 pinctrl. Fix the same.
Fixes: 6e58b8f1daaf1af340fb9309907e5ffa473c7aff (ARM: dts: DRA7: Add
the dts files for dra7 SoC and dra7-evm board)
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..e120fca 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -50,13 +50,13 @@
mcspi1_pins: pinmux_mcspi1_pins {
pinctrl-single,pins =
- 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi2_clk */
- 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi2_d1 */
- 0x3ac (PIN_INPUT | MUX_MODE0) /* spi2_d0 */
- 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs0 */
- 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs1 */
- 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs2 */
- 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs3 */
+ 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi1_sclk */
+ 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi1_d1 */
+ 0x3ac (PIN_INPUT | MUX_MODE0) /* spi1_d0 */
+ 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs0 */
+ 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs1 */
+ 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs2.hdmi1_hpd */
+ 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs3.hdmi1_cec */
;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: dra7-evm: Fix spi1 mux documentation
On 08:23-20140904, Nishanth Menon wrote:
While auditing the various pin ctrl configurations using the following
command:
grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
do
v=`echo $line | sed -e s/\s\s*/|/g | cut -d '|' -f1 |
cut -d 'x' -f2|tr [a-z] [A-Z]`;
HEX=`echo obase=16;ibase=16;4A003400+$v| bc`;
echo $HEX === $line;
done)
against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
documentation errors were found for spi1 pinctrl. Fix the same.
Fixes: 6e58b8f1daaf1af340fb9309907e5ffa473c7aff (ARM: dts: DRA7: Add
the dts files for dra7 SoC and dra7-evm board)
^^^ uggh... apologies.. checkpatch slipped this one.. updated rev below
(wont repost unless requested), Apologies on the spam..
8
From db595b941663f634f5f5106cf0092c7c8e998bb4 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Thu, 4 Sep 2014 08:06:27 -0500
Subject: [PATCH V2 1/2] ARM: dts: dra7-evm: Fix spi1 mux documentation
While auditing the various pin ctrl configurations using the following
command:
grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
do
v=`echo $line | sed -e s/\s\s*/|/g | cut -d '|' -f1 |
cut -d 'x' -f2|tr [a-z] [A-Z]`;
HEX=`echo obase=16;ibase=16;4A003400+$v| bc`;
echo $HEX === $line;
done)
against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
documentation errors were found for spi1 pinctrl. Fix the same.
Fixes: 6e58b8f1daaf1af (ARM: dts: DRA7: Add the dts files for dra7 SoC and
dra7-evm board)
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..e120fca 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -50,13 +50,13 @@
mcspi1_pins: pinmux_mcspi1_pins {
pinctrl-single,pins =
- 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi2_clk */
- 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi2_d1 */
- 0x3ac (PIN_INPUT | MUX_MODE0) /* spi2_d0 */
- 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs0 */
- 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs1 */
- 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs2 */
- 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs3 */
+ 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi1_sclk */
+ 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi1_d1 */
+ 0x3ac (PIN_INPUT | MUX_MODE0) /* spi1_d0 */
+ 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs0 */
+ 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs1 */
+ 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs2.hdmi1_hpd */
+ 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs3.hdmi1_cec */
;
};
--
1.7.9.5
--
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
Re: [PATCH] ARM: dts: omap5.dtsi: add DSS RFBI node
$subject: ARM: dts: OMAP5: Add DSS RFBI node
On 09/04/2014 01:28 AM, Tomi Valkeinen wrote:
The RFBI node for OMAP DSS was left out when adding the rest of the DSS
nodes, because it was not clear how to set up the clocks for the RFBI.
However, it seems that if there is a HWMOD for a device, we also need a
DT node for it. Otherwise, at boot, we get:
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2542
_init+0x464/0x4e0()
omap_hwmod: dss_rfbi: doesn't have mpu register target base
Now that v3.17-rc3 contains a fix
(8fd46439e1f5a7f86d76a08733459b74debd9468) for the L3 ICLK required by
the RFBI, let's add the RFBI node to get rid of the warning.
The usual style is to use the following style:
Commit 8fd46439e1f5 (ARM: dts: omap54xx-clocks: Fix the l3 and l4
clock rates)
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc8df1739f39..1e6ff61a7f12 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -945,6 +945,15 @@
clock-names = fck;
};
+ rfbi: encoder@58002000 {
+ compatible = ti,omap5-rfbi;
+ reg = 0x58002000 0x100;
+ status = disabled;
+ ti,hwmods = dss_rfbi;
+ clocks = dss_dss_clk, l3_iclk_div;
+ clock-names = fck, ick;
+ };
+
dsi1: encoder@58004000 {
compatible = ti,omap5-dsi;
reg = 0x58004000 0x200,
before-omap5-evm: http://paste.ubuntu.org.cn/1477659
after-omap5-evm: http://paste.ubuntu.org.cn/1477658
So, yep, no more warning.
--
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
Re: [PATCH] drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
On 08/21/2014 11:12 AM, Nishanth Menon wrote:
With the recent pinctrl-single changes, SoCs such as Texas
Instrument's OMAP processors can treat wake-up events from deeper idle
states as interrupts.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
Hi,
Gentle Ping.
Regards,
Nishanth Menon
drivers/rtc/rtc-ds1307.c | 57
++
1 file changed, 57 insertions(+)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index f03d5ba..5feedfc 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -15,6 +15,8 @@
#include linux/init.h
#include linux/slab.h
#include linux/i2c.h
+#include linux/of_device.h
+#include linux/of_irq.h
#include linux/string.h
#include linux/rtc.h
#include linux/bcd.h
@@ -115,6 +117,7 @@ struct ds1307 {
struct i2c_client *client;
struct rtc_device *rtc;
struct work_struct work;
+ int wakeirq;
s32 (*read_block_data)(const struct i2c_client *client, u8 command,
u8 length, u8 *values);
s32 (*write_block_data)(const struct i2c_client *client, u8 command,
@@ -835,6 +838,34 @@ ds1307_nvram_write(struct file *filp, struct kobject
*kobj,
/*--*/
+static int ds1307_i2c_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+ struct ds1307 *ds1307 = i2c_get_clientdata(client);
+ struct device *dev = client-dev;
+
+ if (!ds1307-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(ds1307-wakeirq);
+
+ return 0;
+}
+
+static int ds1307_i2c_resume(struct i2c_client *client)
+{
+ struct ds1307 *ds1307 = i2c_get_clientdata(client);
+ struct device *dev = client-dev;
+
+ if (!ds1307-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ disable_irq_nosync(ds1307-wakeirq);
+
+ return 0;
+}
+
static int ds1307_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -1116,6 +1147,8 @@ read_rtc:
}
if (want_irq) {
+ struct device_node *node = client-dev.of_node;
+
err = request_irq(client-irq, ds1307_irq, IRQF_SHARED,
ds1307-rtc-name, client);
if (err) {
@@ -1125,6 +1158,28 @@ read_rtc:
set_bit(HAS_ALARM, ds1307-flags);
dev_dbg(client-dev, got IRQ %d\n, client-irq);
+ if (node)
+ ds1307-wakeirq = irq_of_parse_and_map(node, 1);
+
+ if (ds1307-wakeirq = 0)
+ ds1307-wakeirq = 0;
+ else
+ err = devm_request_irq(client-dev,
+ds1307-wakeirq,
+ds1307_irq,
+IRQF_ONESHOT,
+ds1307-rtc-name,
+client);
+ if (err) {
+ dev_err(client-dev, unable to get wakeIRQ
%d\n,
+ err);
+ free_irq(client-irq, client);
+ goto exit;
+ }
+
+ /* We enable the interrupt only during suspend path */
+ if (ds1307-wakeirq)
+ disable_irq_nosync(ds1307-wakeirq);
}
}
@@ -1189,6 +1244,8 @@ static struct i2c_driver ds1307_driver = {
},
.probe = ds1307_probe,
.remove = ds1307_remove,
+ .suspend= ds1307_i2c_suspend,
+ .resume = ds1307_i2c_resume,
.id_table = ds1307_id,
};
--
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
Re: [PATCH] ARM: dts: DRA7: Add PMU nodes
On 08/19/2014 08:54 AM, Nishanth Menon wrote:
From: Lucas Weaver l-wea...@ti.com
DRA74x and DRA72x family of processors vary slightly in the number
of CPUs. So, add different instances of PMU for each of these processor
groups. Further, since the interrupts bypass crossbar and are directly
connected to GIC, mark the dts nodes with relevant information.
Tested with perf utility.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lucas Weaver l-wea...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Hi,
Gentle ping..
Regards,
Nishanth Menon
arch/arm/boot/dts/dra72x.dtsi |5 +
arch/arm/boot/dts/dra74x.dtsi |6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index f1ec22f..e5a3d23 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -22,4 +22,9 @@
reg = 0;
};
};
+
+ pmu {
+ compatible = arm,cortex-a15-pmu;
+ interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
+ };
};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index a4e8bb9..3be544c 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -38,4 +38,10 @@
reg = 1;
};
};
+
+ pmu {
+ compatible = arm,cortex-a15-pmu;
+ interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI DIRECT_IRQ(132) IRQ_TYPE_LEVEL_HIGH;
+ };
};
--
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
[PATCH] ARM: dts: am335x-bone*: Fix model name and update compatibility information
Beaglebone white and beaglebone black differ in tiny little aspects.
This is the reason why we maintain seperate dts for these platforms.
However, there is no real way to decode from dtb which platform it is
since compatible and model name are the same for both platforms.
Fix this so that beaglebone black and beaglebone are identifiable,
while maintaining compatibility for older zImages which might use old
beaglebone compatible flag for black as well.
Reported-by: Tom Rini tr...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on v3.17-rc1:
Before:
beaglebone-black: Boot PASS: http://paste.ubuntu.org.cn/1473558
beaglebone: Boot PASS: http://paste.ubuntu.org.cn/1473559
After:
beaglebone-black: Boot PASS: http://paste.ubuntu.org.cn/1473480
beaglebone: Boot PASS: http://paste.ubuntu.org.cn/1473481
Side notes: Sorry, new IT policies, new paste website needed :(
arch/arm/boot/dts/am335x-bone-common.dtsi |3 ---
arch/arm/boot/dts/am335x-bone.dts |5 +
arch/arm/boot/dts/am335x-boneblack.dts|5 +
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bde1777..d9d9869 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -7,9 +7,6 @@
*/
/ {
- model = TI AM335x BeagleBone;
- compatible = ti,am335x-bone, ti,am33xx;
-
cpus {
cpu@0 {
cpu0-supply = dcdc2_reg;
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..83d40f7 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,11 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+/ {
+ model = TI AM335x BeagleBone;
+ compatible = ti,am335x-bone, ti,am33xx;
+};
+
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 330;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 305975d..901739f 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -10,6 +10,11 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+/ {
+ model = TI AM335x BeagleBone Black;
+ compatible = ti,am335x-bone-black, ti,am335x-bone, ti,am33xx;
+};
+
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
--
1.7.9.5
--
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: dts: am437x-gp: switch i2c0 to 100KHz
On the GP EVM, the ambient light sensor is limited to 100KHz on the
I2C bus.
So use 100kHz for I2C on the GP EVM due to this limitation on the
ambient light sensor.
Reported-by: Aparna Balasubramanian apar...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
based on v3.17-rc1
arch/arm/boot/dts/am437x-gp-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 646a6ea..9559c19 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,7 +260,7 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
- clock-frequency = 40;
+ clock-frequency = 10;
tps65218: tps65218@24 {
reg = 0x24;
--
1.7.9.5
--
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: PROBLEM: bindings for drivers/mfd/twl4030-power.c
On 09/03/2014 01:45 PM, Tony Lindgren wrote: * Dr. H. Nikolaus Schaller h...@goldelico.com [140901 09:54]: Hi, Am 25.08.2014 um 23:26 schrieb Tony Lindgren: * Dr. H. Nikolaus Schaller h...@goldelico.com [140817 08:46]: I am trying to make ti,use_poweroff work on 3.17-rc1 for the GTA04 board. Poweroff was broken for a while and I found that the driver isn't loaded at all. It appears to me that commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6 did rename the compatible entry from ti,twl4030-power to ti,twl4030-power-reset but this was not documented in the bindings and of course our DT does not match. Even your commit message talks about ti,twl4030-power although I can't find it in the code. Hmm sorry did I accidentally remove ti,twl4030-power? If so, that should be added back for sure. Do you have a patch for that already? No, I have only updated our device tree because I don't know if it really should be added back or not. As you say the ti,twl4030-power does not configure anything. So what is it good for? Only for the poweroff if ti,use_poweroff is set. Care to do a patch as you clearly have a use case to test it with? Tony, we were talking about supporting ti,system-power-controller as the standard way of stating poweroff control is by the PMIC. this seems to be standard in various SoCs. use_poweroff seems to predate that standardization. Should'nt we start using ti,system-power-controller instead? -- 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
[PATCH 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control
ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.
So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/mfd/twl4030-power.txt |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b9ee7b9..e1dff57 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -23,8 +23,11 @@ down during off-idle. Note that this does not work on all
boards
depending on how the external oscillator is wired.
Optional properties:
-- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
- SLEEP-to-OFF transition when the system poweroffs.
+
+- ti,system-power-controller OR ti,use_poweroff: This indicates that
+ TWL4030 is the power supply master of the system. With this flag, the
+ chip will initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when
+ the system poweroffs.
Example:
i2c1 {
--
1.7.9.5
--
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] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off
ti,system-power-controller is more or less the standard way of indicating that the PMIC is the system wide power controller and hence may be used to switch off the system. Almost ALL TI PMIC drivers and many Maxim PMIC drivers follow the same style. So support 'ti,system-power-controller' in addition to the usual 'ti,use_poweroff' to indicate that the PMIC instance has control for switching off the system. Signed-off-by: Nishanth Menon n...@ti.com --- drivers/mfd/twl4030-power.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c index 3bc969a..1c129ba 100644 --- a/drivers/mfd/twl4030-power.c +++ b/drivers/mfd/twl4030-power.c @@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct twl4030_power_data *pdata, if (pdata pdata-use_poweroff) return true; + if (of_property_read_bool(node, ti,system-power-controller)) + return true; + if (of_property_read_bool(node, ti,use_poweroff)) return true; -- 1.7.9.5 -- 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/2] mfd: twl4030-power: support ti,system-power-controller
This series adds ti,system-power-controller to Documentation and the driver seperately as per maintainer preference. Based on v3.17-rc1 Nishanth Menon (2): Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off .../devicetree/bindings/mfd/twl4030-power.txt |7 +-- drivers/mfd/twl4030-power.c|3 +++ 2 files changed, 8 insertions(+), 2 deletions(-) -- 1.7.9.5 -- 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: PROBLEM: bindings for drivers/mfd/twl4030-power.c
On Wed, Sep 3, 2014 at 2:02 PM, Tony Lindgren t...@atomide.com wrote: * Nishanth Menon n...@ti.com [140903 11:51]: On 09/03/2014 01:45 PM, Tony Lindgren wrote: * Dr. H. Nikolaus Schaller h...@goldelico.com [140901 09:54]: Hi, Am 25.08.2014 um 23:26 schrieb Tony Lindgren: * Dr. H. Nikolaus Schaller h...@goldelico.com [140817 08:46]: I am trying to make ti,use_poweroff work on 3.17-rc1 for the GTA04 board. Poweroff was broken for a while and I found that the driver isn't loaded at all. It appears to me that commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6 did rename the compatible entry from ti,twl4030-power to ti,twl4030-power-reset but this was not documented in the bindings and of course our DT does not match. Even your commit message talks about ti,twl4030-power although I can't find it in the code. Hmm sorry did I accidentally remove ti,twl4030-power? If so, that should be added back for sure. Do you have a patch for that already? No, I have only updated our device tree because I don't know if it really should be added back or not. As you say the ti,twl4030-power does not configure anything. So what is it good for? Only for the poweroff if ti,use_poweroff is set. Care to do a patch as you clearly have a use case to test it with? Tony, we were talking about supporting ti,system-power-controller as the standard way of stating poweroff control is by the PMIC. this seems to be standard in various SoCs. use_poweroff seems to predate that standardization. Should'nt we start using ti,system-power-controller instead? Sure we can add that. But need to keep also parsing ti,use_poweroff as it's already in use. Yep. https://patchwork.kernel.org/patch/4836381/ https://patchwork.kernel.org/patch/4836371/ Split documentation out (based on discussion in https://patchwork.kernel.org/patch/4743321/). -- --- 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
Re: [PATCH 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control
On Wed, Sep 3, 2014 at 2:53 PM, Sebastian Reichel s...@kernel.org wrote: On Wed, Sep 03, 2014 at 02:06:47PM -0500, Nishanth Menon wrote: Optional properties: -- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or -SLEEP-to-OFF transition when the system poweroffs. + +- ti,system-power-controller OR ti,use_poweroff: This indicates that + TWL4030 is the power supply master of the system. With this flag, the + chip will initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when + the system poweroffs. I suggest the following wording: - ti,system-power-controller: This indicates that TWL4030 is the power supply master of the system. With this flag, the chip will initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the system poweroffs. - ti,use_poweroff: Deprecated name for ti,system-power-controller Yes, this does indeed sound better. if no one has a different opinion or further comments, will update this patch tomorrow. -- --- 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
Re: [PATCH] mfd: palmas: Add support for optional wakeup
On 09/01/2014 04:32 AM, Lee Jones wrote: On Fri, 29 Aug 2014, Nishanth Menon wrote: On 08/29/2014 05:56 AM, Lee Jones wrote: On Tue, 19 Aug 2014, Nishanth Menon wrote: With the recent pinctrl-single changes, omaps can treat wake-up events from deeper idle states as interrupts. Let's add support for the optional second interrupt for wake-up events. And then SoC can wakeup and handle the event using it's regular handler. Finally, to pass the wake-up interrupt in the dts file, interrupts-extended property needs to be passed. This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add support for optional wake-up) Signed-off-by: Nishanth Menon n...@ti.com --- Documentation/devicetree/bindings/mfd/palmas.txt | 20 DT Ack please. Please read Documentation/devicetree/bindings/submittingpatches.txt I assume you wanted me to note the following: The Documentation/ portion of the patch should be a separate patch. Many maintainers prefer that when the bindings for the device is new, and when additional properties are added, they prefer it part of same patch.. Anyways.. if the above is what you prefer, I can follow that. In short, I assume you'd like three patches: a) fix up style of current documentation - palmas to palmas@40 b) Split documentation for interrupt-extended from the current patch into it's own patch. c) remainder of this patch as is.. Does that sound right? --- 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
Re: [PATCH] mfd: palmas: Add support for optional wakeup
On 08/29/2014 05:56 AM, Lee Jones wrote:
On Tue, 19 Aug 2014, Nishanth Menon wrote:
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper idle states as interrupts.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt | 20
DT Ack please.
drivers/mfd/palmas.c | 59
++
include/linux/mfd/palmas.h |2 +
3 files changed, 81 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..2627842 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -51,3 +51,23 @@ palmas {
};
}
+
+Example: with interrupts extended
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ Use pinmux 0x418 as wakeup interrupt and gpio1_0 as interrupt source
+
+palmas {
Should this be 'palmas@40 {'?
I might have preferred that as well.. I kept the existing style in the
documentation. Would you like me to change existing doc style too?
+compatible = ti,twl6035, ti,palmas;
+reg = 0x48
+interrupt-parent = intc;
+interrupt-controller;
+#interrupt-cells = 2;
+#address-cells = 1;
+#size-cells = 0;
+interrupts-extended = gpio1 0 IRQ_TYPE_LEVEL_HIGH
+ pinmux 0x418;
Can I get a DT Ack, that this is being used correctly? It doesn't
match the syntax given in:
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Did you mean:
gpio1 0 IRQ_TYPE_LEVEL_HIGH, pinmux 0x418;
Yes, I can fix that - sorry, both usage seem to be functional.
+pmic {
+compatible = ti,twl6035-pmic, ti,palmas-pmic;
+
+};
+}
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..11186ab 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS]
= {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+/*
+ * Return Not handled so that interrupt is disabled.
+ * Level event ensures that the event is eventually handled
+ * by the appropriate chip handler already registered
+ */
This looks okay to me, but could do with a second opinion from someone
who is a little more familier with this kind of h/w.
How does this differ from threading IRQs?
I could try with an example:
consider a GPIO block 7 gpio 4 connected to a pinctrl pin 234 as the
interrupt source for palmas.
When the system is active, the GPIO block 7, gpio 4 happily functions
as the interrupt source. However, the SoC might not capable of
achieving SoC wide deepsleep when GPIO block 7 is active, So we have
to power off GPIO block 7. However on achieving low power, the system
needs to be capable of waking backup, for this, SoC uses the hardware
at the pin itself(TI calls it control module, others have other names,
lets for the discussion, call it pinctrl), on going to sleep the
action of enabling the pinctrl irq - enables the wakeup capability of
the pin, and disabling it disabled the wakeup capability. when the
wakeup event does take place, in some cases, it might be a edge event,
where by the time we have recofigured GPIO block, the interrupt event
is long gone - to support this, pinctrl invokes the driver interrupt
handler to ensure this functions. in our case(palmas), we are level
event and can depend on GPIO block to handle it when it is configured.
Basically two interrupt sources when SoC is in deep sleep(1 to exit
from deepsleep, and other from the module handling the actual event) -
Example: powerbutton press OR palmas RTC wakeup OR Palmas GPIO
generated wakeup.
However, this is not the same as threading IRQ as the wakeup event is
involved only during suspend path.
commit 2a0b965cfb6e (serial: omap: Add support for optional wake-up)
is a good reference from serial port handling perspective.
--
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
Re: [PATCH v2 1/2] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants
On Thu, Aug 28, 2014 at 1:19 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 27 Aug 2014, Nishanth Menon wrote: On Mon, Jul 28, 2014 at 12:34 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Monday 28 July 2014 10:59 AM, Paul Walmsley wrote: On Mon, 28 Jul 2014, Lokesh Vutla wrote: From: Rajendra Nayak rna...@ti.com Use the corresponding compatibles to identify the devices. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Acked-by: Nishanth Menon n...@ti.com Tested-by: Nishanth Menon n...@ti.com Thanks, queued for (hopefully) early v3.17-rc. Thanks Paul. Paul, Tony, we are at 3.17-rc2 today, unfortunately.. http://slexy.org/view/s20MbRgipa dra72-evm is still broken due to this. Needs: https://patchwork.kernel.org/patch/4632161/ and https://patchwork.kernel.org/patch/4632171/ What can we do to help speed this along? A simple reminder, like this one, is good. Also providing boards and documentation generally helps, so the patches can be tested and reviewed. TI is working diligently towards a public TRM and potentially a related platform as well for all. Unfortunately, I am not yet aware of a official finalized release date.. hopefully this year.. In the meanwhile, we will try to provide test logs that you may desire for at least the platforms we have functioning and access to. please feel free to request specific test vectors if you feel our coverage is not good enough. -- --- 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
Re: [PATCH 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
On Wed, Aug 27, 2014 at 1:27 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Nishanth Menon n...@ti.com writes:
powerdomain configuration in OMAP is done using PWRSTCTRL register for
each power domain. However, PRCM lets us write any value we'd like to
the logic and power domain target states, however the SoC integration
tends to actually function only at a few discrete states. These valid
states are already in our powerdomains_xxx_data.c file.
So, provide a function to easily query valid low power state that the
power domain is allowed to go to.
Based on work originally done by Jean Pihet j-pi...@ti.com
https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
create a new powerdomain solution here, except fixing issues seen
attempting invalid programming attempts. Future consolidation to the
generic powerdomain framework should consider this requirement as
well.
Similar solutions have been done in product kernels in the past such
as:
https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c
Signed-off-by: Nishanth Menon n...@ti.com
---
nit: this is part of a fixes series, but it's more of a new feature.
That being said, the feature is needed and looks OK, except for...
+up_search:
+ /* OK, no deeper ones, can we get a higher match? */
+ new_pwrst = req_state + 1;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ /* BUG if we have messed up database */
+ BUG_ON(new_pwrst PWRDM_POWER_ON);
I don't think this is BUG() worthy, and should have a saner way to recover.
it is not even a legal value to have a power state higher than ON. I
mean, yeah, we can do
if (new_pwrst PWRDM_POWER_ON) {
pr_debug(powerdomain: %s: fix my powerdomain max to ON\n,
pwrdm-name);
return PWRDM_POWER_ON;
}
if that is your suggestion here, personally, I would use a WARN at least here..
--
---
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
[PATCH V2 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
powerdomain configuration in OMAP is done using PWRSTCTRL register for
each power domain. However, PRCM lets us write any value we'd like to
the logic and power domain target states, however the SoC integration
tends to actually function only at a few discrete states. These valid
states are already in our powerdomains_xxx_data.c file.
So, provide a function to easily query valid low power state that the
power domain is allowed to go to.
Based on work originally done by Jean Pihet j-pi...@ti.com
https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
create a new powerdomain solution here, except fixing issues seen
attempting invalid programming attempts. Future consolidation to the
generic powerdomain framework should consider this requirement as
well.
Similar solutions have been done in product kernels in the past such
as:
https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Not posting the entire series again and updating just this patch..
V2: drop BUG in favor of WARN, picked up Santosh and Kevin's acks.
V1: https://patchwork.kernel.org/patch/4764131/
arch/arm/mach-omap2/powerdomain.c | 76 +
arch/arm/mach-omap2/powerdomain.h |3 ++
2 files changed, 79 insertions(+)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index f391948..7fb033e 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1081,6 +1081,82 @@ int pwrdm_post_transition(struct powerdomain *pwrdm)
}
/**
+ * pwrdm_get_valid_lp_state() - Find best match deep power state
+ * @pwrdm: power domain for which we want to find best match
+ * @is_logic_state: Are we looking for logic state match here? Should
+ * be one of PWRDM_xxx macro values
+ * @req_state: requested power state
+ *
+ * Returns: closest match for requested power state. default fallback
+ * is RET for logic state and ON for power state.
+ *
+ * This does a search from the power domain data looking for the
+ * closest valid power domain state that the hardware can achieve.
+ * PRCM definitions for PWRSTCTRL allows us to program whatever
+ * configuration we'd like, and PRCM will actually attempt such
+ * a transition, however if the powerdomain does not actually support it,
+ * we endup with a hung system. The valid power domain states are already
+ * available in our powerdomain data files. So this function tries to do
+ * the following:
+ * a) find if we have an exact match to the request - no issues.
+ * b) else find if a deeper power state is possible.
+ * c) failing which, it tries to find closest higher power state for the
+ * request.
+ */
+u8 pwrdm_get_valid_lp_state(struct powerdomain *pwrdm,
+ bool is_logic_state, u8 req_state)
+{
+ u8 pwrdm_states = is_logic_state ? pwrdm-pwrsts_logic_ret :
+ pwrdm-pwrsts;
+ /* For logic, ret is highest and others, ON is highest */
+ u8 default_pwrst = is_logic_state ? PWRDM_POWER_RET : PWRDM_POWER_ON;
+ u8 new_pwrst;
+ bool found;
+
+ /* If it is already supported, nothing to search */
+ if (pwrdm_states BIT(req_state))
+ return req_state;
+
+ if (!req_state)
+ goto up_search;
+
+ /*
+* So, we dont have a exact match
+* Can we get a deeper power state match?
+*/
+ new_pwrst = req_state - 1;
+ found = true;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ /* No match even at OFF? Not available */
+ if (new_pwrst == PWRDM_POWER_OFF) {
+ found = false;
+ break;
+ }
+ new_pwrst--;
+ }
+
+ if (found)
+ goto done;
+
+up_search:
+ /* OK, no deeper ones, can we get a higher match? */
+ new_pwrst = req_state + 1;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ if (new_pwrst PWRDM_POWER_ON) {
+ WARN(1, powerdomain: %s: Fix max powerstate to ON\n,
+pwrdm-name);
+ return PWRDM_POWER_ON;
+ }
+
+ if (new_pwrst == default_pwrst)
+ break;
+ new_pwrst++;
+ }
+done:
+ return new_pwrst;
+}
+
+/**
* omap_set_pwrdm_state - change a powerdomain's current power state
* @pwrdm: struct powerdomain * to change the power state of
* @pwrst: power state to change to
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index a754c82..11bd4dd 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -220,6 +220,9 @@ struct voltagedomain *pwrdm_get_voltdm(struct powerdomain
*pwrdm
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
--
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
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.
OK. will try something along that line in the next rev.
--
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
Re: [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle
On 08/22/2014 09:02 AM, Nishanth Menon wrote: [...] An complete integrated branch is available here: https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework Example test log: DRA7 based BeagleBoard X15: http://slexy.org/view/s2jgsH8bos (wakeup from external using pinctrl wakeup). OMAP5UEVM: http://slexy.org/view/s20MiQJQIq (external pinctrl not hooked) Tony wanted a slightly wider test coverage including OMAP4 platforms: So using https://github.com/nmenon/linux-2.6-playground/commit/92e5e7407aa707ad6be8ae3b5bf21cfc741daab6 wakeup timer as a wakeup source (remote boards): am37x-evm: http://slexy.org/raw/s2l2vPAlBi BeagleBoard-XM: http://slexy.org/raw/s2HvJHuZ8K beagleboard-vanilla: http://slexy.org/raw/s2re4CjsVS n900: http://slexy.org/raw/s21kRad9UC sdp3430: http://slexy.org/raw/s217hjHveS pandaboard-es: http://slexy.org/raw/s21Vhfl96g pandaboard-vanilla: http://slexy.org/raw/s21uPHllrR sdp4430: http://slexy.org/raw/s20Jl3cika Vs: 3.17-rc1: am37x-evm: http://slexy.org/raw/s21FKtfXlb BeagleBoard-XM: http://slexy.org/raw/s2q3LCSDkd beagleboard-vanilla: http://slexy.org/raw/s21ioe8utf n900: http://slexy.org/raw/s20E3oQhCl sdp3430: http://slexy.org/raw/s21XQDe1s3 pandaboard-es: http://slexy.org/raw/s21DcS0IIt pandaboard-vanilla: http://slexy.org/raw/s25W1A4JsP sdp4430: http://slexy.org/raw/s2019HPstN -- 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
