Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal, Looks good! Some minor comments ... On 05/01/2012 07:19 AM, Afzal Mohammed wrote: Convert GPMC code to driver. Boards using GPMC should provide driver with type of configuration, timing, CS. Platform devices would then be created for each connected peripheral (details also to be passed by board so that it reaches respective driver). And GPMC driver would populate memory resource details for the connected peripheral driver. Boards should inform gpmc driver with platform data destined for peripheral driver. gpmc driver will provide the same information to peripheral driver. A peripheral connected to GPMC can have multiple address spaces using different chip select. Hence GPMC driver has been provided capability to create platform device for peripheral using mutiple CS. The peripheral that made it necessary was tusb6010. Interrupts of GPMC are presented to drivers of connected peripherals as resource. A fictitious interrupt controller chip handles these interrupts at GPMC hardware level. Clients can use normal interrupt APIs. Platform information of peripheral passed to GPMC driver should indicate interrupts to be used via flags. Driver is capable of configuring waitpin, waitpin details has to be provided per CS. Wait pin has been considered as exclusive resource as multiple peripherals should not using the same pin, at the same it is valid for mutiple CS to use same waitpin provided they are a part of single peripheral (eg. tusb6010) An exported symbol for reconfiguring GPMC settings has been provided. OneNAND is the one that neccessitated this. Acquiring CS# for NAND is done on a few boards. It means, depending on bootloader to embed this information. Probably CS# being used can be set in the Kernel, and acquiring it can be removed. If ever this capbility is needed, GPMC driver has to be made aware of handling it. Modifications has been made keeping in mind that the driver would have to move to driver folder. This explains requirement of clk_prd field; even though clk_prd variable is not necessary as gpmc_get_fclk_period is present in the same file as of now, this will help in moving the driver easily to drivers folder. Code related to GPMC clock may have to continue live in platform folders as input clock is beyond the control of GPMC and calculating timing for the peripheral may need other helpers. This explains presence of 'gpmc_cs_calc_divider' along with 'gpmc_calc_divider', both doing same work, latter meant to go with driver, former for calculation in platform code. Thanks to Vaibhav Hiremath Jonathan Hunter on their various good suggestions which resulted in improving the code. Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Jon Hunter jon-hun...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/gpmc.c | 877 arch/arm/plat-omap/include/plat/gpmc.h | 93 +++- 2 files changed, 872 insertions(+), 98 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 580e684..12916f3 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -14,8 +14,11 @@ */ #undef DEBUG +#include linux/platform_device.h + #include linux/irq.h #include linux/kernel.h +#include linux/slab.h #include linux/init.h #include linux/err.h #include linux/clk.h @@ -53,6 +56,45 @@ #define GPMC_CS0_OFFSET 0x60 #define GPMC_CS_SIZE 0x30 +/* GPMC register bits */ +#define GPMC_CONFIG1_TIMEPARAGRANULARITYBIT(4) +#define GPMC_CONFIG1_DEVICETYPE_NAND GPMC_CONFIG1_DEVICETYPE(0x2) +#define GPMC_CONFIG1_WAIT_PIN_SEL_MASK GPMC_CONFIG1_WAIT_PIN_SEL(0x3) +#define GPMC_CONFIG1_WAIT_MON_TIME(val) ((val 0x3) 18) +#define GPMC_CONFIG1_WRITEMULTIPLE BIT(28) +#define GPMC_CONFIG1_READMULTIPLE BIT(30) +#define GPMC_CONFIG1_WRAPBURST BIT(31) +#define GPMC_CONFIG_WAITPIN_POLARITY_SHIFT 0x8 +#define GPMC_CONFIG1_WAITPIN_MONITOR_TIME(val) ((val 0x3) 18) +#define GPMC_CONFIG1_WAITPIN_MONITOR_TIME_1 \ + GPMC_CONFIG1_WAITPIN_MONITOR_TIME(0x1) +#define GPMC_CONFIG1_WAITPIN_MONITOR_TIME_2 \ + GPMC_CONFIG1_WAITPIN_MONITOR_TIME(0x2) +#define GPMC_CONFIG1_CLOCKACTIVATION_TIME(val) ((val 0x3) 25) +#define GPMC_CONFIG1_CLOCKACTIVATION_TIME_1 \ + GPMC_CONFIG1_CLOCKACTIVATION_TIME(0x1) +#define GPMC_CONFIG1_CLOCKACTIVATION_TIME_2 \ + GPMC_CONFIG1_CLOCKACTIVATION_TIME(0x2) + +#define GPMC_CONFIG2_CSEXTRADELAY BIT(7) + +#define GPMC_CONFIG3_ADVEXTRADELAY BIT(7) + +#define GPMC_CONFIG4_OEEXTRADELAY BIT(7) +#define GPMC_CONFIG4_WEEXTRADELAY
Re: [PATCH v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Afzal,
On 05/01/2012 07:19 AM, Afzal Mohammed wrote:
Create API for platforms to adapt gpmc to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 52
+++-
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 12916f3..c8d07bb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -33,6 +33,8 @@
#include plat/sdrc.h
+#include plat/omap_device.h
+
/* GPMC register offsets */
#define GPMC_REVISION0x00
#define GPMC_SYSCONFIG 0x10
@@ -276,6 +278,31 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
return ticks * gpmc_get_fclk_period() / 1000;
}
+int __init omap_init_gpmc(struct gpmc_pdata *pdata)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *name = omap-gpmc;
+ char *oh_name = gpmc;
+
+ pdata-clk_prd = gpmc_get_fclk_period();
Does this need to be done here? May be this should be done in the probe
function. You could store the handle to the main clk in the pdata.
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(name, -1, oh, pdata,
+ sizeof(*pdata), NULL, 0, 0);
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
@@ -843,24 +870,19 @@ static __devinit void gpmc_mem_init(void)
static int __init gpmc_init(void)
{
- int ret = -EINVAL;
- char *ck = NULL;
-
- if (cpu_is_omap24xx()) {
- ck = core_l3_ck;
- } else if (cpu_is_omap34xx()) {
- ck = gpmc_fck;
- } else if (cpu_is_omap44xx()) {
- ck = gpmc_ck;
- }
+ char *oh_name = gpmc;
+ struct omap_hwmod *oh;
- if (WARN_ON(!ck))
- return ret;
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
- gpmc_l3_clk = clk_get(NULL, ck);
+ gpmc_l3_clk = clk_get(NULL, oh-main_clk);
if (IS_ERR(gpmc_l3_clk)) {
- printk(KERN_ERR Could not get GPMC clock %s\n, ck);
- BUG();
+ pr_err(error: clk_get on %s\n, oh-main_clk);
+ return -EINVAL;
}
clk_enable(gpmc_l3_clk);
I would have thought we should be able to remove the gpmc_init function
completely by now. Most of the code should be moved to the probe function.
Also now with hwmod in place, we should be able to remove the
clk_enable/disable functions and use the pm_runtime APIs instead.
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 v4 04/39] ARM: OMAP2+: gpmc: Acquire NAND CS value
Hi Afzal,
On 05/01/2012 07:20 AM, Afzal Mohammed wrote:
Some boards depend on bootloader to update chip select value for NAND.
It is felt that Kernel should not depend on bootloader to get CS, as
for a particular board CS is hardwired and is fixed, hence this can
directly be updated in Kernel. But as CS value for boards that depend
on this behaviour is not available, educate gpmc driver to acquire
chip select value for NAND. this ideally should be removed once CS
for those boards are available.
Do you know how many boards require this? If so which are those boards?
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 657ce95..ecd3384 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -892,6 +892,30 @@ static int __init gpmc_init(void)
}
postcore_initcall(gpmc_init);
+static __devinit int gpmc_acquire_nand_cs(struct gpmc *gpmc,
+ struct gpmc_device_pdata *gdp)
+{
+ int cs = 0;
+ struct omap_nand_platform_data *nand = gdp-pdata;
+
+ if ((nand-cs = 0) (nand-cs GPMC_CS_NUM))
+ return 0;
+
+ while (cs GPMC_CS_NUM) {
+ u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ if ((l GPMC_CONFIG1_DEVICETYPE(~0)) ==
+ GPMC_CONFIG1_DEVICETYPE_NAND) {
+ dev_info(gpmc-dev, found NAND on CS: %d\n, cs);
+ nand-cs = cs;
+ gdp-cs_data-cs = cs;
+ return 0;
+ }
+ cs++;
+ }
+ return -ENODEV;
+}
+
static __devinit void gpmc_update_nand_reg(struct gpmc *gpmc,
struct omap_nand_platform_data *nand)
{
@@ -1450,8 +1474,14 @@ static __devinit int gpmc_probe(struct platform_device
*pdev)
for (i = 0, gdq = gp-device_pdata, gd = gpmc-device;
(i gp-num_device) (*gdq); i++, gdq++) {
- if ((*gdq)-is_nand)
+ if ((*gdq)-is_nand) {
+ ret = gpmc_acquire_nand_cs(gpmc, *gdq);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(gpmc-dev, CS error: %d\n, ret);
+ continue;
+ }
Should this code be marked with a FIXME?
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: [PATCHv7 2/3] OMAP: I2C: Remove the reset in the init path
Hi Shubhrajyoti,
On 12/2/2011 3:21, Shubhrajyoti D wrote:
- The reset in the driver at init is not needed anymore as the
hwmod framework takes care of reseting it.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
device_reset were added in those places to effect the reset.
- Earlier the hwmod SYSC settings were over-written in the driver.
Removing the same and letting the hwmod take care of the settings.
- Clean up the SYSS_RESETDONE_MASK macro as it is no longer needed.
- Clean up the SYSCONFIG SYSC bit defination macros.
- Fix the typos in wakeup.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 82 +++--
1 files changed, 22 insertions(+), 60 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fa23faa..beff9f3 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -155,19 +155,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_O(1 0) /* SDA line drive out
*/
#endif
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
-/* OCP_SYSCONFIG bit definitions */
-#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
-#define SYSC_SIDLEMODE_MASK(0x3 3)
-#define SYSC_ENAWAKEUP_MASK(1 2)
-#define SYSC_SOFTRESET_MASK(1 1)
-#define SYSC_AUTOIDLE_MASK (1 0)
-
-#define SYSC_IDLEMODE_SMART0x2
-#define SYSC_CLOCKACTIVITY_FCLK0x2
-
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
#define I2C_OMAP3_1P153 (1 1)
@@ -182,6 +169,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*device_reset)(struct device *dev);
u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
@@ -317,60 +305,23 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
- unsigned long timeout;
unsigned long internal_clk = 0;
struct clk *fclk;
struct omap_i2c_bus_platform_data *pdata;
pdata = dev-dev-platform_data;
- if (dev-rev= OMAP_I2C_OMAP1_REV_2) {
- /* Disable I2C controller before soft reset */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
- omap_i2c_read_reg(dev, OMAP_I2C_CON_REG)
- ~(OMAP_I2C_CON_EN));
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, SYSC_SOFTRESET_MASK);
- /* For some reason we need to set the EN bit before the
-* reset done bit gets set. */
- timeout = jiffies + OMAP_I2C_TIMEOUT;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- while (!(omap_i2c_read_reg(dev, OMAP_I2C_SYSS_REG)
-SYSS_RESETDONE_MASK)) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev, timeout waiting
- for controller reset\n);
- return -ETIMEDOUT;
- }
- msleep(1);
- }
-
- /* SYSC register is cleared by the reset; rewrite it */
- if (dev-rev == OMAP_I2C_REV_ON_2430) {
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
- SYSC_AUTOIDLE_MASK);
-
- } else if (dev-rev= OMAP_I2C_REV_ON_3430) {
- dev-syscstate = SYSC_AUTOIDLE_MASK;
- dev-syscstate |= SYSC_ENAWAKEUP_MASK;
- dev-syscstate |= (SYSC_IDLEMODE_SMART
- __ffs(SYSC_SIDLEMODE_MASK));
- dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
- __ffs(SYSC_CLOCKACTIVITY_MASK));
The issue I see with this change is that you are removing the above code
to set the CLKACTIVITY field. Today, AFAIK, hwmod does not set this.
Ideally it should. However, from discussing this with Richard W, this
can cause timeouts to occur for i2c transactions. So before removing
this we need to make sure that this is handled by hwmod or else where.
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
- dev-syscstate);
- /*
-* Enabling all wakup sources to stop I2C freezing
Re: [PATCHv7 2/3] OMAP: I2C: Remove the reset in the init path
Hi Shubhrajyoti,
On 12/2/2011 15:37, Jon Hunter wrote:
[snip]
@@ -594,6 +545,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
*adap,
return r;
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
+ if (dev-device_reset) {
+ r = dev-device_reset(dev-dev);
+ if (r 0)
+ dev_err(dev-dev, reset failed\n);
+ }
omap_i2c_init(dev);
Why put the reset here? The function omap_i2c_init is going to perform a
soft reset. So why not replace the reset in that function?
Furthermore does this work for omap1 devices? I think that you would
need to remove the existing soft-reset from omap_i2c_init() into an omap1.
Sorry, I see you did remove the soft-reset in the omap_i2c_init().
However, why not just replace the reset in the omap_i2c_init() instead
of moving it?
As for omap1, I see we don't perform a soft-reset so that is a don't care.
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] i2c_omap: correct OMAP_I2C_SYSC_REG offset
Hi Kevin,
On 12/8/2011 12:12, Kevin Hilman wrote:
Alexander Aringa.ar...@phytec.de writes:
Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset.
Signed-off-by: Alexander Aringa.ar...@phytec.de
Thanks for the patch!
A different approach to fix this is being done by Shubhrajyoti[1] as
part of his reset series.
However, I think we should probably apply this patch for v3.2 and also
send to the stable kernel for v3.0 v3.1.
Shubhrajyoti/Jon, any objections to me queuing this fix for v3.2 (and
stable.) It would just mean rebasing your other fixes and cleanup
series on top of this.
I have no issue with that and I am in favour of getting the fix in now.
Cheers
Jon
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a43d002..fc3bb37 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -235,7 +235,7 @@ static const u8 reg_map_ip_v2[] = {
[OMAP_I2C_BUF_REG] = 0x94,
[OMAP_I2C_CNT_REG] = 0x98,
[OMAP_I2C_DATA_REG] = 0x9c,
- [OMAP_I2C_SYSC_REG] = 0x20,
+ [OMAP_I2C_SYSC_REG] = 0x10,
[OMAP_I2C_CON_REG] = 0xa4,
[OMAP_I2C_OA_REG] = 0xa8,
[OMAP_I2C_SA_REG] = 0xac,
--
To unsubscribe from this list: send the line unsubscribe 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: hdmi on 4430 (kernel 3.4)
On 11/06/2012 03:05 AM, Federico Fuga wrote: Hi Jon, Il giorno 06/nov/2012, alle ore 00:21, Jon Hunter jon-hun...@ti.com ha scritto: I wanted to check the HDMI registers, but I didn't find the hdmi registers table on the TRM. Does someone have some hint, comment or previous experience on that? Where can I find the hdmi registers list on the manual or other documentation? Note that as far as i know, the 2.6.35 kernel was working correctly (I can't check right now, unfortunately). Thank you. I would recommend posting this query on the TI E2E forum for Linux [1]. You may get better help there seeing that this is with regard to a specific TI development kernel branch. Thank you very much for the suggestion! I'll post there. Can you confirm that the kernel version I am using works without problem with HDMI-1080p? Sorry, I have not tried. However, hopefully someone from the forum can help. 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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/06/2012 01:32 AM, Bedia, Vaibhav wrote:
Hi Jon,
On Tue, Nov 06, 2012 at 02:34:05, Hunter, Jon wrote:
[...]
static struct clock_event_device clockevent_gpt = {
.name = gp_timer,
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
@@ -142,6 +171,8 @@ static struct clock_event_device clockevent_gpt = {
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode = omap2_gp_timer_set_mode,
+ .suspend= omap_clkevt_suspend,
+ .resume = omap_clkevt_resume,
So these suspend/resume callbacks are going to be called for all OMAP2+
and AM devices? I don't think we want that. AFAIK OMAP timers will
idle on their own when stopped and don't require this.
IMO instead of skipping the callback registration we could have checks in the
suspend/resume callbacks to decide what to do.
I'll check if the idling part is AM33xx specific. If not, based on the recent
timer
changes that you did, perhaps checking if the clockevent selected doesn't
have the
ti,timer-alwon capability will be good enough. What do you think?
Yes, I was thinking along the same lines. If I get chance I will try and
test your scenario on an OMAP3 too.
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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/06/2012 03:38 AM, Bedia, Vaibhav wrote: Hi Jon, On Tue, Nov 06, 2012 at 02:50:50, Hunter, Jon wrote: [...] Why is this? How is the dmtimer TIOCP_CFG register configured on AM33xx? Is it using smart-idle? Yes, it is set to smart-idle with wakeup capable mode. (this needs a fixup since this timer is not wakeup capable) but unfortunately this is not sufficient. On AM33xx there's no HW_AUTO mode magic so unless the IPs in PER domain are disabled by s/w, PER domain can't transition. The next one is that the clockevent doesn't generate any further interrupts once the system resumes. We need to restore the pre-suspend configuration. I haven't tried but I guess we could have used the save and restore of timer registers here. It would be interesting to try using an non-wakeup domain timer on OMAP3/4 for clock events and seeing if suspend/resume works. Do you know what the exact problem here is? I understand that the timer context could get lost, but exactly what is not getting restarted by the kernel? For example, the only place we set the interrupt enable is during the clock event init and so if the context is lost, then I could see no more interrupts occurring. So is it enough to just restore the interrupt enable register, do you really need to program the timer again? Just restoring the interrupt enable register works. But since there's no logic retention I think a context save-restore would be better. Ok, we may need to check the order in which events occur following resume. The kernel will restart the clock-events and we just need to make sure we do not restore the context after the clock-events has been restarted. 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 1/3] omap gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
On 11/06/2012 10:44 AM, Matthieu CASTET wrote:
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
I think you need to have something in the changelog for the patch
describing why this change is needed and what device this has been
tested on.
---
arch/arm/mach-omap2/gpmc.c |7 ++-
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..3957ffc 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -333,8 +333,13 @@ int gpmc_cs_set_timings(int cs, const struct
gpmc_timings *t)
if (gpmc_capability GPMC_HAS_WR_DATA_MUX_BUS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
- if (gpmc_capability GPMC_HAS_WR_ACCESS)
+ if (gpmc_capability GPMC_HAS_WR_ACCESS) {
+ /* XXX check on which hardware it is supported */
I understand that you may not have all the documentation but lets fix
this now.
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, busturnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycledelay);
Looking at the documentation for OMAP2420, OMAP3430, OMAP4430 and
OMAP5430, the above fields are present and same size location for all
OMAP devices. So this does not need to be done under the HAS_WR_ACCESS
field test. In fact, I believe that Afzal was going to add these fields
in a patch and was doing it for all devices [1].
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..34ca454 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,8 @@ struct gpmc_timings {
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
+ u16 cycle2cycledelay; /* CYCLE2CYCLEDELAY */
+ u16 busturnaround; /* BUSTURNAROUND */
So you should be able to move these out of OMAP3430 specific as they are
generic.
Cheers
Jon
[1] http://marc.info/?l=linux-omapm=134037095705900w=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 1/3] omap gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
On 11/06/2012 12:00 PM, Matthieu CASTET wrote:
Jon Hunter a écrit :
On 11/06/2012 10:44 AM, Matthieu CASTET wrote:
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..34ca454 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,8 @@ struct gpmc_timings {
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
+ u16 cycle2cycledelay; /* CYCLE2CYCLEDELAY */
+ u16 busturnaround; /* BUSTURNAROUND */
So you should be able to move these out of OMAP3430 specific as they are
generic.
Thanks for the quick review.
I will post another patch, unless this is already done in Afzal patch (Is
there
a tree where I can get Afzal pending patches ?)
Afzal keeps his kernel tree on gitorious [1]. However, I am not sure
what Afzal's plans are for the remaining patches not yet merged and
which branch you should look at (I have a lot of problems viewing
anything on gitorious these days).
Afzal, let us know how you prefer to handle this.
Cheers
Jon
[1] http://gitorious.org/x0148406-public/linux-kernel
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP baseline test results for v3.7-rc4
On 11/04/2012 08:46 PM, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc4/20121104142910/ Passing tests - Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html - added to rmk's patch system as 7566/1 * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite * May be due to an old U-boot with FDT support problems? PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Caused by RT throttling - Fixed by http://www.spinics.net/lists/arm-kernel/msg202224.html - Patch in rmk's patch system as 7565/1 * 3530es3beagle: hangs during off-mode dynamic idle test - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c: - http://marc.info/?l=linux-omapm=135075364705188w=2 - Fixed by http://www.spinics.net/lists/arm-kernel/msg202116.html Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 * 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3) - clock source is from an external I2C-controlled source - must skip reset until the switchover to hwmod late init - http://www.spinics.net/lists/arm-kernel/msg178138.html Failing tests: needing investigation Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file * 4460pandaes: boot fails early - Appears to be due to X-loader problems here - Need to note the X-loader version so we know it's broken Are you still planning to investigate this further or migrate to a new bootloader? With 4460 and 3.7-rc4, I am seeing that resume from suspend is not working (not sure when this broke though). I am just curious if anyone else sees this. My u-boot version is v2012.10. 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: OMAP baseline test results for v3.7-rc4
On 11/07/2012 11:32 AM, Paul Walmsley wrote: On Wed, 7 Nov 2012, Jon Hunter wrote: On 11/04/2012 08:46 PM, Paul Walmsley wrote: * 4460pandaes: boot fails early - Appears to be due to X-loader problems here - Need to note the X-loader version so we know it's broken Are you still planning to investigate this further or migrate to a new bootloader? Yes. The problem with the current boot setup is that the new bootloader is breaking as well! :-( Ugh! This can be seen by comparing: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/4460pandaes/4460pandaes_log.txt (the old bootloader) with http://www.pwsan.com/omap/testlogs/test_v3.7-rc4/20121104142910/boot/4460pandaes/4460pandaes_log.txt (the new bootloader) If you get chance, it would be good to test u-boot v2012.10 release, as I am using this and it is working fine. I see the new bootloader you are using is v2012.07 (however, I though this was working too). Weird ... Dealing with this will require hands-on access, and unfortunately, right now I am traveling and away from my testbed. Next week, will take a closer look. With 4460 and 3.7-rc4, I am seeing that resume from suspend is not working (not sure when this broke though). I am just curious if anyone else sees this. My u-boot version is v2012.10. If you have the chance, it would be useful to know if any of the v3.7-rcs worked. Otherwise, will look at this next week. Ok, I will see if I can figure out where this broke. 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
[PATCH 3/3] ARM: OMAP4460: Workaround ABE DPLL failing to turn-on
With the latest mainline u-boot bootloader (v2012.10), timers (5-8) in
the ABE power domain are failing to turn-on. The timers never come out
of the disabled state when setting the module-mode field to enable.
The problem was exposed when u-boot was updated to NOT configure and
lock the ABE DPLL on start-up. If the ABE DPLL is configured and locked
by u-boot the problem does not occur. However, if the ABE DPLL is in the
idle low-power bypass state and we attempt to enable a timer in the ABE
power domain, it remains stuck in the disabled state. It appears to be a
problem the timer interface clock as this comes from the ABE DPLL.
If we place the ABE DPLL in the MN-bypass state and not the idle
low-power state, then this problem is not seen.
This problem only appears to occur on OMAP4460 and not OMAP4430.
Workaround this problem by locking the ABE DPLL for OMAP4460 in the
kernel on boot. By locking the ABE DPLL, when clocks from the ABE DPLL
are not being requested the DPLL will transition into a low-power stop
mode.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 8a9cbad..1844661 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -46,6 +46,14 @@
#define OMAP4430_MODULEMODE_HWCTRL 0
#define OMAP4430_MODULEMODE_SWCTRL 1
+/*
+ * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
+ * 3.6.3.2.3 CM1_ABE Clock Generator states that the DPLL_ABE_X2_CLK
+ * must be set to 196.608 MHz and hence, the DPLL locked frequency is
+ * half of this value.
+ */
+#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+
/* Root clocks */
static struct clk extalt_clkin_ck = {
@@ -3354,6 +3362,7 @@ int __init omap4xxx_clk_init(void)
{
struct omap_clk *c;
u32 cpu_clkflg;
+ int rc;
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
@@ -3400,5 +3409,18 @@ int __init omap4xxx_clk_init(void)
*/
clk_enable_init_clocks();
+ /*
+* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
+* state when turning the ABE clock domain. Workaround this by
+* locking the ABE DPLL on boot.
+*/
+ if (cpu_is_omap446x()) {
+ rc = clk_set_parent(abe_dpll_refclk_mux_ck, sys_32k_ck);
+ if (!rc)
+ rc = clk_set_rate(dpll_abe_ck, OMAP4_DPLL_ABE_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure ABE DPLL!\n, __func__);
+ }
+
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP4: Update timer clock aliases
Commit ARM: dts: OMAP4: Update timer addresses updated the device-tree
names of the OMAP4 timers 5-7 because the default address for the timers
was changed from the L3 address to the MPU private address. When booting
with device-tree, this introduces a regression when attempting to set
the parent clock of timers 5-7 to the sys_clk_div_ck. Therefore, update
the clock aliases for timer 5-7 to reflect the updated device-tree name
for the timers.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
This change is needed for v3.8 as the patch [1] to update the default
timer addresses is queued for that release.
[1] http://marc.info/?l=linux-omapm=13517858690w=2
arch/arm/mach-omap2/clock44xx_data.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..8f197eb 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3341,10 +3341,10 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4803e000.timer, timer_sys_ck, sys_clkin_ck, CK_443X),
CLK(48086000.timer, timer_sys_ck, sys_clkin_ck, CK_443X),
CLK(48088000.timer, timer_sys_ck, sys_clkin_ck, CK_443X),
- CLK(49038000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(4903a000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(4903c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(4903e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
+ CLK(40138000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
+ CLK(4013a000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
+ CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
+ CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: OMAP4: Clock fixes
Fixes included, fixing up timer clock aliases for v3.8 and working around ABE DPLL issue seen with latest u-boot bootloader (v2012.10). Testing includes: - Boot testing on OMAP3430 Beagle, OMAP4430 Panda and OMAP4460 Panda - Boot tested with device-tree on OMAP4430 Panda and OMAP4460 Panda and validated that all timers are working. - Suspend testing on OMAP3430 Beagle and OMAP4430 Panda (suspend not functional on OMAP4460 Panda prior to this series and so could not be tested). - Core retention validated on OMAP3430 Beagle. Jon Hunter (3): ARM: OMAP4: Update timer clock aliases ARM: OMAP4: Enhance support for DPLLs with 4X multiplier ARM: OMAP4460: Workaround ABE DPLL failing to turn-on arch/arm/mach-omap2/clock44xx_data.c| 32 ++-- arch/arm/mach-omap2/dpll3xxx.c | 46 +++--- arch/arm/mach-omap2/dpll44xx.c | 63 ++- arch/arm/plat-omap/include/plat/clock.h | 10 + 4 files changed, 124 insertions(+), 27 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP4: Enhance support for DPLLs with 4X multiplier
On OMAP4 devices, the ABE DPLL has an internal 4X multiplier that can
be enabled or disabled in addition to the standard configurable
multiplier (M) for OMAP DPLLs. When configuring the ABE DPLL the 4X
multiplier is accounted for by checking to see whether it is enabled or
not. However, when calculating a new rate we only check to see if the
rate can be achieved with the current setting for the 4X multiplier.
Enhance the round_rate() function for such DPLLs to see if the rate
can be achieved with the 4X multiplier if it cannot be achieved without
the 4X multiplier.
This change is necessary, because when using the 32kHz clock as the
source clock for the ABE DPLL, the default DPLL frequency for the ABE
DPLL cannot be achieved without enabling the 4X multiplier.
When using the 32kHz clock as the source clock for the ABE DPLL and
attempting to lock the DPLL to 98.304MHz (default frequency), it was
found that the DPLL would fail to lock if the low-power mode for the DPLL
was not enabled. From reviewing boot-loader settings that configure the
ABE DPLL it was found that the low-power mode is enabled when using the
32kHz clock source, however, the documentation for OMAP does not state
that this is a requirement. Therefore, introduce a new function for
OMAP4 devices to see if low-power mode can be enabled when calculating a
new rate to ensure the DPLL will lock.
New variables for the last calculated 4X multiplier and low-power
setting have been added to the dpll data structure as well as variables
defining the bit mask for enabling these features via the DPLL's
control_reg. It is possible that we could eliminate these bit masks from
the dpll data structure as these bit masks are not unique to OMAP4, if
it is preferred.
The function omap3_noncore_program_dpll() has been updated to avoid
passing the calculated values for the multiplier (M) and divider (N) as
these are stored in the clk structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c|2 +
arch/arm/mach-omap2/dpll3xxx.c | 46 +++---
arch/arm/mach-omap2/dpll44xx.c | 63 ++-
arch/arm/plat-omap/include/plat/clock.h | 10 +
4 files changed, 98 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 8f197eb..8a9cbad 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -226,6 +226,8 @@ static struct dpll_data dpll_abe_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
+ .m4xen_mask = OMAP4430_DPLL_REGM4XEN_MASK,
+ .lpmode_mask= OMAP4430_DPLL_LPMODE_EN_MASK,
.max_multiplier = 2047,
.max_divider= 128,
.min_divider= 1,
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 814e180..8a0259e 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -17,7 +17,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-
#include linux/kernel.h
#include linux/device.h
#include linux/list.h
@@ -292,15 +291,13 @@ static void _lookup_sddiv(struct clk *clk, u8 *sd_div,
u16 m, u8 n)
/*
* _omap3_noncore_dpll_program - set non-core DPLL M,N values directly
- * @clk: struct clk * of DPLL to set
- * @m: DPLL multiplier to set
- * @n: DPLL divider to set
- * @freqsel: FREQSEL value to set
+ * @clk: struct clk * of DPLL to set
+ * @freqsel: FREQSEL value to set
*
- * Program the DPLL with the supplied M, N values, and wait for the DPLL to
- * lock.. Returns -EINVAL upon error, or 0 upon success.
+ * Program the DPLL with the last M, N values calculated, and wait for
+ * the DPLL to lock. Returns -EINVAL upon error, or 0 upon success.
*/
-static int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16
freqsel)
+static int omap3_noncore_dpll_program(struct clk *clk, u16 freqsel)
{
struct dpll_data *dd = clk-dpll_data;
u8 dco, sd_div;
@@ -323,23 +320,45 @@ static int omap3_noncore_dpll_program(struct clk *clk,
u16 m, u8 n, u16 freqsel)
/* Set DPLL multiplier, divider */
v = __raw_readl(dd-mult_div1_reg);
v = ~(dd-mult_mask | dd-div1_mask);
- v |= m __ffs(dd-mult_mask);
- v |= (n - 1) __ffs(dd-div1_mask);
+ v |= dd-last_rounded_m __ffs(dd-mult_mask);
+ v |= (dd-last_rounded_n - 1) __ffs(dd-div1_mask);
/* Configure dco and sd_div for dplls that have these fields */
if (dd-dco_mask) {
- _lookup_dco(clk, dco, m, n);
+ _lookup_dco(clk, dco, dd-last_rounded_m, dd-last_rounded_n);
v = ~(dd-dco_mask);
v |= dco __ffs(dd-dco_mask);
}
if (dd-sddiv_mask) {
- _lookup_sddiv
[PATCH V2 01/14] 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.
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_OFFSET 0x14
#define NUMERATOR_DENUMERATOR_MASK 0xf000
+/*
+ * For clock-events timer, always use posted mode to
+ * minimise CPU overhead for configuring the timer.
+ */
+#define OMAP_CLKEVT_POSTEDMODE OMAP_TIMER_POSTED
+#define OMAP_CLKSRC_POSTEDMODE OMAP_TIMER_POSTED
+
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -107,7 +114,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_CLKEVT_POSTEDMODE);
return 0;
}
@@ -117,7 +124,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_CLKEVT_POSTEDMODE, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
@@ -125,10 +132,12 @@ 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_CLKEVT_POSTEDMODE);
__omap_dm_timer_load_start(clkev,
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
- 0x - period, 1);
+ 0x - period,
+ OMAP_CLKEVT_POSTEDMODE);
break;
case CLOCK_EVT_MODE_ONESHOT:
break;
@@ -358,7 +367,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_CLKSRC_POSTEDMODE);
}
static struct clocksource clocksource_gpt = {
@@ -372,7 +382,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_CLKSRC_POSTEDMODE);
return 0;
}
@@ -454,7 +465,8 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
BUG_ON(res);
__omap_dm_timer_load_start(clksrc,
- OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
+ OMAP_CLKSRC_POSTEDMODE);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(clocksource_gpt, clksrc.rate))
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 348f855..835c3bdf 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,10 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE0x02
+/* posted mode types */
+#define OMAP_TIMER_NONPOSTED 0x00
+#define OMAP_TIMER_POSTED 0x01
+
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x8000
#define OMAP_TIMER_ALWON 0x4000
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
[PATCH V2 00/14] ARM: OMAP: DMTIMER fixes
This series includes several fixes for the OMAP DMTIMER driver. This is based upon 3.7-rc4 with the two series adding device-tree support for DMTIMERs [1] and the 32kHz Counter [2] Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda. Testing includes ... 1. Booting kernel on above boards 2. Set date and ensuring time of day is correct after 24 hours 3. Checking the timer counter is incrementing when configuring and starting a timer 4. Checking the timer overflow interrupt when timer expires. 5. Using different clock sources to operate the timer with. 6. Running a loop test overnight that continually runs test #3 and #4 for each available timer This has also been boot tested on the AM335x Beagle Bone. [1] http://marc.info/?l=linux-omapm=135065875808614w=2 [2] http://marc.info/?l=linux-omapm=135119308123513w=2 Jon Hunter (14): ARM: OMAP: Add DMTIMER definitions for posted mode ARM: OMAP2+: Disable posted mode for the clocksource timer ARM: OMAP3+: Implement timer workaround for errata i103 and i767 ARM: OMAP: Fix timer posted mode support ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs ARM: OMAP2+: Don't use __omap_dm_timer_reset() ARM: OMAP: Fix dmtimer reset for timer1 ARM: OMAP: Don't restore of DMTIMER TISTAT register ARM: OMAP: Don't restore DMTIMER interrupt status register ARM: OMAP: Fix spurious interrupts when using timer match feature ARM: OMAP: Add dmtimer interrupt disable function ARM: OMAP: Remove unnecessary call to clk_get() ARM: OMAP: Remove __omap_dm_timer_set_source function arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 15 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 41 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 + arch/arm/mach-omap2/timer.c| 73 --- arch/arm/plat-omap/dmtimer.c | 132 +++- arch/arm/plat-omap/include/plat/dmtimer.h | 47 --- 6 files changed, 215 insertions(+), 97 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 04/14] ARM: OMAP: Fix timer posted mode support
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the timer-posted variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which was before the
omap_dm_timer_enable_posted() function was introduced. Although this is a
regression from the original code it only impacts performance and so is not
needed for stable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 4abbbe5..bf484aa 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -124,21 +124,16 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- omap_dm_timer_enable(timer);
if (timer-pdev-id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
__omap_dm_timer_reset(timer, 0, 0);
- omap_dm_timer_enable_posted(timer);
- omap_dm_timer_disable(timer);
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
- int ret;
-
/*
* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
* do not call clk_get() for these devices.
@@ -152,13 +147,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
}
}
+ omap_dm_timer_enable(timer);
+
if (timer-capability OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+ omap_dm_timer_enable_posted(timer);
+ omap_dm_timer_disable(timer);
- timer-posted = 1;
- return ret;
+ return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
}
static inline u32 omap_dm_timer_reserved_systimer(int id)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 02/14] ARM: OMAP2+: Disable posted mode for the clocksource timer
When using a DMTIMER as the clock-source timer, posted mode configuration of
the DMTIMER is used. Posted mode is only benefical when configuring timers as
it allows writes to be posted and does not stall the CPU until the write is
complete. The clock-source timer is only configured once on boot and so using
posted mode has no benefit. In fact, by using posted mode, it adds overhead
to reading the timer. Therefore, by default disable posted mode for DMTIMERs
used for clock-source.
Using objdump this change reduces the function clocksource_read_cycles()
function from a total of 15 instructions (including 3 branches and 7 loads)
to 5 instructions (including 1 branch and 3 loads). Please note that before
the minimum number of instructions that would be executed when calling
clocksource_read_cycles() would be 9 instructions (including 2 branches and 5
loads) where as now it will always be 5 instructions.
This change also reduces the function dmtimer_read_sched_clock() function from
a total of 17 instructions (including 4 branches and 8 loads) to 6 instructions
(including 1 branch and 4 loads). Please note that before the minimum number of
instructions that would be executed when calling dmtimer_read_sched_clock()
would be 11 instructions (including 2 branches and 6 loads) where as now it
will always be 6 instructions.
This change removes the configuration of posted mode from the
__omap_dm_timer_reset() function and adds a new function called
omap_dm_timer_enable_posted() for enabling posted mode. Hence, call
omap_dm_timer_enable_posted() where ever we are calling __omap_dm_timer_reset().
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 28
arch/arm/plat-omap/dmtimer.c | 23 ++-
arch/arm/plat-omap/include/plat/dmtimer.h |5 +
3 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 28c6078..78b7712 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -83,11 +83,19 @@
#define NUMERATOR_DENUMERATOR_MASK 0xf000
/*
- * For clock-events timer, always use posted mode to
- * minimise CPU overhead for configuring the timer.
+ * For the clock-events timer, always use posted mode to
+ * minimise CPU overhead for configuring the timer. This timer
+ * is never read and so overhead of reading the timer in posted
+ * mode is not applicable.
*/
#define OMAP_CLKEVT_POSTEDMODE OMAP_TIMER_POSTED
-#define OMAP_CLKSRC_POSTEDMODE OMAP_TIMER_POSTED
+
+/*
+ * For the clock-source timer, always use non-posted mode to
+ * minimise CPU overhead for reading the timer. This timer is
+ * only configured once and so using posted mode has no benefit.
+ */
+#define OMAP_CLKSRC_POSTEDMODE OMAP_TIMER_NONPOSTED
/* Clockevent code */
@@ -233,7 +241,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;
@@ -319,10 +328,11 @@ 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 = clk_get_rate(timer-fclk);
+ if (posted)
+ omap_dm_timer_enable_posted(timer);
+ timer-rate = clk_get_rate(timer-fclk);
timer-reserved = 1;
return res;
@@ -334,7 +344,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property);
+ res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property,
+OMAP_CLKEVT_POSTEDMODE);
BUG_ON(res);
omap2_gp_timer_irq.dev_id = clkev;
@@ -461,7 +472,8 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, NULL);
+ res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, NULL,
+OMAP_CLKSRC_POSTEDMODE);
BUG_ON(res);
__omap_dm_timer_load_start(clksrc,
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index b09e556..699570b 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -131,8 +131,8 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer)
}
__omap_dm_timer_reset(timer, 0, 0);
+ omap_dm_timer_enable_posted
[PATCH V2 05/14] ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
all 12 instances of the DMTIMER. Please note that this is a difference between
OMAP3 and OMAP4 and could be the source of the confusion.
For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
12 timers. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..679c0ec 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -149,28 +149,13 @@ static struct omap_hwmod omap3xxx_debugss_hwmod = {
};
/* timer class */
-static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
- SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
- .sysc_fields= omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
- .name = timer,
- .sysc = omap3xxx_timer_1ms_sysc,
-};
-
static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -220,7 +205,7 @@ static struct omap_hwmod omap3xxx_timer1_hwmod = {
},
},
.dev_attr = capability_alwon_dev_attr,
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer2 */
@@ -237,7 +222,7 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT2_SHIFT,
},
},
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer3 */
@@ -379,7 +364,7 @@ static struct omap_hwmod omap3xxx_timer10_hwmod = {
},
},
.dev_attr = capability_pwm_dev_attr,
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer11 */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 06/14] ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs
For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index bd9220e..8c3b3f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -58,7 +58,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 679c0ec..306c627 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -155,7 +155,8 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 03/14] 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 the timers as the CPU has to wait for the write to complete.
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.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
Please note that now calls to omap_dm_timer_enable_posted() may not able posted
mode if the device is impacted by this errata. Therefore, for system-timers
check to see if the intended posted mode matches the actual. If it does not then
there is a configuration error in the system timers posted configuration.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 15
arch/arm/plat-omap/dmtimer.c | 36 +
arch/arm/plat-omap/include/plat/dmtimer.h | 14 +++
3 files changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 78b7712..8b0068c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -332,6 +332,10 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (posted)
omap_dm_timer_enable_posted(timer);
+ /* Check that the intended posted configuration matches the actual */
+ if (posted != timer-posted)
+ return -EINVAL;
+
timer-rate = clk_get_rate(timer-fclk);
timer-reserved = 1;
@@ -344,6 +348,15 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
+ omap_dm_timer_populate_errata(clkev);
+
+ /*
+* For clock-event timers we never read the timer counter and
+* so we are not impacted by errata i103 and i767. Therefore,
+* we can safely ignore this errata for clock-event timers.
+*/
+ omap_dm_timer_override_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
+
res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property,
OMAP_CLKEVT_POSTEDMODE);
BUG_ON(res);
@@ -472,6 +485,8 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
{
int res;
+ omap_dm_timer_populate_errata(clksrc);
+
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, NULL,
OMAP_CLKSRC_POSTEDMODE);
BUG_ON(res);
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 699570b..4abbbe5 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -177,6 +177,37 @@ int omap_dm_timer_reserve_systimer(int id)
}
/**
+ * omap_dm_timer_populate_errata - populate errata flags for a timer
+ * @timer: pointer to timer handle
+ *
+ * For a given timer, populate the timer errata flags that are specific to the
+ * OMAP device being used.
+ */
+void omap_dm_timer_populate_errata(struct omap_dm_timer *timer)
+{
+ timer-errata = 0;
+
+ if (cpu_class_is_omap1
[PATCH V2 08/14] ARM: OMAP: Fix dmtimer reset for timer1
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
a fix was added to prevent timer1 being reset in the function
omap_dm_timer_reset() because timer1 was being used as the system timer for
OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index bf484aa..5a9f29b 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -124,11 +124,8 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- if (timer-pdev-id != 1) {
- omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
- omap_dm_timer_wait_for_reset(timer);
- }
-
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+ omap_dm_timer_wait_for_reset(timer);
__omap_dm_timer_reset(timer, 0, 0);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 09/14] ARM: OMAP: Don't restore of DMTIMER TISTAT register
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c |3 ---
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 4 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 5a9f29b..a350f12 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -86,9 +86,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- if (timer-revision == 1)
- __raw_writel(timer-context.tistat, timer-sys_stat);
-
__raw_writel(timer-context.tisr, timer-irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer-context.twer);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index ef93017..36b71a5 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -85,7 +85,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tistat;
u32 tisr;
u32 tier;
u32 twer;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 10/14] ARM: OMAP: Don't restore DMTIMER interrupt status register
Restoring the timer interrupt status is not possible because writing a 1 to any
bit in the register clears that bit if set and writing a 0 has no affect.
Furthermore, if an interrupt is pending when someone attempts to disable a
timer, the timer will fail to transition to the idle state and hence it's
context will not be lost. Users should take care to service all interrupts
before disabling the timer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c |5 +
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index a350f12..76553fd5 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -86,7 +86,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer-context.tisr, timer-irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer-context.twer);
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG,
@@ -495,7 +494,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
*/
timer-context.tclr =
omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
- timer-context.tisr = __raw_readl(timer-irq_stat);
omap_dm_timer_disable(timer);
return 0;
}
@@ -738,8 +736,7 @@ int omap_dm_timer_write_status(struct omap_dm_timer *timer,
unsigned int value)
return -EINVAL;
__omap_dm_timer_write_status(timer, value);
- /* Save the context */
- timer-context.tisr = value;
+
return 0;
}
EXPORT_SYMBOL_GPL(omap_dm_timer_write_status);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 36b71a5..af145a9 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -85,7 +85,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tisr;
u32 tier;
u32 twer;
u32 tclr;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 11/14] ARM: OMAP: Fix spurious interrupts when using timer match feature
The OMAP DMTIMERs can generate an interrupt when the timer counter value matches the value stored in the timer's match register. When using this feature spurious interrupts were seen, because the compare logic is being enabled before the match value is loaded and according to the documentation the match value must be loaded before the compare logic is enable. The reset value for the timer counter and match registers is 0 and hence, by enabling the compare logic before the actual match value is loaded a spurious interrupt can be generated as the reset values match. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/plat-omap/dmtimer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 76553fd5..e7bf0d1 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -638,8 +638,8 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable, l |= OMAP_TIMER_CTRL_CE; else l = ~OMAP_TIMER_CTRL_CE; - omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); omap_dm_timer_write_reg(timer, OMAP_TIMER_MATCH_REG, match); + omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); /* Save the context */ timer-context.tclr = l; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 07/14] ARM: OMAP2+: Don't use __omap_dm_timer_reset()
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.
For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
have the fields clock-activity, wakeup-enable and auto-idle and so this
function could configure the OCP_CFG register incorrectly.
Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
register for timers that have this field. Commit 0f0d080 (ARM: OMAP: DMTimer:
Use posted mode) configures the clock-activity field to keep the f-clk enabled
so that the wake-up capability is enabled. Therefore, add the appropriate flags
to the timer HWMOD structures to configure this field in the same way.
For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4
arch/arm/mach-omap2/timer.c|1 -
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 8c3b3f0..043b952 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -60,6 +60,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = CLOCKACT_TEST_ICLK,
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -268,6 +269,7 @@ struct omap_hwmod omap2xxx_timer1_hwmod = {
},
.dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer2 */
@@ -286,6 +288,7 @@ struct omap_hwmod omap2xxx_timer2_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer3 */
@@ -304,6 +307,7 @@ struct omap_hwmod omap2xxx_timer3_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer4 */
@@ -322,6 +326,7 @@ struct omap_hwmod omap2xxx_timer4_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer5 */
@@ -341,6 +346,7 @@ struct omap_hwmod omap2xxx_timer5_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer6 */
@@ -360,6 +366,7 @@ struct omap_hwmod omap2xxx_timer6_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer7 */
@@ -379,6 +386,7 @@ struct omap_hwmod omap2xxx_timer7_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer8 */
@@ -398,6 +406,7 @@ struct omap_hwmod omap2xxx_timer8_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer9 */
@@ -417,6 +426,7 @@ struct omap_hwmod omap2xxx_timer9_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer10 */
@@ -436,6 +446,7 @@ struct omap_hwmod omap2xxx_timer10_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer11 */
@@ -455,6 +466,7 @@ struct omap_hwmod omap2xxx_timer11_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags
[PATCH V2 12/14] ARM: OMAP: Add dmtimer interrupt disable function
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because the same interrupt
enable register is used to disable interrupts. However, some timer instances
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1,
2 and 10 need this function and for OMAP5 all timers need this function.
Please note that the interrupt disable function has been written so that it
can be used by all OMAP devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 31 +
arch/arm/plat-omap/include/plat/dmtimer.h |3 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index e7bf0d1..508a38e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -715,6 +715,37 @@ int omap_dm_timer_set_int_enable(struct omap_dm_timer
*timer,
}
EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_enable);
+/**
+ * omap_dm_timer_set_int_disable - disable timer interrupts
+ * @timer: pointer to timer handle
+ * @mask: bit mask of interrupts to be disabled
+ *
+ * Disables the specified timer interrupts for a timer.
+ */
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
+{
+ u32 l = mask;
+
+ if (unlikely(!timer))
+ return -EINVAL;
+
+ omap_dm_timer_enable(timer);
+
+ if (timer-revision == 1)
+ l = __raw_readl(timer-irq_ena) ~mask;
+
+ __raw_writel(l, timer-irq_dis);
+ l = omap_dm_timer_read_reg(timer, OMAP_TIMER_WAKEUP_EN_REG) ~mask;
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG, l);
+
+ /* Save the context */
+ timer-context.tier = ~mask;
+ timer-context.twer = ~mask;
+ omap_dm_timer_disable(timer);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_disable);
+
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
{
unsigned int l;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index af145a9..14190e8 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -137,6 +137,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int
def_on, int toggle, i
int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler);
int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer, unsigned int
value);
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask);
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer);
int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int
value);
@@ -322,7 +323,7 @@ static inline void __omap_dm_timer_init_regs(struct
omap_dm_timer *timer)
OMAP_TIMER_V1_SYS_STAT_OFFSET;
timer-irq_stat = timer-io_base + OMAP_TIMER_V1_STAT_OFFSET;
timer-irq_ena = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
- timer-irq_dis = NULL;
+ timer-irq_dis = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
timer-pend = timer-io_base + _OMAP_TIMER_WRITE_PEND_OFFSET;
timer-func_base = timer-io_base;
} else {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 13/14] ARM: OMAP: Remove unnecessary call to clk_get()
Whenever we call the function omap_dm_timer_set_source() to set the clock
source of a dmtimer we look-up the dmtimer functional clock source by
calling clk_get(). This is not necessary because on requesting a dmtimer
we look-up the functional clock source and store it in the omap_dm_timer
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 508a38e..191d5e5 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -503,7 +503,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
{
int ret;
char *parent_name = NULL;
- struct clk *fclk, *parent;
+ struct clk *parent;
struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
@@ -522,11 +522,8 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
if (pdata pdata-set_timer_src)
return pdata-set_timer_src(timer-pdev, source);
- fclk = clk_get(timer-pdev-dev, fck);
- if (IS_ERR_OR_NULL(fclk)) {
- pr_err(%s: fck not found\n, __func__);
+ if (!timer-fclk)
return -EINVAL;
- }
switch (source) {
case OMAP_TIMER_SRC_SYS_CLK:
@@ -545,18 +542,15 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
parent = clk_get(timer-pdev-dev, parent_name);
if (IS_ERR_OR_NULL(parent)) {
pr_err(%s: %s not found\n, __func__, parent_name);
- ret = -EINVAL;
- goto out;
+ return -EINVAL;
}
- ret = clk_set_parent(fclk, parent);
+ ret = clk_set_parent(timer-fclk, parent);
if (IS_ERR_VALUE(ret))
pr_err(%s: failed to set %s as parent\n, __func__,
parent_name);
clk_put(parent);
-out:
- clk_put(fclk);
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 14/14] ARM: OMAP: Remove __omap_dm_timer_set_source function
The __omap_dm_timer_set_source() function is only used by the system timer
(clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
remove this code from the dmtimer driver and move it to the system timer
code for OMAP2+ devices.
The current __omap_dm_timer_set_source() function calls clk_disable() before
calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
omap_hwmod_enable() to after the call to clk_set_parent() in
omap_dm_timer_init_one().
The function omap_hwmod_setup_one() will enable the timers functional clock
and therefore increment the use-count of the functional clock to 1.
clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
clk_disable() before calling clk_set_parent() to decrement the use-count.
Hence, avoid these extra calls to disable and enable the functional clock by
moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
clk_set_parent().
We can also remove the delay from the __omap_dm_timer_set_source() function
because enabling the clock will now be handled via the HWMOD framework by
calling omap_hwmod_setup_one(). Therefore, by moving the calls to
omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
clk_set_parent().
It should be safe to move these hwmod calls to later in the
omap_dm_timer_init_one() because other calls to the hwmod layer that occur
before are just requesting resource information.
Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
with the following configurations:
1. CONFIG_OMAP_32K_TIMER=y
2. CONFIG_OMAP_32K_TIMER=y and boot parameter clocksource=gp_timer
3. CONFIG_OMAP_32K_TIMER not set
4. CONFIG_OMAP_32K_TIMER not set and boot parameter clocksource=gp_timer
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |9 -
arch/arm/plat-omap/include/plat/dmtimer.h | 19 ---
2 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b9b6f21..066a48d 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -277,9 +277,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
oh_name = name;
}
- omap_hwmod_setup_one(oh_name);
oh = omap_hwmod_lookup(oh_name);
-
if (!oh)
return -ENODEV;
@@ -309,8 +307,6 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(timer-fclk))
return -ENODEV;
- omap_hwmod_enable(oh);
-
/* FIXME: Need to remove hard-coded test on timer ID */
if (gptimer_id != 12) {
struct clk *src;
@@ -319,13 +315,16 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(src)) {
res = -EINVAL;
} else {
- res = __omap_dm_timer_set_source(timer-fclk, src);
+ res = clk_set_parent(timer-fclk, src);
if (IS_ERR_VALUE(res))
pr_warn(%s: %s cannot set source\n,
__func__, oh-name);
clk_put(src);
}
}
+
+ omap_hwmod_setup_one(oh_name);
+ omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
if (posted)
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 14190e8..24a1c74 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -32,7 +32,6 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include linux/clk.h
#include linux/delay.h
#include linux/io.h
#include linux/platform_device.h
@@ -358,24 +357,6 @@ static inline void __omap_dm_timer_reset(struct
omap_dm_timer *timer,
__raw_writel(l, timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
}
-static inline int __omap_dm_timer_set_source(struct clk *timer_fck,
- struct clk *parent)
-{
- int ret;
-
- clk_disable(timer_fck);
- ret = clk_set_parent(timer_fck, parent);
- clk_enable(timer_fck);
-
- /*
-* When the functional clock disappears, too quick writes seem
-* to cause an abort. XXX Is this still necessary?
-*/
- __delay(30);
-
- return ret;
-}
-
static inline void __omap_dm_timer_stop(struct omap_dm_timer *timer,
int posted, unsigned long rate)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
Re: OMAP baseline test results for v3.7-rc4
On 11/07/2012 11:32 AM, Paul Walmsley wrote: On Wed, 7 Nov 2012, Jon Hunter wrote: On 11/04/2012 08:46 PM, Paul Walmsley wrote: * 4460pandaes: boot fails early - Appears to be due to X-loader problems here - Need to note the X-loader version so we know it's broken Are you still planning to investigate this further or migrate to a new bootloader? Yes. The problem with the current boot setup is that the new bootloader is breaking as well! :-( This can be seen by comparing: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/4460pandaes/4460pandaes_log.txt (the old bootloader) with http://www.pwsan.com/omap/testlogs/test_v3.7-rc4/20121104142910/boot/4460pandaes/4460pandaes_log.txt (the new bootloader) Dealing with this will require hands-on access, and unfortunately, right now I am traveling and away from my testbed. Next week, will take a closer look. With 4460 and 3.7-rc4, I am seeing that resume from suspend is not working (not sure when this broke though). I am just curious if anyone else sees this. My u-boot version is v2012.10. If you have the chance, it would be useful to know if any of the v3.7-rcs worked. Otherwise, will look at this next week. Kevin pointed me to his pm fixes for 3.8 as it is working there and I have confirmed suspend is fixed on v3.7-rc4 with the rom code fix [1] Kevin has queued for v3.8. Cheers Jon [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=ff999b8a0983ee15668394ed49e38d3568fc6859 -- To unsubscribe from this list: send the line unsubscribe 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
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.
#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 ...
{
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.
{
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 gptimer_id,
- const char *fck_source)
+static void __init omap2_sync32k_clocksource_init(int gptimer_id,
+ const char *fck_source)
{
- /*
- * First give preference to kernel parameter configuration
- * by user (clocksource=gp_timer).
- *
- * In case of missing kernel parameter for clocksource,
- * first check for availability for 32k-sync timer, in case
- * of failure in finding 32k_counter module or registering
- * it as clocksource, execution will fallback to gp-timer.
- */
- if (use_gptimer_clksrc == true)
- omap2_gptimer_clocksource_init(gptimer_id, fck_source);
- else if (omap2_sync32k_clocksource_init
Re: [PATCH V2 00/14] ARM: OMAP: DMTIMER fixes
On 11/07/2012 03:22 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121107 11:03]: This series includes several fixes for the OMAP DMTIMER driver. This is based upon 3.7-rc4 with the two series adding device-tree support for DMTIMERs [1] and the 32kHz Counter [2] These look OK to me, I'm assuming you'll do a pull request eventually for these. Might be worth checking if these merge fine also on omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3, rename detection might be able to deal with that for the header. Yes I was going to wait a few days for people to review before sending a pull request. I will make sure it merges on your master. Is Monday too late for v3.8? Cheers Jon [1] http://marc.info/?l=linux-omapm=135065875808614w=2 [2] http://marc.info/?l=linux-omapm=135119308123513w=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 07/11] ARM: OMAP: Move omap-pm-noop.c local to mach-omap2
On 10/31/2012 06:11 PM, Tony Lindgren wrote:
* Laurent Pinchart laurent.pinch...@ideasonboard.com [121031 16:03]:
Hi Tony,
On Wednesday 31 October 2012 13:58:50 Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121030 16:55]:
This code should be private to mach-omap2.
The only use for it in for omap1 has been in dmtimer.c
to check for context loss. However, omap1 does not
lose context during idle, so the code is not needed.
Further, omap1 timer has OMAP_TIMER_ALWON set, so omap1
was not hitting omap_pm_get_dev_context_loss_count()
test.
Noticed one issue with my test compiles in the
omap-for-v3.8/cleanup-headers branch that can be
fixed along with this patch.
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -36,7 +36,6 @@
#include media/v4l2-ioctl.h
#include plat/iommu.h
#include plat/iovmm.h
-#include plat/omap-pm.h
The reason this was included was to call omap_pm_set_min_bus_tput() in
earlier
versions of the driver. We'll have to discuss what to replace that with, but
that's another topic.
OK thanks.
@@ -730,6 +732,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
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)) {
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h index 85868e9..3f5b9cf 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -94,6 +94,7 @@ struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
+ int (*get_context_loss_count)(struct device *);
That's a step forward for the common zImage, but one step backward for DT
support :-) I'm fine with this for now, but do you already have an idea on
how
to solve that ?
When it's converted to be a device driver, it can do it
using runtime PM calls.
I am not sure if you are referring to runtime pm callbacks here, but if
so I am not sure I follow. Drivers such as dmtimer and gpio that are
using runtime pm are still dependent on OMAP specific APIs (such as
omap_pm_get_dev_context_loss_count()) for determining if the context was
lost between suspending and resuming the device. So I am not sure how
runtime pm solves this.
Speaking with Rob Herring, one solution for DT would be using bus
notifiers to populate such function pointers when a device is added.
Given that there are a few devices using this architecture specific API
for context loss I am wondering if we can do something generic in
omap_device.c for DT.
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 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. Yes that's possible, however, in patch #2, I am disabling posted mode for clock-source (see changelog of patch #2 for details). Having these #defines makes it easier to change the posted configuration. That was the real motivation here. 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 V2 02/14] ARM: OMAP2+: Disable posted mode for the clocksource timer
On 11/07/2012 04:10 PM, Santosh Shilimkar wrote: On Wednesday 07 November 2012 01:01 PM, Jon Hunter wrote: When using a DMTIMER as the clock-source timer, posted mode configuration of the DMTIMER is used. Posted mode is only benefical when configuring timers as it allows writes to be posted and does not stall the CPU until the write is complete. The clock-source timer is only configured once on boot and so using posted mode has no benefit. In fact, by using posted mode, it adds overhead to reading the timer. Therefore, by default disable posted mode for DMTIMERs used for clock-source. Using objdump this change reduces the function clocksource_read_cycles() function from a total of 15 instructions (including 3 branches and 7 loads) to 5 instructions (including 1 branch and 3 loads). Please note that before the minimum number of instructions that would be executed when calling clocksource_read_cycles() would be 9 instructions (including 2 branches and 5 loads) where as now it will always be 5 instructions. This change also reduces the function dmtimer_read_sched_clock() function from a total of 17 instructions (including 4 branches and 8 loads) to 6 instructions (including 1 branch and 4 loads). Please note that before the minimum number of instructions that would be executed when calling dmtimer_read_sched_clock() would be 11 instructions (including 2 branches and 6 loads) where as now it will always be 6 instructions. This isn't right way to calculate the penalty of posted mode. Non-posted mode can results in 100 of cycles wait over interconnect and that can not be justified with few instructions savings. Right, I see your point. Non-posted reads are going to add re-synchronisation overhead. However, our hands are tied here because of errata i103 we can't use posted mode for reading the counter. So may be I should squash this change with patch #3 and just make this part of the errata workaround. I can always re-visit later and do some profiling to see what the optimal configuration should be. This change removes the configuration of posted mode from the __omap_dm_timer_reset() function and adds a new function called omap_dm_timer_enable_posted() for enabling posted mode. Hence, call omap_dm_timer_enable_posted() where ever we are calling __omap_dm_timer_reset(). Signed-off-by: Jon Hunter jon-hun...@ti.com --- But clock-source doesn't involve much into writes so patch as such is fine. Yes writes are only on init. 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 V2 01/14] ARM: OMAP: Add DMTIMER definitions for posted mode
On 11/07/2012 04:18 PM, Santosh Shilimkar wrote: On Wednesday 07 November 2012 04:11 PM, Jon Hunter wrote: 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. Yes that's possible, however, in patch #2, I am disabling posted mode for clock-source (see changelog of patch #2 for details). Having these #defines makes it easier to change the posted configuration. That was the real motivation here. Sure but that is more confusing because you are flipping the meaning of the macro. Better to specify direct argument to avoid the confusion. Hmmm ... I guess I don't see it that way. The intent was that the definitions OMAP_CLKxxx_POSTEDMODE described the posted configuration (ie. posted or non-posted) and a user could change/flip it if so desired. I can use the OMAP_TIMER_POSTED/NONPOSTED directly, but my concern with that was if someone wanted to changed the posted mode then they have to change it in multiple places and there is a chance they could miss one. This way, as long as I have it right to begin with, then no one should be able to screw it up :-) 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 V2 03/14] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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. Cheers Jon From 0143aa216ef4c4b7554588bd72c417bc8c614525 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] 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 | 44 + arch/arm/plat-omap/dmtimer.c | 59 - arch/arm/plat-omap/include/plat/dmtimer.h | 19 -- 3 files changed, 109 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 28c6078..37e3089 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -83,11 +83,20 @@ #define NUMERATOR_DENUMERATOR_MASK 0xf000 /* - * For clock-events timer, always use posted mode to - * minimise CPU overhead for configuring the timer. + * For the clock-events timer, always use posted mode to + * minimise CPU overhead for configuring the timer. This timer + * is never read and so overhead of reading the timer in posted + * mode is not applicable. */ #define OMAP_CLKEVT_POSTEDMODE OMAP_TIMER_POSTED -#define OMAP_CLKSRC_POSTEDMODE OMAP_TIMER_POSTED + +/* + * For the clock-source timer, use non-posted mode default due to + * errata i103/i767 that can cause the timer to return an incorrect + * counter value for OMAP3/4/5 devices. REVISIT this to see what is + * the optimal way to handle for future devices. + */ +#define OMAP_CLKSRC_POSTEDMODE OMAP_TIMER_NONPOSTED /* Clockevent code */ @@ -233,7 +242,8 @@ void __init omap_dmtimer_init(void) static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer
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 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 = clk_get_rate(timer
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: [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:
omapx_gptimer_timer_init
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 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 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: [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 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
[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] 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] 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
[PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once. Signed-off-by: Jon Hunter jon-hun...@ti.com --- Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors. [1] http://marc.info/?l=linux-omapm=135231490218361w=2 arch/arm/mach-omap2/soc.h |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index 0700964..6b270a0 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -25,6 +25,9 @@ * */ +#ifndef __ARCH_ARM_MACH_OMAP2_SOC_H +#define __ARCH_ARM_MACH_OMAP2_SOC_H + #include omap24xx.h #include omap34xx.h #include omap44xx.h @@ -471,3 +474,4 @@ OMAP4_HAS_FEATURE(mpu_1_5ghz, MPU_1_5GHZ) #endif /* __ASSEMBLY__ */ +#endif /* __ARCH_ARM_MACH_OMAP2_SOC_H */ -- 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] ARM: OMAP2+: Prevent redefinition errors for soc.h
On 11/09/2012 10:22 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121109 08:21]: If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once. Signed-off-by: Jon Hunter jon-hun...@ti.com --- Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors. [1] http://marc.info/?l=linux-omapm=135231490218361w=2 As these headers are private to mach-omap2, I'd rather not allow including them more than once so we can eventually clean up the includes further. We should include the headers directly where used, except for the legacy board-*.c files that will be going away anyways. Including the files directly should fix this easily, if not let me know. The alternative fix is to ensure anyone including dmtimer.h also includes soc.h. However, I did not know if we should have such a dependency. If you are ok with that then that is what I will do for now. It is not a massive change. 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 V2 03/14] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
On 11/08/2012 10:55 AM, Jon Hunter wrote:
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.
Another minor update after rebasing on Tony's linux-omap master. I
needed to fix-up headers included.
Cheers
Jon
From 0b2e3ef2cea7896f6466e010f9ab22a86a00bba1 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] 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
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 35 +
arch/arm/plat-omap/dmtimer.c | 60 -
arch/arm/plat-omap/include/plat/dmtimer.h | 18 +++--
3 files changed, 100 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a135d28..23ebe15 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -225,7 +225,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;
@@ -311,10 +312,15 @@ static int __init
Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
On 10/15/2012 09:39 PM, Vinod Koul wrote: On Tue, 2012-10-16 at 10:43 +0800, Shawn Guo wrote: On Tue, Sep 25, 2012 at 10:05:01AM +0530, Vinod Koul wrote: On Mon, 2012-09-24 at 17:25 -0500, Jon Hunter wrote: For DT bindings, I think the binding itself shouldn't change based on my work but I would like these same bindings to help build the DMA engine code mappings. Now would it make sense to NOT merge these changes for 3.7 and postpone to 3.8. I can host these patches on a topic branch and merge them when we are ready. I plan to spend some good amount of time on my work this week so we should be ready pretty soon. One these changes are merged, users can start moving to this scheme. I just wanted to see how things are progressing your side. Did you create a topic branch for this? If so let me know where I can find it, I did not find a branch on your infradead git tree. I wanted to pull in the latest patches for some testing. Sorry for delay, I had everything ready, but couldn't manage to commit and push. I have pushed to topic/dmaengine_dt, it is pushing out now... Vinod, Looks it seemed 3.7-rc1. Does that mean we have to wait for 3.8, or will it show on later -rc for 3.7? Yes this will be merged once we work out the common interface, otherwise we will end up redoing interfaces for all drivers. Hi Vinod, A few people have been asking me if getting device-tree support for DMA engine is plan for record for v3.8. I know that you were working through implementing a common interface and so I wanted to check how that is going. Do you have any insight to when device-tree support may get added? 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+: Prevent redefinition errors for soc.h
On 11/09/2012 03:10 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121109 08:31]: On 11/09/2012 10:22 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121109 08:21]: If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once. Signed-off-by: Jon Hunter jon-hun...@ti.com --- Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors. [1] http://marc.info/?l=linux-omapm=135231490218361w=2 As these headers are private to mach-omap2, I'd rather not allow including them more than once so we can eventually clean up the includes further. We should include the headers directly where used, except for the legacy board-*.c files that will be going away anyways. Including the files directly should fix this easily, if not let me know. The alternative fix is to ensure anyone including dmtimer.h also includes soc.h. However, I did not know if we should have such a dependency. If you are ok with that then that is what I will do for now. It is not a massive change. Do you mean anything under mach-omap2/*.c including dmtimer.h also needs to also include soc.h? If sounds OK to me as long as we don't need to include soc.h outside mach-omap2. Yes exactly. Right now dmtimer.h is including plat/cpu.h and so is indirectly including soc.h. The function omap_dm_timer_populate_errata() is using the cpu_is_ macros. So maybe I should move this to into platform data. Is that better? 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+: Prevent redefinition errors for soc.h
On 11/09/2012 05:50 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121109 15:44]:
On 11/09/2012 03:10 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121109 08:31]:
On 11/09/2012 10:22 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121109 08:21]:
If the header soc.h is included more than once in a source (for example
once directly by the source file and once indirectly by another header
file), then the compiler will generate redefintion errors for the macros
in soc.h. Prevent this by only allowing the content in soc.h to be
included once.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Please note that I ran into this problem when rebasing my dmtimer fixes
series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h
in dmtimer.h and I found several other files including dmtimer.h are also
including soc.h and so generate a lot of errors.
[1] http://marc.info/?l=linux-omapm=135231490218361w=2
As these headers are private to mach-omap2, I'd rather not allow including
them more than once so we can eventually clean up the includes further.
We should include the headers directly where used, except for the
legacy board-*.c files that will be going away anyways.
Including the files directly should fix this easily, if not let me
know.
The alternative fix is to ensure anyone including dmtimer.h also
includes soc.h. However, I did not know if we should have such a
dependency. If you are ok with that then that is what I will do for now.
It is not a massive change.
Do you mean anything under mach-omap2/*.c including dmtimer.h also
needs to also include soc.h? If sounds OK to me as long as we don't
need to include soc.h outside mach-omap2.
Yes exactly. Right now dmtimer.h is including plat/cpu.h and so is
indirectly including soc.h. The function omap_dm_timer_populate_errata()
is using the cpu_is_ macros. So maybe I should move this to into
platform data. Is that better?
I think I already fixed that up in the cleanup branch. I've now
merged that into the omap-for-v3.8/dt branch. The only remaining
cpu_is_omap usage there is:
$ grep cpu_is_omap arch/arm/plat-omap/*.[chS]
arch/arm/plat-omap/fb.c:if (cpu_is_omap24xx()) {
arch/arm/plat-omap/fb.c:} else if (cpu_is_omap34xx()) {
So maybe see what needs to be patches on top of omap-for-v3.8/dt?
Sorry, I meant in the fixes series I have posted for dmtimer, I am
adding a new function called omap_dm_timer_populate_errata() that is
using cpu_is_() [1]. I had done this a while back, but now I see
that we want to get away from doing that right?
I was planning on sending you a pull request for that series on Monday
but now I am wondering if I should fix this now or later. I was hoping
this series would make 3.8.
Cheers
Jon
[1] http://marc.info/?l=linux-omapm=135249008128365w=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+: Prevent redefinition errors for soc.h
On 11/09/2012 06:21 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121109 15:59]: Sorry, I meant in the fixes series I have posted for dmtimer, I am adding a new function called omap_dm_timer_populate_errata() that is using cpu_is_() [1]. I had done this a while back, but now I see that we want to get away from doing that right? Yes. Looks like everything we have under plat-omap can be moved to live under drivers eventually, so let's not use cpu_is_omap there either. For legacy boot, you can use pdata-timer_capability for passing that? Yes, but I prefer to keep capability and errata separate. So I have added an timer_errata variable to the pdata for now. I was planning on sending you a pull request for that series on Monday but now I am wondering if I should fix this now or later. I was hoping this series would make 3.8. Yeah, sounds like that should be fixed though as we still have a bit of time early next week. Ok, great. I have re-worked and will stress test over the weekend. I will send out an updated series Monday and then send a pull request later in the week if you are ok with it. 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
[PATCH V3 00/13] ARM: OMAP: DMTIMER fixes
This series includes several fixes for the OMAP DMTIMER driver. This is based upon Tony Lindgren's current master branch [1]. Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda. Testing includes ... 1. Booting kernel on above boards 2. Set date and ensuring time of day is correct after 24 hours 3. Checking the timer counter is incrementing when configuring and starting a timer 4. Checking the timer overflow interrupt when timer expires. 5. Using different clock sources to operate the timer with. 6. Running a loop test overnight that continually runs test #3 and #4 for each available timer This has also been boot tested on the AM335x Beagle Bone. V3 changes: - Combined patches #2 and #3 in version 2 series into single patch. - Updated errata i103/i767 workaround to pass errata information via platform data to avoid using cpu_is_() macros in dmtimer driver. [1] http://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git Jon Hunter (13): ARM: OMAP: Add DMTIMER definitions for posted mode ARM: OMAP3+: Implement timer workaround for errata i103 and i767 ARM: OMAP: Fix timer posted mode support ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs ARM: OMAP2+: Don't use __omap_dm_timer_reset() ARM: OMAP: Fix dmtimer reset for timer1 ARM: OMAP: Don't restore of DMTIMER TISTAT register ARM: OMAP: Don't restore DMTIMER interrupt status register ARM: OMAP: Fix spurious interrupts when using timer match feature ARM: OMAP: Add dmtimer interrupt disable function ARM: OMAP: Remove unnecessary call to clk_get() ARM: OMAP: Remove __omap_dm_timer_set_source function arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 15 +++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 41 +-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 + arch/arm/mach-omap2/timer.c| 70 +- arch/arm/plat-omap/dmtimer.c | 77 arch/arm/plat-omap/include/plat/dmtimer.h | 72 +- 6 files changed, 188 insertions(+), 91 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 02/13] 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
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 49 ++-
arch/arm/plat-omap/dmtimer.c |3 +-
arch/arm/plat-omap/include/plat/dmtimer.h | 52 +++--
3 files changed, 93 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a135d28..63229c5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -222,10 +222,24 @@ void __init omap_dmtimer_init(void)
}
}
+/**
+ * omap_dm_timer_get_errata - get errata flags for a timer
+ *
+ * Get the timer errata flags that are specific to the OMAP device being used.
+ */
+u32 __init omap_dm_timer_get_errata(void)
+{
+ if (cpu_is_omap24xx())
+ return 0;
+
+ return OMAP_TIMER_ERRATA_I103_I767;
+}
+
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;
@@ -311,10 +325,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 = clk_get_rate(timer-fclk);
+ if (posted)
+ __omap_dm_timer_enable_posted(timer);
+
+ /* Check that the intended posted configuration matches the actual */
+ if (posted != timer-posted)
+ return -EINVAL;
+ timer-rate = clk_get_rate(timer-fclk);
timer-reserved = 1;
return res;
@@ -326,7 +345,17 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property);
+ clkev.errata = omap_dm_timer_get_errata();
+
+ /*
+* For clock-event timers we
[PATCH V3 01/13] 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
Acked-by: Santosh Shilimkar santosh.shilim...@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 684d2fc..a135d28 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -108,7 +108,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;
}
@@ -118,7 +118,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:
@@ -126,10 +126,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;
@@ -359,7 +359,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 = {
@@ -373,7 +374,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;
}
@@ -455,7 +457,8 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
BUG_ON(res);
__omap_dm_timer_load_start(clksrc,
- OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
+ OMAP_TIMER_POSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(clocksource_gpt, clksrc.rate))
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index f8943c8..1bee0ac 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,10 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE0x02
+/* posted mode types */
+#define OMAP_TIMER_NONPOSTED 0x00
+#define OMAP_TIMER_POSTED 0x01
+
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x8000
#define OMAP_TIMER_ALWON 0x4000
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 03/13] ARM: OMAP: Fix timer posted mode support
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the timer-posted variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which was before the
omap_dm_timer_enable_posted() function was introduced. Although this is a
regression from the original code it only impacts performance and so is not
needed for stable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 381a612..10ec31b 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -121,21 +121,16 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- omap_dm_timer_enable(timer);
if (timer-pdev-id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
__omap_dm_timer_reset(timer, 0, 0);
- __omap_dm_timer_enable_posted(timer);
- omap_dm_timer_disable(timer);
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
- int ret;
-
/*
* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
* do not call clk_get() for these devices.
@@ -149,13 +144,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
}
}
+ omap_dm_timer_enable(timer);
+
if (timer-capability OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+ __omap_dm_timer_enable_posted(timer);
+ omap_dm_timer_disable(timer);
- timer-posted = 1;
- return ret;
+ return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
}
static inline u32 omap_dm_timer_reserved_systimer(int id)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 04/13] ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
all 12 instances of the DMTIMER. Please note that this is a difference between
OMAP3 and OMAP4 and could be the source of the confusion.
For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
12 timers. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index abe66ce..fac2550 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -153,28 +153,13 @@ static struct omap_hwmod omap3xxx_debugss_hwmod = {
};
/* timer class */
-static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
- SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
- .sysc_fields= omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
- .name = timer,
- .sysc = omap3xxx_timer_1ms_sysc,
-};
-
static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -224,7 +209,7 @@ static struct omap_hwmod omap3xxx_timer1_hwmod = {
},
},
.dev_attr = capability_alwon_dev_attr,
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer2 */
@@ -241,7 +226,7 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT2_SHIFT,
},
},
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer3 */
@@ -383,7 +368,7 @@ static struct omap_hwmod omap3xxx_timer10_hwmod = {
},
},
.dev_attr = capability_pwm_dev_attr,
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer11 */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 05/13] ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs
For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index a0116d0..067fd0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -58,7 +58,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index fac2550..fcce693 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -159,7 +159,8 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 08/13] ARM: OMAP: Don't restore of DMTIMER TISTAT register
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c |3 ---
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 4 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d4f9541..320d103 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -83,9 +83,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- if (timer-revision == 1)
- __raw_writel(timer-context.tistat, timer-sys_stat);
-
__raw_writel(timer-context.tisr, timer-irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer-context.twer);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index ac16f1e..2f9fd1d 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -84,7 +84,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tistat;
u32 tisr;
u32 tier;
u32 twer;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 06/13] ARM: OMAP2+: Don't use __omap_dm_timer_reset()
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.
For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
have the fields clock-activity, wakeup-enable and auto-idle and so this
function could configure the OCP_CFG register incorrectly.
Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
register for timers that have this field. Commit 0f0d080 (ARM: OMAP: DMTimer:
Use posted mode) configures the clock-activity field to keep the f-clk enabled
so that the wake-up capability is enabled. Therefore, add the appropriate flags
to the timer HWMOD structures to configure this field in the same way.
For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4
arch/arm/mach-omap2/timer.c|1 -
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 067fd0a..0db8f45 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -60,6 +60,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = CLOCKACT_TEST_ICLK,
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -268,6 +269,7 @@ struct omap_hwmod omap2xxx_timer1_hwmod = {
},
.dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer2 */
@@ -286,6 +288,7 @@ struct omap_hwmod omap2xxx_timer2_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer3 */
@@ -304,6 +307,7 @@ struct omap_hwmod omap2xxx_timer3_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer4 */
@@ -322,6 +326,7 @@ struct omap_hwmod omap2xxx_timer4_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer5 */
@@ -341,6 +346,7 @@ struct omap_hwmod omap2xxx_timer5_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer6 */
@@ -360,6 +366,7 @@ struct omap_hwmod omap2xxx_timer6_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer7 */
@@ -379,6 +386,7 @@ struct omap_hwmod omap2xxx_timer7_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer8 */
@@ -398,6 +406,7 @@ struct omap_hwmod omap2xxx_timer8_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer9 */
@@ -417,6 +426,7 @@ struct omap_hwmod omap2xxx_timer9_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer10 */
@@ -436,6 +446,7 @@ struct omap_hwmod omap2xxx_timer10_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer11 */
@@ -455,6 +466,7 @@ struct omap_hwmod omap2xxx_timer11_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class
[PATCH V3 09/13] ARM: OMAP: Don't restore DMTIMER interrupt status register
Restoring the timer interrupt status is not possible because writing a 1 to any
bit in the register clears that bit if set and writing a 0 has no affect.
Furthermore, if an interrupt is pending when someone attempts to disable a
timer, the timer will fail to transition to the idle state and hence it's
context will not be lost. Users should take care to service all interrupts
before disabling the timer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c |5 +
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 320d103..f0a3c4c 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -83,7 +83,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer-context.tisr, timer-irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer-context.twer);
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG,
@@ -440,7 +439,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
*/
timer-context.tclr =
omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
- timer-context.tisr = __raw_readl(timer-irq_stat);
omap_dm_timer_disable(timer);
return 0;
}
@@ -684,8 +682,7 @@ int omap_dm_timer_write_status(struct omap_dm_timer *timer,
unsigned int value)
return -EINVAL;
__omap_dm_timer_write_status(timer, value);
- /* Save the context */
- timer-context.tisr = value;
+
return 0;
}
EXPORT_SYMBOL_GPL(omap_dm_timer_write_status);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 2f9fd1d..0c07e37 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -84,7 +84,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tisr;
u32 tier;
u32 twer;
u32 tclr;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 13/13] ARM: OMAP: Remove __omap_dm_timer_set_source function
The __omap_dm_timer_set_source() function is only used by the system timer
(clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
remove this code from the dmtimer driver and move it to the system timer
code for OMAP2+ devices.
The current __omap_dm_timer_set_source() function calls clk_disable() before
calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
omap_hwmod_enable() to after the call to clk_set_parent() in
omap_dm_timer_init_one().
The function omap_hwmod_setup_one() will enable the timers functional clock
and therefore increment the use-count of the functional clock to 1.
clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
clk_disable() before calling clk_set_parent() to decrement the use-count.
Hence, avoid these extra calls to disable and enable the functional clock by
moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
clk_set_parent().
We can also remove the delay from the __omap_dm_timer_set_source() function
because enabling the clock will now be handled via the HWMOD framework by
calling omap_hwmod_setup_one(). Therefore, by moving the calls to
omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
clk_set_parent().
It should be safe to move these hwmod calls to later in the
omap_dm_timer_init_one() because other calls to the hwmod layer that occur
before are just requesting resource information.
Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
with the following configurations:
1. CONFIG_OMAP_32K_TIMER=y
2. CONFIG_OMAP_32K_TIMER=y and boot parameter clocksource=gp_timer
3. CONFIG_OMAP_32K_TIMER not set
4. CONFIG_OMAP_32K_TIMER not set and boot parameter clocksource=gp_timer
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c |9 -
arch/arm/plat-omap/dmtimer.c |1 +
arch/arm/plat-omap/include/plat/dmtimer.h | 19 ---
3 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 19765bd..099e406 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -274,9 +274,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
oh_name = name;
}
- omap_hwmod_setup_one(oh_name);
oh = omap_hwmod_lookup(oh_name);
-
if (!oh)
return -ENODEV;
@@ -306,8 +304,6 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(timer-fclk))
return -ENODEV;
- omap_hwmod_enable(oh);
-
/* FIXME: Need to remove hard-coded test on timer ID */
if (gptimer_id != 12) {
struct clk *src;
@@ -316,13 +312,16 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(src)) {
res = -EINVAL;
} else {
- res = __omap_dm_timer_set_source(timer-fclk, src);
+ res = clk_set_parent(timer-fclk, src);
if (IS_ERR_VALUE(res))
pr_warn(%s: %s cannot set source\n,
__func__, oh-name);
clk_put(src);
}
}
+
+ omap_hwmod_setup_one(oh_name);
+ omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
if (posted)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 305faf5..9deeb30 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -35,6 +35,7 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include linux/clk.h
#include linux/module.h
#include linux/io.h
#include linux/device.h
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 769efb6..05a36e1 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -32,7 +32,6 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include linux/clk.h
#include linux/delay.h
#include linux/io.h
#include linux/platform_device.h
@@ -397,24 +396,6 @@ static inline void __omap_dm_timer_override_errata(struct
omap_dm_timer *timer,
timer-errata = ~errata;
}
-static inline int __omap_dm_timer_set_source(struct clk *timer_fck,
- struct clk *parent)
-{
- int ret;
-
- clk_disable(timer_fck);
- ret = clk_set_parent(timer_fck, parent);
- clk_enable(timer_fck);
-
- /*
-* When the functional clock disappears, too quick
[PATCH V3 11/13] ARM: OMAP: Add dmtimer interrupt disable function
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because the same interrupt
enable register is used to disable interrupts. However, some timer instances
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1,
2 and 10 need this function and for OMAP5 all timers need this function.
Please note that the interrupt disable function has been written so that it
can be used by all OMAP devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 31 +
arch/arm/plat-omap/include/plat/dmtimer.h |3 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index a38e896..b4e6634 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -661,6 +661,37 @@ int omap_dm_timer_set_int_enable(struct omap_dm_timer
*timer,
}
EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_enable);
+/**
+ * omap_dm_timer_set_int_disable - disable timer interrupts
+ * @timer: pointer to timer handle
+ * @mask: bit mask of interrupts to be disabled
+ *
+ * Disables the specified timer interrupts for a timer.
+ */
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
+{
+ u32 l = mask;
+
+ if (unlikely(!timer))
+ return -EINVAL;
+
+ omap_dm_timer_enable(timer);
+
+ if (timer-revision == 1)
+ l = __raw_readl(timer-irq_ena) ~mask;
+
+ __raw_writel(l, timer-irq_dis);
+ l = omap_dm_timer_read_reg(timer, OMAP_TIMER_WAKEUP_EN_REG) ~mask;
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG, l);
+
+ /* Save the context */
+ timer-context.tier = ~mask;
+ timer-context.twer = ~mask;
+ omap_dm_timer_disable(timer);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_disable);
+
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
{
unsigned int l;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 0c07e37..769efb6 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -135,6 +135,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int
def_on, int toggle, i
int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler);
int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer, unsigned int
value);
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask);
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer);
int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int
value);
@@ -321,7 +322,7 @@ static inline void __omap_dm_timer_init_regs(struct
omap_dm_timer *timer)
OMAP_TIMER_V1_SYS_STAT_OFFSET;
timer-irq_stat = timer-io_base + OMAP_TIMER_V1_STAT_OFFSET;
timer-irq_ena = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
- timer-irq_dis = NULL;
+ timer-irq_dis = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
timer-pend = timer-io_base + _OMAP_TIMER_WRITE_PEND_OFFSET;
timer-func_base = timer-io_base;
} else {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 07/13] ARM: OMAP: Fix dmtimer reset for timer1
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
a fix was added to prevent timer1 being reset in the function
omap_dm_timer_reset() because timer1 was being used as the system timer for
OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 10ec31b..d4f9541 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -121,11 +121,8 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- if (timer-pdev-id != 1) {
- omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
- omap_dm_timer_wait_for_reset(timer);
- }
-
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+ omap_dm_timer_wait_for_reset(timer);
__omap_dm_timer_reset(timer, 0, 0);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 10/13] ARM: OMAP: Fix spurious interrupts when using timer match feature
The OMAP DMTIMERs can generate an interrupt when the timer counter value matches the value stored in the timer's match register. When using this feature spurious interrupts were seen, because the compare logic is being enabled before the match value is loaded and according to the documentation the match value must be loaded before the compare logic is enable. The reset value for the timer counter and match registers is 0 and hence, by enabling the compare logic before the actual match value is loaded a spurious interrupt can be generated as the reset values match. Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/plat-omap/dmtimer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index f0a3c4c..a38e896 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -584,8 +584,8 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable, l |= OMAP_TIMER_CTRL_CE; else l = ~OMAP_TIMER_CTRL_CE; - omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); omap_dm_timer_write_reg(timer, OMAP_TIMER_MATCH_REG, match); + omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); /* Save the context */ timer-context.tclr = l; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 12/13] ARM: OMAP: Remove unnecessary call to clk_get()
Whenever we call the function omap_dm_timer_set_source() to set the clock
source of a dmtimer we look-up the dmtimer functional clock source by
calling clk_get(). This is not necessary because on requesting a dmtimer
we look-up the functional clock source and store it in the omap_dm_timer
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index b4e6634..305faf5 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -448,7 +448,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
{
int ret;
char *parent_name = NULL;
- struct clk *fclk, *parent;
+ struct clk *parent;
struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
@@ -467,11 +467,8 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
if (pdata pdata-set_timer_src)
return pdata-set_timer_src(timer-pdev, source);
- fclk = clk_get(timer-pdev-dev, fck);
- if (IS_ERR_OR_NULL(fclk)) {
- pr_err(%s: fck not found\n, __func__);
+ if (!timer-fclk)
return -EINVAL;
- }
switch (source) {
case OMAP_TIMER_SRC_SYS_CLK:
@@ -490,18 +487,15 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
parent = clk_get(timer-pdev-dev, parent_name);
if (IS_ERR_OR_NULL(parent)) {
pr_err(%s: %s not found\n, __func__, parent_name);
- ret = -EINVAL;
- goto out;
+ return -EINVAL;
}
- ret = clk_set_parent(fclk, parent);
+ ret = clk_set_parent(timer-fclk, parent);
if (IS_ERR_VALUE(ret))
pr_err(%s: failed to set %s as parent\n, __func__,
parent_name);
clk_put(parent);
-out:
- clk_put(fclk);
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/11/2012 03:16 AM, Igor Grinberg wrote: On 11/08/12 18:20, 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? Is the renaming that bad? One line per machine_desc structure? Of course we can skip the renaming, but then it will be less consistent and will not reflect the actual timer source used. I tried to make it flexible as much as possible and self explanatory. So above are my considerations, but at this point in time I don't really care if we rename them or just add a new one, but we have to get rid of the ugly fall back. I am not sure if you guys disagree, but does it make sense to start thinking about this with regard to device-tree? With device-tree all the boards files will become obsolete and so we need to be able to handle this during boot time and not compile time. 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? Of course I can... but I tried to create a flexible generic code, so no meter how a board will be wired, you just need to specify which timer source it uses and be done with it. If you are concerned about how a board is wired up (if the 32k is present), then I think that that is best handled via device-tree and we should query device-tree on boot to see what our options are. What do you guys think? 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/11/2012 05:28 AM, Igor Grinberg wrote: On 11/08/12 21:16, Jon Hunter wrote: 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. Well, that is what my commit message says... Sorry, but that was not clear to me from whats in the commit message. Should we be doing this now instead of adding all these static timer init functions? Are there any boards today (supported in the kernel that is), that don't support a 32k? If not, then this becomes simpler for the non-DT case and given that boards such as the AM335x will only support DT boot then we can figure out how to detect the presence of the 32k for DT only. 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 V3 00/13] ARM: OMAP: DMTIMER fixes
On 11/12/2012 02:34 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121112 10:22]: This series includes several fixes for the OMAP DMTIMER driver. This is based upon Tony Lindgren's current master branch [1]. You should be able to use omap-for-v3.8/dt as the base now with the cleanup merged there. The master branch is just a merge of the various topic branches, and can't be used as a base for pull requests. Ok, great will base on top of that branch. 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/13/2012 03:14 AM, Igor Grinberg wrote: On 11/12/12 21:15, Jon Hunter wrote: On 11/11/2012 05:28 AM, Igor Grinberg wrote: On 11/08/12 21:16, Jon Hunter wrote: 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. Well, that is what my commit message says... Sorry, but that was not clear to me from whats in the commit message. From the commit message: 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. The last sentence has it. Right, but it does not go into the details. It would be good to have added a comment to the effect of some boards do not have a 32k clock source and in the future this should be handled by device-tree. The transition to DT is not immediate and we can't (still) neglect the non-DT setups. Absolutely, but I am trying to understand if there are boards being neglected. I see now that your CM-T3517 would be. This was not clear from your patch as even the CM-T3517 board was being configured to the use the sync32k timer. So from looking at your patch I did not see any neglected boards, however, I understand your motivation to add all these init functions so that boards could be customised easily. Should we be doing this now instead of adding all these static timer init functions? I don't see this as adding ..., I see this as expanding the setup which was previously hidden by the CONFIG_OMAP_32K_TIMER option. Are there any boards today (supported in the kernel that is), that don't support a 32k? Yes, starting from revision 1.2, CM-T3517 does not have the 32k. Thanks, this is the exact information I was looking for. You should put this in your commit message to highlight the fact that there are boards that don't have a 32k clock source. I am familiar with the OMAP devices, but less familiar with these AM derivatives (as I don't work with these) and so it is good to put these specifics in the commit message. 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
[GIT PULL] ARM: OMAP: DMTIMER fixes
The following changes since commit d308ba50a1234b299a00e63a95e61fdeb2f1a2df: Merge branch 'omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3' into omap-for-v3.8/dt (2012-11-09 14:58:34 -0800) are available in the git repository at: g...@github.com:jonhunter/linux.git fixes-timer for you to fetch changes up to b1538832191d59e29b1077e64cf416a7617b45bc: ARM: OMAP: Remove __omap_dm_timer_set_source function (2012-11-12 16:23:57 -0600) Several fixes for the OMAP DMTIMER driver including ... 1. Adding workaround for OMAP3+ errata i103/i767 2. Fixing posted mode support 3. Spurious interrupts when using match interrupt 4. HWMOD fixes for timers 5. Unnecessary restoration of read-only registers 6. Adds function for disabling timer interrupts 7. Fixing timer1 reset for OMAP1 Jon Hunter (13): ARM: OMAP: Add DMTIMER definitions for posted mode ARM: OMAP3+: Implement timer workaround for errata i103 and i767 ARM: OMAP: Fix timer posted mode support ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs ARM: OMAP2+: Don't use __omap_dm_timer_reset() ARM: OMAP: Fix dmtimer reset for timer1 ARM: OMAP: Don't restore of DMTIMER TISTAT register ARM: OMAP: Don't restore DMTIMER interrupt status register ARM: OMAP: Fix spurious interrupts when using timer match feature ARM: OMAP: Add dmtimer interrupt disable function ARM: OMAP: Remove unnecessary call to clk_get() ARM: OMAP: Remove __omap_dm_timer_set_source function arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 15 +++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 41 +-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 + arch/arm/mach-omap2/timer.c| 70 +- arch/arm/plat-omap/dmtimer.c | 77 arch/arm/plat-omap/include/plat/dmtimer.h | 72 +- 6 files changed, 188 insertions(+), 91 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] ARM: OMAP: Clean-up DMTIMER
This series cleans-up the DMTIMER code and moves the DMTIMER header from plat/dmtimer.h to plat-omap/dmtimer.h in preparation for single zImage support. This series in based upon DMTIMER fixes series [1]. Tested on OMAP5912 OSK, OMAP3430 Beagle and OMAP4430 Panda. Testing includes ... 1. Booting kernel on above boards 2. Checking the timer counter is incrementing when configuring and starting a timer 3. Checking the timer overflow interrupt when timer expires. 4. Using different clock sources to operate the timer with. This has also been boot tested on the AM335x Beagle Bone. [1] http://marc.info/?l=linux-omapm=135275633628412w=2 Jon Hunter (8): ARM: OMAP: Clean-up dmtimer reset code ARM: OMAP: Define omap_dm_timer_prepare function as static ARM: OMAP: Don't store timers physical address ARM: OMAP2+: Remove unnecessary local variable in timer code ARM: OMAP: Remove unnecessary omap_dm_timer structure declaration ARM: OMAP: Add platform data header for DMTIMERs ARM: OMAP: Remove unnecessary inclusion of dmtimer.h ARM: OMAP: Move plat/dmtimer.h to plat-omap/dmtimer.h arch/arm/mach-omap1/pm.c |2 +- arch/arm/mach-omap1/timer.c|3 +- arch/arm/mach-omap1/timer32k.c |1 - arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 - arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 - arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/mach-omap2/pm-debug.c |1 - arch/arm/mach-omap2/timer.c| 28 +- arch/arm/plat-omap/dmtimer.c | 56 ++- arch/arm/plat-omap/include/plat-omap/dmtimer.h | 420 ++ arch/arm/plat-omap/include/plat/dmtimer.h | 450 drivers/staging/tidspbridge/core/dsp-clock.c |2 +- drivers/staging/tidspbridge/core/ue_deh.c |1 - include/linux/platform_data/dmtimer-omap.h | 31 ++ 16 files changed, 506 insertions(+), 497 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat-omap/dmtimer.h delete mode 100644 arch/arm/plat-omap/include/plat/dmtimer.h create mode 100644 include/linux/platform_data/dmtimer-omap.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] ARM: OMAP: Clean-up dmtimer reset code
Only OMAP1 devices use the omap_dm_timer_reset() and so require the
omap_dm_timer_wait_for_reset() and __omap_dm_timer_reset() functions.
Therefore combine these into a single function called omap_dm_timer_reset()
and simplify the code.
The omap_dm_timer_reset() function is now the only place that is using the
omap_dm_timer structure member sys_stat. Therefore, remove this member and
just use the register offset definition to simplify and clean-up the code. The
TISTAT register is only present on revision 1 timers and so check for this in
the omap_dm_timer_reset() function.
Please note that for OMAP1 devices, the TIOCP_CFG register does not have the
clock-activity field and so when we reset the timer for an OMAP1 device we
only need to configure the idle-mode field in the TIOCP_CFG register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 50 ++---
arch/arm/plat-omap/include/plat/dmtimer.h | 23 -
2 files changed, 31 insertions(+), 42 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 9deeb30..4c28452 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -99,32 +99,39 @@ static void omap_timer_restore_context(struct omap_dm_timer
*timer)
timer-context.tclr);
}
-static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
+static int omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- int c;
+ u32 l, timeout = 10;
- if (!timer-sys_stat)
- return;
+ if (timer-revision != 1)
+ return -EINVAL;
- c = 0;
- while (!(__raw_readl(timer-sys_stat) 1)) {
- c++;
- if (c 10) {
- printk(KERN_ERR Timer failed to reset\n);
- return;
- }
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+
+ do {
+ l = __omap_dm_timer_read(timer,
+OMAP_TIMER_V1_SYS_STAT_OFFSET, 0);
+ } while (!l timeout--);
+
+ if (!timeout) {
+ dev_err(timer-pdev-dev, Timer failed to reset\n);
+ return -ETIMEDOUT;
}
-}
-static void omap_dm_timer_reset(struct omap_dm_timer *timer)
-{
- omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
- omap_dm_timer_wait_for_reset(timer);
- __omap_dm_timer_reset(timer, 0, 0);
+ /* Configure timer for smart-idle mode */
+ l = __omap_dm_timer_read(timer, OMAP_TIMER_OCP_CFG_OFFSET, 0);
+ l |= 0x2 0x3;
+ __omap_dm_timer_write(timer, OMAP_TIMER_OCP_CFG_OFFSET, l, 0);
+
+ timer-posted = 0;
+
+ return 0;
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
+ int rc;
+
/*
* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
* do not call clk_get() for these devices.
@@ -140,8 +147,13 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
omap_dm_timer_enable(timer);
- if (timer-capability OMAP_TIMER_NEEDS_RESET)
- omap_dm_timer_reset(timer);
+ if (timer-capability OMAP_TIMER_NEEDS_RESET) {
+ rc = omap_dm_timer_reset(timer);
+ if (rc) {
+ omap_dm_timer_disable(timer);
+ return rc;
+ }
+ }
__omap_dm_timer_enable_posted(timer);
omap_dm_timer_disable(timer);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 05a36e1..c5c890d 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -267,7 +267,6 @@ struct omap_dm_timer {
struct clk *fclk;
void __iomem*io_base;
- void __iomem*sys_stat; /* TISTAT timer status */
void __iomem*irq_stat; /* TISR/IRQSTATUS interrupt status */
void __iomem*irq_ena; /* irq enable */
void __iomem*irq_dis; /* irq disable, only on v2 ip */
@@ -317,8 +316,6 @@ static inline void __omap_dm_timer_init_regs(struct
omap_dm_timer *timer)
tidr = __raw_readl(timer-io_base);
if (!(tidr 16)) {
timer-revision = 1;
- timer-sys_stat = timer-io_base +
- OMAP_TIMER_V1_SYS_STAT_OFFSET;
timer-irq_stat = timer-io_base + OMAP_TIMER_V1_STAT_OFFSET;
timer-irq_ena = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
timer-irq_dis = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
@@ -326,7 +323,6 @@ static inline void __omap_dm_timer_init_regs(struct
omap_dm_timer *timer)
timer-func_base = timer-io_base;
} else {
timer-revision = 2;
- timer-sys_stat = NULL;
timer-irq_stat = timer-io_base
[PATCH 4/8] ARM: OMAP2+: Remove unnecessary local variable in timer code
The function omap_dm_timer_init_one() declares two local variables of
type int that are used to store the return value of functions called.
One such local variable is sufficient and so remove one of these local
variables.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e9fcc5f..1a662df 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -246,8 +246,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
- int res = 0;
- int r;
+ int r = 0;
if (of_have_populated_dt()) {
np = omap_get_timer_dt(omap_timer_match, NULL);
@@ -307,10 +306,10 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
src = clk_get(NULL, fck_source);
if (IS_ERR(src)) {
- res = -EINVAL;
+ r = -EINVAL;
} else {
- res = clk_set_parent(timer-fclk, src);
- if (IS_ERR_VALUE(res))
+ r = clk_set_parent(timer-fclk, src);
+ if (IS_ERR_VALUE(r))
pr_warn(%s: %s cannot set source\n,
__func__, oh-name);
clk_put(src);
@@ -331,7 +330,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
timer-rate = clk_get_rate(timer-fclk);
timer-reserved = 1;
- return res;
+ return r;
}
static void __init omap2_gp_clockevent_init(int gptimer_id,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] ARM: OMAP: Define omap_dm_timer_prepare function as static
The omap_dm_timer_prepare function is a local function only used in the
dmtimer.c file. Therefore, make this a static function and remove its
declaration from the dmtimer.h file.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c |2 +-
arch/arm/plat-omap/include/plat/dmtimer.h |2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 4c28452..efe4774 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -128,7 +128,7 @@ static int omap_dm_timer_reset(struct omap_dm_timer *timer)
return 0;
}
-int omap_dm_timer_prepare(struct omap_dm_timer *timer)
+static int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
int rc;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index c5c890d..40383b6 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -286,8 +286,6 @@ struct omap_dm_timer {
struct list_head node;
};
-int omap_dm_timer_prepare(struct omap_dm_timer *timer);
-
static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg,
int posted)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] ARM: OMAP: Don't store timers physical address
The OMAP2+ system timer code stores the physical address of the timer
but never uses it. Remove this and clean-up the code by removing the
local variable size and changing the names of the local variables
mem_rsrc and irq_rsrc to mem and irq, respectively.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 13 +
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 099e406..e9fcc5f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -245,8 +245,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
const char *oh_name;
struct device_node *np;
struct omap_hwmod *oh;
- struct resource irq_rsrc, mem_rsrc;
- size_t size;
+ struct resource irq, mem;
int res = 0;
int r;
@@ -280,20 +279,18 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!of_have_populated_dt()) {
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
- irq_rsrc);
+ irq);
if (r)
return -ENXIO;
- timer-irq = irq_rsrc.start;
+ timer-irq = irq.start;
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_MEM, NULL,
- mem_rsrc);
+ mem);
if (r)
return -ENXIO;
- timer-phys_base = mem_rsrc.start;
- size = mem_rsrc.end - mem_rsrc.start;
/* Static mapping, never released */
- timer-io_base = ioremap(timer-phys_base, size);
+ timer-io_base = ioremap(mem.start, mem.end - mem.start);
}
if (!timer-io_base)
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 40383b6..b60e2b6 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -261,7 +261,6 @@ int omap_dm_timers_active(void);
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR WPSHIFT))
struct omap_dm_timer {
- unsigned long phys_base;
int id;
int irq;
struct clk *fclk;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] ARM: OMAP: Remove unnecessary inclusion of dmtimer.h
Some source files are including dmtimer.h but not actually using any dmtimer definitions or functions. Therefore, remove the inclusion dmtimer.h from these source files. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap1/timer32k.c |1 - arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 - arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 - arch/arm/mach-omap2/pm-debug.c |1 - drivers/staging/tidspbridge/core/ue_deh.c |1 - 5 files changed, 5 deletions(-) diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c index 8936819..41152fa 100644 --- a/arch/arm/mach-omap1/timer32k.c +++ b/arch/arm/mach-omap1/timer32k.c @@ -51,7 +51,6 @@ #include asm/mach/time.h #include plat/counter-32k.h -#include plat/dmtimer.h #include mach/hardware.h diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c index a8b3368..e8efe3d 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c @@ -17,7 +17,6 @@ #include linux/platform_data/spi-omap2-mcspi.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h #include omap_hwmod.h #include l3_2xxx.h diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c index dc768c5..32d17e3 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c @@ -18,7 +18,6 @@ #include linux/platform_data/spi-omap2-mcspi.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h #include omap_hwmod.h #include mmc.h diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 3cf4fdf..e2c291f 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -30,7 +30,6 @@ #include clock.h #include powerdomain.h #include clockdomain.h -#include plat/dmtimer.h #include omap-pm.h #include soc.h diff --git a/drivers/staging/tidspbridge/core/ue_deh.c b/drivers/staging/tidspbridge/core/ue_deh.c index 3d28b23..6aea6f1 100644 --- a/drivers/staging/tidspbridge/core/ue_deh.c +++ b/drivers/staging/tidspbridge/core/ue_deh.c @@ -19,7 +19,6 @@ #include linux/kernel.h #include linux/interrupt.h -#include plat/dmtimer.h #include dspbridge/dbdefs.h #include dspbridge/dspdeh.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] ARM: OMAP: Add platform data header for DMTIMERs
Move definition of dmtimer platform data structure in to its own header
under linux/platform_data.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c|1 +
arch/arm/mach-omap2/timer.c|2 ++
arch/arm/plat-omap/dmtimer.c |2 ++
arch/arm/plat-omap/include/plat/dmtimer.h |8 ---
include/linux/platform_data/dmtimer-omap.h | 31
5 files changed, 36 insertions(+), 8 deletions(-)
create mode 100644 include/linux/platform_data/dmtimer-omap.h
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index cdeb9d3..bde7a35 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -25,6 +25,7 @@
#include linux/err.h
#include linux/slab.h
#include linux/platform_device.h
+#include linux/platform_data/dmtimer-omap.h
#include mach/irqs.h
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 1a662df..4daa8b4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -39,6 +39,8 @@
#include linux/of.h
#include linux/of_address.h
#include linux/of_irq.h
+#include linux/platform_device.h
+#include linux/platform_data/dmtimer-omap.h
#include asm/mach/time.h
#include asm/smp_twd.h
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index efe4774..89585c2 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -43,6 +43,8 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/platform_data/dmtimer-omap.h
#include plat/dmtimer.h
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index b3cd91b..a3fbc48 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -124,14 +124,6 @@ struct omap_dm_timer {
struct list_head node;
};
-struct dmtimer_platform_data {
- /* set_timer_src - Only used for OMAP1 devices */
- int (*set_timer_src)(struct platform_device *pdev, int source);
- u32 timer_errata;
- u32 timer_capability;
- int (*get_context_loss_count)(struct device *);
-};
-
int omap_dm_timer_reserve_systimer(int id);
struct omap_dm_timer *omap_dm_timer_request(void);
struct omap_dm_timer *omap_dm_timer_request_specific(int timer_id);
diff --git a/include/linux/platform_data/dmtimer-omap.h
b/include/linux/platform_data/dmtimer-omap.h
new file mode 100644
index 000..a19b78d
--- /dev/null
+++ b/include/linux/platform_data/dmtimer-omap.h
@@ -0,0 +1,31 @@
+/*
+ * DMTIMER platform data for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Jon Hunter jon-hun...@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/.
+ */
+
+#ifndef __PLATFORM_DATA_DMTIMER_OMAP_H__
+#define __PLATFORM_DATA_DMTIMER_OMAP_H__
+
+struct dmtimer_platform_data {
+ /* set_timer_src - Only used for OMAP1 devices */
+ int (*set_timer_src)(struct platform_device *pdev, int source);
+ u32 timer_capability;
+ u32 timer_errata;
+ int (*get_context_loss_count)(struct device *);
+};
+
+#endif /* __PLATFORM_DATA_DMTIMER_OMAP_H__ */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] ARM: OMAP: Move plat/dmtimer.h to plat-omap/dmtimer.h
Move plat/dmtimer.h to plat-omap/dmtimer.h in order to support a single zImage for ARM devices. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap1/pm.c |2 +- arch/arm/mach-omap1/timer.c|2 +- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/mach-omap2/timer.c|2 +- arch/arm/plat-omap/dmtimer.c |2 +- arch/arm/plat-omap/include/plat-omap/dmtimer.h | 420 arch/arm/plat-omap/include/plat/dmtimer.h | 414 --- drivers/staging/tidspbridge/core/dsp-clock.c |2 +- 10 files changed, 428 insertions(+), 422 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat-omap/dmtimer.h delete mode 100644 arch/arm/plat-omap/include/plat/dmtimer.h diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c index 66d663a..ecc1f76 100644 --- a/arch/arm/mach-omap1/pm.c +++ b/arch/arm/mach-omap1/pm.c @@ -53,7 +53,7 @@ #include mach/tc.h #include mach/mux.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h +#include plat-omap/dmtimer.h #include mach/irqs.h diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c index bde7a35..0089fb7 100644 --- a/arch/arm/mach-omap1/timer.c +++ b/arch/arm/mach-omap1/timer.c @@ -29,7 +29,7 @@ #include mach/irqs.h -#include plat/dmtimer.h +#include plat-omap/dmtimer.h #define OMAP1610_GPTIMER1_BASE 0xfffb1400 #define OMAP1610_GPTIMER2_BASE 0xfffb1c00 diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c index 0db8f45..a4169b6 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c @@ -11,7 +11,7 @@ #include linux/platform_data/gpio-omap.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h +#include plat-omap/dmtimer.h #include linux/platform_data/spi-omap2-mcspi.h #include omap_hwmod.h diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index addc1c2..ff835ed 100644 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -24,7 +24,7 @@ #include l4_3xxx.h #include linux/platform_data/asoc-ti-mcbsp.h #include linux/platform_data/spi-omap2-mcspi.h -#include plat/dmtimer.h +#include plat-omap/dmtimer.h #include plat/iommu.h #include am35xx.h diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 399f4ce..2750efe 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -27,7 +27,7 @@ #include linux/platform_data/spi-omap2-mcspi.h #include linux/platform_data/asoc-ti-mcbsp.h -#include plat/dmtimer.h +#include plat-omap/dmtimer.h #include plat/iommu.h #include omap_hwmod.h diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 4daa8b4..b8ee64a 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -50,7 +50,7 @@ #include omap_hwmod.h #include omap_device.h #include plat/counter-32k.h -#include plat/dmtimer.h +#include plat-omap/dmtimer.h #include omap-pm.h #include soc.h diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 89585c2..a1d45c7 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -46,7 +46,7 @@ #include linux/platform_device.h #include linux/platform_data/dmtimer-omap.h -#include plat/dmtimer.h +#include plat-omap/dmtimer.h static u32 omap_reserved_systimers; static LIST_HEAD(omap_timer_list); diff --git a/arch/arm/plat-omap/include/plat-omap/dmtimer.h b/arch/arm/plat-omap/include/plat-omap/dmtimer.h new file mode 100644 index 000..abe073f --- /dev/null +++ b/arch/arm/plat-omap/include/plat-omap/dmtimer.h @@ -0,0 +1,420 @@ +/* + * arch/arm/plat-omap/include/plat-omap/dmtimer.h + * + * OMAP Dual-Mode Timers + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * Tarun Kanti DebBarma tarun.ka...@ti.com + * Thara Gopinath th...@ti.com + * + * Platform device conversion and hwmod support. + * + * Copyright (C) 2005 Nokia Corporation + * Author: Lauri Leukkunen lauri.leukku...@nokia.com + * PWM and clock framwork support by Timo Teras. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED
[PATCH 5/8] ARM: OMAP: Remove unnecessary omap_dm_timer structure declaration
Remove unnecessary declaration of structure omap_dm_timer from dmtimer.h and
move the actual declaration of structure omap_dm_timer towards top of dmtimer.h
to avoid any compilation errors.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/include/plat/dmtimer.h | 52 ++---
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index b60e2b6..b3cd91b 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -79,8 +79,6 @@ struct omap_timer_capability_dev_attr {
u32 timer_capability;
};
-struct omap_dm_timer;
-
struct timer_regs {
u32 tidr;
u32 tier;
@@ -101,6 +99,31 @@ struct timer_regs {
u32 towr;
};
+struct omap_dm_timer {
+ int id;
+ int irq;
+ struct clk *fclk;
+
+ void __iomem*io_base;
+ void __iomem*irq_stat; /* TISR/IRQSTATUS interrupt status */
+ void __iomem*irq_ena; /* irq enable */
+ void __iomem*irq_dis; /* irq disable, only on v2 ip */
+ void __iomem*pend; /* write pending */
+ void __iomem*func_base; /* function register base */
+
+ unsigned long rate;
+ unsigned reserved:1;
+ unsigned posted:1;
+ struct timer_regs context;
+ int (*get_context_loss_count)(struct device *);
+ int ctx_loss_count;
+ int revision;
+ u32 capability;
+ u32 errata;
+ struct platform_device *pdev;
+ struct list_head node;
+};
+
struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
@@ -260,31 +283,6 @@ int omap_dm_timers_active(void);
#define OMAP_TIMER_TICK_INT_MASK_COUNT_REG \
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR WPSHIFT))
-struct omap_dm_timer {
- int id;
- int irq;
- struct clk *fclk;
-
- void __iomem*io_base;
- void __iomem*irq_stat; /* TISR/IRQSTATUS interrupt status */
- void __iomem*irq_ena; /* irq enable */
- void __iomem*irq_dis; /* irq disable, only on v2 ip */
- void __iomem*pend; /* write pending */
- void __iomem*func_base; /* function register base */
-
- unsigned long rate;
- unsigned reserved:1;
- unsigned posted:1;
- struct timer_regs context;
- int (*get_context_loss_count)(struct device *);
- int ctx_loss_count;
- int revision;
- u32 capability;
- u32 errata;
- struct platform_device *pdev;
- struct list_head node;
-};
-
static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg,
int posted)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP2420: Fix ethernet support
Fix ethernet support for OMAP2420 and remove legacy code for ethernet configuration. Jon Hunter (2): ARM: OMAP2420: Fix ethernet support for OMAP2420 H4 ARM: OMAP: Remove debug-devices.c arch/arm/mach-omap2/board-h4.c | 80 +++--- arch/arm/mach-omap2/debug-devices.h |9 arch/arm/plat-omap/Makefile |1 - arch/arm/plat-omap/debug-devices.c | 93 --- 4 files changed, 19 insertions(+), 164 deletions(-) delete mode 100644 arch/arm/mach-omap2/debug-devices.h delete mode 100644 arch/arm/plat-omap/debug-devices.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP: Remove debug-devices.c
The OMAP2420 H4 board was the only board using the
plat-omap/debug-devices.c code for configuring ethernet support. Now
that OMAP2420 H4 has been migrated to use the generic gpmc code for
configuring ethernet support, the debug-devices.c file is no longer
used and so remove it and its header file.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/debug-devices.h |9
arch/arm/plat-omap/Makefile |1 -
arch/arm/plat-omap/debug-devices.c | 93 ---
3 files changed, 103 deletions(-)
delete mode 100644 arch/arm/mach-omap2/debug-devices.h
delete mode 100644 arch/arm/plat-omap/debug-devices.c
diff --git a/arch/arm/mach-omap2/debug-devices.h
b/arch/arm/mach-omap2/debug-devices.h
deleted file mode 100644
index a4edbd2..000
--- a/arch/arm/mach-omap2/debug-devices.h
+++ /dev/null
@@ -1,9 +0,0 @@
-#ifndef _OMAP_DEBUG_DEVICES_H
-#define _OMAP_DEBUG_DEVICES_H
-
-#include linux/types.h
-
-/* for TI reference platforms sharing the same debug card */
-extern int debug_card_init(u32 addr, unsigned gpio);
-
-#endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index dacaee0..1eca088 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -12,7 +12,6 @@ obj- :=
obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o
obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
-obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o
obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-y)
diff --git a/arch/arm/plat-omap/debug-devices.c
b/arch/arm/plat-omap/debug-devices.c
deleted file mode 100644
index 5a4678e..000
--- a/arch/arm/plat-omap/debug-devices.c
+++ /dev/null
@@ -1,93 +0,0 @@
-/*
- * linux/arch/arm/plat-omap/debug-devices.c
- *
- * Copyright (C) 2005 Nokia Corporation
- * Modified from mach-omap2/board-h4.c
- *
- * 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.
- */
-#include linux/gpio.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/io.h
-#include linux/smc91x.h
-
-#include mach/hardware.h
-#include ../mach-omap2/debug-devices.h
-
-/* Many OMAP development platforms reuse the same debug board; these
- * platforms include H2, H3, H4, and Perseus2.
- */
-
-static struct smc91x_platdata smc91x_info = {
- .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
- .leda = RPC_LED_100_10,
- .ledb = RPC_LED_TX_RX,
-};
-
-static struct resource smc91x_resources[] = {
- [0] = {
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
- },
-};
-
-static struct platform_device smc91x_device = {
- .name = smc91x,
- .id = -1,
- .dev= {
- .platform_data = smc91x_info,
- },
- .num_resources = ARRAY_SIZE(smc91x_resources),
- .resource = smc91x_resources,
-};
-
-static struct resource led_resources[] = {
- [0] = {
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device led_device = {
- .name = omap_dbg_led,
- .id = -1,
- .num_resources = ARRAY_SIZE(led_resources),
- .resource = led_resources,
-};
-
-static struct platform_device *debug_devices[] __initdata = {
- smc91x_device,
- led_device,
- /* ps2 kbd + mouse ports */
- /* 4 extra uarts */
- /* 6 input dip switches */
- /* 8 output pins */
-};
-
-int __init debug_card_init(u32 addr, unsigned gpio)
-{
- int status;
-
- smc91x_resources[0].start = addr + 0x300;
- smc91x_resources[0].end = addr + 0x30f;
-
- smc91x_resources[1].start = gpio_to_irq(gpio);
- smc91x_resources[1].end = gpio_to_irq(gpio);
-
- status = gpio_request(gpio, SMC91x irq);
- if (status 0) {
- printk(KERN_ERR GPIO%d unavailable for smc91x IRQ\n, gpio);
- return status;
- }
- gpio_direction_input(gpio);
-
- led_resources[0].start = addr;
- led_resources[0].end = addr + SZ_4K - 1;
-
- return platform_add_devices(debug_devices, ARRAY_SIZE(debug_devices));
-}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2420: Fix ethernet support for OMAP2420 H4
Ethernet is not currently working on the OMAP2420 H4 board. In commit
f604931 (ARM: OMAP: abstract debug card setup (smc, leds)) the function
h4_init_smc91x() that initialised the ethernet controller was renamed to
h4_init_debug() but was never called when initialising the board.
Adding a call to h4_init_debug() fixes ethernet support, however,
instead of using the legacy H4 code migrate the H4 to use the
gpmc_smc91x_init() function instead and remove the legacy H4 code.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/board-h4.c | 80 ++--
1 file changed, 19 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 8d04bf8..2adba9d 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -34,19 +34,16 @@
#include plat/menelaus.h
#include plat/dma.h
#include plat/gpmc.h
-#include debug-devices.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
#include common.h
+#include gpmc-smc91x.h
#include mux.h
#include control.h
#define H4_FLASH_CS0
-#define H4_SMC91X_CS 1
-
-#define H4_ETHR_GPIO_IRQ 92
#if defined(CONFIG_KEYBOARD_MATRIX) || defined(CONFIG_KEYBOARD_MATRIX_MODULE)
static const uint32_t board_matrix_keys[] = {
@@ -250,71 +247,31 @@ static u32 is_gpmc_muxed(void)
return 0;
}
-static inline void __init h4_init_debug(void)
-{
- int eth_cs;
- unsigned long cs_mem_base;
- unsigned int muxed, rate;
- struct clk *gpmc_fck;
-
- eth_cs = H4_SMC91X_CS;
+#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
- gpmc_fck = clk_get(NULL, gpmc_fck); /* Always on ENABLE_ON_INIT */
- if (IS_ERR(gpmc_fck)) {
- WARN_ON(1);
- return;
- }
-
- clk_prepare_enable(gpmc_fck);
- rate = clk_get_rate(gpmc_fck);
- clk_disable_unprepare(gpmc_fck);
- clk_put(gpmc_fck);
+static struct omap_smc91x_platform_data board_smc91x_data = {
+ .cs = 1,
+ .gpio_irq = 92,
+ .flags = GPMC_TIMINGS_SMC91C96 | IORESOURCE_IRQ_LOWLEVEL,
+};
+static void __init board_smc91x_init(void)
+{
if (is_gpmc_muxed())
- muxed = 0x200;
- else
- muxed = 0;
-
- /* Make sure CS1 timings are correct */
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG1,
- 0x00011000 | muxed);
-
- if (rate = 16000) {
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG2, 0x001f1f01);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG3, 0x00080803);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG4, 0x1c0b1c0a);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG5, 0x041f1F1F);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG6, 0x04C4);
- } else if (rate = 13000) {
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG2, 0x001f1f00);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG3, 0x00080802);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG4, 0x1C091C09);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG5, 0x041f1F1F);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG6, 0x04C4);
- } else {/* rate = 1 */
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG2, 0x001f1f00);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG3, 0x00080802);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG4, 0x1C091C09);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG5, 0x031A1F1F);
- gpmc_cs_write_reg(eth_cs, GPMC_CS_CONFIG6, 0x03C2);
- }
-
- if (gpmc_cs_request(eth_cs, SZ_16M, cs_mem_base) 0) {
- printk(KERN_ERR Failed to request GPMC mem for smc91x\n);
- goto out;
- }
+ board_smc91x_data.flags |= GPMC_MUX_ADD_DATA;
- udelay(100);
+ omap_mux_init_gpio(board_smc91x_data.gpio_irq, OMAP_PIN_INPUT);
+ gpmc_smc91x_init(board_smc91x_data);
+}
- omap_mux_init_gpio(92, 0);
- if (debug_card_init(cs_mem_base, H4_ETHR_GPIO_IRQ) 0)
- gpmc_cs_free(eth_cs);
+#else
-out:
- clk_disable_unprepare(gpmc_fck);
- clk_put(gpmc_fck);
+static inline void board_smc91x_init(void)
+{
}
+#endif
+
static void __init h4_init_flash(void)
{
unsigned long base;
@@ -371,6 +328,7 @@ static void __init omap_h4_init(void)
omap_serial_init();
omap_sdrc_init(NULL, NULL);
h4_init_flash();
+ board_smc91x_init();
omap_display_init(h4_dss_data);
}
--
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 8/8] ARM: OMAP: Move plat/dmtimer.h to plat-omap/dmtimer.h
On 11/13/2012 04:26 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121113 10:15]: Move plat/dmtimer.h to plat-omap/dmtimer.h in order to support a single zImage for ARM devices. Let's skip this one for now as it turns out this solution won't work either for multiplatform without adding nasty hacks to arch/arm/Makefile to include arch/arm/plat-omap. Sorry I don't have any real solution in mind other than making the remaining dmtimer.h users to use Linux generic timer functions, or pass the dmtimer functions in platform_data for now. Ok, no problem. Are you happy with the others? One thing that we could do, is not include the dmtimer driver in the multi-platform build for now. I believe that only the dsp/iva/gfx is using this driver currently. I believe that there are some issues with building the kernel without the dmtimer and so I can look into fixing that. Is there a way to not include dmtimer with multi-platform but still enable in omap2plus_defconfig? Or are we planning to kill omap2plus_defconfig too? 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 7/8] ARM: OMAP: Remove unnecessary inclusion of dmtimer.h
On 11/13/2012 12:13 PM, Jon Hunter wrote: Some source files are including dmtimer.h but not actually using any dmtimer definitions or functions. Therefore, remove the inclusion dmtimer.h from these source files. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap1/timer32k.c |1 - arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 - arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 - arch/arm/mach-omap2/pm-debug.c |1 - drivers/staging/tidspbridge/core/ue_deh.c |1 - 5 files changed, 5 deletions(-) diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c index 8936819..41152fa 100644 --- a/arch/arm/mach-omap1/timer32k.c +++ b/arch/arm/mach-omap1/timer32k.c @@ -51,7 +51,6 @@ #include asm/mach/time.h #include plat/counter-32k.h -#include plat/dmtimer.h #include mach/hardware.h diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c index a8b3368..e8efe3d 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c @@ -17,7 +17,6 @@ #include linux/platform_data/spi-omap2-mcspi.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h #include omap_hwmod.h #include l3_2xxx.h diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c index dc768c5..32d17e3 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c @@ -18,7 +18,6 @@ #include linux/platform_data/spi-omap2-mcspi.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h #include omap_hwmod.h #include mmc.h diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 3cf4fdf..e2c291f 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -30,7 +30,6 @@ #include clock.h #include powerdomain.h #include clockdomain.h -#include plat/dmtimer.h #include omap-pm.h #include soc.h diff --git a/drivers/staging/tidspbridge/core/ue_deh.c b/drivers/staging/tidspbridge/core/ue_deh.c index 3d28b23..6aea6f1 100644 --- a/drivers/staging/tidspbridge/core/ue_deh.c +++ b/drivers/staging/tidspbridge/core/ue_deh.c @@ -19,7 +19,6 @@ #include linux/kernel.h #include linux/interrupt.h -#include plat/dmtimer.h #include dspbridge/dbdefs.h #include dspbridge/dspdeh.h Hi Omar, I should have had you in copy on this one. Are you ok with the removal of the above dmtimer.h include? It does not appear that this file needs to include dmtimer.h. Is it ok for this to go through Tony's tree? If so, care to ACK? 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: Fix errata 751472 handling on Cortex-A9 r1p*
On 11/14/2012 12:53 PM, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. I checked the CA9MP errata document and this erratum impacts all r0/r1/r2 CPUs. I am wondering if the problem is because the workaround requires you to set a bit in the Diagnostic Control register and the read-modify-write sequence provided in the workaround is for secure mode. Not sure if there is a non-secure workaround available :-( 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] Remove inline from clock framework function definitions to build the kernel with GCC 4.7
On 11/15/2012 11:07 AM, Igor Mazanov wrote: Remove inline from clock framework function definitions to build the kernel with GCC 4.7 Adding Mike to the party ... May be good to add some details about the exact problem seen. I am seeing the same problem today with GCC 4.7 and Tony's master branch. For a bit of background it seems that for 4.7 not having the body of the inlined function available in the header is causing this error. Another example here [1]. The actual compiler error seen for OMAP is ... In file included from arch/arm/mach-omap2/clockdomain.c:25:0: arch/arm/mach-omap2/clockdomain.c: In function ‘clkdm_clk_disable’: include/linux/clk-provider.h:338:12: error: inlining failed in call to always_inline ‘__clk_get_enable_count’: function body not available arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Signed-off-by: Igor Mazanov i.maza...@gmail.com --- include/linux/clk-provider.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index c127315..f9f5e9e 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk); struct clk_hw *__clk_get_hw(struct clk *clk); u8 __clk_get_num_parents(struct clk *clk); struct clk *__clk_get_parent(struct clk *clk); -inline int __clk_get_enable_count(struct clk *clk); -inline int __clk_get_prepare_count(struct clk *clk); +int __clk_get_enable_count(struct clk *clk); +int __clk_get_prepare_count(struct clk *clk); unsigned long __clk_get_rate(struct clk *clk); unsigned long __clk_get_flags(struct clk *clk); int __clk_is_enabled(struct clk *clk); Do we also need to remove the inline from the functions declared in drivers/clk/clk.c too? Cheers Jon [1] https://bugs.launchpad.net/linaro-android/+bug/983496 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
