[PATCH v2 07/10] pwm: pwm-tiehrpwm: pinctrl support
Enable pinctrl for pwm-tiehrpwm
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 fba7f9b... 07911e6... M drivers/pwm/pwm-tiehrpwm.c
drivers/pwm/pwm-tiehrpwm.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index fba7f9b..07911e6 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -26,6 +26,7 @@
#include linux/clk.h
#include linux/pm_runtime.h
#include linux/of_device.h
+#include linux/pinctrl/consumer.h
#include tipwmss.h
@@ -418,6 +419,11 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
struct resource *r;
struct clk *clk;
struct ehrpwm_pwm_chip *pc;
+ struct pinctrl *pinctrl;
+
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, failed to configure pins from driver\n);
pc = devm_kzalloc(pdev-dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/10] pwm: pwm-tiehrpwm: Adding TBCLK gating support.
Some platforms (like AM33XX) requires clock gating from control module
explicitly for TBCLK. Enabling of this clock required for the
functioning of the time base sub module in EHRPWM module. So adding
optional TBCLK handling if DT node populated with tbclkgating. This
helps the driver can coexist for Davinci platforms.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
---
Changes since v1:
- Moved TBCLK enable from probe to .pwm_enable disable from
remove to .pwm_disable
:100644 100644 07911e6... 927a8ed... M drivers/pwm/pwm-tiehrpwm.c
drivers/pwm/pwm-tiehrpwm.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 07911e6..927a8ed 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -126,6 +126,7 @@ struct ehrpwm_pwm_chip {
void __iomem*mmio_base;
unsigned long period_cycles[NUM_PWM_CHANNEL];
enum pwm_polarity polarity[NUM_PWM_CHANNEL];
+ struct clk *tbclk;
};
static inline struct ehrpwm_pwm_chip *to_ehrpwm_pwm_chip(struct pwm_chip *chip)
@@ -346,6 +347,13 @@ static int ehrpwm_pwm_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
/* Channels polarity can be configured from action qualifier module */
configure_polarity(pc, pwm-hwpwm);
+ /*
+* Platforms require explicit clock enabling of TBCLK has
+* to enable TBCLK explicitly before enabling PWM device
+*/
+ if (pc-tbclk)
+ clk_enable(pc-tbclk);
+
/* Enable time counter for free_run */
ehrpwm_modify(pc-mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_FREE_RUN);
return 0;
@@ -374,6 +382,10 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
ehrpwm_modify(pc-mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
+ /* Disabling TBCLK on PWM disable */
+ if (pc-tbclk)
+ clk_disable(pc-tbclk);
+
/* Stop Time base counter */
ehrpwm_modify(pc-mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_STOP_NEXT);
@@ -464,6 +476,16 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
return ret;
}
+
+ /* Some platforms require explicit tbclk gating */
+ if (of_property_read_bool(pdev-dev.of_node, tbclkgating)) {
+ pc-tbclk = clk_get(pdev-dev, tbclk);
+ if (IS_ERR(pc-tbclk)) {
+ dev_err(pdev-dev, Could not get EHRPWM TBCLK\n);
+ return PTR_ERR(pc-tbclk);
+ }
+ }
+
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);
if (!(pwmss_submodule_state_change(pdev-dev.parent, EPWMCLK_EN)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/07/12 23:36, Jon Hunter wrote:
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT.
2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
separate timer structures along with the timer init functions.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
[snip]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a4ad7a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -63,20 +63,8 @@
#define OMAP2_32K_SOURCEfunc_32k_ck
#define OMAP3_32K_SOURCEomap_32k_fck
#define OMAP4_32K_SOURCEsys_32k_ck
-
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
#define TIMER_PROP_SECURE ti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECURE ti,timer-alwon
-#endif
+#define TIMER_PROP_ALWONti,timer-alwon
Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
ti,timer-secure and ti,timer-alwon directly?
Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
was to drop this and use the property string directly to remove any
abstraction.
Well, I don't understand what do you mean by any abstraction.
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET0x10
@@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
-np = omap_get_timer_dt(omap_timer_match, ti,timer-secure);
+np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
if (np)
of_node_put(np);
}
@@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __omap2_sync32k_clocksource_init(void)
Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
{
int ret;
struct device_node *np = NULL;
@@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
-return -ENODEV;
-}
-#endif
-static void __init omap2_gptimer_clocksource_init(int gptimer_id,
-const char *fck_source)
+static void __init omap2_gp_clocksource_init(int gptimer_id,
+ const char *fck_source)
Nit, I personally prefer keeping gptimer, because gp just means
general-purpose and does not imply a timer per-se.
I've made this change, so we will not get something like:
omapx_gptimer_timer_init(), but this really does not meter to me,
so no problem will do for v2.
{
int res;
@@ -466,23 +447,10 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
gptimer_id, clksrc.rate);
}
-static void __init omap2_clocksource_init(int
[PATCH v2 10/10] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
PWM output from ecap0 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 185d632... 9857050... M arch/arm/boot/dts/am335x-evm.dts
arch/arm/boot/dts/am335x-evm.dts | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..9857050 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -18,6 +18,14 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ ecap0_pins: backlight_pins {
+ pinctrl-single,pins =
+ 0x164 0x0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
@@ -31,6 +39,12 @@
reg = 0x2d;
};
};
+
+ ecap0: ecap@48300100 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = ecap0_pins;
+ };
};
vbat: fixedregulator@0 {
@@ -40,6 +54,13 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ backlight {
+ compatible = pwm-backlight;
+ pwms = ecap0 0 5 0;
+ brightness-levels = 0 51 53 56 62 75 101 152 255;
+ default-brightness-level = 8;
+ };
};
/include/ tps65910.dtsi
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/10] ARM: dts: AM33XX: Add PWMSS device tree nodes
Add PWMSS device tree nodes in relation with ECAP EHRPWM DT nodes to
AM33XX SoC family. Also populates device tree nodes for ECAP EHRPWM by
adding necessary properties like pwm-cells, base reg set disabled as
status.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 bb31bff... cf5e049... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 90 +
1 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..cf5e049 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,95 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ epwmss0: epwmss@4830 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x4830 0x10
+ 0x48300100 0x80
+ 0x48300180 0x80
+ 0x48300200 0x80;
+ ti,hwmods = epwmss0;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
+
+ ecap0: ecap@48300100 {
+ compatible = ti,am33xx-ecap;
+ #pwm-cells = 3;
+ reg = 0x48300100 0x80;
+ ti,hwmods = ecap0;
+ status = disabled;
+ };
+
+ ehrpwm0: ehrpwm@48300200 {
+ compatible = ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48300200 0x80;
+ ti,hwmods = ehrpwm0;
+ status = disabled;
+ tbclkgating;
+ };
+ };
+
+ epwmss1: epwmss@48302000 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x48302000 0x10
+ 0x48302100 0x80
+ 0x48302180 0x80
+ 0x48302200 0x80;
+ ti,hwmods = epwmss1;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
+
+ ecap1: ecap@48302100 {
+ compatible = ti,am33xx-ecap;
+ #pwm-cells = 3;
+ reg = 0x48302100 0x80;
+ ti,hwmods = ecap1;
+ status = disabled;
+ };
+
+ ehrpwm1: ehrpwm@48302200 {
+ compatible = ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48302200 0x80;
+ ti,hwmods = ehrpwm1;
+ status = disabled;
+ tbclkgating;
+ };
+ };
+
+ epwmss2: epwmss@48304000 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x48304000 0x10
+ 0x48304100 0x80
+ 0x48304180 0x80
+ 0x48304200 0x80;
+ ti,hwmods = epwmss2;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
+
+ ecap2: ecap@48304100 {
+ compatible = ti,am33xx-ecap;
+ #pwm-cells = 3;
+ reg = 0x48304100 0x80;
+ ti,hwmods = ecap2;
+ status = disabled;
+ };
+
+ ehrpwm2: ehrpwm@48304200 {
+ compatible = ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48304200 0x80;
+ ti,hwmods = ehrpwm2;
+ status = disabled;
+ tbclkgating;
+ };
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] mmc: omap_hsmmc: cleanup the bitmap definitions of Interrupt Register
On Wed, Nov 7, 2012 at 6:54 PM, Balaji T K balaj...@ti.com wrote: On Tuesday 06 November 2012 10:22 PM, Venkatraman S wrote: Define the most frequently used bitmasks of the Interrupt Enable / Interrupt Status register with consistent naming ( with _EN suffix). Use meaningful concatenation of bitfields for INT_EN_MASK, which shows which interrupts are enabled by default. No functional changes. Signed-off-by: Venkatraman S svenk...@ti.com Hi Venkat, Not sure if you had chance to look into my comments on Version 2 of this patch Acked-by: Felipe Balbi ba...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 54 +-- 1 file changed, 31 insertions(+), 23 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e91e85a..d16ef0f 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -80,29 +80,17 @@ #define CLKD_SHIFT6 #define DTO_MASK 0x000F #define DTO_SHIFT 16 -#define INT_EN_MASK0x307F0033 -#define BWR_ENABLE (1 4) -#define BRR_ENABLE (1 5) -#define DTO_ENABLE (1 20) #define INIT_STREAM (1 1) #define DP_SELECT (1 21) #define DDIR (1 4) -#define DMA_EN 0x1 +#define DMAE 0x1 This change is not needed or may not be part of this patch. Actually its about consistency in naming convention. As part of this patch, the IE, ISE and STAT family of registers all use the _EN suffix for the bitfields, so this one had to have something different. #define MSBS (1 5) #define BCE (1 1) #define FOUR_BIT (1 1) #define HSPE (1 2) #define DDR (1 19) #define DW8 (1 5) -#define CC 0x1 -#define TC 0x02 #define OD0x1 -#define ERR(1 15) -#define CMD_TIMEOUT(1 16) -#define DATA_TIMEOUT (1 20) -#define CMD_CRC(1 17) -#define DATA_CRC (1 21) -#define CARD_ERR (1 28) #define STAT_CLEAR0x #define INIT_STREAM_CMD 0x #define DUAL_VOLT_OCR_BIT 7 @@ -111,6 +99,26 @@ #define SOFTRESET (1 1) #define RESETDONE (1 0) +/* Interrupt masks for IE and ISE register */ +#define CC_EN (1 0) +#define TC_EN (1 1) You might want to retain CC, TC ... which has been defined and already used for in many places for MMCHS_STAT instead of CC_EN. CC_EN is not mentioned in TRM however CC is defined as bit field in TRM Register spec. So It would be better to reuse the previously defined CC, TC (and other bits fields) for MMCHS_IE, MMCHS_ISE inorder to reduce the number of #define's. Probably yes - One way would be to use TRM fields as is, but sometimes it leads to conflicts like the DMAE/DMA_EN case. Do you think it would be better to switch to _IE suffix instead of _EN ? +#define BWR_EN (1 4) +#define BRR_EN (1 5) +#define ERR_EN (1 15) ERR_EN is not applicable for Interrupt masks for IE and ISE register Ok. The define would still be needed, but probably I shouldn't include it in INT_EN_MASK then ? +#define CTO_EN (1 16) +#define CCRC_EN(1 17) +#define CEB_EN (1 18) +#define CIE_EN (1 19) +#define DTO_EN (1 20) +#define DCRC_EN(1 21) +#define DEB_EN (1 22) +#define CERR_EN(1 28) +#define BADA_EN(1 29) + +#define INT_EN_MASK(BADA_EN | CERR_EN | DEB_EN | DCRC_EN |\ + DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | ERR_EN |\ + BRR_EN | BWR_EN | TC_EN | CC_EN) + #define MMC_AUTOSUSPEND_DELAY 100 #define MMC_TIMEOUT_MS20 #define OMAP_MMC_MIN_CLOCK40 @@ -458,13 +466,13 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host, unsigned int irq_mask; if (host-use_dma) - irq_mask = INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE); + irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN); else irq_mask = INT_EN_MASK; /* Disable timeout for erases */ if (cmd-opcode == MMC_ERASE) - irq_mask = ~DTO_ENABLE; + irq_mask = ~DTO_EN; OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR); OMAP_HSMMC_WRITE(host-base, ISE, irq_mask); @@ -702,8 +710,8 @@ static void send_init_stream(struct omap_hsmmc_host *host) OMAP_HSMMC_WRITE(host-base, CMD, INIT_STREAM_CMD); timeout =
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
+ Peter
Hi Stephen,
On 11/7/2012 6:25 PM, Stephen Warren wrote:
On 11/07/2012 03:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the versioning
provision seems to stand, I hope we address how much the fragment versioning
thing is similar to the way board revisions progress.
If a versioning syntax is available then one could create a single DT
file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start having
as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is probably
the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only the
relevant one.
Something that can find the driver that will provide the proper board version
or subsystem version or whatever like that:
compatible-version = ti,panda-version, panda;
Then at runtime we should create only the node with the correct match between
the driver version and the string version.
/* regular panda audio routing */
sound: sound {
compatible = ti,abe-twl6040;
ti,model = PandaBoard;
compatible-version = ti,panda-version, panda;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
HSMIC, Headset Mic,
Headset Mic, Headset Mic Bias,
AFML, Line In,
AFMR, Line In;
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
sound {
ti,model = PandaBoardES;
compatible-version = ti,panda-version, panda-es;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
AFML, Line In,
AFMR, Line In;
};
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Is the only difference here the content of the ti,audio-routing
property? If so, then I don't think there's any need for infra-structure
for this; the driver code already reads that property and adjusts its
behaviour based upon it.
That was just an example, and maybe not the best one. It could be any
kind of HW differences, like a different GPIO line, a different I2C
peripheral, an extra DCDC...
The point was just that you might have several version of the same node
with different attributes depending of the board revision.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
On Thu, Nov 8, 2012 at 9:14 AM, Péter Ujfalusi peter.ujfal...@ti.com wrote:
On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
+ if (pwm-hwpwm) {
+ /* PWM 1 */
+ mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
+ bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
+ } else {
+ /* PWM 0 */
+ mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
+ bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
+ }
+
+ /* Save the current MUX configuration for the PWM */
+ twl-twl4030_pwm_mux = ~mask;
+ twl-twl4030_pwm_mux |= (val mask);
Do we really need this mask clearing here? After probe twl4030_pwm_mux
should be zero, and if twl4030_pwm_request is called twice you don't
clear the important bits before |=, I think 'twl4030_pwm_mux = val
mask' would be better here.
I'm storing both PWM's state in the same variable, but in different offsets:
PWM0: bits 2-3
PWM1: bits 4-5
Probably it is over engineering to clear the relevant bits in the backup
storage, but better to be safe IMHO.
I would leave this part as it is.
Oh, it should be good then.
--
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On Thu, Nov 8, 2012 at 9:34 AM, Péter Ujfalusi peter.ujfal...@ti.com wrote:
On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
*pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
+ u8 on_time;
+ u8 pwm_config[2];
+ int base, ret;
+
+ if (duty_cycle = TWL4030_LED_MAX)
+ on_time = TWL4030_LED_MAX;
+ else if (!duty_cycle)
+ on_time = TWL4030_LED_MAX - 1;
+ else
+ on_time = TWL4030_LED_MAX - duty_cycle;
+
+ base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
+
+ pwm_config[0] = on_time;
+ pwm_config[1] = TWL4030_LED_MAX;
+
+ ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
Shouldn't this use TWL4030_MODULE_PWMA and TWL4030_MODULE_PWMB as
first argument? I can guess it works your way too, but
TWL4030_MODULE_PWMx would match the TRM better.
I don't have strong opinion regarding to this. You mean changing from:
base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
to:
if (pwm-hwpwm)
module = TWL4030_MODULE_PWMB;
else
module = TWL4030_MODULE_PWMA;
ret = twl_i2c_write(module, pwm_config, 0, 2);
But I want to note that I'm currently trying to clean up the mess around
twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
is for driving the LED A/B outputs. We should have only these modules for
PWM/LED in twl-core:
TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
for twl6030
From here the driver can figure out what to do IMHO.
There's no need to have separate TWL 'modules' for:
TWL4030_BASEADD_PWM0
TWL4030_BASEADD_PWM1
TWL4030_BASEADD_PWMA
TWL4030_BASEADD_PWMB
Well all these seem to come from TRM, no hard feelings here too but if
you are going to remove them, probably worth adding a comment.
--
Gražvydas
--
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 gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
Hi Tony, On Thu, Nov 08, 2012 at 03:10:14, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [121107 01:00]: And Daniel has started working on gpmc dt. Let us take Tony's opinion on how to deal with this, Tony ? Up to you to figure out the ordering. Maybe send pull requests for the ones that are ready to go? Pending timing related patches, a. ARM: OMAP2+: nand: remove redundant rounding b. ARM: OMAP2+: gpmc: handle additional timings c. ARM: OMAP2+: gpmc: generic timing calculation d. ARM: OMAP2+: onenand: generic timing calculation e. ARM: OMAP2+: smc91x: generic timing calculation f. ARM: OMAP2+: tusb6010: generic timing calculation can be divided to two categories, 1. timing cleanup (a,b) 2. migrate to generic timing routine (c-f) '1' has been tested on omap3evm (also with the help of a local patch adding onenand support). '2' has been verified on omap3evm onenand async operation (support for omap3evm onenand is not present in mainline) and by simulation. These changes could not be validated on boards supported in mainline that make use of runtime timing calculation as I do not have those boards. I will be sending pull request containing both sets 1 2, please let me know in case you have a different opinion. Regards Afzal
Re: [PATCH 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On 11/08/2012 01:29 PM, Grazvydas Ignotas wrote:
But I want to note that I'm currently trying to clean up the mess around
twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
is for driving the LED A/B outputs. We should have only these modules for
PWM/LED in twl-core:
TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
for twl6030
From here the driver can figure out what to do IMHO.
There's no need to have separate TWL 'modules' for:
TWL4030_BASEADD_PWM0
TWL4030_BASEADD_PWM1
TWL4030_BASEADD_PWMA
TWL4030_BASEADD_PWMB
Well all these seem to come from TRM, no hard feelings here too but if
you are going to remove them, probably worth adding a comment.
From the 'outside' of twl4030 we have: LEDA, LEDB, PWM0 and PWM1 pins. This is
more important from system integration point of view than what name the TRM
calls the PWM (PWMA) behind of the LEDA terminal for example.
At the end in the board file you will have to use something like this:
static struct pwm_lookup zoom_pwm_lookup[] = {
PWM_LOOKUP(twl-pwm, 0, leds_pwm, zoom::keypad), /* PWM0 */
PWM_LOOKUP(twl-pwm, 1, pwm-backlight, backlight), /* PWM1 */
PWM_LOOKUP(twl-pwm-led, 0, leds_pwm, zoom::blinking), /* LEDA */
};
I'll add comment to both the pwm-twl and pwm-twl-led driver for clarification.
--
Péter
--
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/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
On 10/31/2012 8:47 PM, Benoit Cousson wrote:
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
Why are you using that kind of interface? You seem to want a reference
to a device.
Cannot you have something less hard coded like:
phy_id = davinci_mdio, 0;
Benoit
I am having a issue in converting the above phy_id conversion from
davinci_mdio, 0 to
4a101000.mdio:00. Since davinci_mdio is a child node to cpsw, the
platform device for mdio is
not created to get the mdio device name 4a101000.mdio.
Can you point me a reference to get the right implementation.
Regards
Mugunthan V N
--
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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Wed, Nov 07, 2012 at 22:45:20, Kevin Hilman wrote: [...] We could perhaps add a couple of APIs to check the SYSC values when coming out of suspend and take appropriate action if the sysc cache does not match? Yes, for IPs with only SW support and no drivers, we may need something like this. But again, it needs to be suspend and idle aware, not just suspend. Ok, if the pwrmdm pre and post transition callbacks do this that should take care of both suspend and idle. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
Hi Santosh, On Tue, Nov 06, 2012 at 20:05:40, Bedia, Vaibhav wrote: Hi Santosh, On Tue, Nov 06, 2012 at 03:29:22, Shilimkar, Santosh wrote: [...] IMO, assuming that idle will not be useful from the begining is leading down the path to poor design choices that will be much more difficult to fixup down the road in order to add idle support later. We need to design both idle and suspend at the same time. I agree with Kevin. Not supporting CPUIDLE deep states can hit the active power numbers dearly. I just don't know why the SOCs don't share the standard and must have design choices. But thats another discussion. Yes, active power numbers are not comparable to OMAP :( How about leaving the timer choices as is. PER timer for clock source and wakeuptimer for clock event. Anyway in suspend the clock-source can be suspended and that is evident from recent discussion. The only downside is you won't count time in suspend which is any way the case. Vaibhav, Do you guys see any implementation bottleneck for above ? Looking at the timekeeping code I see one more potential reason for making this change. OMAP registers the 32k sync timer as the persistent clock and since there's no 32k sync timer in AM33xx it doesn't register a persistent clock right now. Based on what I understood, we need to have to register one and DMTimer1 is the only clock that can serve as the persistent clock in suspend state. When we do so we might as well use it as the clocksource. A related question that I had was, is there a mechanism to handle the 32k counter (DMTimer or sync timer) wraparound condition in suspend? Does interchanging the clksrc and clkevt look fine to you? Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Op 7 nov. 2012, om 23:35 heeft Ryan Mallon rmal...@gmail.com het volgende geschreven: On 06/11/12 08:40, Tabi Timur-B04825 wrote: On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. This is probably okay for some hardware, but doesn't work in the general case. Not all hardware is detectable, for example a cape which just adds a set of LEDs for GPIO pins. Also, some hardware might not easily be detectable without adding additional complexity to the boot loader. And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Touching the bootloader is just too accident prone, we had a ton of RMA requests for older versions of the beagleboard from people trying to upgrade u-boot. Apart from the above I'd like to have fewer points of failure. Right now I need to keep uImage and foo.dtb in sync and I hate to add u-boot to that equasion as well. regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] pwm: Drivers for twl4030/6030 PWMs and LEDs
Hello, Changes cince v1: - The turn on/off sequence has been corrected for twl4030 PWMs as suggested by Grazvydas Ignotas - Comment section added to the new drivers to describe what they are controlling The series has been tested (with additional, pending patches): Zoom2 for twl4030 PWM0 (keypad light), PWM1 (LCD backlight) BeagleBoard for twl4030 LEDB (PWMB - pmu_stat led) OMAP4 Blaze (SDP4430) for twl6030 PWM1 (keypad light), PWM2 (LCD backlight) and LED (charging indication led). Intro mail from v1: The currently available pwm-twl6030.c driver only supports TWL6030's Charging indication LED. Remove this driver and add two new ones which implements support for all PWM driven outputs: pwm-twl driver supports twl4030 (PWM 0/1) and twl6030 (PWM 1/2) instances pwm-twl-led driver supports twl4030 (PWM driven LED A/B ports) and twl6030's Charging indication LED (PWM driven). Regards, Peter --- Peter Ujfalusi (3): pwm: Remove pwm-twl6030 driver pwm: New driver to support PWMs on TWL4030/6030 series of PMICs pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs drivers/pwm/Kconfig | 19 ++- drivers/pwm/Makefile | 3 +- drivers/pwm/pwm-twl-led.c | 295 ++ drivers/pwm/pwm-twl.c | 322 ++ drivers/pwm/pwm-twl6030.c | 184 -- 5 files changed, 634 insertions(+), 189 deletions(-) create mode 100644 drivers/pwm/pwm-twl-led.c create mode 100644 drivers/pwm/pwm-twl.c delete mode 100644 drivers/pwm/pwm-twl6030.c -- 1.8.0 -- 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] pwm: Remove pwm-twl6030 driver
This driver only supported the Charging indicator LED.
New set of drivers going to provide support for both PWMs and LEDs for twl4030
and twl6030 series of PMICs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 9 ---
drivers/pwm/Makefile | 1 -
drivers/pwm/pwm-twl6030.c | 184 --
3 files changed, 194 deletions(-)
delete mode 100644 drivers/pwm/pwm-twl6030.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..e678005 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -142,15 +142,6 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
-config PWM_TWL6030
- tristate TWL6030 PWM support
- depends on TWL4030_CORE
- help
- Generic PWM framework driver for TWL6030.
-
- To compile this driver as a module, choose M here: the module
- will be called pwm-twl6030.
-
config PWM_VT8500
tristate vt8500 pwm support
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..29cf57e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,5 +11,4 @@ obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
-obj-$(CONFIG_PWM_TWL6030) += pwm-twl6030.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl6030.c b/drivers/pwm/pwm-twl6030.c
deleted file mode 100644
index 8e63878..000
--- a/drivers/pwm/pwm-twl6030.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * twl6030_pwm.c
- * Driver for PHOENIX (TWL6030) Pulse Width Modulator
- *
- * Copyright (C) 2010 Texas Instruments
- * Author: Hemanth V heman...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see http://www.gnu.org/licenses/.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/pwm.h
-#include linux/i2c/twl.h
-#include linux/slab.h
-
-#define LED_PWM_CTRL1 0xF4
-#define LED_PWM_CTRL2 0xF5
-
-/* Max value for CTRL1 register */
-#define PWM_CTRL1_MAX 255
-
-/* Pull down disable */
-#define PWM_CTRL2_DIS_PD (1 6)
-
-/* Current control 2.5 milli Amps */
-#define PWM_CTRL2_CURR_02 (2 4)
-
-/* LED supply source */
-#define PWM_CTRL2_SRC_VAC (1 2)
-
-/* LED modes */
-#define PWM_CTRL2_MODE_HW (0 0)
-#define PWM_CTRL2_MODE_SW (1 0)
-#define PWM_CTRL2_MODE_DIS (2 0)
-
-#define PWM_CTRL2_MODE_MASK0x3
-
-struct twl6030_pwm_chip {
- struct pwm_chip chip;
-};
-
-static int twl6030_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- int ret;
- u8 val;
-
- /* Configure PWM */
- val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_02 | PWM_CTRL2_SRC_VAC |
- PWM_CTRL2_MODE_HW;
-
- ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
- if (ret 0) {
- dev_err(chip-dev, %s: Failed to configure PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- return 0;
-}
-
-static int twl6030_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
-{
- u8 duty_cycle = (duty_ns * PWM_CTRL1_MAX) / period_ns;
- int ret;
-
- ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, duty_cycle, LED_PWM_CTRL1);
- if (ret 0) {
- pr_err(%s: Failed to configure PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- return 0;
-}
-
-static int twl6030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- int ret;
- u8 val;
-
- ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
- if (ret 0) {
- dev_err(chip-dev, %s: Failed to enable PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- /* Change mode to software control */
- val = ~PWM_CTRL2_MODE_MASK;
- val |= PWM_CTRL2_MODE_SW;
-
- ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
- if (ret 0) {
- dev_err(chip-dev, %s: Failed to enable PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- twl_i2c_read_u8(TWL6030_MODULE_ID1, val,
[PATCH v2 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl-led.c | 295 ++
3 files changed, 306 insertions(+)
create mode 100644 drivers/pwm/pwm-twl-led.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c577db9..49c2082 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -152,6 +152,16 @@ config PWM_TWL
To compile this driver as a module, choose M here: the module
will be called pwm-twl.
+config PWM_TWL_LED
+ tristate TWL4030/6030 PWM support for LED drivers
+ select HAVE_PWM
+ depends on TWL4030_CORE
+ help
+ Generic PWM framework driver for TWL4030/6030 LED.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-twl-led.
+
config PWM_VT8500
tristate vt8500 pwm support
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 3324c06..5f26134 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,4 +12,5 @@ obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
obj-$(CONFIG_PWM_TWL) += pwm-twl.o
+obj-$(CONFIG_PWM_TWL_LED) += pwm-twl-led.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
new file mode 100644
index 000..a9cadd8
--- /dev/null
+++ b/drivers/pwm/pwm-twl-led.c
@@ -0,0 +1,295 @@
+/*
+ * Driver for TWL4030/6030 Pulse Width Modulator used as LED driver
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This driver is a complete rewrite of the former pwm-twl6030.c authorded by:
+ * Hemanth V heman...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/pwm.h
+#include linux/i2c/twl.h
+#include linux/slab.h
+
+/*
+ * This driver handles the PWM driven LED terminals of TWL4030 and TWL6030.
+ * To generate the signal on TWL4030:
+ * - LEDA uses PWMA
+ * - LEDB uses PWMB
+ * TWL6030 has one LED pin with dedicated LEDPWM
+ */
+
+#define TWL4030_LED_MAX0x7f
+#define TWL6030_LED_MAX0xff
+
+/* Registers, bits and macro for TWL4030 */
+#define TWL4030_LEDEN_REG 0x00
+#define TWL4030_PWMA_REG 0x01
+
+#define TWL4030_LEDXON (1 0)
+#define TWL4030_LEDXPWM(1 4)
+#define TWL4030_LED_PINS (TWL4030_LEDXON | TWL4030_LEDXPWM)
+#define TWL4030_LED_TOGGLE(led, x) ((x) (led))
+
+/* Register, bits and macro for TWL6030 */
+#define TWL6030_LED_PWM_CTRL1 0xf4
+#define TWL6030_LED_PWM_CTRL2 0xf5
+
+#define TWL6040_LED_MODE_HW0x00
+#define TWL6040_LED_MODE_ON0x01
+#define TWL6040_LED_MODE_OFF 0x02
+#define TWL6040_LED_MODE_MASK 0x03
+
+struct twl_pwmled_chip {
+ struct pwm_chip chip;
+};
+
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
+ u8 on_time;
+ u8 pwm_config[2];
+ int base, ret;
+
+ if (duty_cycle = TWL4030_LED_MAX)
+ on_time = TWL4030_LED_MAX;
+ else if (!duty_cycle)
+ on_time = TWL4030_LED_MAX - 1;
+ else
+ on_time = TWL4030_LED_MAX - duty_cycle;
+
+ base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
+
+ pwm_config[0] = on_time;
+ pwm_config[1] = TWL4030_LED_MAX;
+
+ ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
+ if (ret 0)
+ dev_err(chip-dev, %s: Failed to configure PWM\n, pwm-label);
+
+ return ret;
+}
+
+static int twl4030_pwmled_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_LED, val, TWL4030_LEDEN_REG);
+
[PATCH v2 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
The driver supports the following PWM outputs:
TWL4030 PWM0 and PWM1
TWL6030 PWM1 and PWM2
On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
will select the correct mux so the PWM can be used. When the PWM has been
freed the original configuration going to be restored.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl.c | 322 ++
3 files changed, 333 insertions(+)
create mode 100644 drivers/pwm/pwm-twl.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e678005..c577db9 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -142,6 +142,16 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
+config PWM_TWL
+ tristate TWL4030/6030 PWM support
+ select HAVE_PWM
+ depends on TWL4030_CORE
+ help
+ Generic PWM framework driver for TWL4030/6030.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-twl.
+
config PWM_VT8500
tristate vt8500 pwm support
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 29cf57e..3324c06 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,4 +11,5 @@ obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
+obj-$(CONFIG_PWM_TWL) += pwm-twl.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c
new file mode 100644
index 000..26e57e9
--- /dev/null
+++ b/drivers/pwm/pwm-twl.c
@@ -0,0 +1,322 @@
+/*
+ * Driver for TWL4030/6030 Generic Pulse Width Modulator
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/pwm.h
+#include linux/i2c/twl.h
+#include linux/slab.h
+
+/*
+ * This driver handles the PWMs of TWL4030 and TWL6030.
+ * The TRM names for the PWMs on TWL4030 are: PWM0, PWM1
+ * TWL6030 also have two PWMs named in the TRM as PWM1, PWM2
+ */
+
+#define TWL_PWM_MAX0x7f
+
+/* Registers, bits and macro for TWL4030 */
+#define TWL4030_GPBR1_REG 0x0c
+#define TWL4030_PMBR1_REG 0x0d
+
+/* GPBR1 register bits */
+#define TWL4030_PWMXCLK_ENABLE (1 0)
+#define TWL4030_PWMX_ENABLE(1 2)
+#define TWL4030_PWMX_BITS (TWL4030_PWMX_ENABLE | TWL4030_PWMXCLK_ENABLE)
+#define TWL4030_PWM_TOGGLE(pwm, x) ((x) (pwm))
+
+/* PMBR1 register bits */
+#define TWL4030_GPIO6_PWM0_MUTE_MASK (0x03 2)
+#define TWL4030_GPIO6_PWM0_MUTE_PWM0 (0x01 2)
+#define TWL4030_GPIO7_VIBRASYNC_PWM1_MASK (0x03 4)
+#define TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1 (0x03 4)
+
+/* Register, bits and macro for TWL6030 */
+#define TWL6030_TOGGLE3_REG0x92
+
+#define TWL6030_PWMXR (1 0)
+#define TWL6030_PWMXS (1 1)
+#define TWL6030_PWMXEN (1 2)
+#define TWL6030_PWM_TOGGLE(pwm, x) ((x) (pwm * 3))
+
+struct twl_pwm_chip {
+ struct pwm_chip chip;
+ u8 twl6030_toggle3;
+ u8 twl4030_pwm_mux;
+};
+
+static int twl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = (duty_ns * TWL_PWM_MAX) / period_ns;
+ u8 on_time;
+ u8 pwm_config[2];
+ int base, ret;
+
+ if (duty_cycle = TWL_PWM_MAX)
+ on_time = TWL_PWM_MAX;
+ else if (!duty_cycle)
+ on_time = TWL_PWM_MAX - 1;
+ else
+ on_time = TWL_PWM_MAX - duty_cycle;
+
+ base = pwm-hwpwm * 3;
+
+ pwm_config[0] = on_time;
+ pwm_config[1] = TWL_PWM_MAX;
+
+ ret = twl_i2c_write(TWL_MODULE_PWM, pwm_config, base, 2);
+ if (ret 0)
+ dev_err(chip-dev, %s: Failed to configure PWM\n, pwm-label);
+
+ return ret;
+}
+
+static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+ if (ret 0) {
+ dev_err(chip-dev,
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Koen Kooi wrote: And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Well, U-Boot does allow you to manipulate the device tree from the command-line, but I understand that this feature doesn't work that well. -- Timur Tabi Linux kernel developer at Freescale -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
On 11/07/12 23:36, Jon Hunter wrote:
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT.
2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
separate timer structures along with the timer init functions.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
[snip]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a4ad7a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -63,20 +63,8 @@
#define OMAP2_32K_SOURCE func_32k_ck
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
#define TIMER_PROP_SECURE ti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECURE ti,timer-alwon
-#endif
+#define TIMER_PROP_ALWON ti,timer-alwon
Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
ti,timer-secure and ti,timer-alwon directly?
Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
was to drop this and use the property string directly to remove any
abstraction.
Well, I don't understand what do you mean by any abstraction.
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
I understand your point, but right now I don't anticipate that we will
have many options here and so I think that we should drop these.
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
- np = omap_get_timer_dt(omap_timer_match, ti,timer-secure);
+ np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
if (np)
of_node_put(np);
}
@@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __omap2_sync32k_clocksource_init(void)
Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
Ok.
{
int ret;
struct device_node *np = NULL;
@@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
-static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+static void __init omap2_gp_clocksource_init(int gptimer_id,
+const char *fck_source)
Nit, I personally prefer keeping gptimer, because gp just means
general-purpose and does not imply a timer per-se.
I've made this change, so we will not get something like:
omapx_gptimer_timer_init(), but this really does not meter to me,
so no problem will do for v2.
Thanks.
{
int res;
@@ -466,23 +447,10 @@
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
* Igor Grinberg grinb...@compulab.co.il [121107 23:15]: On 11/07/12 19:33, Tony Lindgren wrote: I think this should be the default for the timers as that counter does not stop during deeper idle states. Well, it is the default as you can see from the patch. The problem is that for boards that for some reason do not have the 32k wired and rely on MPU/GP timer source, the default will not work and currently there is no way for board to specify which timer source it can use. Yes. I was just wondering if we can avoid patching all the board files by doing it the other way around by introducing a new omap_gp_timer rather than renaming all the existing ones? We have discussed this in San Diego (remember?) and you actually proposed this way as a solution. Well, may be I took it a bit further than you thought, but this is because the board code cannot know which timer source should be used at runtime and the fall back described below, does not work. Yes thanks I agree we should get rid of that Kconfig option for sure. --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, OMAP2430 sdp2430 board) .handle_irq = omap2_intc_handle_irq, .init_machine = omap_2430sdp_init, .init_late = omap2430_init_late, - .timer = omap2_timer, + .timer = omap2_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, OMAP3430 3430SDP board) .handle_irq = omap3_intc_handle_irq, .init_machine = omap_3430sdp_init, .init_late = omap3430_init_late, - .timer = omap3_timer, + .timer = omap3_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END ... Can't we assume that the default timer is omap[234]_sync32k_timer to avoid renaming the timer entries in all the board files? Hmmm... How will this work with the macros defining the sys_timer structure? I would also not want to hide the exact timer used under the default name. Can't you just add a new sys_timer (or a new macro) for GP only setups? Then we just need a new timer entries for the hardware that does not have the sycn32k_timer available? Well, I tried to make it small patch just for the hardware that needs it, but I always found some corner case where, IMHO, this does not work/look good. Can you explain a bit further? I guess what I'm after is just to avoid renaming the existing timers in the board-*.c files and only rename the ones that need gp timer only. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ARM: omap: remove obsoleted init_consistent_dma_size()
* Marek Szyprowski m.szyprow...@samsung.com [121107 23:48]:
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/io.c |1 -
arch/arm/mach-omap2/io.c | 12
arch/arm/plat-omap/common.c |7 ---
arch/arm/plat-omap/include/plat/dma.h |1 -
4 files changed, 21 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 6a5baab..b3d0fb3 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -134,7 +134,6 @@ void __init omap1_init_early(void)
*/
omap1_clk_init();
omap1_mux_init();
- omap_init_consistent_dma_size();
}
void __init omap1_init_late(void)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4234d28..2597846 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -354,11 +354,6 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod
*oh, void *data)
return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
}
-static void __init omap_common_init_early(void)
-{
- omap_init_consistent_dma_size();
-}
-
static void __init omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
...
Thanks we already have a similar patch from Tomi Valkeinen queued in
the omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3 branch, so
this patch can be dropped.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/14] ARM: OMAP: Add DMTIMER definitions for posted mode
On 11/07/2012 04:04 PM, Santosh Shilimkar wrote:
On Wednesday 07 November 2012 01:01 PM, Jon Hunter wrote:
For OMAP2+ devices, when using DMTIMERs for system timers
(clock-events and
clock-source) the posted mode configuration of the timers is used. To
allow
the compiler to optimise the functions for configuring and reading the
system
timers, the posted flag variable is hard-coded with the value 1. To
make it
clear that posted mode is being used add some definitions so that it
is more
readable.
Add separate definitions for the clock-events and clock-source timers
so that
we can change the posted mode of clock-events and clock-source
independently.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 26
+++---
arch/arm/plat-omap/include/plat/dmtimer.h |4
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 0758bae..28c6078 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -82,6 +82,13 @@
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET0x14
#define NUMERATOR_DENUMERATOR_MASK0xf000
+/*
+ * For clock-events timer, always use posted mode to
+ * minimise CPU overhead for configuring the timer.
+ */
+#define OMAP_CLKEVT_POSTEDMODEOMAP_TIMER_POSTED
+#define OMAP_CLKSRC_POSTEDMODEOMAP_TIMER_POSTED
+
I don't see need of above defines. Just use OMAP_TIMER_POSTED directly
with API. Rest of the patch looks fine.
Apart from above one comment,
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Ok, updated and dropped the additional definitions. Let me know if you
are ok with this.
Cheers
Jon
From f1c783b5af933374431bcb8acb01d0b5c79d5661 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Thu, 27 Sep 2012 11:49:45 -0500
Subject: [PATCH 1/2] ARM: OMAP: Add DMTIMER definitions for posted mode
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 17 ++---
arch/arm/plat-omap/include/plat/dmtimer.h |4
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 0758bae..ad427ba 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -107,7 +107,7 @@ static int omap2_gp_timer_set_next_event(unsigned long
cycles,
struct clock_event_device *evt)
{
__omap_dm_timer_load_start(clkev, OMAP_TIMER_CTRL_ST,
- 0x - cycles, 1);
+ 0x - cycles, OMAP_TIMER_POSTED);
return 0;
}
@@ -117,7 +117,7 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
{
u32 period;
- __omap_dm_timer_stop(clkev, 1, clkev.rate);
+ __omap_dm_timer_stop(clkev, OMAP_TIMER_POSTED, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
@@ -125,10 +125,10 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
period -= 1;
/* Looks like we need to first set the load value separately */
__omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG,
- 0x - period, 1);
+ 0x - period, OMAP_TIMER_POSTED);
__omap_dm_timer_load_start(clkev,
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
- 0x - period, 1);
+ 0x - period, OMAP_TIMER_POSTED);
break;
case CLOCK_EVT_MODE_ONESHOT:
break;
@@ -358,7 +358,8 @@ static bool use_gptimer_clksrc;
*/
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
- return (cycle_t)__omap_dm_timer_read_counter(clksrc, 1);
+ return (cycle_t)__omap_dm_timer_read_counter(clksrc,
+OMAP_TIMER_POSTED);
}
static struct clocksource clocksource_gpt = {
@@ -372,7 +373,8 @@ static struct clocksource clocksource_gpt = {
static u32 notrace dmtimer_read_sched_clock(void)
{
if (clksrc.reserved)
- return __omap_dm_timer_read_counter(clksrc, 1);
+ return __omap_dm_timer_read_counter(clksrc,
+ OMAP_TIMER_POSTED);
return 0;
}
@@ -454,7 +456,8 @@
Re: [PATCH V2 03/14] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
On 11/07/2012 05:43 PM, Santosh Shilimkar wrote:
On Wednesday 07 November 2012 05:28 PM, Jon Hunter wrote:
On 11/07/2012 04:14 PM, Santosh Shilimkar wrote:
Looks sensible considering alternative WAs.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Thanks. With further thought I think that it would be best to combine
patches #2 and #3. Really the main motivation here is the errata
workaround and without actually benchmarking the timer read I should
not claim the improvement in overhead as stated in patch #2. So I
have combined #2 and #3 and updated the changelog/comments
appropriately. Let me know if you guys are ok with this.
Yep. Sounds good.
Updated, removing the additional OMAP_CLKEVT/SRC_POSTEDMODE definitions.
Cheers
Jon
From 5b55c6c2ca6f41e37f531d8ca0ea80a0e49f3e4d Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Thu, 27 Sep 2012 12:47:43 -0500
Subject: [PATCH 2/2] ARM: OMAP3+: Implement timer workaround for errata i103
and i767
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 35 +
arch/arm/plat-omap/dmtimer.c | 59 -
arch/arm/plat-omap/include/plat/dmtimer.h | 19 --
3 files changed, 100 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ad427ba..e99b95c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -224,7 +224,8 @@ void __init omap_dmtimer_init(void)
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
int gptimer_id,
const char *fck_source,
- const char *property)
+ const char *property,
+ int posted)
{
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
const char *oh_name;
@@ -310,10 +311,15 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
}
__omap_dm_timer_init_regs(timer);
__omap_dm_timer_reset(timer, 1, 1);
- timer-posted = 1;
- timer-rate =
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/8/2012 3:28 AM, Koen Kooi wrote: Op 7 nov. 2012, om 23:35 heeft Ryan Mallon rmal...@gmail.com het volgende geschreven: On 06/11/12 08:40, Tabi Timur-B04825 wrote: On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. This is probably okay for some hardware, but doesn't work in the general case. Not all hardware is detectable, for example a cape which just adds a set of LEDs for GPIO pins. Also, some hardware might not easily be detectable without adding additional complexity to the boot loader. And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Touching the bootloader is just too accident prone, we had a ton of RMA requests for older versions of the beagleboard from people trying to upgrade u-boot. One possibility for dynamic device tree mods would be to run Open Firmware from u-boot and have it generate the device tree and possibly modify it either interactively or from a script loaded from a file or the network. OFW could then either load Linux directly or return to u-boot, which would proceed with loading. Apart from the above I'd like to have fewer points of failure. Right now I need to keep uImage and foo.dtb in sync and I hate to add u-boot to that equasion as well. regards, Koen ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
On 11/07/12 23:36, Jon Hunter wrote:
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT.
2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
separate timer structures along with the timer init functions.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
[snip]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a4ad7a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -63,20 +63,8 @@
#define OMAP2_32K_SOURCE func_32k_ck
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
#define TIMER_PROP_SECUREti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECUREti,timer-alwon
-#endif
+#define TIMER_PROP_ALWON ti,timer-alwon
Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
ti,timer-secure and ti,timer-alwon directly?
Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
was to drop this and use the property string directly to remove any
abstraction.
Well, I don't understand what do you mean by any abstraction.
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and
small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
I understand your point, but right now I don't anticipate that we will
have many options here and so I think that we should drop these.
#define REALTIME_COUNTER_BASE0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
- np = omap_get_timer_dt(omap_timer_match, ti,timer-secure);
+ np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
if (np)
of_node_put(np);
}
@@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __omap2_sync32k_clocksource_init(void)
Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
Ok.
{
int ret;
struct device_node *np = NULL;
@@ -439,15 +426,9 @@ static int __init
omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
-static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+static void __init omap2_gp_clocksource_init(int gptimer_id,
+ const char *fck_source)
Nit, I personally prefer keeping gptimer, because gp just means
general-purpose and does not imply a timer per-se.
I've made
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 21:50:05, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [121107 23:15]: On 11/07/12 19:33, Tony Lindgren wrote: I think this should be the default for the timers as that counter does not stop during deeper idle states. Well, it is the default as you can see from the patch. The problem is that for boards that for some reason do not have the 32k wired and rely on MPU/GP timer source, the default will not work and currently there is no way for board to specify which timer source it can use. Yes. I was just wondering if we can avoid patching all the board files by doing it the other way around by introducing a new omap_gp_timer rather than renaming all the existing ones? We have discussed this in San Diego (remember?) and you actually proposed this way as a solution. Well, may be I took it a bit further than you thought, but this is because the board code cannot know which timer source should be used at runtime and the fall back described below, does not work. Yes thanks I agree we should get rid of that Kconfig option for sure. --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, OMAP2430 sdp2430 board) .handle_irq = omap2_intc_handle_irq, .init_machine = omap_2430sdp_init, .init_late = omap2430_init_late, -.timer = omap2_timer, +.timer = omap2_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, OMAP3430 3430SDP board) .handle_irq = omap3_intc_handle_irq, .init_machine = omap_3430sdp_init, .init_late = omap3430_init_late, -.timer = omap3_timer, +.timer = omap3_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END ... Can't we assume that the default timer is omap[234]_sync32k_timer to avoid renaming the timer entries in all the board files? Hmmm... How will this work with the macros defining the sys_timer structure? I would also not want to hide the exact timer used under the default name. Can't you just add a new sys_timer (or a new macro) for GP only setups? Then we just need a new timer entries for the hardware that does not have the sycn32k_timer available? Well, I tried to make it small patch just for the hardware that needs it, but I always found some corner case where, IMHO, this does not work/look good. Can you explain a bit further? I guess what I'm after is just to avoid renaming the existing timers in the board-*.c files and only rename the ones that need gp timer only. That would be AM33xx family :) Thanks, Vaibhav Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
On 11/07/2012 05:44 PM, Tony Lindgren wrote:
Hi Jon,
* Tony Lindgren t...@atomide.com [121106 16:48]:
* Jon Hunter jon-hun...@ti.com [121102 12:01]:
g...@github.com:jonhunter/linux.git dev-dt-timer
Thanks pulling into omap-for-v3.8/dt branch.
Looks like omap-for-v3.8/dt boots OK on blaze when booted
with device tree, but then current omap-for-v3.8/tmp-merge
oopses.
That's a bugger. I completely missed your patch last week sorry (I will blame
the Danish
beer) and had clearly not folded in to my testing!
I guess we should apply the following fix somewhere or
do we need to check other places too?
I will re-test your master branch today and put it through my dmtimer tests to
double check.
However, in general I did ensure that we checked pdata was not NULL before
accessing when
I introduced the dt stuff. In my changelog [1] I had ...
5. When device-tree is present the platform_data structure will be NULL and so
check for
this.
I just need to make sure that get_context_loss_count() is not called before
checking it is
populated.
Regards,
Tony
[c04e3d30] (omap_dm_timer_probe+0x110/0x310) from [c0334a18]
(platform_drv_probe+0x1c/0x24)
[c0334a18] (platform_drv_probe+0x1c/0x24) from [c03335d4]
(really_probe+0x60/0x1f4)
[c03335d4] (really_probe+0x60/0x1f4) from [c033379c]
(driver_probe_device+0x34/0x50)
[c033379c] (driver_probe_device+0x34/0x50) from [c033384c]
(__driver_attach+0x94/0x98)
[c033384c] (__driver_attach+0x94/0x98) from [c0331df8]
(bus_for_each_dev+0x60/0x8c)
[c0331df8] (bus_for_each_dev+0x60/0x8c) from [c03326c4]
(bus_add_driver+0x18c/0x254)
[c03326c4] (bus_add_driver+0x18c/0x254) from [c0333e44]
(driver_register+0x5c/0x150)
[c0333e44] (driver_register+0x5c/0x150) from [c0008868]
(do_one_initcall+0x2c/0x178)
[c0008868] (do_one_initcall+0x2c/0x178) from [c06df2a0]
(do_basic_setup+0x94/0xd0)
[c06df2a0] (do_basic_setup+0x94/0xd0) from [c06df358]
(kernel_init_freeable+0x7c/0x124)
[c06df358] (kernel_init_freeable+0x7c/0x124) from [c04e1810]
(kernel_init+0x8/0x1a8)
[c04e1810] (kernel_init+0x8/0x1a8) from [c0014410]
(ret_from_fork+0x14/0x24)
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -803,8 +803,11 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-pdev = pdev;
- timer-capability = pdata-timer_capability;
- timer-get_context_loss_count = pdata-get_context_loss_count;
+
+ if (pdata) {
+ timer-capability = pdata-timer_capability;
You don't need this it is already handled a few lines before.
+ timer-get_context_loss_count = pdata-get_context_loss_count;
We could probably move this too. For example ...
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 38c12ef..9dca23e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-capability = pdata-timer_capability;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
+ timer-get_context_loss_count = pdata-get_context_loss_count;
}
timer-irq = irq-start;
timer-pdev = pdev;
- timer-capability = pdata-timer_capability;
- timer-get_context_loss_count = pdata-get_context_loss_count;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
Cheers
Jon
[1] http://marc.info/?l=linux-omapm=135065877008624w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
* Jon Hunter jon-hun...@ti.com [121108 09:21]:
On 11/07/2012 05:44 PM, Tony Lindgren wrote:
That's a bugger. I completely missed your patch last week sorry (I will blame
the Danish
beer) and had clearly not folded in to my testing!
:)
I guess we should apply the following fix somewhere or
do we need to check other places too?
I will re-test your master branch today and put it through my dmtimer tests
to double check.
However, in general I did ensure that we checked pdata was not NULL before
accessing when
I introduced the dt stuff. In my changelog [1] I had ...
5. When device-tree is present the platform_data structure will be NULL and
so check for
this.
I just need to make sure that get_context_loss_count() is not called before
checking it is
populated.
OK
+
+ if (pdata) {
+ timer-capability = pdata-timer_capability;
You don't need this it is already handled a few lines before.
+ timer-get_context_loss_count = pdata-get_context_loss_count;
We could probably move this too. For example ...
OK yeah makes sense to me.
Regards,
Tony
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 38c12ef..9dca23e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-capability = pdata-timer_capability;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
+ timer-get_context_loss_count = pdata-get_context_loss_count;
}
timer-irq = irq-start;
timer-pdev = pdev;
- timer-capability = pdata-timer_capability;
- timer-get_context_loss_count = pdata-get_context_loss_count;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
Cheers
Jon
[1] http://marc.info/?l=linux-omapm=135065877008624w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 11:08 AM, Hiremath, Vaibhav wrote:
On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
On 11/07/12 23:36, Jon Hunter wrote:
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT.
2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
separate timer structures along with the timer init functions.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
[snip]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a4ad7a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -63,20 +63,8 @@
#define OMAP2_32K_SOURCE func_32k_ck
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
#define TIMER_PROP_SECUREti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECUREti,timer-alwon
-#endif
+#define TIMER_PROP_ALWON ti,timer-alwon
Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
ti,timer-secure and ti,timer-alwon directly?
Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
was to drop this and use the property string directly to remove any
abstraction.
Well, I don't understand what do you mean by any abstraction.
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and
small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
I understand your point, but right now I don't anticipate that we will
have many options here and so I think that we should drop these.
#define REALTIME_COUNTER_BASE0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
- np = omap_get_timer_dt(omap_timer_match, ti,timer-secure);
+ np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
if (np)
of_node_put(np);
}
@@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __omap2_sync32k_clocksource_init(void)
Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
Ok.
{
int ret;
struct device_node *np = NULL;
@@ -439,15 +426,9 @@ static int __init
omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
-static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+static void __init omap2_gp_clocksource_init(int gptimer_id,
+ const char *fck_source)
Nit, I personally prefer keeping gptimer, because gp just means
general-purpose and does not imply a timer per-se.
I've made this change, so we will not get something like:
[PATCH] pinctrl: pinctrl-single: Fix the pins debug output
The offset parameter is in fact the pin index. The printed value is then most of the time wrong. Multiply that value by the width to get the proper offset. Signed-off-by: Benoit Cousson b-cous...@ti.com --- Hi Tony, I guess that should probably go for 3.7-rc. Regards, Benoit drivers/pinctrl/pinctrl-single.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c index 726a729..aeca3bd 100644 --- a/drivers/pinctrl/pinctrl-single.c +++ b/drivers/pinctrl/pinctrl-single.c @@ -251,7 +251,7 @@ static void pcs_pin_dbg_show(struct pinctrl_dev *pctldev, pcs = pinctrl_dev_get_drvdata(pctldev); - val = pcs-read(pcs-base + offset); + val = pcs-read(pcs-base + offset * (pcs-width / BITS_PER_BYTE)); val = pcs-fmask; seq_printf(s, %08x %s , val, DRIVER_NAME); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
On 11/08/2012 11:08 AM, Hiremath, Vaibhav wrote:
On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
On 11/07/12 23:36, Jon Hunter wrote:
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the
platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT.
2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
separate timer structures along with the timer init functions.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
[snip]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a4ad7a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -63,20 +63,8 @@
#define OMAP2_32K_SOURCE func_32k_ck
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
#define TIMER_PROP_SECURE ti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECURE ti,timer-alwon
-#endif
+#define TIMER_PROP_ALWON ti,timer-alwon
Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
ti,timer-secure and ti,timer-alwon directly?
Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
was to drop this and use the property string directly to remove any
abstraction.
Well, I don't understand what do you mean by any abstraction.
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and
small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
I understand your point, but right now I don't anticipate that we will
have many options here and so I think that we should drop these.
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
- np = omap_get_timer_dt(omap_timer_match,
ti,timer-secure);
+ np = omap_get_timer_dt(omap_timer_match,
TIMER_PROP_SECURE);
if (np)
of_node_put(np);
}
@@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __omap2_sync32k_clocksource_init(void)
Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
Ok.
{
int ret;
struct device_node *np = NULL;
@@ -439,15 +426,9 @@ static int __init
omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
-static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+static void __init omap2_gp_clocksource_init(int gptimer_id,
+
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, 8 Nov 2012, Jon Hunter wrote: Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 PRM Clock Generator and the AM3517 DM Rev C (SPRS550C) Section 4 Clock Specifications. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: pinctrl-single: Fix the pins debug output
* Benoit Cousson b-cous...@ti.com [121108 09:46]: The offset parameter is in fact the pin index. The printed value is then most of the time wrong. Multiply that value by the width to get the proper offset. Signed-off-by: Benoit Cousson b-cous...@ti.com --- Hi Tony, I guess that should probably go for 3.7-rc. Regards, Benoit There is a similar patch already posted by Haojian at: http://www.spinics.net/lists/arm-kernel/msg205682.html Linus' take was that by definition a debug output fix is not a fix, so not for the -rc cycle. Haojian is adding support for pinconf, so let's use his version as it also removes the fmask allowing it to show the whole register. Regards, Tony drivers/pinctrl/pinctrl-single.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c index 726a729..aeca3bd 100644 --- a/drivers/pinctrl/pinctrl-single.c +++ b/drivers/pinctrl/pinctrl-single.c @@ -251,7 +251,7 @@ static void pcs_pin_dbg_show(struct pinctrl_dev *pctldev, pcs = pinctrl_dev_get_drvdata(pctldev); - val = pcs-read(pcs-base + offset); + val = pcs-read(pcs-base + offset * (pcs-width / BITS_PER_BYTE)); val = pcs-fmask; seq_printf(s, %08x %s , val, DRIVER_NAME); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
On Wed, 7 Nov 2012, Paul Walmsley wrote: On Wed, 7 Nov 2012, Paul Walmsley wrote: On Tue, 6 Nov 2012, Tony Lindgren wrote: I'm getting errors with the allnoconfig ones, there are total four omap defconfigs there not counting the randconfigs. That might indeed explain the discrepancy; so far only have been building his oldconfig seeds here. Will add his allnoconfig seeds and test again. Can reproduce this here. Thanks for catching this. Will fix and send a new pull request today and ensure that the two allnoconfigs are added to the build tests from now on. Just a quick followup on this one: I observed a couple of minor regressions during the retest, so, will deal with those before sending out a new pull request. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
On Wed, 7 Nov 2012, Mike Turquette wrote: From: Rajendra Nayak rna...@ti.com The patch is the output from a python script which converts from the old OMAP clk format to COMMON clk format using a JSON parser in between which was developed by Paul Walmsley. Signed-off-by: Rajendra Nayak rna...@ti.com [p...@pwsan.com: AM3517/05: dropped bogus hsotgusb ick and fck clkdev aliases; added hsotgusb_fck alias; added emac_ick and emac_fck aliases; replace omap2_init_clksel_parent() with omap2_clksel_find_parent_index(); reflow macros and parent name lists; add clkdm_name argument to DEFINE_STRUCT_CLK_HW_OMAP macros] Signed-off-by: Mike Turquette mturque...@ti.com Am seeing warnings during the disable-unused-clocks phase of the boot on the OMAP3 test boards here. Log is included at the bottom of this E-mail, with some debugging added for extra context. The problem appears to be that the clock code is disabling clocks that are active in the hardware, but for which the clockdomain use count is 0, since they've never been enabled. Ideally there would be some way for the core CCF code to indicate to the underlying clock hardware implementation that the disable-unused-clock process is a 'force disable'. The OMAP clock hardware implementation code could then also put the clockdomain to sleep (and skip the warning) in such a circumstance. - Paul [2.685943] disabling sys_clkout1: ec = 0 [2.690277] disabling wdt1_ick: ec = 0 [2.694366] disabling cam_mclk: ec = 0 [2.698333] [ cut here ] [2.703216] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8() [2.712646] Modules linked in: [2.715911] [c001c38c] (unwind_backtrace+0x0/0xf0) from [c0043cd8] (warn_slowpath_common+0x4c/0x64) [2.725799] [c0043cd8] (warn_slowpath_common+0x4c/0x64) from [c0043d0c] (warn_slowpath_null+0x1c/0x24) [2.735961] [c0043d0c] (warn_slowpath_null+0x1c/0x24) from [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) [2.746520] [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) [2.757781] [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) from [c0437b40] (clk_disable_unused_subtree+0x20/0xbc) [2.769226] ---[ end trace ebefd5468131571a ]--- [2.774261] disabling mspro_fck: ec = 0 [2.778320] disabling ssi_ssr_fck_3430es2: ec = 0 [2.783355] disabling pka_ick: ec = 0 [2.787231] disabling sad2d_ick: ec = 0 [2.791259] [ cut here ] [2.796142] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8() [2.805572] Modules linked in: [2.808807] [c001c38c] (unwind_backtrace+0x0/0xf0) from [c0043cd8] (warn_slowpath_common+0x4c/0x64) [2.818695] [c0043cd8] (warn_slowpath_common+0x4c/0x64) from [c0043d0c] (warn_slowpath_null+0x1c/0x24) [2.828857] [c0043d0c] (warn_slowpath_null+0x1c/0x24) from [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) [2.839416] [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) [2.850677] [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) from [c0437b40] (clk_disable_unused_subtree+0x20/0xbc) [2.862121] ---[ end trace ebefd5468131571b ]--- [2.867065] disabling wdt3_ick: ec = 0 [2.871032] disabling des1_ick: ec = 0 [2.875030] disabling sha11_ick: ec = 0 [2.879089] disabling rng_ick: ec = 0 [2.882995] disabling aes1_ick: ec = 0 [2.886932] disabling ssi_ick_3430es2: ec = 0 [2.891601] disabling mspro_ick: ec = 0 [2.895660] disabling des2_ick: ec = 0 [2.899658] disabling sha12_ick: ec = 0 [2.903686] disabling aes2_ick: ec = 0 [2.907684] disabling icr_ick: ec = 0 [2.911621] disabling wdt3_fck: ec = 0 -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 11:58 AM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 PRM Clock Generator and the AM3517 DM Rev C (SPRS550C) Section 4 Clock Specifications. Thanks Paul. But AFAICT, even in that h/w configuration the internal 32k oscillator will be used and so the gptimer will still have a 32k clock source. So I still don't see a use-case where the gptimer would not have a 32k source available. Admittedly, I could be missing one somewhere or I am just plain old wrong ... Cheers Jon -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? So I admit I am not familiar with the details on the AM stuff side so much. So maybe I should ask this question ... Do you support a configuration where there is no external 32k clock AND the internal oscillator and hence, RTC are not used? I would have expected that you would always want the RTC running, but if you are saying that you don't require an external 32k and the internal 32k is not accurate, then I assume that having the RTC available is not mandatory either. Jon -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Jon -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, 8 Nov 2012, Jon Hunter wrote: On 11/08/2012 11:58 AM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 PRM Clock Generator and the AM3517 DM Rev C (SPRS550C) Section 4 Clock Specifications. But AFAICT, even in that h/w configuration the internal 32k oscillator will be used Just to clarify, there's no internal 32k oscillator used on the 3517/3505; just a divider from the HF clock. and so the gptimer will still have a 32k clock source. That's a good question and you might want to check with Igor on that one, the AM3517 TRM conflicts with the DM as to whether it's available to the GPTIMER or not :-( - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 0/2] usb: musb: am335x support part-2
Hi, On Tue, Nov 06, 2012 at 08:44:59PM +0530, Afzal Mohammed wrote: Hi Balbi, This is a resend of remaining changes to get am335x usb working. These were sent on 31 Oct with subject, usb: musb: dsps: fixes for -rc. there is no more time for this to reach -rc. Do we need it for v3.8 merge window ? First one restores capability to support at least one instance of musb. Without it, even a single instance can't be supported as change which is reverted by it was made along with multi phy changes and nop transciever dt support, both other changes didn't make it to mainline. Second one corrects binding document; changes were made in driver as per review comments, but documentation was not updated. second one is clearly not for -rc. -- balbi signature.asc Description: Digital signature
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 23:43:31, Hunter, Jon wrote: On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? So I admit I am not familiar with the details on the AM stuff side so much. So maybe I should ask this question ... Do you support a configuration where there is no external 32k clock AND the internal oscillator and hence, RTC are not used? Why not, you could give-up on persistent time across suspend/resume and use OSC clock as a input clock to timer. And the timer code, which we have we have added fallback mechanism for this, First make sure that timer is properly set for RTC32K, if yes, then use it, and if no, then fall back to OSC clock. I would have expected that you would always want the RTC running, but if you are saying that you don't require an external 32k and the internal 32k is not accurate, then I assume that having the RTC available is not mandatory either. Yes, it is not mandatory, considering fact that, you will not have persistent time and other low-power modes. Actually it depends on board/EVM use-case, right? Thanks, Vaibhav Jon -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 12:17 PM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: On 11/08/2012 11:58 AM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 PRM Clock Generator and the AM3517 DM Rev C (SPRS550C) Section 4 Clock Specifications. But AFAICT, even in that h/w configuration the internal 32k oscillator will be used Just to clarify, there's no internal 32k oscillator used on the 3517/3505; just a divider from the HF clock. Ah yes I see that now! and so the gptimer will still have a 32k clock source. That's a good question and you might want to check with Igor on that one, the AM3517 TRM conflicts with the DM as to whether it's available to the GPTIMER or not :-( Well the external 32k and internal divided down version go through the same mux and so that seems to imply either they are both available to the gptimer or neither is. Cheers Jon -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 12:28 PM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:43:31, Hunter, Jon wrote: On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? So I admit I am not familiar with the details on the AM stuff side so much. So maybe I should ask this question ... Do you support a configuration where there is no external 32k clock AND the internal oscillator and hence, RTC are not used? Why not, you could give-up on persistent time across suspend/resume and use OSC clock as a input clock to timer. And the timer code, which we have we have added fallback mechanism for this, First make sure that timer is properly set for RTC32K, if yes, then use it, and if no, then fall back to OSC clock. You mean sync-32k and not rtc32k right? We are just detecting the presence of the sync-32k counter and if so use it, otherwise use a gptimer. I would have expected that you would always want the RTC running, but if you are saying that you don't require an external 32k and the internal 32k is not accurate, then I assume that having the RTC available is not mandatory either. Yes, it is not mandatory, considering fact that, you will not have persistent time and other low-power modes. Actually it depends on board/EVM use-case, right? Yes absolutely, just trying to understand if that is a valid use-case or not. So for AM33xx the external 32k is not mandatory. Thanks. Jon -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 01:59 AM, Igor Grinberg wrote: [snip] There is no reliable way to determine which source should be used in runtime for boards that do not have the 32k oscillator wired. So thinking about this some more and given that we are moving away from board files, if a board does not provide a 32kHz clock source, then this should be reflected in the device-tree source file for that board. Hence, at boot time we should be able to determine if a 32kHz clock source can be used. Cheers Jon -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: On 11/08/2012 01:59 AM, Igor Grinberg wrote: [snip] There is no reliable way to determine which source should be used in runtime for boards that do not have the 32k oscillator wired. So thinking about this some more and given that we are moving away from board files, if a board does not provide a 32kHz clock source, then this should be reflected in the device-tree source file for that board. Hence, at boot time we should be able to determine if a 32kHz clock source can be used. Let me feed some more thoughts here :) The way it is being detected currently is based on timer idle status bit. I am worried that, this is the only option we have. You can also refer to the implementation, so that it will help us to conclude on this - http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=58abec6ac010f4f8818caa4a52d16c4802e14acc Note that this is based on v3.2 kernel (+ additional patches), you should look the implementation of function omap_dm_timer_switch_src(). Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] Move OMAP2+ over to common clk framework
On 11/8/2012 6:42 AM, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org Hi all, This series is based on top of Paul's PRM/CM clean-up work. It is a refresh of the patches Rajendra sent out a while back[1], with the addition of several fixes for PM regressions[2] across several platforms. I have tested on OMAP4430 Panda including PRCM diffing against pre-CCF patches (delta is zero) and also suspend/resume. I also tested on OMAP4460 Panda-ES. Boot is fine and PRCM programming appears sane. However Panda-ES never comes back from suspend/resume. This problem exists on the PRM/CM branch I based on and was not introduced by this series. I am investigating that independently of this series. Anyone wanting to pull the work can find it at: git://git.linaro.org/people/mturquette/linux.git clk-omap-3.8 [1] http://article.gmane.org/gmane.linux.ports.arm.omap/78771 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/84015 Mike Turquette (3): ARM: OMAP4: clock: Convert to common clk ARM: OMAP2+: clock: remove unnecessary declarations ARM: OMAP2+: clock: Cleanup !CONFIG_COMMON_CLK parts Paul Walmsley (7): ARM: OMAP2xxx: clock: add APLL rate recalculation functions ARM: OMAP2+: clock: add OMAP CCF convenience macros to mach-omap2/clock.h ARM: AM33XX: clock: add clock data in common clock format ARM: OMAP44xx: clock: drop obsolete clock data ARM: OMAP3xxx: clk: drop obsolete clock data ARM: AM33xx: clock: drop obsolete clock data ARM: OMAP2xxx: clock: drop obsolete clock data Rajendra Nayak (15): ARM: OMAP: clock: Nuke plat/clock.c reuse struct clk as clk_hw_omap ARM: OMAP: hwmod: Fix up hwmod based clkdm accesses ARM: OMAP3: clock: Convert to common clk ARM: OMAP2: clock: Convert to common clk ARM: OMAP: clock: list all clk_hw_omap clks to enable/disable autoidle ARM: OMAP: clock: Define a function to enable clocks at init ARM: OMAP: clock: Get rid of some clkdm assocations within clks ARM: OMAP4: clock: Add 44xx data using common struct clk ARM: OMAP3: clock: Add 3xxx data using common struct clk ARM: omap2: clock: Add 24xx data using common struct clk ARM: OMAP: clock: Switch to COMMON clk ARM: OMAP: hwmod: Cleanup !CONFIG_COMMON_CLK parts ARM: OMAP4: clock: Cleanup !CONFIG_COMMON_CLK parts ARM: omap3: clock: Cleanup !CONFIG_COMMON_CLK parts ARM: omap2: clock: Cleanup !CONFIG_COMMON_CLK parts Vaibhav Hiremath (1): ARM: OMAP2+: hwmod: Invoke init_clkdm before other init functions arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile | 10 +- arch/arm/mach-omap2/cclock2420_data.c| 1959 ++ arch/arm/mach-omap2/cclock2430_data.c| 2073 +++ arch/arm/mach-omap2/cclock33xx_data.c| 961 +++ arch/arm/mach-omap2/cclock3xxx_data.c| 3595 + arch/arm/mach-omap2/cclock44xx_data.c| 1991 ++ arch/arm/mach-omap2/clkt2xxx_apll.c | 66 +- arch/arm/mach-omap2/clkt2xxx_dpll.c |8 +- arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 12 +- arch/arm/mach-omap2/clkt2xxx_osc.c | 13 +- arch/arm/mach-omap2/clkt2xxx_sys.c |7 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 11 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c |8 +- arch/arm/mach-omap2/clkt_clksel.c| 194 +- arch/arm/mach-omap2/clkt_dpll.c | 28 +- arch/arm/mach-omap2/clkt_iclk.c | 31 +- arch/arm/mach-omap2/clock.c | 845 ++ arch/arm/mach-omap2/clock.h | 356 ++- arch/arm/mach-omap2/clock2420_data.c | 1986 -- arch/arm/mach-omap2/clock2430.c |8 +- arch/arm/mach-omap2/clock2430_data.c | 2085 --- arch/arm/mach-omap2/clock2xxx.c |1 + arch/arm/mach-omap2/clock2xxx.h | 47 +- arch/arm/mach-omap2/clock33xx_data.c | 1107 arch/arm/mach-omap2/clock34xx.c | 51 +- arch/arm/mach-omap2/clock3517.c | 24 +- arch/arm/mach-omap2/clock36xx.c | 22 +- arch/arm/mach-omap2/clock36xx.h |2 +- arch/arm/mach-omap2/clock3xxx.c |6 +- arch/arm/mach-omap2/clock3xxx.h |6 +- arch/arm/mach-omap2/clock3xxx_data.c | 3613 -- arch/arm/mach-omap2/clock44xx_data.c | 3398 arch/arm/mach-omap2/clock_common_data.c | 22 +- arch/arm/mach-omap2/cm-regbits-24xx.h|5 + arch/arm/mach-omap2/cm-regbits-34xx.h| 31 + arch/arm/mach-omap2/cm2xxx_3xxx.h|1 + arch/arm/mach-omap2/dpll3xxx.c | 226 +- arch/arm/mach-omap2/dpll44xx.c | 21 +- arch/arm/mach-omap2/io.c | 25 +
[PATCH] ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC
From: Kevin Hilman khil...@ti.com
On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC. This signal
controls the secure-mode operation of the PMIC. If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.
For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.
To fix, ensure the signal is properly mux'd as output when TWL is
intialized.
This fix is required when using recent versions of u-boot (= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Based on v3.7-rc4. Targetted as a fix for v3.7.
A correponding DT fix for this is needed as well, but that will be part of
a bigger series to get PM working with DT boot and needs to include other
pins like sys_nirq1.
arch/arm/mach-omap2/twl-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 635e109..96cae8b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -73,6 +73,7 @@ void __init omap4_pmic_init(const char *pmic_type,
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
+ omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT);
omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START,
pmic_data);
/* Register additional devices on i2c1 bus if needed */
--
1.8.0
--
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+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote: On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: On 11/08/2012 01:59 AM, Igor Grinberg wrote: [snip] There is no reliable way to determine which source should be used in runtime for boards that do not have the 32k oscillator wired. So thinking about this some more and given that we are moving away from board files, if a board does not provide a 32kHz clock source, then this should be reflected in the device-tree source file for that board. Hence, at boot time we should be able to determine if a 32kHz clock source can be used. Let me feed some more thoughts here :) The way it is being detected currently is based on timer idle status bit. I am worried that, this is the only option we have. Why not use device-tree to indicate the presence of a 32k clock source? This seems like a board level configuration and so device-tree seems to be the perfect place for this IMO. Jon -- 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 00/26] Move OMAP2+ over to common clk framework
Mike Turquette mturque...@ti.com writes: Quoting Rajendra Nayak (2012-11-07 21:02:59) On Thursday 08 November 2012 06:42 AM, Mike Turquette wrote: I also tested on OMAP4460 Panda-ES. Boot is fine and PRCM programming appears sane. However Panda-ES never comes back from suspend/resume. This problem exists on the PRM/CM branch I based on and was not introduced by this series. I am investigating that independently of this series. Don't bother. Its been a know issue for a long time now. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72056.html Thanks. I realized that after posting! I think there are fixes posted to the list so I will re-test with those fixes tomorrow. I recently sent a pull request for these: http://marc.info/?l=linux-omapm=135224963505956w=2 With that, suspend/resume is working fine on 4460/Panda-ES. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
On Mon, 15 Oct 2012, Paul Walmsley wrote:
The OMAP watchdog timer driver directly calls a function exported by
code in arch/arm/mach-omap2. This is not good; it tightly couples
this driver to the mach-omap2 integration code. Instead, add a
temporary platform_data function pointer to abstract this function
call. A subsequent patch will convert the watchdog driver to use this
function pointer.
This patch also moves the device creation code out of
arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c.
This is another step towards the removal of
arch/arm/mach-omap2/devices.c.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Wim Van Sebroeck w...@iguana.be
This patch missed the change from commit
6e152231995aa4ed5eafd87a6a8348563248f843 (ARM: OMAP: avoid build wdt
platform device if with dt support) to skip the mach-omap2/ device build
if the DT blob was present. This resulted in the watchdog getting
probed twice. This didn't result in any problems, aside from a
message in the kernel log.
Anyway, here's an update with that change added.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Mon, 29 Oct 2012 20:49:44 -0600
Subject: [PATCH] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata
function pointer
The OMAP watchdog timer driver directly calls a function exported by
code in arch/arm/mach-omap2. This is not good; it tightly couples
this driver to the mach-omap2 integration code. Instead, add a
temporary platform_data function pointer to abstract this function
call. A subsequent patch will convert the watchdog driver to use this
function pointer.
This patch also moves the device creation code out of
arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c.
This is another step towards the removal of
arch/arm/mach-omap2/devices.c.
Cc: Wim Van Sebroeck w...@iguana.be
Acked-by: Wim Van Sebroeck w...@iguana.be
[p...@pwsan.com: skip wd_timer device creation when DT blob is present]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/devices.c | 21 ---
arch/arm/mach-omap2/devices.c | 26 --
arch/arm/mach-omap2/wd_timer.c | 35 +++-
include/linux/platform_data/omap-wd-timer.h | 38 +++
4 files changed, 90 insertions(+), 30 deletions(-)
create mode 100644 include/linux/platform_data/omap-wd-timer.h
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 645668e..7450318 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -17,6 +17,8 @@
#include linux/platform_device.h
#include linux/spi/spi.h
+#include linux/platform_data/omap-wd-timer.h
+
#include asm/mach/map.h
#include mach/tc.h
@@ -448,18 +450,31 @@ static struct resource wdt_resources[] = {
};
static struct platform_device omap_wdt_device = {
- .name = omap_wdt,
- .id = -1,
+ .name = omap_wdt,
+ .id = -1,
.num_resources = ARRAY_SIZE(wdt_resources),
.resource = wdt_resources,
};
static int __init omap_init_wdt(void)
{
+ struct omap_wd_timer_platform_data pdata;
+ int ret;
+
if (!cpu_is_omap16xx())
return -ENODEV;
- return platform_device_register(omap_wdt_device);
+ pdata.read_reset_sources = omap1_get_reset_sources;
+
+ ret = platform_device_register(omap_wdt_device);
+ if (!ret) {
+ ret = platform_device_add_data(omap_wdt_device, pdata,
+ sizeof(pdata));
+ if (ret)
+ platform_device_del(omap_wdt_device);
+ }
+
+ return ret;
}
subsys_initcall(omap_init_wdt);
#endif
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2ad491d..cf365c3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -646,29 +646,3 @@ static int __init omap2_init_devices(void)
return 0;
}
arch_initcall(omap2_init_devices);
-
-#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-static int __init omap_init_wdt(void)
-{
- int id = -1;
- struct platform_device *pdev;
- struct omap_hwmod *oh;
- char *oh_name = wd_timer2;
- char *dev_name = omap_wdt;
-
- if (!cpu_class_is_omap2() || of_have_populated_dt())
- return 0;
-
- oh = omap_hwmod_lookup(oh_name);
- if (!oh) {
- pr_err(Could not look up wd_timer%d hwmod\n, id);
- return -EINVAL;
- }
-
- pdev = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);
- WARN(IS_ERR(pdev), Can't build omap_device for %s:%s.\n,
- dev_name, oh-name);
- return 0;
-}
-subsys_initcall(omap_init_wdt);
-#endif
diff --git a/arch/arm/mach-omap2/wd_timer.c b/arch/arm/mach-omap2/wd_timer.c
index f6b6c37..5a8629f
Re: [PATCH] ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC
Hi,
On Thu, Nov 08, 2012 at 11:08:50AM -0800, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC. This signal
controls the secure-mode operation of the PMIC. If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.
For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.
To fix, ensure the signal is properly mux'd as output when TWL is
intialized.
This fix is required when using recent versions of u-boot (= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Based on v3.7-rc4. Targetted as a fix for v3.7.
A correponding DT fix for this is needed as well, but that will be part of
a bigger series to get PM working with DT boot and needs to include other
pins like sys_nirq1.
arch/arm/mach-omap2/twl-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 635e109..96cae8b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -73,6 +73,7 @@ void __init omap4_pmic_init(const char *pmic_type,
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
+ omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT);
omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START,
pmic_data);
/* Register additional devices on i2c1 bus if needed */
not entirely related to $SUBJECT but this essentially means we're
dropping the security feature whenever Linux runs.
Shouldn't we try to change that pin at register write boundaries so we
keep the secure feature enabled until we know we're going to write to
the HW ?
Maybe it could even be done later through pinctrl, perhaps ?
--
balbi
signature.asc
Description: Digital signature
Re: [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
On 11/08/2012 11:38 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121108 09:21]:
On 11/07/2012 05:44 PM, Tony Lindgren wrote:
That's a bugger. I completely missed your patch last week sorry (I will
blame the Danish
beer) and had clearly not folded in to my testing!
:)
I guess we should apply the following fix somewhere or
do we need to check other places too?
I will re-test your master branch today and put it through my dmtimer tests
to double check.
However, in general I did ensure that we checked pdata was not NULL before
accessing when
I introduced the dt stuff. In my changelog [1] I had ...
5. When device-tree is present the platform_data structure will be NULL and
so check for
this.
I just need to make sure that get_context_loss_count() is not called before
checking it is
populated.
OK
+
+ if (pdata) {
+ timer-capability = pdata-timer_capability;
You don't need this it is already handled a few lines before.
+ timer-get_context_loss_count = pdata-get_context_loss_count;
We could probably move this too. For example ...
OK yeah makes sense to me.
Regards,
Tony
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 38c12ef..9dca23e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-capability = pdata-timer_capability;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
+ timer-get_context_loss_count =
pdata-get_context_loss_count;
}
timer-irq = irq-start;
timer-pdev = pdev;
- timer-capability = pdata-timer_capability;
- timer-get_context_loss_count = pdata-get_context_loss_count;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
I have tested the dmtimers with this on the 3430-beagle and 4430-panda
with and without device tree and is working fine.
Do you want to generate the patch or me?
Cheers
Jon
[1] http://marc.info/?l=linux-omapm=135065877008624w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC
On 21:28-20121108, Felipe Balbi wrote:
Hi,
On Thu, Nov 08, 2012 at 11:08:50AM -0800, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC. This signal
controls the secure-mode operation of the PMIC. If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.
For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.
To fix, ensure the signal is properly mux'd as output when TWL is
intialized.
This fix is required when using recent versions of u-boot (= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Based on v3.7-rc4. Targetted as a fix for v3.7.
A correponding DT fix for this is needed as well, but that will be part of
a bigger series to get PM working with DT boot and needs to include other
pins like sys_nirq1.
arch/arm/mach-omap2/twl-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 635e109..96cae8b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -73,6 +73,7 @@ void __init omap4_pmic_init(const char *pmic_type,
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
+ omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT);
omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START,
pmic_data);
/* Register additional devices on i2c1 bus if needed */
not entirely related to $SUBJECT but this essentially means we're
dropping the security feature whenever Linux runs.
Unless we intend to remove RTC driver in it's entirety and implement RTC
time change update in secure driver, current twl rtc driver was never
meant to exist with RTC time updates only in trustzone mode. Neither does
it drop any security feature when ever Linux runs- msecure pin has not
been used for any other purpose to my knowledge with Linux. So, this
change does not change the status quo we are currently in,
Shouldn't we try to change that pin at register write boundaries so we
keep the secure feature enabled until we know we're going to write to
the HW ?
Maybe it could even be done later through pinctrl, perhaps ?
That might be a better solution I agree. We might be locking down to a
specific pin name here, which could potentially change in a future SoC.
The right approach IMHO would be omap_gpio_mux equivalent.
Example change for OMAP5 purely from a board perspective(gerrit warning):
http://review.omapzoom.org/#/c/23819/5/arch/arm/mach-omap2/board-omap5evm.c,unified
Further, depending on how it is hooked on a different board (not that I
have seen any different other than msecure), it might even be hooked on
to another GPIO, making this scenario not scaling to theoretical board
configuration.
--
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: OMAP1: use BUG_ON where possible
Just use BUG_ON() instead of constructions such as: if (...) BUG() A simplified version of the semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // smpl @@ expression e; @@ - if (e) BUG(); + BUG_ON(e); // /smpl Signed-off-by: Sasha Levin sasha.le...@oracle.com --- arch/arm/mach-omap1/board-fsample.c |3 +-- arch/arm/mach-omap1/board-h2.c |3 +-- arch/arm/mach-omap1/board-h3.c |3 +-- arch/arm/mach-omap1/board-perseus2.c |3 +-- 4 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap1/board-fsample.c b/arch/arm/mach-omap1/board-fsample.c index 8b5800a..7ca6cc4 100644 --- a/arch/arm/mach-omap1/board-fsample.c +++ b/arch/arm/mach-omap1/board-fsample.c @@ -307,8 +307,7 @@ static void __init omap_fsample_init(void) fsample_init_smc91x(); - if (gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, NAND ready) 0) - BUG(); + BUG_ON(gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, NAND ready) 0); gpio_direction_input(FSAMPLE_NAND_RB_GPIO_PIN); omap_cfg_reg(L3_1610_FLASH_CS2B_OE); diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c index 9134b64..4953cf7 100644 --- a/arch/arm/mach-omap1/board-h2.c +++ b/arch/arm/mach-omap1/board-h2.c @@ -412,8 +412,7 @@ static void __init h2_init(void) h2_nand_resource.end = h2_nand_resource.start = OMAP_CS2B_PHYS; h2_nand_resource.end += SZ_4K - 1; - if (gpio_request(H2_NAND_RB_GPIO_PIN, NAND ready) 0) - BUG(); + BUG_ON(gpio_request(H2_NAND_RB_GPIO_PIN, NAND ready) 0); gpio_direction_input(H2_NAND_RB_GPIO_PIN); omap_cfg_reg(L3_1610_FLASH_CS2B_OE); diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c index bf213d1..563ba16 100644 --- a/arch/arm/mach-omap1/board-h3.c +++ b/arch/arm/mach-omap1/board-h3.c @@ -406,8 +406,7 @@ static void __init h3_init(void) nand_resource.end = nand_resource.start = OMAP_CS2B_PHYS; nand_resource.end += SZ_4K - 1; - if (gpio_request(H3_NAND_RB_GPIO_PIN, NAND ready) 0) - BUG(); + BUG_ON(gpio_request(H3_NAND_RB_GPIO_PIN, NAND ready) 0); gpio_direction_input(H3_NAND_RB_GPIO_PIN); /* GPIO10 Func_MUX_CTRL reg bit 29:27, Configure V2 to mode1 as GPIO */ diff --git a/arch/arm/mach-omap1/board-perseus2.c b/arch/arm/mach-omap1/board-perseus2.c index 030bd48..67c2612 100644 --- a/arch/arm/mach-omap1/board-perseus2.c +++ b/arch/arm/mach-omap1/board-perseus2.c @@ -275,8 +275,7 @@ static void __init omap_perseus2_init(void) perseus2_init_smc91x(); - if (gpio_request(P2_NAND_RB_GPIO_PIN, NAND ready) 0) - BUG(); + BUG_ON(gpio_request(P2_NAND_RB_GPIO_PIN, NAND ready) 0); gpio_direction_input(P2_NAND_RB_GPIO_PIN); omap_cfg_reg(L3_1610_FLASH_CS2B_OE); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
On 11/02/2012 07:32 AM, Vaibhav Bedia wrote: AM33XX has only one usable timer in the WKUP domain. Currently the timer instance in WKUP domain is used as the clockevent and the timer in non-WKUP domain as the clocksource. The timer in WKUP domain can keep running in suspend from a 32K clock and hence serve as the persistent clock. To enable this, interchange the timers used as clocksource and clockevent for AM33XX. A subsequent patch will add suspend-resume support for the clockevent to ensure that there are no issues with timekeeping. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com --- arch/arm/mach-omap2/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 565e575..6584ee0 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -460,7 +460,7 @@ OMAP_SYS_TIMER(3_secure) #endif #ifdef CONFIG_SOC_AM33XX -OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE) +OMAP_SYS_TIMER_INIT(3_am33xx, 2, OMAP4_MPU_SOURCE, 1, OMAP4_MPU_SOURCE) OMAP_SYS_TIMER(3_am33xx) #endif By the way, for v3.8 (assuming that timer DT patches go in, currently queued in Tony's master), when booting with DT the clock-source and clock-events will be selected by timer feature and not ID. So you may wish to rebase on top of Tony's master. Cheers Jon -- 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 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
Quoting Paul Walmsley (2012-11-08 10:08:16) On Wed, 7 Nov 2012, Mike Turquette wrote: From: Rajendra Nayak rna...@ti.com The patch is the output from a python script which converts from the old OMAP clk format to COMMON clk format using a JSON parser in between which was developed by Paul Walmsley. Signed-off-by: Rajendra Nayak rna...@ti.com [p...@pwsan.com: AM3517/05: dropped bogus hsotgusb ick and fck clkdev aliases; added hsotgusb_fck alias; added emac_ick and emac_fck aliases; replace omap2_init_clksel_parent() with omap2_clksel_find_parent_index(); reflow macros and parent name lists; add clkdm_name argument to DEFINE_STRUCT_CLK_HW_OMAP macros] Signed-off-by: Mike Turquette mturque...@ti.com Am seeing warnings during the disable-unused-clocks phase of the boot on the OMAP3 test boards here. Log is included at the bottom of this E-mail, with some debugging added for extra context. The problem appears to be that the clock code is disabling clocks that are active in the hardware, but for which the clockdomain use count is 0, since they've never been enabled. Right. The old omap2_disabled_unused_clocks code used to call omap2_clk_enable before calling omap2_clk_disable. That approach is sort of cooking the books and the generic implementation in drivers/clk/clk.c simply disables the clocks (without first enabling), which is why these WARNs are new. Ideally there would be some way for the core CCF code to indicate to the underlying clock hardware implementation that the disable-unused-clock process is a 'force disable'. The OMAP clock hardware implementation code could then also put the clockdomain to sleep (and skip the warning) in such a circumstance. I'm looking at a few different ways to do that now. Regards, Mike - Paul [2.685943] disabling sys_clkout1: ec = 0 [2.690277] disabling wdt1_ick: ec = 0 [2.694366] disabling cam_mclk: ec = 0 [2.698333] [ cut here ] [2.703216] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8() [2.712646] Modules linked in: [2.715911] [c001c38c] (unwind_backtrace+0x0/0xf0) from [c0043cd8] (warn_slowpath_common+0x4c/0x64) [2.725799] [c0043cd8] (warn_slowpath_common+0x4c/0x64) from [c0043d0c] (warn_slowpath_null+0x1c/0x24) [2.735961] [c0043d0c] (warn_slowpath_null+0x1c/0x24) from [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) [2.746520] [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) [2.757781] [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) from [c0437b40] (clk_disable_unused_subtree+0x20/0xbc) [2.769226] ---[ end trace ebefd5468131571a ]--- [2.774261] disabling mspro_fck: ec = 0 [2.778320] disabling ssi_ssr_fck_3430es2: ec = 0 [2.783355] disabling pka_ick: ec = 0 [2.787231] disabling sad2d_ick: ec = 0 [2.791259] [ cut here ] [2.796142] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8() [2.805572] Modules linked in: [2.808807] [c001c38c] (unwind_backtrace+0x0/0xf0) from [c0043cd8] (warn_slowpath_common+0x4c/0x64) [2.818695] [c0043cd8] (warn_slowpath_common+0x4c/0x64) from [c0043d0c] (warn_slowpath_null+0x1c/0x24) [2.828857] [c0043d0c] (warn_slowpath_null+0x1c/0x24) from [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) [2.839416] [c003705c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) [2.850677] [c0437bd0] (clk_disable_unused_subtree+0xb0/0xbc) from [c0437b40] (clk_disable_unused_subtree+0x20/0xbc) [2.862121] ---[ end trace ebefd5468131571b ]--- [2.867065] disabling wdt3_ick: ec = 0 [2.871032] disabling des1_ick: ec = 0 [2.875030] disabling sha11_ick: ec = 0 [2.879089] disabling rng_ick: ec = 0 [2.882995] disabling aes1_ick: ec = 0 [2.886932] disabling ssi_ick_3430es2: ec = 0 [2.891601] disabling mspro_ick: ec = 0 [2.895660] disabling des2_ick: ec = 0 [2.899658] disabling sha12_ick: ec = 0 [2.903686] disabling aes2_ick: ec = 0 [2.907684] disabling icr_ick: ec = 0 [2.911621] disabling wdt3_fck: ec = 0 -- 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 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
On Thu, 8 Nov 2012, Paul Walmsley wrote: Am seeing warnings during the disable-unused-clocks phase of the boot on the OMAP3 test boards here. Similar problems during system suspend on 3530ES3 Beagle. Not sure what's causing these yet. At this point the clockdomain usecounts should be accurate. - Paul root@beagleboard:~# echo mem /sys/power/state [ 36.488800] PM: Syncing filesystems ... done. [ 37.037841] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 37.059600] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 37.082885] Suspending console(s) (use no_console_suspend to debug) [ 37.222747] PM: suspend of devices complete after 129.791 msecs [ 37.228057] PM: late suspend of devices complete after 5.310 msecs [ 37.235412] [ cut here ] [ 37.235473] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8() [ 37.235504] Modules linked in: [ 37.235565] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c00435f8] (warn_slowpath_common+0x4c/0x64) [ 37.235565] [c00435f8] (warn_slowpath_common+0x4c/0x64) from [c004362c] (warn_slowpath_null+0x1c/0x24) [ 37.235595] [c004362c] (warn_slowpath_null+0x1c/0x24) from [c003697c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) [ 37.235626] [c003697c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [c0437d1c] (__clk_disable+0x70/0xa8) [ 37.235656] [c0437d1c] (__clk_disable+0x70/0xa8) from [c0437d74] (clk_disable+0x20/0x34) [ 37.235687] [c0437d74] (clk_disable+0x20/0x34) from [c002a330] (_disable_clocks+0x18/0x68) [ 37.235717] [c002a330] (_disable_clocks+0x18/0x68) from [c002b09c] (_idle+0xf8/0x1b4) [ 37.235717] [c002b09c] (_idle+0xf8/0x1b4) from [c002bf08] (omap_hwmod_idle+0x24/0x40) [ 37.235748] [c002bf08] (omap_hwmod_idle+0x24/0x40) from [c002ce34] (omap_device_idle_hwmods+0x24/0x3c) [ 37.235778] [c002ce34] (omap_device_idle_hwmods+0x24/0x3c) from [c002d024] (_omap_device_deactivate+0x9c/0x138) [ 37.235778] [c002d024] (_omap_device_deactivate+0x9c/0x138) from [c002d984] (omap_device_idle+0x28/0x54) [ 37.235809] [c002d984] (omap_device_idle+0x28/0x54) from [c002da48] (_od_suspend_noirq+0x74/0x7c) [ 37.235839] [c002da48] (_od_suspend_noirq+0x74/0x7c) from [c034cbec] (dpm_run_callback.clone.9+0x30/0xb4) [ 37.235870] [c034cbec] (dpm_run_callback.clone.9+0x30/0xb4) from [c034d440] (dpm_suspend_end+0x364/0x554) [ 37.235870] [c034d440] (dpm_suspend_end+0x364/0x554) from [c0084ec0] (suspend_devices_and_enter+0xbc/0x2d0) [ 37.235900] [c0084ec0] (suspend_devices_and_enter+0xbc/0x2d0) from [c0085260] (pm_suspend+0x18c/0x208) [ 37.235931] [c0085260] (pm_suspend+0x18c/0x208) from [c00844f4] (state_store+0x120/0x134) [ 37.235961] [c00844f4] (state_store+0x120/0x134) from [c02d29b8] (kobj_attr_store+0x14/0x20) [ 37.235992] [c02d29b8] (kobj_attr_store+0x14/0x20) from [c017a630] (sysfs_write_file+0x100/0x184) [ 37.236022] [c017a630] (sysfs_write_file+0x100/0x184) from [c0116630] (vfs_write+0xb4/0x148) [ 37.236022] [c0116630] (vfs_write+0xb4/0x148) from [c01168b4] (sys_write+0x40/0x6c) [ 37.236053] [c01168b4] (sys_write+0x40/0x6c) from [c0013ee0] (ret_fast_syscall+0x0/0x3c) [ 37.236083] ---[ end trace 86835b3ee8ec9dde ]--- [ 37.236083] [ cut here ] [ 37.236114] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8() [ 37.236145] Modules linked in: [ 37.236175] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c00435f8] (warn_slowpath_common+0x4c/0x64) [ 37.236175] [c00435f8] (warn_slowpath_common+0x4c/0x64) from [c004362c] (warn_slowpath_null+0x1c/0x24) [ 37.236206] [c004362c] (warn_slowpath_null+0x1c/0x24) from [c003697c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) [ 37.236236] [c003697c] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [c0437d1c] (__clk_disable+0x70/0xa8) [ 37.236267] [c0437d1c] (__clk_disable+0x70/0xa8) from [c0437d74] (clk_disable+0x20/0x34) [ 37.236267] [c0437d74] (clk_disable+0x20/0x34) from [c002a330] (_disable_clocks+0x18/0x68) [ 37.236297] [c002a330] (_disable_clocks+0x18/0x68) from [c002b09c] (_idle+0xf8/0x1b4) [ 37.236328] [c002b09c] (_idle+0xf8/0x1b4) from [c002bf08] (omap_hwmod_idle+0x24/0x40) [ 37.236328] [c002bf08] (omap_hwmod_idle+0x24/0x40) from [c002ce34] (omap_device_idle_hwmods+0x24/0x3c) [ 37.236358] [c002ce34] (omap_device_idle_hwmods+0x24/0x3c) from [c002d024] (_omap_device_deactivate+0x9c/0x138) [ 37.236389] [c002d024] (_omap_device_deactivate+0x9c/0x138) from [c002d984] (omap_device_idle+0x28/0x54) [ 37.236389] [c002d984] (omap_device_idle+0x28/0x54) from [c002da48] (_od_suspend_noirq+0x74/0x7c) [ 37.236419] [c002da48] (_od_suspend_noirq+0x74/0x7c) from [c034cbec] (dpm_run_callback.clone.9+0x30/0xb4) [ 37.236450] [c034cbec] (dpm_run_callback.clone.9+0x30/0xb4) from [c034d440] (dpm_suspend_end+0x364/0x554) [ 37.236450] [c034d440] (dpm_suspend_end+0x364/0x554) from [c0084ec0]
Re: [PATCH 08/13] ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions
On Thu, 25 Oct 2012, Paul Walmsley wrote:
Convert the OMAP clock code's _omap2_module_wait_ready() to use
SoC-independent CM functions that are provided by the CM code, rather
than using a deprecated function from mach-omap2/prcm.c.
This facilitates the future conversion of the CM code to a driver, and
also removes a mach-omap2/prcm.c user. mach-omap2/prcm.c will be removed
by a subsequent patch.
Signed-off-by: Paul Walmsley p...@pwsan.com
Here's an update of this one. Further testing with the AM3517/3505 boards
resulted in a warning message being logged from _omap2_wait_module_ready()
for emac_ick. The AM3517 designers didn't integrate the IPSS IDLEST bits
into the CM as other OMAPs do. They just put them into the SCM module.
This shortcut taken during hardware integration just resulted in more time
wasted on the software side :-(
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Mon, 29 Oct 2012 20:56:29 -0600
Subject: [PATCH] ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to
use SoC-independent CM functions
Convert the OMAP clock code's _omap2_module_wait_ready() to use
SoC-independent CM functions that are provided by the CM code, rather
than using a deprecated function from mach-omap2/prcm.c.
This facilitates the future conversion of the CM code to a driver, and
also removes a mach-omap2/prcm.c user. mach-omap2/prcm.c will be removed
by a subsequent patch.
Some modules have IDLEST registers that aren't in the CM module, such
as the AM3517 IDLEST bits. So we also need a fallback function for
these non-CM odd cases. Create a temporary one in mach-omap2/clock.c,
intended to exist until the SCM drivers are ready.
Signed-off-by: Paul Walmsley p...@pwsan.com
Tested-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/clock.c | 56 +++--
arch/arm/mach-omap2/cm.h| 12 ++-
arch/arm/mach-omap2/cm2xxx.c| 65 ++
arch/arm/mach-omap2/cm2xxx.h|4 +++
arch/arm/mach-omap2/cm3xxx.c| 66 +++
arch/arm/mach-omap2/cm3xxx.h|5 +++
arch/arm/mach-omap2/cm_common.c | 48
arch/arm/mach-omap2/io.c|5 +++
8 files changed, 257 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 9205ea7..2fe57d6 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -33,10 +33,18 @@
#include soc.h
#include clockdomain.h
#include clock.h
+#include cm.h
#include cm2xxx.h
#include cm3xxx.h
#include cm-regbits-24xx.h
#include cm-regbits-34xx.h
+#include common.h
+
+/*
+ * MAX_MODULE_ENABLE_WAIT: maximum of number of microseconds to wait
+ * for a module to indicate that it is no longer in idle
+ */
+#define MAX_MODULE_ENABLE_WAIT 10
u16 cpu_mask;
@@ -58,6 +66,40 @@ static DEFINE_SPINLOCK(clockfw_lock);
/* Private functions */
+
+/**
+ * _wait_idlest_generic - wait for a module to leave the idle state
+ * @reg: virtual address of module IDLEST register
+ * @mask: value to mask against to determine if the module is active
+ * @idlest: idle state indicator (0 or 1) for the clock
+ * @name: name of the clock (for printk)
+ *
+ * Wait for a module to leave idle, where its idle-status register is
+ * not inside the CM module. Returns 1 if the module left idle
+ * promptly, or 0 if the module did not leave idle before the timeout
+ * elapsed. XXX Deprecated - should be moved into drivers for the
+ * individual IP block that the IDLEST register exists in.
+ */
+static int _wait_idlest_generic(void __iomem *reg, u32 mask, u8 idlest,
+ const char *name)
+{
+ int i = 0, ena = 0;
+
+ ena = (idlest) ? 0 : mask;
+
+ omap_test_timeout(((__raw_readl(reg) mask) == ena),
+ MAX_MODULE_ENABLE_WAIT, i);
+
+ if (i MAX_MODULE_ENABLE_WAIT)
+ pr_debug(omap clock: module associated with clock %s ready
after %d loops\n,
+name, i);
+ else
+ pr_err(omap clock: module associated with clock %s didn't
enable in %d tries\n,
+ name, MAX_MODULE_ENABLE_WAIT);
+
+ return (i MAX_MODULE_ENABLE_WAIT) ? 1 : 0;
+};
+
/**
* _omap2_module_wait_ready - wait for an OMAP module to leave IDLE
* @clk: struct clk * belonging to the module
@@ -71,7 +113,9 @@ static DEFINE_SPINLOCK(clockfw_lock);
static void _omap2_module_wait_ready(struct clk *clk)
{
void __iomem *companion_reg, *idlest_reg;
- u8 other_bit, idlest_bit, idlest_val;
+ u8 other_bit, idlest_bit, idlest_val, idlest_reg_id;
+ s16 prcm_mod;
+ int r;
/* Not all modules have multiple clocks that their IDLEST depends on */
if (clk-ops-find_companion) {
@@ -82,8 +126,14 @@ static void _omap2_module_wait_ready(struct clk *clk)
clk-ops-find_idlest(clk, idlest_reg,
[PATCH] ARM: OMAP2+: clockdomain: disabling unused clks
The OMAP port to the common clk framework[1] resulted in spurious WARNs
while disable unused clocks. This is due to _clkdm_clk_hwmod_disable
catching clkdm-usecount's with a value of zero. Even less desirable it
would not allow the clkdm_clk_disable function pointer to get called due
to an early return of -ERANGE.
This patch adds a check for such a corner case by skipping the WARN and
early return in the event that clkdm-usecount and clk-enable_usecount
are both zero. Presumably this could only happen during the check for
unused clocks at boot-time.
[1] http://article.gmane.org/gmane.linux.ports.arm.omap/88824
Signed-off-by: Mike Turquette mturque...@ti.com
---
arch/arm/mach-omap2/clockdomain.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 64e5046..b0c0ce6 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -947,16 +947,22 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
return 0;
}
-static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm)
+static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm,
+ struct clk *clk)
{
unsigned long flags;
+ int clk_enable_count = 1;
if (!clkdm || !arch_clkdm || !arch_clkdm-clkdm_clk_disable)
return -EINVAL;
spin_lock_irqsave(clkdm-lock, flags);
- if (atomic_read(clkdm-usecount) == 0) {
+ /* corner case: disabling unused clocks */
+ if (clk)
+ clk_enable_count = __clk_get_enable_count(clk);
+
+ if (atomic_read(clkdm-usecount) == 0 clk_enable_count) {
spin_unlock_irqrestore(clkdm-lock, flags);
WARN_ON(1); /* underflow */
return -ERANGE;
@@ -1026,7 +1032,7 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ return _clkdm_clk_hwmod_disable(clkdm, clk);
}
/**
@@ -1089,6 +1095,6 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct
omap_hwmod *oh)
if (!oh)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ return _clkdm_clk_hwmod_disable(clkdm, NULL);
}
--
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 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
On Thu, 8 Nov 2012, Paul Walmsley wrote: On Thu, 8 Nov 2012, Paul Walmsley wrote: Am seeing warnings during the disable-unused-clocks phase of the boot on the OMAP3 test boards here. Similar problems during system suspend on 3530ES3 Beagle. Not sure what's causing these yet. At this point the clockdomain usecounts should be accurate. Here's a redacted debugging log for these cases. The suspend events start around the 30 second mark. One observation is that dpll4_m5x2_ck and dpll4_m6x2_ck are never enabled. The tracebacks occur when something in the suspend path tries to disable those clocks. - Paul [0.135528] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck [0.135559] clockdomain: dpll4_clkdm: enabled [0.135589] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck [0.135711] clockdomain: dpll4_clkdm: disabled [0.135772] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck [0.135803] clockdomain: dpll4_clkdm: enabled [0.135833] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [0.135894] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [0.135925] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck [0.135955] clockdomain: dpll4_clkdm: disabled [0.135986] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck [0.136016] clockdomain: dpll4_clkdm: enabled [0.136047] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [0.136138] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [0.136169] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck [0.136169] clockdomain: dpll4_clkdm: disabled [0.136260] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck [0.136291] clockdomain: dpll4_clkdm: enabled [0.136322] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [0.140594] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck [0.140686] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck [0.140838] disabling clkdm dpll4_clkdm during disable of clk dpll4_m3x2_ck [0.140930] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck [0.141479] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck [0.141571] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck [0.141601] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck [0.141662] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck [0.141693] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck [0.141784] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck [0.141815] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck [0.141876] disabling clkdm dpll4_clkdm during disable of clk dpll4_m3x2_ck [3.399200] disabling clkdm dpll4_clkdm during disable of clk dpll4_m6x2_ck [3.417694] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [3.445251] ---[ end trace 72e2d7bdcf98ea8b ]--- [3.450134] disabling clkdm dpll4_clkdm during disable of clk dpll4_m5x2_ck [3.453918] clockdomain: dpll4_clkdm: disabled [3.477569] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [3.505096] ---[ end trace 72e2d7bdcf98ea8c ]--- [3.531280] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [3.558807] ---[ end trace 72e2d7bdcf98ea8d ]--- [ 38.999145] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [ 38.999267] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [ 38.999816] ---[ end trace 72e2d7bdcf98ea8e ]--- [ 38.999816] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck [ 38.08] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [ 39.000366] ---[ end trace 72e2d7bdcf98ea8f ]--- [ 42.169647] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck [ 42.169647] clockdomain: dpll4_clkdm: enabled [ 42.169677] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [ 45.730346] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [ 45.795654] ---[ end trace 72e2d7bdcf98ea90 ]--- -- 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: OMAP: Fix kernel panic in dmtimer probe
When booting with device-tree the kernel is panicing in the probe of the
DMTIMER driver. The panic is caused because the pointer to platform_data
structure is NULL when booting with device-tree and the driver is
attempting to access the structure without checking if the pointer is
valid.
Fix this by moving the code that accesses the platform data structure
under the else clause of the if (dev-of_node) statement because
here the pointer to platform_data is guaranteed to be valid. The code
accessing the timer_capability member of the platform data is simply
removed as this is already handled under the else clause.
This regression was introduced while integrating commit ARM: OMAP: Add
DT support for timer driver to add device-tree support to the DMTIMER
driver and commit ARM: OMAP: Move omap-pm-noop.c local to mach-omap2
to prepare for single zImage support.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 38c12ef..9dca23e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-capability = pdata-timer_capability;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
+ timer-get_context_loss_count = pdata-get_context_loss_count;
}
timer-irq = irq-start;
timer-pdev = pdev;
- timer-capability = pdata-timer_capability;
- timer-get_context_loss_count = pdata-get_context_loss_count;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
--
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: [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
On 11/08/2012 01:47 PM, Jon Hunter wrote: Do you want to generate the patch or me? Patch posted here ... http://marc.info/?l=linux-omapm=135242025202171w=2 Cheers Jon -- 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 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
On Fri, 9 Nov 2012, Paul Walmsley wrote: One observation is that dpll4_m5x2_ck and dpll4_m6x2_ck are never enabled. The tracebacks occur when something in the suspend path tries to disable those clocks. Sorry, this part is inaccurate - I misread the trace. The suspend path errors are coming from a disable of dpll4_m2x2_ck which is probably caused by the disable of i2c1_fck. Here's the unredacted trace of this section. The enables and disables of dpll4_m2x2_ck from the entire log appear to be balanced: [0.135589] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [0.135833] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [0.135894] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [0.136047] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [0.136138] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [0.136322] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck [ 38.999145] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck - Paul [ 38.986267] PM: suspend of devices complete after 129.760 msecs [ 38.991668] PM: late suspend of devices complete after 5.340 msecs [ 38.996459] disabling clkdm core_l4_clkdm during disable of clk mmchs1_fck [ 38.998718] disabling clkdm per_clkdm during disable of clk uart3_fck [ 38.998840] disabling clkdm core_l4_clkdm during disable of clk uart2_fck [ 38.998931] disabling clkdm core_l4_clkdm during disable of clk uart1_fck [ 38.999114] disabling clkdm core_l4_clkdm during disable of clk i2c1_fck [ 38.999145] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck [ 38.999145] [ cut here ] [ 38.999206] WARNING: at arch/arm/mach-omap2/clockdomain.c:962 _clkdm_clk_hwmod_disable+0xa4/0xf8() [ 38.999206] Modules linked in: [ 38.999267] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [ 38.999298] [c0043680] (warn_slowpath_common+0x4c/0x64) from [c00436b4] (warn_slowpath_null+0x1c/0x24) [ 38.999328] [c00436b4] (warn_slowpath_null+0x1c/0x24) from [c003695c] (_clkdm_clk_hwmod_disable+0xa4/0xf8) [ 38.999359] [c003695c] (_clkdm_clk_hwmod_disable+0xa4/0xf8) from [c0437d38] (__clk_disable+0x70/0xac) [ 38.999389] [c0437d38] (__clk_disable+0x70/0xac) from [c0437d94] (clk_disable+0x20/0x34) [ 38.999420] [c0437d94] (clk_disable+0x20/0x34) from [c002a330] (_disable_clocks+0x18/0x68) [ 38.999420] [c002a330] (_disable_clocks+0x18/0x68) from [c002b09c] (_idle+0xf8/0x1b4) [ 38.999450] [c002b09c] (_idle+0xf8/0x1b4) from [c002bf08] (omap_hwmod_idle+0x24/0x40) [ 38.999481] [c002bf08] (omap_hwmod_idle+0x24/0x40) from [c002ce34] (omap_device_idle_hwmods+0x24/0x3c) [ 38.999511] [c002ce34] (omap_device_idle_hwmods+0x24/0x3c) from [c002d024] (_omap_device_deactivate+0x9c/0x138) [ 38.999511] [c002d024] (_omap_device_deactivate+0x9c/0x138) from [c002d984] (omap_device_idle+0x28/0x54) [ 38.999542] [c002d984] (omap_device_idle+0x28/0x54) from [c002da48] (_od_suspend_noirq+0x74/0x7c) [ 38.999572] [c002da48] (_od_suspend_noirq+0x74/0x7c) from [c034cc6c] (dpm_run_callback.clone.9+0x30/0xb4) [ 38.999603] [c034cc6c] (dpm_run_callback.clone.9+0x30/0xb4) from [c034d4c0] (dpm_suspend_end+0x364/0x554) [ 38.999603] [c034d4c0] (dpm_suspend_end+0x364/0x554) from [c0084f48] (suspend_devices_and_enter+0xbc/0x2d0) [ 38.999633] [c0084f48] (suspend_devices_and_enter+0xbc/0x2d0) from [c00852e8] (pm_suspend+0x18c/0x208) [ 38.999664] [c00852e8] (pm_suspend+0x18c/0x208) from [c008457c] (state_store+0x120/0x134) [ 38.999694] [c008457c] (state_store+0x120/0x134) from [c02d2a38] (kobj_attr_store+0x14/0x20) [ 38.999725] [c02d2a38] (kobj_attr_store+0x14/0x20) from [c017a6b8] (sysfs_write_file+0x100/0x184) [ 38.999755] [c017a6b8] (sysfs_write_file+0x100/0x184) from [c01166b8] (vfs_write+0xb4/0x148) [ 38.999755] [c01166b8] (vfs_write+0xb4/0x148) from [c011693c] (sys_write+0x40/0x6c) [ 38.999786] [c011693c] (sys_write+0x40/0x6c) from [c0013ee0] (ret_fast_syscall+0x0/0x3c) [ 38.999816] ---[ end trace 72e2d7bdcf98ea8e ]--- [ 38.999816] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck [ 38.999847] [ cut here ] [ 38.999847] WARNING: at arch/arm/mach-omap2/clockdomain.c:962 _clkdm_clk_hwmod_disable+0xa4/0xf8() [ 38.999877] Modules linked in: [ 38.08] [c001c1cc] (unwind_backtrace+0x0/0xf0) from [c0043680] (warn_slowpath_common+0x4c/0x64) [ 38.38] [c0043680] (warn_slowpath_common+0x4c/0x64) from [c00436b4] (warn_slowpath_null+0x1c/0x24) [ 38.38] [c00436b4] (warn_slowpath_null+0x1c/0x24) from [c003695c] (_clkdm_clk_hwmod_disable+0xa4/0xf8) [ 38.69] [c003695c] (_clkdm_clk_hwmod_disable+0xa4/0xf8) from [c0437d38] (__clk_disable+0x70/0xac) [ 38.99] [c0437d38] (__clk_disable+0x70/0xac) from [c0437d94]
Re: [PATCH 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
On Fri, 9 Nov 2012, Paul Walmsley wrote: The enables and disables of dpll4_m2x2_ck from the entire log appear to be balanced: Looks like this is an artifact of the disable-unused-clocks problem. The disable of dpll4_m6x2_ck during that phase removes the usecount that was previously added by the enable of dpll4_m2x2_ck. So fixing that problem should clean this one up. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? By the way, according to the AM3358 data manual (paragraph above), even if there is no external 32k clock source and if you don't use the internal 32k oscillator, you can still generate a 32k clock from the PER PLL (CLK_32KHZ). So therefore, there should always be a 32k clock source available for the gptimer. Is that correct? At the end of the day, I am just trying to understand if any OMAP/AM device supports a h/w configuration where there is no 32k clock source available for the gptimer. Jon -- 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 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
Quoting Paul Walmsley (2012-11-08 16:11:12)
On Thu, 8 Nov 2012, Paul Walmsley wrote:
On Thu, 8 Nov 2012, Paul Walmsley wrote:
Am seeing warnings during the disable-unused-clocks phase of the boot on
the OMAP3 test boards here.
Similar problems during system suspend on 3530ES3 Beagle. Not sure
what's causing these yet. At this point the clockdomain usecounts
should be accurate.
Here's a redacted debugging log for these cases. The suspend events start
around the 30 second mark.
One observation is that dpll4_m5x2_ck and dpll4_m6x2_ck are never enabled.
The tracebacks occur when something in the suspend path tries to disable
those clocks.
Hi Paul,
My instrumentation shows that dpll4_ck dpll4_m2x2_ck are triggering
the WARNs:
[ 25.214599] _clkdm_clk_hwmod_disable: dpll4_m2x2_ck
[ 25.214599] [ cut here ]
[ 25.214660] WARNING: at arch/arm/mach-omap2/clockdomain.c:967
_clkdm_clk_hwmod_disable+0xd0/0x118()
...
[ 25.215209] _clkdm_clk_hwmod_disable: dpll4_ck
[ 25.215209] [ cut here ]
[ 25.215240] WARNING: at arch/arm/mach-omap2/clockdomain.c:967
_clkdm_clk_hwmod_disable+0xd0/0x118()
Patch that give that information:
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 64e5046..a9d5965 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -947,7 +947,8 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
return 0;
}
-static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm)
+static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm,
+ struct clk *clk)
{
unsigned long flags;
@@ -957,6 +958,9 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain
*clkdm)
spin_lock_irqsave(clkdm-lock, flags);
if (atomic_read(clkdm-usecount) == 0) {
+ if (clk)
+ pr_err(%s: %s\n, __func__, __clk_get_name(clk));
+
spin_unlock_irqrestore(clkdm-lock, flags);
WARN_ON(1); /* underflow */
return -ERANGE;
@@ -1026,7 +1030,7 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ return _clkdm_clk_hwmod_disable(clkdm, clk);
}
/**
@@ -1089,6 +1093,6 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct
omap_hwmod *oh)
if (!oh)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ return _clkdm_clk_hwmod_disable(clkdm, NULL);
}
Regards,
Mike
- Paul
[0.135528] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[0.135559] clockdomain: dpll4_clkdm: enabled
[0.135589] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[0.135711] clockdomain: dpll4_clkdm: disabled
[0.135772] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[0.135803] clockdomain: dpll4_clkdm: enabled
[0.135833] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[0.135894] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[0.135925] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[0.135955] clockdomain: dpll4_clkdm: disabled
[0.135986] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[0.136016] clockdomain: dpll4_clkdm: enabled
[0.136047] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[0.136138] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[0.136169] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[0.136169] clockdomain: dpll4_clkdm: disabled
[0.136260] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[0.136291] clockdomain: dpll4_clkdm: enabled
[0.136322] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[0.140594] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[0.140686] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck
[0.140838] disabling clkdm dpll4_clkdm during disable of clk dpll4_m3x2_ck
[0.140930] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[0.141479] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[0.141571] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[0.141601] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[0.141662] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[0.141693] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[0.141784] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[0.141815] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck
[0.141876] disabling clkdm
Re: [PATCH] ARM: OMAP2+: clockdomain: disabling unused clks
On Thu, 8 Nov 2012, Mike Turquette wrote: The OMAP port to the common clk framework[1] resulted in spurious WARNs while disable unused clocks. This is due to _clkdm_clk_hwmod_disable catching clkdm-usecount's with a value of zero. Even less desirable it would not allow the clkdm_clk_disable function pointer to get called due to an early return of -ERANGE. This patch adds a check for such a corner case by skipping the WARN and early return in the event that clkdm-usecount and clk-enable_usecount are both zero. Presumably this could only happen during the check for unused clocks at boot-time. [1] http://article.gmane.org/gmane.linux.ports.arm.omap/88824 Signed-off-by: Mike Turquette mturque...@ti.com I don't think this is going to work, as it currently stands. The code will just bypass the warning and the error return. The clockdomain usecount still will be decremented, which is going to cause problems since the usecount will be inaccurate. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix kernel panic in dmtimer probe
On 11/08/2012 06:17 PM, Jon Hunter wrote:
When booting with device-tree the kernel is panicing in the probe of the
DMTIMER driver. The panic is caused because the pointer to platform_data
structure is NULL when booting with device-tree and the driver is
attempting to access the structure without checking if the pointer is
valid.
Fix this by moving the code that accesses the platform data structure
under the else clause of the if (dev-of_node) statement because
here the pointer to platform_data is guaranteed to be valid. The code
accessing the timer_capability member of the platform data is simply
removed as this is already handled under the else clause.
This regression was introduced while integrating commit ARM: OMAP: Add
DT support for timer driver to add device-tree support to the DMTIMER
driver and commit ARM: OMAP: Move omap-pm-noop.c local to mach-omap2
to prepare for single zImage support.
By the way, I meant to add ...
Reported-by: Tony Lindgren t...@atomide.com
Jon
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 38c12ef..9dca23e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-capability = pdata-timer_capability;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
+ timer-get_context_loss_count = pdata-get_context_loss_count;
}
timer-irq = irq-start;
timer-pdev = pdev;
- timer-capability = pdata-timer_capability;
- timer-get_context_loss_count = pdata-get_context_loss_count;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
--
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+: clockdomain: disabling unused clks
Quoting Paul Walmsley (2012-11-08 16:58:21) On Thu, 8 Nov 2012, Mike Turquette wrote: The OMAP port to the common clk framework[1] resulted in spurious WARNs while disable unused clocks. This is due to _clkdm_clk_hwmod_disable catching clkdm-usecount's with a value of zero. Even less desirable it would not allow the clkdm_clk_disable function pointer to get called due to an early return of -ERANGE. This patch adds a check for such a corner case by skipping the WARN and early return in the event that clkdm-usecount and clk-enable_usecount are both zero. Presumably this could only happen during the check for unused clocks at boot-time. [1] http://article.gmane.org/gmane.linux.ports.arm.omap/88824 Signed-off-by: Mike Turquette mturque...@ti.com I don't think this is going to work, as it currently stands. The code will just bypass the warning and the error return. The clockdomain usecount still will be decremented, which is going to cause problems since the usecount will be inaccurate. You're right. In my rush I glossed over the clkdm decrement part. In light of the suspend/resume issues I'm not sure this approach is really valid. I think getting to the bottom of those issues will give the final word. Regards, Mike - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Mon, Nov 05, 2012 at 08:40:30PM +, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
Device Tree Overlay Feature
Hrm. So, you may yet convince me otherwise, but I'm really getting a
feeling of overengineering from this proposal so far.
Purpose
===
Sometimes it is not convenient to describe an entire system with a
single FDT. For example, processor modules that are plugged into one or
more modules (a la the BeagleBone), or systems with an FPGA peripheral
that is programmed after the system is booted.
For these cases it is proposed to implement an overlay feature for the
so that the initial device tree data can be modified by userspace at
runtime by loading additional overlay FDTs that amend the original data.
User Stories
[snip]
The user stories mostly sound reasonable to me, but I don't know
enough about the hardware in question to know what they'll mean in
terms of what needs to be added to the base device tree.
Summary points:
- Create an FDT overlay data format and usage model
- SHALL reliable resolve or validate of phandles between base and
overlay trees
So, I'm not at all clear on what this proposed phandle validation
would involve. I'm also not convinced it's as necessary as you
think, more on that below.
[snip - lots of technical stuff]
So, let me take a stab at this from a more bottom-up approach, and see
if we meet in the middle somewhere. As I discussed in the other
thread with Daniel Mack, I can see two different operationso on the
fdt that might be useful in this context. I think of them as graft
- which takes one fdt and adds it as a new subtree to an existing fdt
- and overlay where a new fdt adds or overrides arbitrary properties
in an existing tree. Overlay is more or less what we do at the source
level in dtc already.
Overlay is obviously more general - you can add, change and possibly
delete any existing node or property.
Graft can only add new nodes and properties, not modify existing ones.
But that restriction comes with some advantages: reversing the
operation is just a matter of deleting the subtree with no extra
tracking info required. It's simple to see how to have rules or
permissions about where subtrees can be grafted, and if the graft
point is identified by a label or id, rather than full path, it
automatically adapts to at least some changes in the base tree
structure.
I think graft is basically a safer operation, particular if we're
doing this at runtime with userspace passing in these fdt fragments.
In fact I'd go so far as to say if you really need the full overlay
functionality, then you really ought to be working at the bootloader
or early kernel load level to assemble the correct full device tree.
And as Mitch says, an existing programming language (C, OFW Forth or
whatever as you please) will serve you better for this sort of general
manipulation than a limited template system.
I also think graft will handle most of your use cases, although as I
said I don't fully understand the implications of some of them, so I
could be wrong. So, the actual insertion of the subtree is pretty
trivial to implement. phandles are the obvious other matter to be
dealt with. I haven't found the right thread where what you've
envisaged so far is discussed, so here are things I can see:
1) Avoiding phandle collisions between main tree and subtree (or
between subtrees).
I'm hopeful that this can be resolved just by establishing some
conventions about the ranges of phandles to be used for various
components. I'd certainly be happy to add a directive to dtc which
enforces allocation of phandles within a specified range.
2) Resolving phandle references within a subtree
If we can handle (1) by convention, we don't need anything here, the
references are fine as is.
(3) Resolving phandle references from the subtree to the main tree.
So, I think this can actually be avoided, at least in cases where what
physical connections are available to the expansion module is well
defined. The main causes to have external references are interrupts
and gpios. Interrupts we handle by defining an interrupt specifier
space for the interrupts available on the expansion
socket/connector/bus/whatever. In the master tree we then have
something like:
...
expansion-socket@ {
expansion-id = SlotA;
interrupt-map = /* map expansion irq specs to
board interrupt controllers */ ;
interrupt-map-mask = ... ;
ranges = /* map expansion local addresses to global
mmio */ ;
};
The subtree for the expansion module gets attached as a subnode of
this one. It doesn't use explicit interrupt-parents but instead just
uses the expansion local irq specifiers,
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Pantelis, I hope I'm not too late to reply as I'm traveling. On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Joanne has purchased one of Jane's capes and packaged it into a rugged case for data logging. As far as Joanne is concerned, the BeagleBone and cape together are a single unit and she'd prefer a single monolithic FDT instead of using an FDT overlay. Option A: Using dtc, she uses the BeagleBone and cape .dts source files to generate a single .dtb for the entire system which is loaded by U-Boot. -or- Unlikely. Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files (instead of .dts files), -or- Possible but low probability. Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. I love Grant's hashing idea a lot keeping the phandle problem for compile time and not requiring fixups. IMO it is still a cleaner approach if u-boot does the simple tree merging for all cases, and not the kernel reasons mentioned below. (1) From a development standpoint, very little or nothing will have to be changed in kernel (except for scripts/dtc) considering we are moving forward with hashing. (2) Also this discussed a while back but at some point is going to brought up again- loading of dt fragment directly from EEPROM and merging at run time. If we were to implement this in kernel, we would have to add cape specific EEPROM reading code, merge the tree before it is unflattened and parse. I think doing tree merging in kernel is messy and we should do it in uboot considering we might have to read EEPROM for this use case. Ideally reading the fragment from the EEPROM for all capes and merging without worrying about version detection, Doing the merge and passing the merged blob to the kernel which (kernel) works the same way it does today. It may be sufficient to solve it by making the phandle values less volatile. Right now dtc generates phandles linearly. Generated phandles could be overridden with explicit phandle properties, but it isn't a fantastic solution. Perhaps generating the phandle from a hash of the node name would be sufficient. I doubt the hash method will work reliably. We only have 32 bits to work with, nothing like the SHA hashes of git. I was wondering I have worked with kernel's crypto code in the past to generate 32 bit md5sums of 1000s of dataitems, from what I've seen, collisions are rare and since we are talking about just a few nodes that are being referenced in the base dt. I think the probability is even less (ofcourse such an analysis strongly depends on dataset). this method also takes away a lot of complexity with having it to do runtime fixups and will help us get off the ground quickly. We can also put in a collision handling mechanism if needed. I think it is worthy doing a sample hash of all nodes in all dts we have in a script and see for once if we have collisions and what it looks like. Alternatively to hashing, reading David Gibson's paper I followed, phandle is supposed to 'uniquely' identity node. I wonder why the node name itself is not sufficient to uniquely identify. The code that does the tree walking can then just strcmp the node name while it walks the tree instead of having to find a node with a phandle number. I guess the reason is phandles are small to store as data values. Another approach can be to arrange the string block in alphabetical order (unless it already is), and store phandle as index of the node name referenced relative to the starting of the strong block. This will not affect nodes in dtb being moved around since they will still have the same index value. the problem being adding or removing nodes Changes the index of all other nodes in the string block as well.. Hmm. Regards, Joel -- 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 01/10] PWMSS: Add PWM Subsystem driver for parent-child relationship
On Thu, Nov 08, 2012 at 01:23:08PM +0530, Philip, Avinash wrote:
diff --git a/Documentation/devicetree/bindings/pwm/tipwmss.txt
b/Documentation/devicetree/bindings/pwm/tipwmss.txt
new file mode 100644
index 000..b6c2814
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/tipwmss.txt
@@ -0,0 +1,30 @@
[...]
+Also child nodes should also populated under PWMSS DT node.
+Example:
Maybe put an blank line between these two lines for readability?
+pwmss0: pwmss@4830 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x4830 0x10
+ 0x48300100 0x80
+ 0x48300180 0x80
+ 0x48300200 0x80;
I don't think you should list the register spaces of the children here.
From what I understand, all regions listed in the reg property are
supposed to be requested by the corresponding driver and therefore
cannot be used by any other device.
+ ti,hwmods = epwmss0;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
I think to represent which memory regions go to the children, you should
put them in this ranges property, which would then look like this:
ranges = 0x48300100 0x48300100 0x80 /* ECAP */
0x48300180 0x48300180 0x80 /* EQEP */
0x48300200 0x48300200 0x80; /* EHRPWM */
+
+ /* child nodes go here */
+};
Maybe you should actually list a full set of children here?
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 6e556c7..384a346 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -136,6 +136,7 @@ config PWM_TEGRA
config PWM_TIECAP
tristate ECAP PWM support
depends on SOC_AM33XX
+ select PWM_TIPWMSS
help
PWM driver support for the ECAP APWM controller found on AM33XX
TI SOC
@@ -146,6 +147,7 @@ config PWM_TIECAP
config PWM_TIEHRPWM
tristate EHRPWM PWM support
depends on SOC_AM33XX
+ select PWM_TIPWMSS
help
PWM driver support for the EHRPWM controller found on AM33XX
TI SOC
@@ -153,6 +155,15 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
+config PWM_TIPWMSS
+ tristate TI PWM Subsytem parent support
+ depends on SOC_AM33XX (PWM_TIEHRPWM || PWM_TIECAP)
Since you select the symbol from the PWM_TIECAP and PWM_TIEHRPWM symbols
there is no need to depend on them, right? Oh, but maybe that's to make
sure the symbol is deselected automatically if neither user is selected.
Perhaps this should actually be a hidden symbol (i.e. leave away the
prompt string in the tristate option) since it's purely a dependency and
not useful of its own.
+ help
+ PWM Subsystem driver support for AM33xx SOC.
+
+ PWM submodules require PWM config space access from submodule
+ drivers and require common parent driver support.
+
config PWM_TWL6030
tristate TWL6030 PWM support
depends on TWL4030_CORE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 3b3f4c9..55f6fb2 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
+obj-$(CONFIG_PWM_TIPWMSS)+= tipwmss.o
This should have a pwm- prefix as well.
obj-$(CONFIG_PWM_TWL6030)+= pwm-twl6030.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/tipwmss.c b/drivers/pwm/tipwmss.c
new file mode 100644
index 000..c188348
--- /dev/null
+++ b/drivers/pwm/tipwmss.c
@@ -0,0 +1,142 @@
[...]
+#include tipwmss.h
+
+#define PWMSS_CLKCONFIG 0x8 /* Clock gaitng reg, for PWM
submodules */
gating
+#define PWMSS_CLKSTATUS 0xc /* Clock gating status reg */
+
+struct pwmss_info {
+ void __iomem*mmio_base;
+ struct mutexpwmss_lock;
+ u16 pwmss_clkconfig;
The indentation looks weird on this last field.
+};
+
+u16 pwmss_submodule_state_change(struct device *dev, int set)
+{
+ struct pwmss_info *info = dev_get_drvdata(dev);
+ u16 val;
+
+ val = readw(info-mmio_base + PWMSS_CLKCONFIG);
+ val |= set;
+ mutex_lock(info-pwmss_lock);
+ writew(val , info-mmio_base + PWMSS_CLKCONFIG);
+ mutex_unlock(info-pwmss_lock);
The mutex needs to span the whole read-modify-write sequence, not just
the write.
Also, how do you clear this state?
+ return readw(info-mmio_base + PWMSS_CLKSTATUS);
+}
+EXPORT_SYMBOL(pwmss_submodule_state_change);
+
+static const struct of_device_id pwmss_of_match[] = {
+ {
+ .compatible = ti,am33xx-pwmss,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pwmss_of_match);
+
+static int __devinit pwmss_probe(struct platform_device *pdev)
