* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-25 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024185818.GB772@arwen.pp.htv.fi>
On Wed, Oct 24, 2012 at 09:58:19PM +0300, Felipe Balbi wrote:
> need a way to tell drivers/base "hey, don't touch pinctrl at all because
> I know what I'm doing" and that has to happen before probe() too,
> otherwise it's already too late and, according to what you suggest,
> drivers/base will already have touched pinctrl. The only way I see would
> be to add an extra "dont_touch_my_pins" field to every driver structure
> in the kernel. Clearly what you say is nonsense.
I suspect that's not actually a big deal and that if we went down this
route we'd have the driver take over control from the core code during
probe() with the core still setting up the default state.
Personally I do think we want to be factoring bolierplate out of
drivers, if they're not doing anything constructive with pinctrl they
should be able to avoid having code for it. There definitely are issues
to work through but it seems like we ought to be able to do something.
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer (fwd)
From: Paul Walmsley @ 2012-10-25 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023080533.GA16482@spo001.leaseweb.com>
Hi Wim,
On Tue, 23 Oct 2012, Wim Van Sebroeck wrote:
> > When you have the opportunity, could you take a look at this patch, and
> > the subsequent patch 6/7, and ack them if you're okay with them?
>
> Signed them off, Acked-by would probably have been better :-).
Great! Will add your Acked-by:s.
> > We'd like to merge thse as part of a larger cleanup series through the
> > arm-soc tree. They like cleanup patches to arrive at the beginning of the
> > -rc series, which means that we need to have the pull request sent pretty
> > soon.
>
> Please go ahead. The sooner those ifdefs are gone the better.
Thanks Wim,
- Paul
^ permalink raw reply
* [PATCH V2] ARM: dt: tegra: ventana: define pinmux for ddc
From: Stephen Warren @ 2012-10-25 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351147951-19706-1-git-send-email-markz@nvidia.com>
On 10/25/2012 12:52 AM, Mark Zhang wrote:
> Tegra 2's I2C2 controller can be routed to either the PTA
> or DDC pin group on Ventana. So:
> - Remove the HDMI function definition of pta pingroup
> - Define child i2c adapters(ddc & pta) for I2C2 controller
Thanks, this looks good now.
I've applied it to Tegra's for-3.8/dt branch for now, although I may
have to shuffle things around (or just rename that branch) depending on
exactly what patches we end up with to enable tegradrm.
^ permalink raw reply
* [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
From: David Brown @ 2012-10-25 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351099475-29349-1-git-send-email-sboyd@codeaurora.org>
On Wed, Oct 24, 2012 at 10:24:35AM -0700, Stephen Boyd wrote:
> The TWD and SCU configs are selected by default as long as
> MSM_SCORPIONMP is false and/or MCT is false. Implementing the
> logic this way certainly saves lines in the Kconfig but it
> precludes those machines which select MSM_SCORPIONMP or MCT from
> participating in the single zImage effort because when those
> machines are combined with other SMP capable machines the TWD and
> SCU are no longer selected by default.
>
> Push the select out to the machine entries so that we can compile
> these machines together and still select the appropriate configs.
> arch/arm/mach-msm/Kconfig | 7 ++-----
Acked-by: David Brown <davidb@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 6/7] watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
From: Paul Walmsley @ 2012-10-25 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210252015490.21193@utopia.booyaka.com>
On Thu, 25 Oct 2012, Paul Walmsley wrote:
> On Thu, 25 Oct 2012, Jon Hunter wrote:
>
> > In the case of booting with device-tree, pdata could be null and so
> > should we check for this too? In other words ...
> >
> > + if (!pdata || !pdata->read_reset_sources)
> > + return put_user(0, (int __user *)arg);
>
> Thanks, good catch, will integrate that fix.
Here's the updated patch.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Sun, 7 Oct 2012 20:13:26 -0600
Subject: [PATCH] watchdog: OMAP: use standard GETBOOTSTATUS interface; use
platform_data fn ptr
Previously the OMAP watchdog driver used a non-standard way to report
the chip reset source via the GETBOOTSTATUS ioctl. This patch
converts the driver to use the standard WDIOF_* flags for this
purpose.
This patch may break existing userspace code that uses the existing
non-standard data format returned by the OMAP watchdog driver's
GETBOOTSTATUS ioctl. To fetch detailed reset source information,
userspace code will need to retrieve it directly from the CGRM or PRM
drivers when those are completed.
Previously, to fetch the reset source, the driver either read a
register outside the watchdog IP block (OMAP1), or called a function
exported directly from arch/arm/mach-omap2. Both approaches are
broken. This patch also converts the driver to use a platform_data
function pointer. This approach is temporary, and is due to the lack
of drivers for the OMAP16xx+ Clock Generation and Reset Management IP
block and the OMAP2+ Power and Reset Management IP block. Once
drivers are available for those IP blocks, the watchdog driver can be
converted to call exported drivers from those functions directly.
At that point, the platform_data function pointer can be removed.
In the short term, this patch is needed to allow the PRM code to be
removed from arch/arm/mach-omap2 (it is being moved to a driver).
This version integrates a fix from Jon Hunter <jon-hunter@ti.com>
that avoids a NULL pointer dereference in a DT-only boot.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Jon Hunter <jon-hunter@ti.com>
---
drivers/watchdog/omap_wdt.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index f5db18db..477a1d4 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -46,8 +46,8 @@
#include <linux/slab.h>
#include <linux/pm_runtime.h>
#include <mach/hardware.h>
-#include <plat/cpu.h>
-#include <plat/prcm.h>
+
+#include <linux/platform_data/omap-wd-timer.h>
#include "omap_wdt.h"
@@ -202,8 +202,10 @@ static ssize_t omap_wdt_write(struct file *file, const char __user *data,
static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
+ struct omap_wd_timer_platform_data *pdata;
struct omap_wdt_dev *wdev;
- int new_margin;
+ u32 rs;
+ int new_margin, bs;
static const struct watchdog_info ident = {
.identity = "OMAP Watchdog",
.options = WDIOF_SETTIMEOUT,
@@ -211,6 +213,7 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
};
wdev = file->private_data;
+ pdata = wdev->dev->platform_data;
switch (cmd) {
case WDIOC_GETSUPPORT:
@@ -219,17 +222,12 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
case WDIOC_GETSTATUS:
return put_user(0, (int __user *)arg);
case WDIOC_GETBOOTSTATUS:
-#ifdef CONFIG_ARCH_OMAP1
- if (cpu_is_omap16xx())
- return put_user(__raw_readw(ARM_SYSST),
- (int __user *)arg);
-#endif
-#ifdef CONFIG_ARCH_OMAP2PLUS
- if (cpu_is_omap24xx())
- return put_user(omap_prcm_get_reset_sources(),
- (int __user *)arg);
-#endif
- return put_user(0, (int __user *)arg);
+ if (!pdata || !pdata->read_reset_sources)
+ return put_user(0, (int __user *)arg);
+ rs = pdata->read_reset_sources();
+ bs = (rs & (1 << OMAP_MPU_WD_RST_SRC_ID_SHIFT)) ?
+ WDIOF_CARDRESET : 0;
+ return put_user(bs, (int __user *)arg);
case WDIOC_KEEPALIVE:
spin_lock(&wdt_lock);
omap_wdt_ping(wdev);
--
1.7.10.4
^ permalink raw reply related
* [PATCH V2] ARM: PMU: fix runtime PM enable
From: Jon Hunter @ 2012-10-25 20:23 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
use runtime PM which was prototyped and validated on the OMAP devices. In this
commit, there is no call pm_runtime_enable() and for OMAP devices
pm_runtime_enable() is currently being called from the OMAP PMU code when the
PMU device is created. However, there are two problems with this:
1. For any other ARM device wishing to use runtime PM for PMU they will need
to call pm_runtime_enable() for runtime PM to work.
2. When booting with device-tree and using device-tree to create the PMU
device, pm_runtime_enable() needs to be called from within the ARM PERF
driver as we are no longer calling any device specific code to create the
device. Hence, PMU does not work on OMAP devices that use the runtime PM
callbacks when using device-tree to create the PMU device.
Therefore, call pm_runtime_enable() directly from the ARM PMU driver when
registering the device. For platforms that do not use runtime PM,
pm_runtime_enable() does nothing and for platforms that do use runtime PM but
may not require it specifically for PMU, this will just add a little overhead
when initialising and uninitialising the PMU device.
Tested with PERF on OMAP2420, OMAP3430 and OMAP4460.
V2 changes:
- Call pm_runtime_enable() unconditionally on registering the PMU device.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/kernel/perf_event.c | 1 +
arch/arm/mach-omap2/pmu.c | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 1f7166f..5ea182e 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -510,6 +510,7 @@ static void __init armpmu_init(struct arm_pmu *armpmu)
int armpmu_register(struct arm_pmu *armpmu, int type)
{
armpmu_init(armpmu);
+ pm_runtime_enable(&armpmu->plat_device->dev);
pr_info("enabled with %s PMU driver, %d counters available\n",
armpmu->name, armpmu->num_events);
return perf_pmu_register(&armpmu->pmu, armpmu->name, type);
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 2a79176..031e2fb 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -57,8 +57,6 @@ static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
if (IS_ERR(omap_pmu_dev))
return PTR_ERR(omap_pmu_dev);
- pm_runtime_enable(&omap_pmu_dev->dev);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Laurent Pinchart @ 2012-10-25 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025165643.GP11928@atomide.com>
Hi Tony,
On Thursday 25 October 2012 09:56:44 Tony Lindgren wrote:
> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [121025 01:39]:
> > I still think you should split this in two files, omap-iommu.h and omap-
> > iovmm.h. The later would just be arch/arm/plat-omap/include/plat/iovmm.h
> > moved to include/linux.h.
>
> Can you please explain a bit more why you're thinking a separate
> omap-iovmm.h is needed in addtion to omap-iommu.h?
The IOVMM API is layered top of the IOMMU API. It's really a separate API, so
two header files make sense. This patch creates a hybrid omap-iommu.h header
with mixed definitions, it just doesn't feel right :-) I won't insist for a
split though, if you think it's better to have a single header we can keep it
that way.
> My reasoning for not adding it is that neither intel nor amd needs
> more than intel-iommu.h and amd-iommu.h. And hopefully the iommu
> framework will eventually provide the API needed. And I'd rather
> not be the person introducing this second new file into
> include/linux :)
>
> Joerg and Ohad, do you have any opinions on this?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Michael Walle @ 2012-10-25 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025094343.58015440@skate>
Am Donnerstag 25 Oktober 2012, 09:43:43 schrieb Thomas Petazzoni:
> Dear Michael Walle,
>
> On Thu, 25 Oct 2012 09:39:13 +0200, Michael Walle wrote:
> > LSXL_GPIO_USB_POWER and LSXL_GPIO_HDD_POWER switches the power on the USB
> > and SATA connector. So they are not needed to be set before the driver
> > probes, at least in my case here.
>
> Ok.
>
> > But i can imagine boards where you have to enable some kind of
> > buffer/muxer/etc which are controlled by GPIO pins. And I don't think
> > that should be part of the actual driver, because that would be highly
> > board dependant.
>
> You'd have to provide a more specific example so I can imagine how it
> will be solved. But for example, if you have a GPIO-controlled muxer
> for an I2C bus, then the I2C devices behind the muxer are described as
> sub-devices of the muxer, so the probing order is correct.
Assume an ethernet phy which needs a valid reference clock before it can be
probed for example. Of course, this is pure theoretical. But should we impose
restrictions on when we can do the GPIO settings? Esp. since it worked before
(i guess).
> Of course, I'm not pretending I have ready-to-use solutions for all
> situations, but I think we can solve this problem on a case-by-case
> basis.
> Regardless of those GPIOs, did you solve the hang that happened even
> when you removed the gpio_set_value() calls? Or is it still a problem
> currently?
Still a problem. Haven't really looket into i atm. Hopefully i find some time
this weekend.
--
michael
^ permalink raw reply
* [PATCH v4 5/5] zynq: move static peripheral mappings
From: Nick Bowler @ 2012-10-25 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024200451.GF6713@beefymiracle.amer.corp.natinst.com>
Hi Josh,
On 2012-10-24 15:04 -0500, Josh Cartwright wrote:
> Shifting them up into the vmalloc region prevents the following warning,
> when booting a zynq qemu target with more than 512mb of RAM:
[...]
> -/* For now, all mappings are flat (physical = virtual)
> +/* Static peripheral mappings are mapped at the top of the
> + * vmalloc region
> */
> -#define UART0_PHYS 0xE0000000
> -#define UART0_VIRT UART0_PHYS
> +#define UART0_PHYS 0xE0000000
> +#define UART0_SIZE SZ_4K
> +#define UART0_VIRT (VMALLOC_END - UART0_SIZE)
Did you test this on any real hardware? I can't get the ZC702 to work
with the UART mapped at this address (this ends up being mapped at
0xFEFFF000), although I can't for the life of me figure out why the
virtual address even matters. Note that for the ZC702, the physical
address of the "main" UART is 0xE0001000.
All I end up seeing is "Uncompressing Linux... done, booting the
kernel." with no further messages. With the UART mapped at
0xF0001000, all printouts make it to the console. I tried a couple
different virtual addresses and I'm surprised at the results, since
the behaviour seems to vary wildly. I saw three behaviours depending
only on the virtual address of the static mapping; all results are 100%
reproducible:
"Works": all printouts make it to the console
"Fails": no printouts make it to the console after decompression
"Truncated": the first few lines of output do not make it to the
console, but after that it "Works". The first line
successfully printed is always
"Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096"
And here are the addresses I tested:
Address Result
-----------------------
0xf0000000 Truncated
0xf0001000 Works
0xf0007000 Truncated
0xf0008000 Fails
0xf0009000 Fails
0xf000e000 Truncated
0xf000f000 Fails
0xf8000000 Truncated
0xf8001000 Works
0xfef00000 Truncated
0xfef01000 Works
0xfef08000 Fails
0xfef0f000 Fails
0xfeff0000 Fails
0xfeff1000 Fails
0xfeffe000 Fails
0xfefff000 Fails
Judging by the list, the console seems to only work properly if the
defined virtual address is Fxxx1000 and xxx is not too big...
Confused,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* [PATCH 6/7] watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
From: Paul Walmsley @ 2012-10-25 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50899DB9.8050308@ti.com>
On Thu, 25 Oct 2012, Jon Hunter wrote:
> > + if (!pdata->read_reset_sources)
> > + return put_user(0, (int __user *)arg);
>
> In the case of booting with device-tree, pdata could be null and so
> should we check for this too? In other words ...
>
> + if (!pdata || !pdata->read_reset_sources)
> + return put_user(0, (int __user *)arg);
Thanks, good catch, will integrate that fix.
- Paul
^ permalink raw reply
* [PATCH 6/7] watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
From: Jon Hunter @ 2012-10-25 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016013233.21844.1279.stgit@dusk.lan>
Hi Paul,
On 10/15/2012 08:32 PM, Paul Walmsley wrote:
> Previously the OMAP watchdog driver used a non-standard way to report
> the chip reset source via the GETBOOTSTATUS ioctl. This patch
> converts the driver to use the standard WDIOF_* flags for this
> purpose.
>
> This patch may break existing userspace code that uses the existing
> non-standard data format returned by the OMAP watchdog driver's
> GETBOOTSTATUS ioctl. To fetch detailed reset source information,
> userspace code will need to retrieve it directly from the CGRM or PRM
> drivers when those are completed.
>
> Previously, to fetch the reset source, the driver either read a
> register outside the watchdog IP block (OMAP1), or called a function
> exported directly from arch/arm/mach-omap2. Both approaches are
> broken. This patch also converts the driver to use a platform_data
> function pointer. This approach is temporary, and is due to the lack
> of drivers for the OMAP16xx+ Clock Generation and Reset Management IP
> block and the OMAP2+ Power and Reset Management IP block. Once
> drivers are available for those IP blocks, the watchdog driver can be
> converted to call exported drivers from those functions directly.
> At that point, the platform_data function pointer can be removed.
>
> In the short term, this patch is needed to allow the PRM code to be
> removed from arch/arm/mach-omap2 (it is being moved to a driver).
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> ---
> drivers/watchdog/omap_wdt.c | 26 ++++++++++++--------------
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index f5db18db..5d33bc0 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -46,8 +46,8 @@
> #include <linux/slab.h>
> #include <linux/pm_runtime.h>
> #include <mach/hardware.h>
> -#include <plat/cpu.h>
> -#include <plat/prcm.h>
> +
> +#include <linux/platform_data/omap-wd-timer.h>
>
> #include "omap_wdt.h"
>
> @@ -202,8 +202,10 @@ static ssize_t omap_wdt_write(struct file *file, const char __user *data,
> static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> + struct omap_wd_timer_platform_data *pdata;
> struct omap_wdt_dev *wdev;
> - int new_margin;
> + u32 rs;
> + int new_margin, bs;
> static const struct watchdog_info ident = {
> .identity = "OMAP Watchdog",
> .options = WDIOF_SETTIMEOUT,
> @@ -211,6 +213,7 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
> };
>
> wdev = file->private_data;
> + pdata = wdev->dev->platform_data;
>
> switch (cmd) {
> case WDIOC_GETSUPPORT:
> @@ -219,17 +222,12 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
> case WDIOC_GETSTATUS:
> return put_user(0, (int __user *)arg);
> case WDIOC_GETBOOTSTATUS:
> -#ifdef CONFIG_ARCH_OMAP1
> - if (cpu_is_omap16xx())
> - return put_user(__raw_readw(ARM_SYSST),
> - (int __user *)arg);
> -#endif
> -#ifdef CONFIG_ARCH_OMAP2PLUS
> - if (cpu_is_omap24xx())
> - return put_user(omap_prcm_get_reset_sources(),
> - (int __user *)arg);
> -#endif
> - return put_user(0, (int __user *)arg);
> + if (!pdata->read_reset_sources)
> + return put_user(0, (int __user *)arg);
In the case of booting with device-tree, pdata could be null and so
should we check for this too? In other words ...
+ if (!pdata || !pdata->read_reset_sources)
+ return put_user(0, (int __user *)arg);
Cheers
Jon
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Paul Walmsley @ 2012-10-25 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025200812.GC11623@blackmetal.musicnaut.iki.fi>
On Thu, 25 Oct 2012, Aaro Koskinen wrote:
> On Thu, Oct 25, 2012 at 07:57:31PM +0000, Paul Walmsley wrote:
> > [ As an aside, neither the OMAP watchdog driver, nor the TWL watchdog
> > driver have been updated to use the new watchdog core code. So they both
> > can't be loaded at the same time until one or both are fixed. ]
>
> FYI, this is being done currently:
>
> - OMAP wdt: https://lkml.org/lkml/2012/10/10/402
> - TWL wdt: http://marc.info/?l=linux-omap&m=134734329319385&w=2
Thanks, that's good news.
- Paul
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Aaro Koskinen @ 2012-10-25 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210251944540.21193@utopia.booyaka.com>
Hi,
On Thu, Oct 25, 2012 at 07:57:31PM +0000, Paul Walmsley wrote:
> [ As an aside, neither the OMAP watchdog driver, nor the TWL watchdog
> driver have been updated to use the new watchdog core code. So they both
> can't be loaded at the same time until one or both are fixed. ]
FYI, this is being done currently:
- OMAP wdt: https://lkml.org/lkml/2012/10/10/402
- TWL wdt: http://marc.info/?l=linux-omap&m=134734329319385&w=2
A.
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Paul Walmsley @ 2012-10-25 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025193413.GA11928@atomide.com>
On Thu, 25 Oct 2012, Tony Lindgren wrote:
> I have not looked how the watchdog subsystem handles multiple
> watchdogs, but..
In the new watchdog core code, each watchdog driver gets a separate
/dev/watchdog* character device. The ioctls are called on those device
nodes.
[ As an aside, neither the OMAP watchdog driver, nor the TWL watchdog
driver have been updated to use the new watchdog core code. So they both
can't be loaded at the same time until one or both are fixed. ]
> Can't we have the omap watchdog and twl watchdog return -ENOTSUPP for
> WDIOC_GETBOOTSTATUS and have the watchdog core fail over to the third
> wathcdog omap_prcm_wdt_ioctl() that only implements WDIOC_GETBOOTSTATUS?
> Or something like that.
Sounds like a question better asked of Alan Cox and Wim, who wrote the
watchdog core code.
Two other observations:
- It's possible that two different watchdogs could report different boot
reasons. The TWL might store its own watchdog boot reason which could be
different from what's reported via the OMAP PRM. For example, the TWL can
record a thermal shutdown reset event, STS_BOOT.TS, which wouldn't be
reflected in the PRM reset source data, which would just see some kind of
external reset or power-off event.
- The PRM doesn't contain a hardware watchdog, so not sure it makes sense
to create a watchdog driver for it.
- Paul
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Tony Lindgren @ 2012-10-25 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025193413.GA11928@atomide.com>
* Tony Lindgren <tony@atomide.com> [121025 12:35]:
> * Paul Walmsley <paul@pwsan.com> [121025 12:32]:
> > On Thu, 25 Oct 2012, Tony Lindgren wrote:
> >
> > > I wonder if we can now with multiple watchdogs supported to
> > > have also PRM/CM implement omap_prcm_wdt_ioctl() that just
> > > handles WDIOC_GETBOOTSTATUS and then just remove that handling
> > > from the other omap watchdog drivers?
> >
> > The watchdog ioctl code needs access to internal watchdog state and
> > functions, for example WDIOC_KEEPALIVE and WDIOC_SETTIMEOUT. How would
> > the approach you're thinking of implement those operations?
>
> I have not looked how the watchdog subsystem handles multiple
> watchdogs, but.. Can't we have the omap watchdog and twl watchdog
> return -ENOTSUPP for WDIOC_GETBOOTSTATUS and have the watchdog
> core fail over to the third wathcdog omap_prcm_wdt_ioctl() that
> only implements WDIOC_GETBOOTSTATUS? Or something like that.
After poking around a bit, probably the way to do this would
be to have watchdog core bootstatus in addition to the
bootstatus in struct watchdog_device?
Then the omap_prcm watchdog could just initialize the
watchdog core bootstatus, and the other omap watchdog drivers
would just return the watchdog core bootstatus.
Not that it's related to this patchset, just trying to figure
out how it could be done in a generic way :)
Regards,
Tony
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Tony Lindgren @ 2012-10-25 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210251929500.21193@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121025 12:32]:
> On Thu, 25 Oct 2012, Tony Lindgren wrote:
>
> > I wonder if we can now with multiple watchdogs supported to
> > have also PRM/CM implement omap_prcm_wdt_ioctl() that just
> > handles WDIOC_GETBOOTSTATUS and then just remove that handling
> > from the other omap watchdog drivers?
>
> The watchdog ioctl code needs access to internal watchdog state and
> functions, for example WDIOC_KEEPALIVE and WDIOC_SETTIMEOUT. How would
> the approach you're thinking of implement those operations?
I have not looked how the watchdog subsystem handles multiple
watchdogs, but.. Can't we have the omap watchdog and twl watchdog
return -ENOTSUPP for WDIOC_GETBOOTSTATUS and have the watchdog
core fail over to the third wathcdog omap_prcm_wdt_ioctl() that
only implements WDIOC_GETBOOTSTATUS? Or something like that.
Regards,
Tony
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Paul Walmsley @ 2012-10-25 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025191936.GZ11928@atomide.com>
On Thu, 25 Oct 2012, Tony Lindgren wrote:
> I wonder if we can now with multiple watchdogs supported to
> have also PRM/CM implement omap_prcm_wdt_ioctl() that just
> handles WDIOC_GETBOOTSTATUS and then just remove that handling
> from the other omap watchdog drivers?
The watchdog ioctl code needs access to internal watchdog state and
functions, for example WDIOC_KEEPALIVE and WDIOC_SETTIMEOUT. How would
the approach you're thinking of implement those operations?
- Paul
^ permalink raw reply
* [PATCH V3 2/2] ARM: OMAP2+: Add device-tree support for 32kHz counter
From: Jon Hunter @ 2012-10-25 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351193055-12488-1-git-send-email-jon-hunter@ti.com>
For OMAP devices, the 32kHz counter is the default clock-source for the kernel.
However, this is not the only possible clock-source the kernel can use for OMAP
devices.
When booting with device-tree, if the 32kHz counter is the desired clock-source
for the kernel, then parse the device-tree blob to ensure that the counter is
present and if so map memory for the counter using the device-tree of_iomap()
function so we are no longer reliant on the OMAP HWMOD framework to do this for
us.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/timer.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 92447cd..0758bae 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -159,6 +159,11 @@ static struct of_device_id omap_timer_match[] __initdata = {
{ }
};
+static struct of_device_id omap_counter_match[] __initdata = {
+ { .compatible = "ti,omap-counter32k", },
+ { }
+};
+
/**
* omap_get_timer_dt - get a timer using device-tree
* @match - device-tree match structure for matching a device type
@@ -377,11 +382,26 @@ static u32 notrace dmtimer_read_sched_clock(void)
static int __init omap2_sync32k_clocksource_init(void)
{
int ret;
+ struct device_node *np = NULL;
struct omap_hwmod *oh;
void __iomem *vbase;
const char *oh_name = "counter_32k";
/*
+ * If device-tree is present, then search the DT blob
+ * to see if the 32kHz counter is supported.
+ */
+ if (of_have_populated_dt()) {
+ np = omap_get_timer_dt(omap_counter_match, NULL);
+ if (!np)
+ return -ENODEV;
+
+ of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
+ if (!oh_name)
+ return -ENODEV;
+ }
+
+ /*
* First check hwmod data is available for sync32k counter
*/
oh = omap_hwmod_lookup(oh_name);
@@ -390,7 +410,13 @@ static int __init omap2_sync32k_clocksource_init(void)
omap_hwmod_setup_one(oh_name);
- vbase = omap_hwmod_get_mpu_rt_va(oh);
+ if (np) {
+ vbase = of_iomap(np, 0);
+ of_node_put(np);
+ } else {
+ vbase = omap_hwmod_get_mpu_rt_va(oh);
+ }
+
if (!vbase) {
pr_warn("%s: failed to get counter_32k resource\n", __func__);
return -ENXIO;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 1/2] ARM: dts: OMAP: Add counter-32k nodes
From: Jon Hunter @ 2012-10-25 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351193055-12488-1-git-send-email-jon-hunter@ti.com>
Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
device-tree binding documentation for OMAP counter-32k.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
.../devicetree/bindings/arm/omap/counter.txt | 15 +++++++++++++++
arch/arm/boot/dts/omap2420.dtsi | 6 ++++++
arch/arm/boot/dts/omap2430.dtsi | 6 ++++++
arch/arm/boot/dts/omap3.dtsi | 6 ++++++
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
5 files changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt b/Documentation/devicetree/bindings/arm/omap/counter.txt
new file mode 100644
index 0000000..5bd8aa0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/counter.txt
@@ -0,0 +1,15 @@
+OMAP Counter-32K bindings
+
+Required properties:
+- compatible: Must be "ti,omap-counter32k" for OMAP controllers
+- reg: Contains timer register address range (base address and length)
+- ti,hwmods: Name of the hwmod associated to the counter, which is typically
+ "counter_32k"
+
+Example:
+
+counter32k: counter at 4a304000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x4a304000 0x20>;
+ ti,hwmods = "counter_32k";
+};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index af5ee26..af65609 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -14,6 +14,12 @@
compatible = "ti,omap2420", "ti,omap2";
ocp {
+ counter32k: counter at 48004000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x48004000 0x20>;
+ ti,hwmods = "counter_32k";
+ };
+
omap2420_pmx: pinmux at 48000030 {
compatible = "ti,omap2420-padconf", "pinctrl-single";
reg = <0x48000030 0x0113>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 6887298..c392445 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -14,6 +14,12 @@
compatible = "ti,omap2430", "ti,omap2";
ocp {
+ counter32k: counter at 49020000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x49020000 0x20>;
+ ti,hwmods = "counter_32k";
+ };
+
omap2430_pmx: pinmux at 49002030 {
compatible = "ti,omap2430-padconf", "pinctrl-single";
reg = <0x49002030 0x0154>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index da8c0f5..805504a 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,6 +61,12 @@
ranges;
ti,hwmods = "l3_main";
+ counter32k: counter at 48320000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x48320000 0x20>;
+ ti,hwmods = "counter_32k";
+ };
+
intc: interrupt-controller at 48200000 {
compatible = "ti,omap2-intc";
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3a82e0..23ee149 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -95,6 +95,12 @@
ranges;
ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
+ counter32k: counter at 4a304000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x4a304000 0x20>;
+ ti,hwmods = "counter_32k";
+ };
+
omap4_pmx_core: pinmux at 4a100040 {
compatible = "ti,omap4-padconf", "pinctrl-single";
reg = <0x4a100040 0x0196>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 0/2] ARM: OMAP2+: Add device-tree support for 32kHz counter
From: Jon Hunter @ 2012-10-25 19:24 UTC (permalink / raw)
To: linux-arm-kernel
This series adds device-tree support for the 32kHz counter on OMAP2+ devices,
which is used as the default kernel clock-source for OMAP devices.
Boot tested on OMAP2420 H4, OMAP3430 Beagle Board and OMAP4430 Panda Board
with and without device-tree present.
Based and dependent upon OMAP2+ series that adds device-tree support for
DMTIMERs [1].
V3 changes:
- Correct counter register sizes
V2 changes:
- Updated counter name in binding per Benoit Cousson's feedback
[1] http://marc.info/?l=linux-omap&m=135065875808614&w=2
Jon Hunter (2):
ARM: dts: OMAP: Add counter-32k nodes
ARM: OMAP2+: Add device-tree support for 32kHz counter
.../devicetree/bindings/arm/omap/counter.txt | 15 +++++++++++
arch/arm/boot/dts/omap2420.dtsi | 6 +++++
arch/arm/boot/dts/omap2430.dtsi | 6 +++++
arch/arm/boot/dts/omap3.dtsi | 6 +++++
arch/arm/boot/dts/omap4.dtsi | 6 +++++
arch/arm/mach-omap2/timer.c | 28 +++++++++++++++++++-
6 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter.txt
--
1.7.9.5
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Tony Lindgren @ 2012-10-25 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210251908560.21193@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121025 12:11]:
> On Thu, 25 Oct 2012, Tony Lindgren wrote:
>
> > Ideally we'd have some Linux generic function to implement in the PRM/CM
> > drivers for getting the bootreason. But I guess we don't?
>
> Do you know of one, apart from WDIOC_GETBOOTSTATUS?
I wonder if we can now with multiple watchdogs supported to
have also PRM/CM implement omap_prcm_wdt_ioctl() that just
handles WDIOC_GETBOOTSTATUS and then just remove that handling
from the other omap watchdog drivers?
Regards,
Tony
^ permalink raw reply
* [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
From: Tony Lindgren @ 2012-10-25 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5088DD22.1050000@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [121024 23:34]:
> On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote:
> >* Tony Lindgren <tony@atomide.com> [121024 17:36]:
> >>* Santosh Shilimkar <santosh.shilimkar@ti.com> [121017 06:35]:
> >>>(Looping Arnd and Olof)
> >>>
> >>>On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:
> >>>>When building omap_l3_noc/smx drivers as modules, the following
> >>>>warning appears:
> >>>>
> >>>>CC [M] drivers/bus/omap_l3_smx.o
> >>>>drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class
> >>>>drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync'
> >>>>drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration
> >>>>drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
> >>>>CC [M] drivers/bus/omap_l3_noc.o
> >>>>drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class
> >>>>drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync'
> >>>>drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration
> >>>>drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used
> >>>>
> >>>>Adding module_init() and macros in omap_l3_noc/smx drivers when building
> >>>>as modules to remove the above warning.
> >>>>
> >>>>Reported-by: Tony Lindgren <tony@atomide.com>
> >>>>Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> >>>>---
> >>>Thanks for the fix Lokesh. Looks fine to me.
> >>>
> >>>Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >>
> >>Looks like nobody else has picked this up so I'll queue this along
> >>with few other omap warnings and regressions.
> >
> >Hmm actually this might require some more discussion. If we make
> >it use regular initcalls, then the ugly ifdefs can be left
> >out. Is there a reason to init this early, can't we just use regular
> >initcalls?
> >
> I thought about it. The whole reason we want interconnect errors
> enabled early in the boot to avoid bad accesses issued on
> interconnect
> in early boot by various init codes. We managed to discovered many
> init sequence issues where the a driver is trying to access registers
> when clocks are not active, or drivers are using bad mapping. At times
> these errors gets un-noticed because of the behavior of interconnect
> and later causes serious issues. Leaving the driver init late in the
> boot means we can't catch any of the issues happen till the L3 driver
> init happens.
OK yeah that makes sense. How about let's just make it
just postcore_initcall instead of postcore_initcall_sync?
In include/linux/module.h we have:
...
#else /* MODULE */
/* Don't use these in loadable modules, but some people do... */
#define early_initcall(fn) module_init(fn)
#define core_initcall(fn) module_init(fn)
#define postcore_initcall(fn) module_init(fn)
...
While the postcore_initcall_sync does not have those.
No idea what the current plan is, but I sort of remember reading
that the _sync versions are going away at some point anyways?
Regards,
Tony
^ permalink raw reply
* [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
From: Jon Hunter @ 2012-10-25 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50880C19.2090508@ti.com>
Hi Benoit,
On 10/24/2012 10:41 AM, Benoit Cousson wrote:
> Hi Jon,
>
> On 10/19/2012 04:59 PM, Jon Hunter wrote:
>> Add the 12 GP timers nodes present in OMAP2.
>> Add the 12 GP timers nodes present in OMAP3.
>> Add the 11 GP timers nodes present in OMAP4.
>> Add the 7 GP timers nodes present in AM33xx.
>>
>> Add documentation for timer properties specific to OMAP.
>>
>> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
>> Vaibhav's original nodes adding information on which timers support a PWM
>> output.
>>
>> Cc: Benoit Cousson <b-cousson@ti.com>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>
> I updated the patch to remove the interrupt-parent from the DTS nodes and the documentation, as discussed on the list in the context of OMAP5 DTS for GPIO.
>
> If you are OK with that version, I'll push it to Tony along with the others DTS patches.
Per our discussion please find below an updated patch with corrected
register sizes.
Vaibhav, I have changed the AM335x register size for timers to be 1KB
instead of 4KB to align with the AM335x HWMOD. I have boot tested on
the AM335x.
Cheers
Jon
>From 1bf082d78ecff2c1a08ffccc133010975d7478f5 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Fri, 19 Oct 2012 09:59:00 -0500
Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
Vaibhav's original nodes adding information on which timers support a PWM
output.
V5 changes:
- Updated timer register sizes for OMAP2/3/4.
- Modified AM335x timer register size to be 1KB instead of 4KB to align with
HWMOD.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
.../devicetree/bindings/arm/omap/timer.txt | 31 +++++++
arch/arm/boot/dts/am33xx.dtsi | 54 +++++++++++
arch/arm/boot/dts/omap2.dtsi | 85 ++++++++++++++++++
arch/arm/boot/dts/omap2420.dtsi | 8 ++
arch/arm/boot/dts/omap2430.dtsi | 8 ++
arch/arm/boot/dts/omap3.dtsi | 95 ++++++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 86 ++++++++++++++++++
7 files changed, 367 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 0000000..8732d4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,31 @@
+OMAP Timer bindings
+
+Required properties:
+- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
+- reg: Contains timer register address range (base address and
+ length).
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the OMAP device uses.
+- ti,hwmods: Name of the hwmod associated to the timer, "timer<X>",
+ where <X> is the instance number of the timer from the
+ HW spec.
+
+Optional properties:
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in
+ addition to the ARM CPU.
+- ti,timer-pwm: Indicates the timer can generate a PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
+ and therefore cannot be used by the kernel.
+
+Example:
+
+timer12: timer at 48304000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48304000 0x400>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4709269..70d24b8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -237,5 +237,59 @@
interrupts = <55>;
status = "disabled";
};
+
+ timer1: timer at 44e31000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x44e31000 0x400>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48040000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48040000 0x400>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48042000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48042000 0x400>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48044000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48044000 0x400>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ ti,timer-pwm;
+ };
+
+ timer5: timer at 48046000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48046000 0x400>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ ti,timer-pwm;
+ };
+
+ timer6: timer at 48048000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48048000 0x400>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ ti,timer-pwm;
+ };
+
+ timer7: timer at 4804a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4804a000 0x400>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ ti,timer-pwm;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index f366482..761c4b6 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -66,5 +66,90 @@
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
+
+ timer2: timer at 4802a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4802a000 0x400>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48078000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48078000 0x400>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 4807a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4807a000 0x400>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 4807c000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4807c000 0x400>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ ti,timer-dsp;
+ };
+
+ timer6: timer at 4807e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4807e000 0x400>;
+ interrupts = <42>;
+ ti,hwmods = "timer6";
+ ti,timer-dsp;
+ };
+
+ timer7: timer at 48080000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48080000 0x400>;
+ interrupts = <43>;
+ ti,hwmods = "timer7";
+ ti,timer-dsp;
+ };
+
+ timer8: timer at 48082000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48082000 0x400>;
+ interrupts = <44>;
+ ti,hwmods = "timer8";
+ ti,timer-dsp;
+ };
+
+ timer9: timer at 48084000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48084000 0x400>;
+ interrupts = <45>;
+ ti,hwmods = "timer9";
+ ti,timer-pwm;
+ };
+
+ timer10: timer at 48086000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48086000 0x400>;
+ interrupts = <46>;
+ ti,hwmods = "timer10";
+ ti,timer-pwm;
+ };
+
+ timer11: timer at 48088000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48088000 0x400>;
+ interrupts = <47>;
+ ti,hwmods = "timer11";
+ ti,timer-pwm;
+ };
+
+ timer12: timer at 4808a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4808a000 0x400>;
+ interrupts = <48>;
+ ti,hwmods = "timer12";
+ ti,timer-pwm;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 4d5ce91..af5ee26 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -42,5 +42,13 @@
interrupt-names = "tx", "rx";
ti,hwmods = "mcbsp2";
};
+
+ timer1: timer at 48028000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48028000 0x400>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index fa84532..6887298 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -83,5 +83,13 @@
ti,buffer-size = <128>;
ti,hwmods = "mcbsp5";
};
+
+ timer1: timer at 49018000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49018000 0x400>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 955cbdc..da8c0f5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -296,5 +296,100 @@
ti,buffer-size = <128>;
ti,hwmods = "mcbsp5";
};
+
+ timer1: timer at 48318000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48318000 0x400>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 49032000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49032000 0x400>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 49034000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49034000 0x400>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 49036000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49036000 0x400>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 49038000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49038000 0x400>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ ti,timer-dsp;
+ };
+
+ timer6: timer at 4903a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903a000 0x400>;
+ interrupts = <42>;
+ ti,hwmods = "timer6";
+ ti,timer-dsp;
+ };
+
+ timer7: timer at 4903c000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903c000 0x400>;
+ interrupts = <43>;
+ ti,hwmods = "timer7";
+ ti,timer-dsp;
+ };
+
+ timer8: timer at 4903e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903e000 0x400>;
+ interrupts = <44>;
+ ti,hwmods = "timer8";
+ ti,timer-pwm;
+ ti,timer-dsp;
+ };
+
+ timer9: timer at 49040000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49040000 0x400>;
+ interrupts = <45>;
+ ti,hwmods = "timer9";
+ ti,timer-pwm;
+ };
+
+ timer10: timer at 48086000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48086000 0x400>;
+ interrupts = <46>;
+ ti,hwmods = "timer10";
+ ti,timer-pwm;
+ };
+
+ timer11: timer at 48088000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48088000 0x400>;
+ interrupts = <47>;
+ ti,hwmods = "timer11";
+ ti,timer-pwm;
+ };
+
+ timer12: timer at 48304000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48304000 0x400>;
+ interrupts = <95>;
+ ti,hwmods = "timer12";
+ ti,timer-alwon;
+ ti,timer-secure;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2ab6e68..d3a82e0 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -433,5 +433,91 @@
ranges;
ti,hwmods = "ocp2scp_usb_phy";
};
+
+ timer1: timer at 4a318000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4a318000 0x80>;
+ interrupts = <0 37 0x4>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48032000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48032000 0x80>;
+ interrupts = <0 38 0x4>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48034000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48034000 0x80>;
+ interrupts = <0 39 0x4>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48036000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48036000 0x80>;
+ interrupts = <0 40 0x4>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 49038000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49038000 0x80>;
+ interrupts = <0 41 0x4>;
+ ti,hwmods = "timer5";
+ ti,timer-dsp;
+ };
+
+ timer6: timer at 4903a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903a000 0x80>;
+ interrupts = <0 42 0x4>;
+ ti,hwmods = "timer6";
+ ti,timer-dsp;
+ };
+
+ timer7: timer at 4903c000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903c000 0x80>;
+ interrupts = <0 43 0x4>;
+ ti,hwmods = "timer7";
+ ti,timer-dsp;
+ };
+
+ timer8: timer at 4903e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903e000 0x80>;
+ interrupts = <0 44 0x4>;
+ ti,hwmods = "timer8";
+ ti,timer-pwm;
+ ti,timer-dsp;
+ };
+
+ timer9: timer at 4803e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4803e000 0x80>;
+ interrupts = <0 45 0x4>;
+ ti,hwmods = "timer9";
+ ti,timer-pwm;
+ };
+
+ timer10: timer at 48086000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48086000 0x80>;
+ interrupts = <0 46 0x4>;
+ ti,hwmods = "timer10";
+ ti,timer-pwm;
+ };
+
+ timer11: timer at 48088000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48088000 0x80>;
+ interrupts = <0 47 0x4>;
+ ti,hwmods = "timer11";
+ ti,timer-pwm;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Paul Walmsley @ 2012-10-25 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025185755.GV11928@atomide.com>
On Thu, 25 Oct 2012, Tony Lindgren wrote:
> Ideally we'd have some Linux generic function to implement in the PRM/CM
> drivers for getting the bootreason. But I guess we don't?
Do you know of one, apart from WDIOC_GETBOOTSTATUS?
- Paul
^ permalink raw reply
* [PATCH 08/16] ARM: OMAP2: Move plat/menelaus.h to linux/mfd/menelaus.h
From: Tony Lindgren @ 2012-10-25 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025111158.GA5297@sortiz-mobl>
* Samuel Ortiz <sameo@linux.intel.com> [121025 04:14]:
> Hi Tony,
>
> On Thu, Oct 04, 2012 at 03:04:52PM -0700, Tony Lindgren wrote:
> > We can move menelaus.h to live with other mfd headers to
> > get it out of plat for ARM common zImage support.
> >
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Thanks, I've now pushed a branch with this patch only
to omap-for-v3.8/cleanup-headers-menelaus branch in case
you need to merge it in too.
Regards,
Tony
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox