Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On 02/07/2013 10:07 AM, Arnd Bergmann wrote:
> On Thursday 07 February 2013 09:51:11 Jon Hunter wrote:
>>>> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
>>>> {
>>>> int rc = platform_driver_register(&omap_dma_driver);
>>>>
>>>> -if (rc == 0) {
>>>> +if ((rc == 0) && (!of_have_populated_dt())) {
>>>> pdev = platform_device_register_full(&omap_dma_dev_info);
>>>> if (IS_ERR(pdev)) {
>>>> platform_driver_unregister(&omap_dma_driver);
>>>
>>> There is already a patch in linux-next that makes this obsolete.
>>> The device is now registered in arch/arm/mach-omap2/dma.c, so
>>> I guess you have to change that location now.
>>
>> Thanks. Will rebase on top of linux-next.
>
> Actually, there is another problem with that, because then
> you may get into the situation where nobody can apply your
> patch.
Yes Tony mentioned always using a proper branch for pulls. I will base
upon his omap-for-v3.9/multiplatform-v2 (per your inputs, thanks!).
> You should never build work on top of linux-next, because
> then your base gets rebuilt every day. Instead, you should
> /test/ your branch merged with linux-next to ensure it works
> with all the other things in place, and when you see conflicts
> like this, you have to find out what they are and then decide
> whether you need to rebase it, and to what.
Ugh, looks like linux-next is broken for omap2+ boards at the moment
and is panic'ing in the twl i2c code ... some else to look into ...
Peter have you seen this on linux-next? I am seeing this on omap2-4 boards.
[2.286132] Unable to handle kernel NULL pointer dereference at virtual
address
[2.294738] pgd = c0004000
[2.297576] [] *pgd=
[2.301361] Internal error: Oops: 5 [#1] SMP ARM
[2.306243] Modules linked in:
[2.309448] CPU: 0Not tainted (3.8.0-rc6-next-20130207-00016-g735c237
#35)
[2.317169] PC is at twl_i2c_read+0x3c/0xec
[2.321563] LR is at twl_i2c_read+0x1c/0xec
[2.325988] pc : []lr : []psr: 8153
[2.325988] sp : c702fed0 ip : fp :
[2.338043] r10: c702e000 r9 : c06e84e8 r8 : c06e51c8
[2.343536] r7 : 0001 r6 : 0006 r5 : c702fef6 r4 : 0004
[2.350402] r3 : c129508c r2 : 0006 r1 : c702fef6 r0 : 000e
[2.357269] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment
kernel
[2.365051] Control: 10c5387d Table: 80004019 DAC: 0017
[2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240)
[2.377410] Stack: (0xc702fed0 to 0xc703)
[2.382019] fec0: c0d42180 c0d429d0
c70a7640 c07354c4
[2.390624] fee0: 0001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac
c07354c4
[2.399230] ff00: 0007 c06f2d64 0017 c06fb308 c06f07a4
c0cb8580 c06edee0
[2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 009e c00611b4
0001
[2.416442] ff40: c061994c c06b7548 0007 0007 c07354c4
0007 c0719798
[2.425048] ff60: c0d42180 c06e51c8 c07197a0 009e c06e590c
0007 0007
[2.433654] ff80: c06e51c8 c04d26ec
[2.442260] ffa0: c04d26f4 c00137b0
[2.450866] ffc0:
[2.459472] ffe0: 0013
80fb6c10 71bbcd20
[2.468078] [] (twl_i2c_read+0x3c/0xec) from []
(omap3_twl_set_sr_bit+0x3c/0xb4)
[2.477722] [] (omap3_twl_set_sr_bit+0x3c/0xb4) from []
(omap3_twl_init+0x2c/0x70)
[2.487518] [] (omap3_twl_init+0x2c/0x70) from []
(omap_pmic_late_init+0x18/0x24)
[2.497222] [] (omap_pmic_late_init+0x18/0x24) from []
(omap2_common_pm_late_init+0x18/0xd0)
[2.507934] [] (omap2_common_pm_late_init+0x18/0xd0) from
[] (omap3_init_late+0xc/0x18)
[2.518188] [] (omap3_init_late+0xc/0x18) from []
(init_machine_late+0x1c/0x28)
[2.527740] [] (init_machine_late+0x1c/0x28) from []
(do_one_initcall+0x100/0x16c)
[2.537536] [] (do_one_initcall+0x100/0x16c) from []
(kernel_init_freeable+0xfc/0x1c8)
[2.547698] [] (kernel_init_freeable+0xfc/0x1c8) from []
(kernel_init+0x8/0xe4)
[2.557250] [] (kernel_init+0x8/0xe4) from []
(ret_from_fork+0x14/0x24)
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 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On 02/07/2013 08:39 AM, Arnd Bergmann wrote:
> On Wednesday 06 February 2013, Jon Hunter wrote:
>> +static struct of_dma_filter_info info;
>
> Both members of this structure are constant, so you can just initialize it
> here,
> and it would be nice to give it a more descriptive name, such as
> omap_dmadev_info.
>
>> static struct platform_driver omap_dma_driver = {
>> .probe = omap_dma_probe,
>> .remove = omap_dma_remove,
>> .driver = {
>> .name = "omap-dma-engine",
>> .owner = THIS_MODULE,
>> +.of_match_table = of_match_ptr(omap_dma_match)
>> },
>> };
>
> please end the new line with a comma.
Ok.
>> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
>> {
>> int rc = platform_driver_register(&omap_dma_driver);
>>
>> -if (rc == 0) {
>> +if ((rc == 0) && (!of_have_populated_dt())) {
>> pdev = platform_device_register_full(&omap_dma_dev_info);
>> if (IS_ERR(pdev)) {
>> platform_driver_unregister(&omap_dma_driver);
>
> There is already a patch in linux-next that makes this obsolete.
> The device is now registered in arch/arm/mach-omap2/dma.c, so
> I guess you have to change that location now.
Thanks. Will rebase on top of linux-next.
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 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On 02/06/2013 03:03 PM, Jon Hunter wrote:
> If the device-tree blob is present during boot, then register the SDMA
> controller with the device-tree DMA driver so that we can use device-tree
> to look-up DMA client information.
>
> Signed-off-by: Jon Hunter
> ---
> drivers/dma/omap-dma.c | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 5a31264..a32d81b 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "virt-dma.h"
>
> @@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
> [OMAP_DMA_DATA_TYPE_S32] = 4,
> };
>
> +static struct of_dma_filter_info info;
> +
> static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
> {
> return container_of(d, struct omap_dmadev, ddev);
> @@ -621,10 +625,25 @@ static int omap_dma_probe(struct platform_device *pdev)
> pr_warn("OMAP-DMA: failed to register slave DMA engine device:
> %d\n",
> rc);
> omap_dma_free(od);
> + return rc;
> } else {
> platform_set_drvdata(pdev, od);
> }
I realise now that I could get rid of the else here and just call
platform_set_drvdata(), if we don't return.
Anyway, I will wait for other comments before changing.
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 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter
---
drivers/dma/omap-dma.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 5a31264..a32d81b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
#include "virt-dma.h"
@@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
};
+static struct of_dma_filter_info info;
+
static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
{
return container_of(d, struct omap_dmadev, ddev);
@@ -621,10 +625,25 @@ static int omap_dma_probe(struct platform_device *pdev)
pr_warn("OMAP-DMA: failed to register slave DMA engine device:
%d\n",
rc);
omap_dma_free(od);
+ return rc;
} else {
platform_set_drvdata(pdev, od);
}
+ if (pdev->dev.of_node) {
+ info.dma_cap = od->ddev.cap_mask;
+ info.filter_fn = omap_dma_filter_fn;
+
+ /* Device-tree DMA controller registration */
+ rc = of_dma_controller_register(pdev->dev.of_node,
+ of_dma_simple_xlate, &info);
+ if (rc) {
+ pr_warn("OMAP-DMA: failed to register DMA
controller\n");
+ dma_async_device_unregister(&od->ddev);
+ omap_dma_free(od);
+ }
+ }
+
dev_info(&pdev->dev, "OMAP DMA engine driver\n");
return rc;
@@ -634,18 +653,28 @@ static int omap_dma_remove(struct platform_device *pdev)
{
struct omap_dmadev *od = platform_get_drvdata(pdev);
+ if (pdev->dev.of_node)
+ of_dma_controller_free(pdev->dev.of_node);
+
dma_async_device_unregister(&od->ddev);
omap_dma_free(od);
return 0;
}
+static const struct of_device_id omap_dma_match[] = {
+ { .compatible = "ti,omap-sdma", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_dma_match);
+
static struct platform_driver omap_dma_driver = {
.probe = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = "omap-dma-engine",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_dma_match)
},
};
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
{
int rc = platform_driver_register(&omap_dma_driver);
- if (rc == 0) {
+ if ((rc == 0) && (!of_have_populated_dt())) {
pdev = platform_device_register_full(&omap_dma_dev_info);
if (IS_ERR(pdev)) {
platform_driver_unregister(&omap_dma_driver);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/dma/omap-sdma.txt | 44
arch/arm/boot/dts/omap2.dtsi | 12 ++
arch/arm/boot/dts/omap3.dtsi | 40 ++
arch/arm/boot/dts/omap4.dtsi | 41 ++
arch/arm/boot/dts/omap5.dtsi | 41 ++
5 files changed, 178 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt
b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 000..5c2c125
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,44 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible: Must be "ti,omap-sdma"
+- reg: Contains DMA registers location and length.
+- interrupts: Contains DMA interrupt information.
+- #dma-cells: Must be 1.
+- #dma-channels: Contains total number of programmable DMA channels.
+- #dma-requests: Contains total number of DMA requests.
+
+Example:
+
+ sdma: dma-controller@4A056000 {
+ compatible = "ti,omap-sdma";
+ reg = <0x4A056000 0x1000>;
+ interrupts = <0 12 0x4>,
+<0 13 0x4>,
+<0 14 0x4>,
+<0 15 0x4>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <127>;
+ };
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas:List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - The DMA request number associated with client device
+- dma-names: Contains one identifier string for each dma specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+
+Example:
+
+ mmc1: mmc@4809c000 {
+ ...
+ dmas = <&sdma 61>, /* TX channel */
+ <&sdma 62>; /* RX channel */
+ dma-names = "tx", "rx";
+ ...
+ };
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..7288972 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -49,6 +49,18 @@
reg = <0x480FE000 0x1000>;
};
+ sdma: dma-controller@48056000 {
+ compatible = "ti,omap-sdma";
+ reg = <0x48056000 0x1000>;
+ interrupts = <12>,
+<13>,
+<14>,
+<15>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <64>;
+ };
+
uart1: serial@4806a000 {
compatible = "ti,omap2-uart";
ti,hwmods = "uart1";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..4d63aa2 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -75,6 +75,18 @@
reg = <0x4820 0x1000>;
};
+ sdma: dma-controller@48056000 {
+ compatible = "ti,omap-sdma";
+ reg = <0x48056000 0x1000>;
+ interrupts = <12>,
+<13>,
+<14>,
+<15>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <96>;
+ };
+
omap3_pmx_core: pinmux@48002030 {
compatible = "ti,omap3-padconf", "pinctrl-single";
reg = <0x48002030 0x05cc>;
@@ -192,6 +204,16 @@
#size-cells = <0>;
ti,hwmods = "mcspi1";
ti,spi-num-cs = <4>;
+ dmas = <&sdma 35>,
+ <&s
[PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA
Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client bindings are also added for devices that have SPI and MMC bindings populated. Client binding data is based upon existing HWMOD data for OMAP and has been checked against OMAP documentation. Testing includes ... 1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. 2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. Testing branch available here [1]. Series is based upon v3.8-rc6 on top of the following ... - Vinod's topic/dmaengine_dt branch [2] - Matt Porter's series "DMA Engine support for AM33XX" [3] - Matt Porter's series "omap_hsmmc DT DMA Client support" [4] - Sourav Poddar's series "add omap mcspi device tree data" [5] [1] https://github.com/jonhunter/linux/commits/dev-dt-dma [2] http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt [3] http://permalink.gmane.org/gmane.linux.kernel.spi.devel/12508 [4] http://permalink.gmane.org/gmane.linux.ports.arm.omap/93165 [5] http://permalink.gmane.org/gmane.linux.kernel/1435002 Jon Hunter (2): ARM: dts: OMAP2+: Add SDMA controller bindings and nodes dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver .../devicetree/bindings/dma/omap-sdma.txt | 44 arch/arm/boot/dts/omap2.dtsi | 12 ++ arch/arm/boot/dts/omap3.dtsi | 40 ++ arch/arm/boot/dts/omap4.dtsi | 41 ++ arch/arm/boot/dts/omap5.dtsi | 41 ++ drivers/dma/omap-dma.c | 31 +- 6 files changed, 208 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Clear GPMC bits when applying new setting
On 02/06/2013 08:15 AM, Mark Jackson wrote: > When setting the GPMC device type, make sure any previous > bits are cleared down, before applying the new setting. > > Signed-off-by: Mark Jackson > --- > arch/arm/mach-omap2/gpmc.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c > index 1adb2d4..026e786 100644 > --- a/arch/arm/mach-omap2/gpmc.c > +++ b/arch/arm/mach-omap2/gpmc.c > @@ -613,6 +613,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval) > > case GPMC_CONFIG_DEV_TYPE: > regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1); > + /* clear 3 target bits */ > + regval &= ~(GPMC_CONFIG1_DEVICETYPE(3) | > + GPMC_CONFIG1_MUXADDDATA); MUXADDDATA is actually a 2-bit field on current devices (OMAP4+ and AM335x). For OMAP2/3 devices it was only a one bit field. So it may be worth clearing both bits for all devices. For OMAP2 devices bit 8 is reserved but the TRM says to writes a 0, so clearing bit 8 on OMAP2/3 devices should not be a problem. In fact bit 8 should read as 0 on OMAP2/3. > + /* set the proper value */ > regval |= GPMC_CONFIG1_DEVICETYPE(wval); > if (wval == GPMC_DEVICETYPE_NOR) > regval |= GPMC_CONFIG1_MUXADDDATA; > Otherwise ... Acked-by: Jon Hunter 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 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/05/2013 05:34 PM, Tony Lindgren wrote: > * Jon Hunter [130204 14:49]: >> >> On 02/04/2013 04:12 PM, Jon Hunter wrote: >>> >>> On 02/01/2013 03:51 PM, Tony Lindgren wrote: >>> >>>> How about let's fix this properly to start with so we don't add >>>> more blockers moving this code to drivers/bus? >>>> >>>> Looks like gpmc_mem_init() gets called from gpmc_probe() so >>>> we can pass that information in pdev. >>> >>> I have re-worked this a bit to use platform data. I have also update >>> the logic for testing internal/external boot on omap2430 which is >>> different from omap2420 (according to the TRM). However, I have only >>> boot tested on omap2420. >>> >>> Do you know why this was changed in the first place? See below ... >>> >>> http://permalink.gmane.org/gmane.linux.kernel.commits.head/95931 >>> >>> Heres what I have now ... >> >> Updated patch (I was missing a kfree()). By the way, this is based >> upon the apollon removal patch. I understand probably needs to be >> rebased on your latest gpmc series too. > > Yeah makes sense to me thanks. I'll figure out where to apply this > so we don't get too many dependencies. Actually, let me look into this a bit more. It appears that for all omap2+ devices NOR should be mapped to CS0 at 0x0800. So I am wondering if the boot-loader is re-mapping the CS0 space. If it is then may be we can avoid having such hacks in the kernel by fixing the bootloader. To date only the apollon board has really had this problem and I need to check what I have on my H4 (which has been hacked by me ;-) 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: OMAP4 PM bootloader dependency problems
Hi Paul,
On 01/21/2013 08:42 PM, Paul Walmsley wrote:
>
> Hi Tero, Rajendra, Santosh,
>
> As we've discussed, there are known bootloader dependencies with the OMAP4
> PM retention idle code, introduced in v3.8. Boards booted with u-boot
> versions even as recent as 2011 won't enter retention idle correctly; for
> example:
>
>
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
>
> The right thing for you all to do is what was done for OMAP3: to add code
> to correctly reset and initialize these on-chip devices. However, since
> it's already late in the v3.8-rc cycle, this seems unlikely to happen in
> time for the v3.8 release -- and that's assuming that you guys are working
> on this, which I'm unsure of.
I noticed on my OMAP4430 SDP that in suspend L3INIT was failing to enter
retention state. I am not sure if this is the same problem that you are
seeing or not. However, I found that the reason the L3INIT was not entering
retention on this board was because the USB DPLL was not locked by the
bootloader on this board. On my panda the USB DPLL is locked the L3INIT
is entering suspend.
I crafted the following which is working on my omap4430 panda, sdp and
omap4460 panda. Let me know what you think ...
Cheers
Jon
>From 3bfe708af8e91564bc78c79111f9080a35fb5b88 Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Tue, 5 Feb 2013 13:27:57 -0600
Subject: [PATCH] ARM: OMAP4: Fix low power in kernel suspend
Some versions of the u-boot bootloader do not lock the USB DPLL and
when the USB DPLL is not locked, then it is observed that the L3INIT
power domain does not transition to retention state during kernel
suspend on OMAP4 devices. Fix this by locking the USB DPLL at 960 MHz
on kernel boot.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/cclock44xx_data.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index e71a19c..2c811d9 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -48,6 +48,13 @@
*/
#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+/*
+ * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
+ * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
+ * locked frequency for the USB DPLL is 960MHz.
+ */
+#define OMAP4_DPLL_USB_DEFFREQ 96000
+
/* Root clocks */
DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
@@ -2045,5 +2052,13 @@ int __init omap4xxx_clk_init(void)
if (rc)
pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+ /*
+* Lock USB DPLL on OMAP4 devices so that the L3INIT power
+* domain can transition to retention state when not in use.
+*/
+ rc = clk_set_rate(&dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ);
+ if (rc)
+ pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DT GPMC SRAM and NOR flash support ?
On 02/05/2013 10:48 AM, Mark Jackson wrote:
> On 05/02/13 16:35, Jon Hunter wrote:
>>
>> On 02/05/2013 10:16 AM, Mark Jackson wrote:
>>> On 01/02/13 19:39, Mark Jackson wrote:
>>>> On 01/02/13 17:12, Jon Hunter wrote:
>>>>> Hi Mark,
>>>>>
>>>>> On 02/01/2013 10:56 AM, Mark Jackson wrote:
>>>>>> There's plenty of DT support going in for NAND flash, but is there any
>>>>>> work going on to support NOR
>>>>>> flash ?
>>>>>
>>>>> What board and device are you working that is using NOR? I have a
>>>>> OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
>>>>> I don't spend much time on it. Eventually it will have to be done but it
>>>>> is always good to know if there is a pressing need.
>>>>
>>>> We have a custom AM335x CPU board (arriving on my desk within the next few
>>>> weeks) that has both NAND
>>>> and NOR Flash.
>>>>
>>>>>> And how about SRAM chips or other memory mapped devices ?
>>>>>
>>>>> Not sure about SRAM (trying to think if I have a board with SRAM even),
>>>>> but definitely, boards using the GPMC to interface to ethernet chips
>>>>> need to be added.
>>>>
>>>> The board also contains an FRAM chip (which is just treated as SRAM).
>>>>
>>>> If you'd anything in the pipeline, I'm glad to help in any testing. I've
>>>> created a custom cape board
>>>> for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not
>>>> waiting for the new
>>>> hardware to arrive.
>>
>> Sorry for the delay. I personally don't have anything in the pipe.
>>
>> Afzal, do you know of anyone looking at this?
>>
>>> I've experimented with trying to add a mtd-physmap device, but no joy.
>>>
>>> I'm guessing that the current mtd-physmap code is (in some way) currently
>>> incompatible with the GPMC
>>> device ?
>>
>> I am not familiar with mtd-physmap to comment. Is that DT specific?
>
> Well, it's documented in
> Documentation/devicetree/bindings/mtd/mtd-physmap.txt, showing you can
> specify "cfi-flash" or "mtd-ram" devices, eg (taken from mtd-physmap.txt):-
>
> flash@ff00 {
> compatible = "amd,am29lv128ml", "cfi-flash";
> reg = ;
> bank-width = <4>;
> device-width = <1>;
> #address-cells = <1>;
> #size-cells = <1>;
> fs@0 {
> label = "fs";
> reg = <0 f8>;
> };
> firmware@f8 {
> label ="firmware";
> reg = ;
> read-only;
> };
> };
>
> sram@2,0 {
> compatible = "samsung,k6f1616u6a", "mtd-ram";
> reg = <2 0 0x0020>;
> bank-width = <2>;
> };
Ok, I see that the NOR flash on my omap2420 H4 is named "physmap-flash"
(I have not ported to DT yet). So the GPMC should work with it.
> But I guess the GPMC needs to be configured to enable chip selects, data
> widths, etc.
Exactly.
> I did get *something* on the address / data bus by adding the patches below,
> but I'm getting bus
> contention, so something else needs setting up in the GPMC.
>
> I'm no great device driver writer, but if anyone can give me some pointers,
> I'm happy to keep digging.
>
> Cheers
> Mark J.
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index a37e1c9..8f45d18 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
> struct device_node *child;
> const struct of_device_id *of_id =
> of_match_device(gpmc_dt_ids, &pdev->dev);
> + unsigned long base;
>
> if (!of_id)
> return 0;
>
> + gpmc_cs_request(0, SZ_16M, &base);
> +
You should check what gpmc_cs_request returns.
Where are the NOR flash timings setup? Or are they already configured by
the bootloader? If so then that is probably ok for now.
> for_each_node_by_name(child, "nand") {
> ret = gpmc_probe_nand_child(pdev, child);
> of_node_put(child);
If you look at the gpmc_probe_nand_child(), this function is setting up
the NAND timings for the GPMC.
Ideally, we would have a similar function for nor (ie.
gpmc_probe_nor_child()), that would read the NOR information
(chip-select, size, timings, etc) from DT. However, I understand that
the above is just for test purposes.
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 V3 5/7] ARM: OMAP3: Update clocksource timer selection
On 02/05/2013 02:39 AM, Igor Grinberg wrote: > On 02/04/13 21:46, Jon Hunter wrote: >> When booting with device-tree for OMAP3 and AM335x devices and a gptimer >> is used as the clocksource (which is always the case for AM335x), a >> gptimer located in a power domain that is not always-on is selected. >> Ideally we should use a gptimer located in a power domain that is always >> on (such as the wake-up domain) so that time can be maintained during a >> kernel suspend without keeping on additional power domains unnecessarily. >> >> In order to fix this so that we can select a gptimer located in a power >> domain that is always-on, the following changes were made ... >> 1. Currently, only when selecting a gptimer to use for a clockevent >>timer, do we pass a timer property that can be used to select a >>specific gptimer. Change this so that we can pass a property when >>selecting a gptimer to use for a clocksource timer too. >> 2. Currently, when selecting either a gptimer to use for a clockevent >>timer or a clocksource timer and no timer property is passed, then >>the first available timer is selected regardless of the properties >>it has. Change this so that if no properties are passed, then a timer >>that does not have additional features (such as always-on, dsp-irq, >>pwm, and secure) is selected. >> >> Please note that using a gptimer for both clocksource and clockevents >> can have a system power impact during idle. The reason being is that >> OMAP and AMxxx devices typically only have one gptimer in a power domain >> that is always-on. Therefore when the kernel is idle both the clocksource >> and clockevent timers will be active and this will keep additional power >> domains on. During kernel suspend, only the clocksource timer is active >> and therefore, it is better to use a gptimer in a power domain that is >> always-on for clocksource. > > Hmmm... > Do I miss something or you have forgot to update the commit message? Ugh you are right :-( Some how yesterday when rebasing the series and adding a couple more patches, I royally screwed it up. How about the following ... Cheers Jon >From c82699e94d0255b3b1524e0d5ff4fd1f5852de69 Mon Sep 17 00:00:00 2001 From: Jon Hunter Date: Mon, 28 Jan 2013 17:53:57 -0600 Subject: [PATCH] ARM: OMAP3: Update clocksource timer selection When booting with device-tree for OMAP3 and AM335x devices and a gptimer is used as the clocksource (which is always the case for AM335x), a gptimer located in a power domain that is not always-on is selected. Ideally we should use a gptimer for clocksource that is located in a power domain that is always on (such as the wake-up domain) so that time can be maintained during a kernel suspend without keeping on additional power domains unnecessarily. In order to fix this so that we can select a gptimer located in a power domain that is always-on, the following changes were made ... 1. Currently, only when selecting a gptimer to use for a clockevent timer, do we pass a timer property that can be used to select a specific gptimer. Change this so that we can pass a property when selecting a gptimer to use for a clocksource timer too. 2. Currently, when selecting either a gptimer to use for a clockevent timer or a clocksource timer and no timer property is passed, then the first available timer is selected regardless of the properties it has. Change this so that if no properties are passed, then a timer that does not have additional features (such as always-on, dsp-irq, pwm, and secure) is selected. For OMAP3 and AM335x devices that use a gptimer for clocksource, change the selection of the gptimer so that by default the gptimer located in the always-on power domain is used for clocksource instead of clockevents. Please note that using a gptimer for both clocksource and clockevents can have a system power impact during idle. The reason being is that OMAP and AMxxx devices typically only have one gptimer in a power domain that is always-on. Therefore when the kernel is idle both the clocksource and clockevent timers will be active and this will keep additional power domains on. During kernel suspend, only the clocksource timer is active and therefore, it is better to use a gptimer in a power domain that is always-on for clocksource. Signed-off-by: Jon Hunter Acked-by: Santosh Shilimkar Acked-by: Igor Grinberg --- arch/arm/mach-omap2/timer.c | 33 + 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 3ad9a3b..fce495e 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -160,6 +160,12 @@ static struct device_node * __init omap_get_timer_dt(struct of_device_id
Re: DT GPMC SRAM and NOR flash support ?
On 02/05/2013 10:16 AM, Mark Jackson wrote: > On 01/02/13 19:39, Mark Jackson wrote: >> On 01/02/13 17:12, Jon Hunter wrote: >>> Hi Mark, >>> >>> On 02/01/2013 10:56 AM, Mark Jackson wrote: >>>> There's plenty of DT support going in for NAND flash, but is there any >>>> work going on to support NOR >>>> flash ? >>> >>> What board and device are you working that is using NOR? I have a >>> OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but >>> I don't spend much time on it. Eventually it will have to be done but it >>> is always good to know if there is a pressing need. >> >> We have a custom AM335x CPU board (arriving on my desk within the next few >> weeks) that has both NAND >> and NOR Flash. >> >>>> And how about SRAM chips or other memory mapped devices ? >>> >>> Not sure about SRAM (trying to think if I have a board with SRAM even), >>> but definitely, boards using the GPMC to interface to ethernet chips >>> need to be added. >> >> The board also contains an FRAM chip (which is just treated as SRAM). >> >> If you'd anything in the pipeline, I'm glad to help in any testing. I've >> created a custom cape board >> for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not >> waiting for the new >> hardware to arrive. Sorry for the delay. I personally don't have anything in the pipe. Afzal, do you know of anyone looking at this? > I've experimented with trying to add a mtd-physmap device, but no joy. > > I'm guessing that the current mtd-physmap code is (in some way) currently > incompatible with the GPMC > device ? I am not familiar with mtd-physmap to comment. Is that DT specific? 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 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/04/2013 04:12 PM, Jon Hunter wrote:
>
> On 02/01/2013 03:51 PM, Tony Lindgren wrote:
>
>> How about let's fix this properly to start with so we don't add
>> more blockers moving this code to drivers/bus?
>>
>> Looks like gpmc_mem_init() gets called from gpmc_probe() so
>> we can pass that information in pdev.
>
> I have re-worked this a bit to use platform data. I have also update
> the logic for testing internal/external boot on omap2430 which is
> different from omap2420 (according to the TRM). However, I have only
> boot tested on omap2420.
>
> Do you know why this was changed in the first place? See below ...
>
> http://permalink.gmane.org/gmane.linux.kernel.commits.head/95931
>
> Heres what I have now ...
Updated patch (I was missing a kfree()). By the way, this is based
upon the apollon removal patch. I understand probably needs to be
rebased on your latest gpmc series too.
Jon
>From 643656e3754ed949d9a8af31b22ed3727e0962f6 Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Thu, 31 Jan 2013 15:56:08 -0600
Subject: [PATCH] ARM: OMAP2: Fix GPMC memory initialisation
OMAP2+ devices have an internal ROM that by default is typically mapped
to the first 1MB of the GPMC address space (0x0).
For OMAP24xx devices, GPMC chip-select 0 (CS0) may be mapped to address
0x0 instead of the internal ROM if configured for an external boot mode.
If configured for an internal boot mode then the internal ROM is mapped
to 0x0.
Currently, the function gpmc_mem_init() function reserves the first 1MB
of GPMC address space for the internal OMAP ROM. This prevents any
device (ethernet chip, flash memories, etc) from using this address
range. This causes the GPMC probe to fail on the OMAP2420 H4 when NOR
flash is mapped to address 0x0. Fix this by checking the SYS_BOOT pin
setting for OMAP24xx devices, to see the device is configured for
an internal or external boot and pass the amount of ROM mapped to
address 0x0 to the GPMC driver via platform data.
Please note that for OMAP3-5 devices, when booting from NOR or NAND
memories connected to CS0, these memories are always mapped to address
0x0800 and so reserving this memory range does not present any
problems for these devices.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 60
arch/arm/mach-omap2/gpmc.h |5
2 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a124849..aa58258 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,7 @@
#include "soc.h"
#include "common.h"
+#include "control.h"
#include "omap_device.h"
#include "gpmc.h"
@@ -87,7 +89,6 @@
#define GPMC_MEM_START 0x
#define GPMC_MEM_END 0x3FFF
-#define BOOT_ROM_SPACE 0x10/* 1MB */
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
@@ -775,16 +776,11 @@ static void gpmc_mem_exit(void)
}
-static int gpmc_mem_init(void)
+static int gpmc_mem_init(u32 offset)
{
int cs, rc;
- unsigned long boot_rom_space = 0;
- /* never allocate the first page, to facilitate bug detection;
-* even if we didn't boot from ROM.
-*/
- boot_rom_space = BOOT_ROM_SPACE;
- gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
+ gpmc_mem_root.start = GPMC_MEM_START + offset;
gpmc_mem_root.end = GPMC_MEM_END;
/* Reserve all regions that has been set up by bootloader */
@@ -1124,6 +1120,12 @@ static int gpmc_probe(struct platform_device *pdev)
int rc;
u32 l;
struct resource *res;
+ struct gpmc_platform_data *pdata = pdev->dev.platform_data;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "%s: no platform data.\n", __func__);
+ return -ENODEV;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
@@ -1161,7 +1163,7 @@ static int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- rc = gpmc_mem_init();
+ rc = gpmc_mem_init(pdata->gpmc_rom_space);
if (IS_ERR_VALUE(rc)) {
clk_disable_unprepare(gpmc_l3_clk);
clk_put(gpmc_l3_clk);
@@ -1213,18 +1215,54 @@ static int __init omap_gpmc_init(void)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
+ struct gpmc_platform_data *pdata;
char *oh_name = "gpmc";
+ pdata = kzalloc(sizeof(struct gpmc_platform_data), GFP_KERNEL);
+
Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
> How about let's fix this properly to start with so we don't add
> more blockers moving this code to drivers/bus?
>
> Looks like gpmc_mem_init() gets called from gpmc_probe() so
> we can pass that information in pdev.
I have re-worked this a bit to use platform data. I have also updated
the logic for testing internal/external boot on omap2430 which is
different from omap2420 (according to the TRM). However, I have only
boot tested on omap2420.
Do you know why this was changed in the first place? See below ...
http://permalink.gmane.org/gmane.linux.kernel.commits.head/95931
Heres what I have now ...
>From df2eebd3580f478f569241d294c2f810359fab6a Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Thu, 31 Jan 2013 15:56:08 -0600
Subject: [PATCH] ARM: OMAP2: Fix GPMC memory initialisation
OMAP2+ devices have an internal ROM that by default is typically mapped
to the first 1MB of the GPMC address space (0x0).
For OMAP24xx devices, GPMC chip-select 0 (CS0) may be mapped to address
0x0 instead of the internal ROM if configured for an external boot mode.
If configured for an internal boot mode then the internal ROM is mapped
to 0x0.
Currently, the function gpmc_mem_init() function reserves the first 1MB
of GPMC address space for the internal OMAP ROM. This prevents any
device (ethernet chip, flash memories, etc) from using this address
range. This causes the GPMC probe to fail on the OMAP2420 H4 when NOR
flash is mapped to address 0x0. Fix this by checking the SYS_BOOT pin
setting for OMAP24xx devices, to see the device is configured for
an internal or external boot and pass the amount of ROM mapped to
address 0x0 to the GPMC driver via platform data.
Please note that for OMAP3-5 devices, when booting from NOR or NAND
memories connected to CS0, these memories are always mapped to address
0x0800 and so reserving this memory range does not present any
problems for these devices.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 53 +++-
arch/arm/mach-omap2/gpmc.h |5 +
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a124849..71c0134 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,7 @@
#include "soc.h"
#include "common.h"
+#include "control.h"
#include "omap_device.h"
#include "gpmc.h"
@@ -87,7 +89,6 @@
#define GPMC_MEM_START 0x
#define GPMC_MEM_END 0x3FFF
-#define BOOT_ROM_SPACE 0x10/* 1MB */
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
@@ -775,16 +776,11 @@ static void gpmc_mem_exit(void)
}
-static int gpmc_mem_init(void)
+static int gpmc_mem_init(u32 offset)
{
int cs, rc;
- unsigned long boot_rom_space = 0;
- /* never allocate the first page, to facilitate bug detection;
-* even if we didn't boot from ROM.
-*/
- boot_rom_space = BOOT_ROM_SPACE;
- gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
+ gpmc_mem_root.start = GPMC_MEM_START + offset;
gpmc_mem_root.end = GPMC_MEM_END;
/* Reserve all regions that has been set up by bootloader */
@@ -1124,6 +1120,12 @@ static int gpmc_probe(struct platform_device *pdev)
int rc;
u32 l;
struct resource *res;
+ struct gpmc_platform_data *pdata = pdev->dev.platform_data;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "%s: no platform data.\n", __func__);
+ return -ENODEV;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
@@ -1161,7 +1163,7 @@ static int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- rc = gpmc_mem_init();
+ rc = gpmc_mem_init(pdata->gpmc_rom_space);
if (IS_ERR_VALUE(rc)) {
clk_disable_unprepare(gpmc_l3_clk);
clk_put(gpmc_l3_clk);
@@ -1213,15 +1215,46 @@ static int __init omap_gpmc_init(void)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
+ struct gpmc_platform_data *pdata;
char *oh_name = "gpmc";
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err("%s: No memory for gpmc\n", __func__);
+ return -ENOMEM;
+ }
+
+ /*
+* The first 1MB of GPMC address space is mapped to the internal
+* ROM. OMAP2 devices are an exception to this where the first
+* 1MB may be mapped to the GPMC. O
Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/04/2013 01:47 PM, Tony Lindgren wrote: > * Jon Hunter [130204 11:37]: >> >> On 02/04/2013 01:15 PM, Tony Lindgren wrote: >>> * Jon Hunter [130204 10:49]: >>>> On 02/04/2013 11:45 AM, Tony Lindgren wrote: >>>>> >>>>> AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT >>>>> pins, so using generic pinconf there makes sense. But this of course >>>>> should >>>>> be checked. >>>> >>>> Not sure I am a fan of that idea. It is possible the pins could be >>>> re-used as GPIOs after reset. Given that the state at reset is latched >>>> in a register, it is best just to read the register directly. >>> >>> Yes the physical SYSBOOT pins can be reused as GPIO, but that's are already >>> handled by the padconf and GPIO registers. This is a different register >>> showing the boot time pin values for some pins. So it makes sense to use >>> generic pinconf to make the pin values available to the client drivers >>> as needed. >>> >>> The advantage doing it this way is that we don't need to export any omap >>> custom functions to the drivers from the SCM driver. This way we need zero >>> platform glue code, and can deal with it directly in the drivers in a >>> generic way. And all we need to do is just need to map the SoC specific >>> SYSBOOT pin register in the .dts files. >> >> I see what you are saying exporting the state in control_status register >> via the pinconf. That could work. >> >>> It may also make sense to export DEVICETYPE this way. At least early omaps >>> had the GP vs HS mode configured by pulls on some pins during the boot time. >>> So those bits too may reflect actual physical pins during the boot time >>> configured by the efuse settings? >> >> I *believe* that was only omap1. > > Yeah but maybe the efuses just configure some pulls for selected pins for > later omaps? > >>>>>>> Regarding omap_device, we should find a way to keep the dependencies >>>>>>> between drivers and the bus code down to minimum. So ideally things >>>>>>> like this would be only done using just the compatible flag. But the >>>>>>> pdata we cannot remove quite yet. >>>>>> >>>>>> Agree. However, there are several drivers today (gpio, dmtimer, mmc, >>>>>> serial, dss, etc), that make use of a function pointer to >>>>>> omap_pm_get_dev_context_loss_count() to determine when the peripheral's >>>>>> state has been lost. When booting with DT this function pointer is not >>>>>> populated and so with DT we currently have no way to determine this. I >>>>>> see this as a blocker to migrating completely to DT. Ideally we would >>>>>> find a way for RPM to handle this and remove the function pointer. >>>>>> However, right now we still need a generic way to pass this type of >>>>>> platform data to drivers. >>>>> >>>>> Yeah pinconf generic won't help us with the legacy boot. >>>> >>>> Right. I view all this sort of thing as system-level device information >>>> that some drivers may need. It does not seem that we have a good way to >>>> handle that at the moment. Any ideas? >>> >>> I suggest just passing it in in pdata for now for the legacy boot. Then >>> I suggest we make what we can generic with pinconf in the long run. >> >> I don't see why we would want to export a function pointer to >> omap_pm_get_dev_context_loss_count() with pinconf. Have we got our wires >> crossed here? > > Yes sorry, too many muxes here. I got this topic mixed up with the sysboot > pin topic :) > > We really need to find a Linux generic API to query this. Sounds like it > should be part of runtime PM? Ideally, yes. I had discussed with Kevin about adding a new state for "logic state lost" and then if this could be passed to the RPM resume callback then we could use this. May be I need to bring this up with Tero. 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 5/7] ARM: OMAP3: Update clocksource timer selection
When booting with device-tree for OMAP3 and AM335x devices and a gptimer
is used as the clocksource (which is always the case for AM335x), a
gptimer located in a power domain that is not always-on is selected.
Ideally we should use a gptimer located in a power domain that is always
on (such as the wake-up domain) so that time can be maintained during a
kernel suspend without keeping on additional power domains unnecessarily.
In order to fix this so that we can select a gptimer located in a power
domain that is always-on, the following changes were made ...
1. Currently, only when selecting a gptimer to use for a clockevent
timer, do we pass a timer property that can be used to select a
specific gptimer. Change this so that we can pass a property when
selecting a gptimer to use for a clocksource timer too.
2. Currently, when selecting either a gptimer to use for a clockevent
timer or a clocksource timer and no timer property is passed, then
the first available timer is selected regardless of the properties
it has. Change this so that if no properties are passed, then a timer
that does not have additional features (such as always-on, dsp-irq,
pwm, and secure) is selected.
Please note that using a gptimer for both clocksource and clockevents
can have a system power impact during idle. The reason being is that
OMAP and AMxxx devices typically only have one gptimer in a power domain
that is always-on. Therefore when the kernel is idle both the clocksource
and clockevent timers will be active and this will keep additional power
domains on. During kernel suspend, only the clocksource timer is active
and therefore, it is better to use a gptimer in a power domain that is
always-on for clocksource.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 3ad9a3b..fce495e 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -160,6 +160,12 @@ static struct device_node * __init
omap_get_timer_dt(struct of_device_id *match,
if (property && !of_get_property(np, property, NULL))
continue;
+ if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
+ of_get_property(np, "ti,timer-dsp", NULL) ||
+ of_get_property(np, "ti,timer-pwm", NULL) ||
+ of_get_property(np, "ti,timer-secure", NULL)))
+ continue;
+
of_add_property(np, &device_disabled);
return np;
}
@@ -435,13 +441,14 @@ static int __init __maybe_unused
omap2_sync32k_clocksource_init(void)
}
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+ const char *fck_source,
+ const char *property)
{
int res;
clksrc.errata = omap_dm_timer_get_errata();
- res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
+ res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, property,
&clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
BUG_ON(res);
@@ -538,47 +545,49 @@ static inline void __init realtime_counter_init(void)
#endif
#define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
- clksrc_nr, clksrc_src) \
+ clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
- omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src);\
+ omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
+ clksrc_prop); \
}
#define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
- clksrc_nr, clksrc_src) \
+ clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
{ \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clo
[PATCH V3 7/7] ARM: OMAP4+: Fix sparse warning in system timers
Commit 6bb27d7 (ARM: delete struct sys_timer) changed the function created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void. For OMAP4+ devices this created the following sparse warning ... arch/arm/mach-omap2/timer.c:585:1: warning: symbol 'omap4_sync32k_timer_init' was not declared. Should it be static? The function omap4_sync32k_timer_init() is not referenced outside of the file timer.c and so make this function static. Signed-off-by: Jon Hunter --- arch/arm/mach-omap2/timer.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index d0c698f..9fbecd8 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -587,8 +587,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, #endif #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) -OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon", - 2, "sys_clkin_ck", NULL); +static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon", + 2, "sys_clkin_ck", NULL); #endif #ifdef CONFIG_ARCH_OMAP4 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 6/7] ARM: OMAP2+: Store ID of system timers in timer structure
Currently, the timer ID is being passed to the function
omap_dm_timer_init_one(). Instead of passing the ID separately, store it
in the omap_dm_timer structure, that is also passed, and access the ID
from this structure.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fce495e..d0c698f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -210,7 +210,6 @@ static u32 __init omap_dm_timer_get_errata(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 **timer_name,
@@ -241,10 +240,10 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
of_node_put(np);
} else {
- if (omap_dm_timer_reserve_systimer(gptimer_id))
+ if (omap_dm_timer_reserve_systimer(timer->id))
return -ENODEV;
- sprintf(name, "timer%d", gptimer_id);
+ sprintf(name, "timer%d", timer->id);
oh_name = name;
}
@@ -317,6 +316,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
+ clkev.id = gptimer_id;
clkev.errata = omap_dm_timer_get_errata();
/*
@@ -326,7 +326,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
*/
__omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
- res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property,
+ res = omap_dm_timer_init_one(&clkev, fck_source, property,
&clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
@@ -446,9 +446,10 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
{
int res;
+ clksrc.id = gptimer_id;
clksrc.errata = omap_dm_timer_get_errata();
- res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, property,
+ res = omap_dm_timer_init_one(&clksrc, fck_source, property,
&clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
BUG_ON(res);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 4/7] ARM: OMAP2+: Simplify system timers definitions
There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function omap4_sync32k_timer_init() can be re-used for OMAP5 devices.
Therefore, consolidate the definitions to simplify the code.
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
Acked-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/common.h |3 +--
arch/arm/mach-omap2/timer.c | 17 -
4 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 6a9529a..7c1ad68 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -297,6 +297,6 @@ MACHINE_START(CM_T3517, "Compulab CM-T3517")
.handle_irq = omap3_intc_handle_irq,
.init_machine = cm_t3517_init,
.init_late = am35xx_init_late,
- .init_time = omap3_gp_gptimer_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.restart= omap3xxx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 2590463..dfd9f48 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -138,7 +138,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened
Device Tree)")
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
- .init_time = omap3_am33xx_gptimer_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.dt_compat = am33xx_boards_compat,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b435027..594ab3b 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -82,8 +82,7 @@ extern void omap2_init_common_infrastructure(void);
extern void omap2_sync32k_timer_init(void);
extern void omap3_sync32k_timer_init(void);
extern void omap3_secure_sync32k_timer_init(void);
-extern void omap3_gp_gptimer_timer_init(void);
-extern void omap3_am33xx_gptimer_timer_init(void);
+extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
extern void omap5_realtime_timer_init(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b4a06c1..3ad9a3b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -569,18 +569,19 @@ OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck",
"ti,timer-alwon",
2, "timer_sys_ck");
OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
2, "timer_sys_ck");
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, "timer_sys_ck", "ti,timer-alwon",
- 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP3 */
-#ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, "timer_sys_ck", "ti,timer-alwon",
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon",
2, "timer_sys_ck");
-#endif /* CONFIG_SOC_AM33XX */
+#endif
-#ifdef CONFIG_ARCH_OMAP4
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
2, "sys_clkin_ck");
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
#ifdef CONFIG_LOCAL_TIMERS
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
void __init omap4_local_timer_init(void)
@@ -609,13 +610,11 @@ void __init omap4_local_timer_init(void)
#endif /* CONFIG_ARCH_OMAP4 */
#ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, "timer_32k_ck", "ti,timer-alwon",
- 2, "sys_clkin_ck");
void __init omap5_realtime_timer_init(void)
{
int err;
- omap5_sync32k_timer_init();
+ omap4_sync32k_timer_init();
realtime_counter_init();
err = arch_timer_of_register();
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 3/7] ARM: OMAP2+: Simplify system timer clock definitions
In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases), new
clock aliases for dmtimers were added to simplify the code. These clock
aliases can also be used when configuring the system timers and allow us
to remove the current definitions, simplifying the code.
Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is
no clock alias for "timer_sys_ck" with NULL as the device name. Therefore
we still need to use the alias "sys_clkin_ck" for these devices.
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer.c | 37 ++---
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c6b3fdd..b4a06c1 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -57,15 +57,6 @@
#include "common.h"
#include "powerdomain.h"
-/* Parent clocks, eventually these will come from the clock framework */
-
-#define OMAP2_MPU_SOURCE "sys_ck"
-#define OMAP3_MPU_SOURCE OMAP2_MPU_SOURCE
-#define OMAP4_MPU_SOURCE "sys_clkin_ck"
-#define OMAP2_32K_SOURCE "func_32k_ck"
-#define OMAP3_32K_SOURCE "omap_32k_fck"
-#define OMAP4_32K_SOURCE "sys_32k_ck"
-
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
@@ -569,27 +560,27 @@ void __init omap##name##_sync32k_timer_init(void)
\
}
#ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, OMAP2_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP2_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP2 */
#ifdef CONFIG_ARCH_OMAP3
-OMAP_SYS_32K_TIMER_INIT(3, 1, OMAP3_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP3_MPU_SOURCE);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, OMAP3_32K_SOURCE, "ti,timer-secure",
- 2, OMAP3_MPU_SOURCE);
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, OMAP3_MPU_SOURCE, "ti,timer-alwon",
- 2, OMAP3_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
+OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
+ 2, "timer_sys_ck");
+OMAP_SYS_GP_TIMER_INIT(3_gp, 1, "timer_sys_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP3 */
#ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, "timer_sys_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_SOC_AM33XX */
#ifdef CONFIG_ARCH_OMAP4
-OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "sys_clkin_ck");
#ifdef CONFIG_LOCAL_TIMERS
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
void __init omap4_local_timer_init(void)
@@ -618,8 +609,8 @@ void __init omap4_local_timer_init(void)
#endif /* CONFIG_ARCH_OMAP4 */
#ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(5, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "sys_clkin_ck");
void __init omap5_realtime_timer_init(void)
{
int err;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/7] ARM: OMAP2+: Remove hard-coded test on timer ID
Currently, when configuring the clock-events and clock-source timers
for OMAP2+ devices, we check whether the timer ID is 12 before
attempting to set the parent clock for the timer.
This test was added for OMAP3 general purpose devices (no security
features enabled) that a 12th timer available but unlike the other
timers only has a single functional clock source. Calling
clk_set_parent() for this 12th timer would always return an error
because there is only one choice for a parent clock. Therefore,
this hard-coded timer ID test was added.
To avoid this timer ID test, simply check to see if the timer's current
parent clock is the desired parent clock and only call clk_set_parent()
if this is not the case.
Also if clk_get() fails, then use PTR_ERR() to return the error code.
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 83118fb..c6b3fdd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -224,6 +224,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;
+ struct clk *src;
int r = 0;
if (of_have_populated_dt()) {
@@ -278,24 +279,24 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
/* After the dmtimer is using hwmod these clocks won't be needed */
timer->fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
if (IS_ERR(timer->fclk))
- return -ENODEV;
+ return PTR_ERR(timer->fclk);
+
+ src = clk_get(NULL, fck_source);
+ if (IS_ERR(src))
+ return PTR_ERR(src);
- /* FIXME: Need to remove hard-coded test on timer ID */
- if (gptimer_id != 12) {
- struct clk *src;
-
- src = clk_get(NULL, fck_source);
- if (IS_ERR(src)) {
- r = -EINVAL;
- } else {
- r = clk_set_parent(timer->fclk, src);
- if (IS_ERR_VALUE(r))
- pr_warn("%s: %s cannot set source\n",
- __func__, oh->name);
+ if (clk_get_parent(timer->fclk) != src) {
+ 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);
+ return r;
}
}
+ clk_put(src);
+
omap_hwmod_setup_one(oh_name);
omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/7] ARM: OMAP2+: System timer updates
This series consists mainly of clean-ups for clockevents and clocksource timers on OMAP2+ devices. The most significant change in functionality comes from the 5th patch which is changing the selection of the clocksource timer for OMAP3 and AM335x devices when gptimers are used for clocksource. This change came about from Vaibhav Bedia's series for AM335x [1]. See patch for more details on the exact nature of the change. Boot tested with and without device-tree on OMAP2420 H4, OMAP3430 SDP, OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only supports device-tree boot). Also boot tested boards with kernel boot parameter "clocksource=gp_timer". This series is based upon ARM-SoC next branch. V3 changes: - Post the intended patches this time! - Use PTR_ERR() to return the error code if clk_get() fails (thanks Russell!) V2 changes: - Fixed bug in patch that updates clocksource and clockevents timer names to use the hwmod timer names (thanks Vaibhav Bedia!) - Updated patch that removes the hard-coded ID test to return an error as soon as clk_set_parent fails instead of waiting for the end of the function. - Fixed bug in patches that "simplify system timer clock definitions" and "simplify system timer definitions" that was prevent omap4/5 boards from booting with kernel boot parameter "clocksource=gp_timer". - Updated changelog for patch "simplify system timer definitions" per feedback received from Igor. - Added new patch to store the timer ID in the omap_dm_timer structure to clean-up the code. - Added new patch to fix a sparse warning seen in ARM-SOC next. [1] https://patchwork.kernel.org/patch/1921421/ Jon Hunter (7): ARM: OMAP2+: Display correct system timer name ARM: OMAP2+: Remove hard-coded test on timer ID ARM: OMAP2+: Simplify system timer clock definitions ARM: OMAP2+: Simplify system timers definitions ARM: OMAP3: Update clocksource timer selection ARM: OMAP2+: Store ID of system timers in timer structure ARM: OMAP4+: Fix sparse warning in system timers arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/common.h |3 +- arch/arm/mach-omap2/timer.c | 121 +- 4 files changed, 65 insertions(+), 63 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/7] ARM: OMAP2+: Display correct system timer name
Currently on boot, when displaying the name of the gptimer used for
clockevents and clocksource timers, the timer ID is shown. However,
when booting with device-tree, the timer ID is not used to select a
gptimer but a timer property. Hence, it is possible that the timer
selected when booting with device-tree does not match the ID shown.
Therefore, instead display the HWMOD name of the gptimer and use
the HWMOD name as the name of clockevent and clocksource timer (if a
gptimer is used).
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 72c2ca1..83118fb 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -129,7 +129,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
static struct clock_event_device clockevent_gpt = {
- .name = "gp_timer",
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
@@ -214,10 +213,11 @@ static u32 __init omap_dm_timer_get_errata(void)
}
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
- int gptimer_id,
- const char *fck_source,
- const char *property,
- int posted)
+int gptimer_id,
+const char *fck_source,
+const char *property,
+const char **timer_name,
+int posted)
{
char name[10]; /* 10 = sizeof("gptXX_Xck0") */
const char *oh_name;
@@ -254,6 +254,8 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!oh)
return -ENODEV;
+ *timer_name = oh->name;
+
if (!of_have_populated_dt()) {
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
&irq);
@@ -327,7 +329,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
__omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property,
-OMAP_TIMER_POSTED);
+&clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
omap2_gp_timer_irq.dev_id = &clkev;
@@ -341,8 +343,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
3, /* Timer internal resynch latency */
0x);
- pr_info("OMAP clockevent source: GPTIMER%d at %lu Hz\n",
- gptimer_id, clkev.rate);
+ pr_info("OMAP clockevent source: %s at %lu Hz\n", clockevent_gpt.name,
+ clkev.rate);
}
/* Clocksource code */
@@ -359,7 +361,6 @@ static cycle_t clocksource_read_cycles(struct clocksource
*cs)
}
static struct clocksource clocksource_gpt = {
- .name = "gp_timer",
.rating = 300,
.read = clocksource_read_cycles,
.mask = CLOCKSOURCE_MASK(32),
@@ -449,6 +450,7 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
clksrc.errata = omap_dm_timer_get_errata();
res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
+&clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
BUG_ON(res);
@@ -461,8 +463,8 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
pr_err("Could not register clocksource %s\n",
clocksource_gpt.name);
else
- pr_info("OMAP clocksource: GPTIMER%d at %lu Hz\n",
- gptimer_id, clksrc.rate);
+ pr_info("OMAP clocksource: %s at %lu Hz\n",
+ clocksource_gpt.name, clksrc.rate);
}
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/04/2013 01:15 PM, Tony Lindgren wrote: > * Jon Hunter [130204 10:49]: >> On 02/04/2013 11:45 AM, Tony Lindgren wrote: >>> >>> AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT >>> pins, so using generic pinconf there makes sense. But this of course should >>> be checked. >> >> Not sure I am a fan of that idea. It is possible the pins could be >> re-used as GPIOs after reset. Given that the state at reset is latched >> in a register, it is best just to read the register directly. > > Yes the physical SYSBOOT pins can be reused as GPIO, but that's are already > handled by the padconf and GPIO registers. This is a different register > showing the boot time pin values for some pins. So it makes sense to use > generic pinconf to make the pin values available to the client drivers > as needed. > > The advantage doing it this way is that we don't need to export any omap > custom functions to the drivers from the SCM driver. This way we need zero > platform glue code, and can deal with it directly in the drivers in a > generic way. And all we need to do is just need to map the SoC specific > SYSBOOT pin register in the .dts files. I see what you are saying exporting the state in control_status register via the pinconf. That could work. > It may also make sense to export DEVICETYPE this way. At least early omaps > had the GP vs HS mode configured by pulls on some pins during the boot time. > So those bits too may reflect actual physical pins during the boot time > configured by the efuse settings? I *believe* that was only omap1. >>>>> Regarding omap_device, we should find a way to keep the dependencies >>>>> between drivers and the bus code down to minimum. So ideally things >>>>> like this would be only done using just the compatible flag. But the >>>>> pdata we cannot remove quite yet. >>>> >>>> Agree. However, there are several drivers today (gpio, dmtimer, mmc, >>>> serial, dss, etc), that make use of a function pointer to >>>> omap_pm_get_dev_context_loss_count() to determine when the peripheral's >>>> state has been lost. When booting with DT this function pointer is not >>>> populated and so with DT we currently have no way to determine this. I >>>> see this as a blocker to migrating completely to DT. Ideally we would >>>> find a way for RPM to handle this and remove the function pointer. >>>> However, right now we still need a generic way to pass this type of >>>> platform data to drivers. >>> >>> Yeah pinconf generic won't help us with the legacy boot. >> >> Right. I view all this sort of thing as system-level device information >> that some drivers may need. It does not seem that we have a good way to >> handle that at the moment. Any ideas? > > I suggest just passing it in in pdata for now for the legacy boot. Then > I suggest we make what we can generic with pinconf in the long run. I don't see why we would want to export a function pointer to omap_pm_get_dev_context_loss_count() with pinconf. Have we got our wires crossed here? 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 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/04/2013 11:45 AM, Tony Lindgren wrote: > * Jon Hunter [130204 07:09]: >> >> On 02/02/2013 12:11 PM, Tony Lindgren wrote: >>> * Jon Hunter [130201 17:25]: >>>> >>>> On 02/01/2013 03:51 PM, Tony Lindgren wrote: >>>>> >>>>> How about let's fix this properly to start with so we don't add >>>>> more blockers moving this code to drivers/bus? >>>>> >>>>> Looks like gpmc_mem_init() gets called from gpmc_probe() so >>>>> we can pass that information in pdev. >>>> >>>> I wondered if you would suggest that ;-) >>> >>> :) >>> >>>> I definitely can and it is probably best. Things like this become >>>> painful when we move to device-tree. We really need a generic way for >>>> passing stuff like this to drivers for omap. Our options are auxdata or >>>> bus notifiers. I am wondering whether we can plug pdata in the >>>> omap_device bus notifier for device-tree. Let me know if you have any >>>> thoughts. >>> >>> Hmm but in this case can't you just do it based on the compatible >>> flag? For legacy systems we also need to pass it in pdata. >> >> This is a boot-time configuration. So really you need to read the >> control status register at boot and then determine the mapping. We could >> store the address of the control status read in the pdata, but I think >> that is a bit of a hack. > > Ah right. Well once we have Haojian's generic pinconf patches merged for > pinctrl-single, we can set up the CONTROL_STATUS register as a > pinctrl-single,bits register and query the SYSBOOT_3 pin value directly > from the driver. > > AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT > pins, so using generic pinconf there makes sense. But this of course should > be checked. Not sure I am a fan of that idea. It is possible the pins could be re-used as GPIOs after reset. Given that the state at reset is latched in a register, it is best just to read the register directly. >>> Regarding omap_device, we should find a way to keep the dependencies >>> between drivers and the bus code down to minimum. So ideally things >>> like this would be only done using just the compatible flag. But the >>> pdata we cannot remove quite yet. >> >> Agree. However, there are several drivers today (gpio, dmtimer, mmc, >> serial, dss, etc), that make use of a function pointer to >> omap_pm_get_dev_context_loss_count() to determine when the peripheral's >> state has been lost. When booting with DT this function pointer is not >> populated and so with DT we currently have no way to determine this. I >> see this as a blocker to migrating completely to DT. Ideally we would >> find a way for RPM to handle this and remove the function pointer. >> However, right now we still need a generic way to pass this type of >> platform data to drivers. > > Yeah pinconf generic won't help us with the legacy boot. Right. I view all this sort of thing as system-level device information that some drivers may need. It does not seem that we have a good way to handle that at the moment. Any ideas? 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 3/7] ARM: OMAP2+: Remove hard-coded test on timer ID
On 02/04/2013 11:46 AM, Russell King - ARM Linux wrote:
> On Mon, Feb 04, 2013 at 11:43:02AM -0600, Jon Hunter wrote:
>> @@ -280,22 +281,22 @@ static int __init omap_dm_timer_init_one(struct
>> omap_dm_timer *timer,
>> if (IS_ERR(timer->fclk))
>> return -ENODEV;
>>
>> -/* FIXME: Need to remove hard-coded test on timer ID */
>> -if (gptimer_id != 12) {
>> -struct clk *src;
>> -
>> -src = clk_get(NULL, fck_source);
>> -if (IS_ERR(src)) {
>> -r = -EINVAL;
>> -} else {
>> -r = clk_set_parent(timer->fclk, src);
>> -if (IS_ERR_VALUE(r))
>> -pr_warn("%s: %s cannot set source\n",
>> -__func__, oh->name);
>> +src = clk_get(NULL, fck_source);
>> +if (IS_ERR(src))
>> +return -EINVAL;
>
> This should be:
> return PTR_ERR(src);
>
> and should've been there previously...
Thanks for the catch. I will include this and resend.
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 0/7] ARM: OMAP2+: System timer updates
On 02/04/2013 11:42 AM, Jon Hunter wrote: > This series consists mainly of clean-ups for clockevents and > clocksource timers on OMAP2+ devices. The most significant change > in functionality comes from the 5th patch which is changing the > selection of the clocksource timer for OMAP3 and AM335x devices > when gptimers are used for clocksource. This change came about from > Vaibhav Bedia's series for AM335x [1]. See patch for more details on > the exact nature of the change. > > Boot tested with and without device-tree on OMAP2420 H4, OMAP3430 SDP, > OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only > supports device-tree boot). Also boot tested boards with kernel boot > parameter "clocksource=gp_timer". > > This series is based upon ARM-SoC next branch. > > V2 changes: > - Fixed bug in patch that updates clocksource and clockevents timer > names to use the hwmod timer names (thanks Vaibhav Bedia!) > - Updated patch that removes the hard-coded ID test to return an error > as soon as clk_set_parent fails instead of waiting for the end of the > function. > - Fixed bug in patches that "simplify system timer clock definitions" > and "simplify system timer definitions" that was prevent omap4/5 > boards from booting with kernel boot parameter "clocksource=gp_timer". > - Updated changelog for patch "simplify system timer definitions" per > feedback received from Igor. > - Added new patch to store the timer ID in the omap_dm_timer structure > to clean-up the code. > - Added new patch to fix a sparse warning seen in ARM-SOC next. > > [1] https://patchwork.kernel.org/patch/1921421/ > > > Jon Hunter (7): > ARM: OMAP2+: Fix selection of clockevent timer when using device-tree Ugh, sorry something got screwed up here. This was not meant to be included and I am missing another patch. Will resend this series. 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 V2 6/7] ARM: OMAP2+: Store ID of system timers in timer structure
Currently, the timer ID is being passed to the function
omap_dm_timer_init_one(). Instead of passing the ID separately, store it
in the omap_dm_timer structure, that is also passed, and access the ID
from this structure.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 1b99b41..c5770ff 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -210,7 +210,6 @@ static u32 __init omap_dm_timer_get_errata(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 **timer_name,
@@ -241,10 +240,10 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
of_node_put(np);
} else {
- if (omap_dm_timer_reserve_systimer(gptimer_id))
+ if (omap_dm_timer_reserve_systimer(timer->id))
return -ENODEV;
- sprintf(name, "timer%d", gptimer_id);
+ sprintf(name, "timer%d", timer->id);
oh_name = name;
}
@@ -317,6 +316,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
+ clkev.id = gptimer_id;
clkev.errata = omap_dm_timer_get_errata();
/*
@@ -326,7 +326,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
*/
__omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
- res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property,
+ res = omap_dm_timer_init_one(&clkev, fck_source, property,
&clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
@@ -446,9 +446,10 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
{
int res;
+ clksrc.id = gptimer_id;
clksrc.errata = omap_dm_timer_get_errata();
- res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, property,
+ res = omap_dm_timer_init_one(&clksrc, fck_source, property,
&clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
BUG_ON(res);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 4/7] ARM: OMAP2+: Simplify system timer clock definitions
In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases), new
clock aliases for dmtimers were added to simplify the code. These clock
aliases can also be used when configuring the system timers and allow us
to remove the current definitions, simplifying the code.
Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is
no clock alias for "timer_sys_ck" with NULL as the device name. Therefore
we still need to use the alias "sys_clkin_ck" for these devices.
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer.c | 37 ++---
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ec2fb80..4213bf4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -57,15 +57,6 @@
#include "common.h"
#include "powerdomain.h"
-/* Parent clocks, eventually these will come from the clock framework */
-
-#define OMAP2_MPU_SOURCE "sys_ck"
-#define OMAP3_MPU_SOURCE OMAP2_MPU_SOURCE
-#define OMAP4_MPU_SOURCE "sys_clkin_ck"
-#define OMAP2_32K_SOURCE "func_32k_ck"
-#define OMAP3_32K_SOURCE "omap_32k_fck"
-#define OMAP4_32K_SOURCE "sys_32k_ck"
-
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
@@ -569,27 +560,27 @@ void __init omap##name##_sync32k_timer_init(void)
\
}
#ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, OMAP2_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP2_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP2 */
#ifdef CONFIG_ARCH_OMAP3
-OMAP_SYS_32K_TIMER_INIT(3, 1, OMAP3_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP3_MPU_SOURCE);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, OMAP3_32K_SOURCE, "ti,timer-secure",
- 2, OMAP3_MPU_SOURCE);
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, OMAP3_MPU_SOURCE, "ti,timer-alwon",
- 2, OMAP3_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
+OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
+ 2, "timer_sys_ck");
+OMAP_SYS_GP_TIMER_INIT(3_gp, 1, "timer_sys_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP3 */
#ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, "timer_sys_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_SOC_AM33XX */
#ifdef CONFIG_ARCH_OMAP4
-OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "sys_clkin_ck");
#ifdef CONFIG_LOCAL_TIMERS
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
void __init omap4_local_timer_init(void)
@@ -618,8 +609,8 @@ void __init omap4_local_timer_init(void)
#endif /* CONFIG_ARCH_OMAP4 */
#ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(5, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "sys_clkin_ck");
void __init omap5_realtime_timer_init(void)
{
int err;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 7/7] ARM: OMAP4+: Fix sparse warning in system timers
Commit 6bb27d7 (ARM: delete struct sys_timer) changed the function created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void. For OMAP4+ devices this created the following sparse warning ... arch/arm/mach-omap2/timer.c:585:1: warning: symbol 'omap4_sync32k_timer_init' was not declared. Should it be static? The function omap4_sync32k_timer_init() is not referenced outside of the file timer.c and so make this function static. Signed-off-by: Jon Hunter --- arch/arm/mach-omap2/timer.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index c5770ff..a5f88b2 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -587,8 +587,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, #endif #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) -OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon", - 2, "sys_clkin_ck", NULL); +static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon", + 2, "sys_clkin_ck", NULL); #endif #ifdef CONFIG_ARCH_OMAP4 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 5/7] ARM: OMAP2+: Simplify system timers definitions
There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function omap4_sync32k_timer_init() can be re-used for OMAP5 devices.
Therefore, consolidate the definitions to simplify the code.
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
Acked-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/common.h |3 +--
arch/arm/mach-omap2/timer.c | 48 --
4 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 6a9529a..7c1ad68 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -297,6 +297,6 @@ MACHINE_START(CM_T3517, "Compulab CM-T3517")
.handle_irq = omap3_intc_handle_irq,
.init_machine = cm_t3517_init,
.init_late = am35xx_init_late,
- .init_time = omap3_gp_gptimer_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.restart= omap3xxx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 2590463..dfd9f48 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -138,7 +138,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened
Device Tree)")
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
- .init_time = omap3_am33xx_gptimer_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.dt_compat = am33xx_boards_compat,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b435027..594ab3b 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -82,8 +82,7 @@ extern void omap2_init_common_infrastructure(void);
extern void omap2_sync32k_timer_init(void);
extern void omap3_sync32k_timer_init(void);
extern void omap3_secure_sync32k_timer_init(void);
-extern void omap3_gp_gptimer_timer_init(void);
-extern void omap3_am33xx_gptimer_timer_init(void);
+extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
extern void omap5_realtime_timer_init(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4213bf4..1b99b41 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -160,6 +160,12 @@ static struct device_node * __init
omap_get_timer_dt(struct of_device_id *match,
if (property && !of_get_property(np, property, NULL))
continue;
+ if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
+ of_get_property(np, "ti,timer-dsp", NULL) ||
+ of_get_property(np, "ti,timer-pwm", NULL) ||
+ of_get_property(np, "ti,timer-secure", NULL)))
+ continue;
+
of_add_property(np, &device_disabled);
return np;
}
@@ -435,13 +441,14 @@ static int __init __maybe_unused
omap2_sync32k_clocksource_init(void)
}
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+ const char *fck_source,
+ const char *property)
{
int res;
clksrc.errata = omap_dm_timer_get_errata();
- res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
+ res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, property,
&clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
BUG_ON(res);
@@ -538,49 +545,52 @@ static inline void __init realtime_counter_init(void)
#endif
#define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
- clksrc_nr, clksrc_src) \
+ clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
- omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src);\
+ omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
+ clksr
[PATCH V2 2/7] ARM: OMAP2+: Display correct system timer name
Currently on boot, when displaying the name of the gptimer used for
clockevents and clocksource timers, the timer ID is shown. However,
when booting with device-tree, the timer ID is not used to select a
gptimer but a timer property. Hence, it is possible that the timer
selected when booting with device-tree does not match the ID shown.
Therefore, instead display the HWMOD name of the gptimer and use
the HWMOD name as the name of clockevent and clocksource timer (if a
gptimer is used).
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 72c2ca1..83118fb 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -129,7 +129,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
static struct clock_event_device clockevent_gpt = {
- .name = "gp_timer",
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
@@ -214,10 +213,11 @@ static u32 __init omap_dm_timer_get_errata(void)
}
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
- int gptimer_id,
- const char *fck_source,
- const char *property,
- int posted)
+int gptimer_id,
+const char *fck_source,
+const char *property,
+const char **timer_name,
+int posted)
{
char name[10]; /* 10 = sizeof("gptXX_Xck0") */
const char *oh_name;
@@ -254,6 +254,8 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!oh)
return -ENODEV;
+ *timer_name = oh->name;
+
if (!of_have_populated_dt()) {
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
&irq);
@@ -327,7 +329,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
__omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property,
-OMAP_TIMER_POSTED);
+&clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
omap2_gp_timer_irq.dev_id = &clkev;
@@ -341,8 +343,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
3, /* Timer internal resynch latency */
0x);
- pr_info("OMAP clockevent source: GPTIMER%d at %lu Hz\n",
- gptimer_id, clkev.rate);
+ pr_info("OMAP clockevent source: %s at %lu Hz\n", clockevent_gpt.name,
+ clkev.rate);
}
/* Clocksource code */
@@ -359,7 +361,6 @@ static cycle_t clocksource_read_cycles(struct clocksource
*cs)
}
static struct clocksource clocksource_gpt = {
- .name = "gp_timer",
.rating = 300,
.read = clocksource_read_cycles,
.mask = CLOCKSOURCE_MASK(32),
@@ -449,6 +450,7 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
clksrc.errata = omap_dm_timer_get_errata();
res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
+&clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
BUG_ON(res);
@@ -461,8 +463,8 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
pr_err("Could not register clocksource %s\n",
clocksource_gpt.name);
else
- pr_info("OMAP clocksource: GPTIMER%d at %lu Hz\n",
- gptimer_id, clksrc.rate);
+ pr_info("OMAP clocksource: %s at %lu Hz\n",
+ clocksource_gpt.name, clksrc.rate);
}
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/7] ARM: OMAP2+: Remove hard-coded test on timer ID
Currently, when configuring the clock-events and clock-source timers
for OMAP2+ devices, we check whether the timer ID is 12 before
attempting to set the parent clock for the timer.
This test was added for OMAP3 general purpose devices (no security
features enabled) that a 12th timer available but unlike the other
timers only has a single functional clock source. Calling
clk_set_parent() for this 12th timer would always return an error
because there is only one choice for a parent clock. Therefore,
this hard-coded timer ID test was added.
To avoid this timer ID test, simply check to see if the timer's current
parent clock is the desired parent clock and only call clk_set_parent()
if this is not the case.
Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 83118fb..ec2fb80 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -224,6 +224,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;
+ struct clk *src;
int r = 0;
if (of_have_populated_dt()) {
@@ -280,22 +281,22 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(timer->fclk))
return -ENODEV;
- /* FIXME: Need to remove hard-coded test on timer ID */
- if (gptimer_id != 12) {
- struct clk *src;
-
- src = clk_get(NULL, fck_source);
- if (IS_ERR(src)) {
- r = -EINVAL;
- } else {
- r = clk_set_parent(timer->fclk, src);
- if (IS_ERR_VALUE(r))
- pr_warn("%s: %s cannot set source\n",
- __func__, oh->name);
+ src = clk_get(NULL, fck_source);
+ if (IS_ERR(src))
+ return -EINVAL;
+
+ if (clk_get_parent(timer->fclk) != src) {
+ 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);
+ return r;
}
}
+ clk_put(src);
+
omap_hwmod_setup_one(oh_name);
omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/7] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
device-tree support for selecting a clockevent timer by property.
However, the code is currently ignoring the property passed and
selecting the first available timer found. Hence, for the OMAP3 beagle
board timer-12 is not being selected as expected. Fix this problem
by ensuring the timer property is passed to omap_get_timer_dt().
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2822833..72c2ca1 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -227,7 +227,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
int r = 0;
if (of_have_populated_dt()) {
- np = omap_get_timer_dt(omap_timer_match, NULL);
+ np = omap_get_timer_dt(omap_timer_match, property);
if (!np)
return -ENODEV;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/7] ARM: OMAP2+: System timer updates
This series consists mainly of clean-ups for clockevents and clocksource timers on OMAP2+ devices. The most significant change in functionality comes from the 5th patch which is changing the selection of the clocksource timer for OMAP3 and AM335x devices when gptimers are used for clocksource. This change came about from Vaibhav Bedia's series for AM335x [1]. See patch for more details on the exact nature of the change. Boot tested with and without device-tree on OMAP2420 H4, OMAP3430 SDP, OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only supports device-tree boot). Also boot tested boards with kernel boot parameter "clocksource=gp_timer". This series is based upon ARM-SoC next branch. V2 changes: - Fixed bug in patch that updates clocksource and clockevents timer names to use the hwmod timer names (thanks Vaibhav Bedia!) - Updated patch that removes the hard-coded ID test to return an error as soon as clk_set_parent fails instead of waiting for the end of the function. - Fixed bug in patches that "simplify system timer clock definitions" and "simplify system timer definitions" that was prevent omap4/5 boards from booting with kernel boot parameter "clocksource=gp_timer". - Updated changelog for patch "simplify system timer definitions" per feedback received from Igor. - Added new patch to store the timer ID in the omap_dm_timer structure to clean-up the code. - Added new patch to fix a sparse warning seen in ARM-SOC next. [1] https://patchwork.kernel.org/patch/1921421/ Jon Hunter (7): ARM: OMAP2+: Fix selection of clockevent timer when using device-tree ARM: OMAP2+: Display correct system timer name ARM: OMAP2+: Remove hard-coded test on timer ID ARM: OMAP2+: Simplify system timer clock definitions ARM: OMAP2+: Simplify system timers definitions ARM: OMAP2+: Store ID of system timers in timer structure ARM: OMAP4+: Fix sparse warning in system timers arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/common.h |3 +- arch/arm/mach-omap2/timer.c | 121 +- 4 files changed, 65 insertions(+), 63 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: OMAP2+: Simplify system timers definitions
On 01/30/2013 11:04 AM, Jon Hunter wrote: > There is a lot of redundancy in the definitions for the various system > timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init() > function is the same as the omap3_gp_gptimer_timer_init() function and the > function omap2_sync32k_timer_init() can be re-used for OMAP4/5 devices. After further testing, I have found that using the omap2_sync32k_timer_init() for omap4/5 devices does not work for the case where we boot with boot parameter "clocksource=gp_timer". The problem is omap4/5 devices, unlike omap2/3 devices, does not have a clock alias for "timer_sys_ck" with NULL as the device name. Therefore we fail to find the parent clock and boot fails. So I am going to update this patch so that omap4 and omap5 both use omap4_sync32k_timer_init() and just get rid of the extra function defined for omap5. Hope this makes sense. 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 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/02/2013 12:11 PM, Tony Lindgren wrote: > * Jon Hunter [130201 17:25]: >> >> On 02/01/2013 03:51 PM, Tony Lindgren wrote: >>> >>> How about let's fix this properly to start with so we don't add >>> more blockers moving this code to drivers/bus? >>> >>> Looks like gpmc_mem_init() gets called from gpmc_probe() so >>> we can pass that information in pdev. >> >> I wondered if you would suggest that ;-) > > :) > >> I definitely can and it is probably best. Things like this become >> painful when we move to device-tree. We really need a generic way for >> passing stuff like this to drivers for omap. Our options are auxdata or >> bus notifiers. I am wondering whether we can plug pdata in the >> omap_device bus notifier for device-tree. Let me know if you have any >> thoughts. > > Hmm but in this case can't you just do it based on the compatible > flag? For legacy systems we also need to pass it in pdata. This is a boot-time configuration. So really you need to read the control status register at boot and then determine the mapping. We could store the address of the control status read in the pdata, but I think that is a bit of a hack. > Regarding omap_device, we should find a way to keep the dependencies > between drivers and the bus code down to minimum. So ideally things > like this would be only done using just the compatible flag. But the > pdata we cannot remove quite yet. Agree. However, there are several drivers today (gpio, dmtimer, mmc, serial, dss, etc), that make use of a function pointer to omap_pm_get_dev_context_loss_count() to determine when the peripheral's state has been lost. When booting with DT this function pointer is not populated and so with DT we currently have no way to determine this. I see this as a blocker to migrating completely to DT. Ideally we would find a way for RPM to handle this and remove the function pointer. However, right now we still need a generic way to pass this type of platform data to drivers. 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 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
> Hi Jon,
>
> * Jon Hunter [130201 08:42]:
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -32,6 +32,7 @@
>>
>> #include "soc.h"
>> #include "common.h"
>> +#include "control.h"
>> #include "omap_device.h"
>> #include "gpmc.h"
>>
>> @@ -778,18 +779,26 @@ static void gpmc_mem_exit(void)
>> static int gpmc_mem_init(void)
>> {
>> int cs, rc;
>> -unsigned long boot_rom_space = 0;
>>
>> -/* never allocate the first page, to facilitate bug detection;
>> - * even if we didn't boot from ROM.
>> +/*
>> + * The first 1MB of GPMC address space is mapped to the
>> + * internal ROM. OMAP2 devices are an exception to this
>> + * where the first 1MB may be mapped to the GPMC.
>> */
>> -boot_rom_space = BOOT_ROM_SPACE;
>> -/* In apollon the CS0 is mapped as 0x */
>> -if (machine_is_omap_apollon())
>> -boot_rom_space = 0;
>
> This part is going away anyways with the patch dropping apollon
> board support from Kyungin.
Yes just saw that today.
>> -gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
>> +gpmc_mem_root.start = GPMC_MEM_START + BOOT_ROM_SPACE;
>> gpmc_mem_root.end = GPMC_MEM_END;
>>
>> +/*
>> + * OMAP2 devices that boot from external memory devices, will
>> + * map CS0 to the start of the GPMC address space (0x0). We can
>> + * test this by checking if SYS_BOOT3 pin is set. If not set
>> + * then CS0 is mapped to 0x0.
>> + */
>> +if (cpu_is_omap24xx())
>> +if (!(omap_ctrl_readl(OMAP24XX_CONTROL_STATUS) &
>> + OMAP2_SYSBOOT_3_MASK))
>> +gpmc_mem_root.start = GPMC_MEM_START;
>> +
>> /* Reserve all regions that has been set up by bootloader */
>> for (cs = 0; cs < GPMC_CS_NUM; cs++) {
>> u32 base, size;
>
> How about let's fix this properly to start with so we don't add
> more blockers moving this code to drivers/bus?
>
> Looks like gpmc_mem_init() gets called from gpmc_probe() so
> we can pass that information in pdev.
I wondered if you would suggest that ;-)
I definitely can and it is probably best. Things like this become
painful when we move to device-tree. We really need a generic way for
passing stuff like this to drivers for omap. Our options are auxdata or
bus notifiers. I am wondering whether we can plug pdata in the
omap_device bus notifier for device-tree. Let me know if you have any
thoughts.
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: DT GPMC SRAM and NOR flash support ?
Hi Mark, On 02/01/2013 10:56 AM, Mark Jackson wrote: > There's plenty of DT support going in for NAND flash, but is there any work > going on to support NOR > flash ? What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need. > And how about SRAM chips or other memory mapped devices ? Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be 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
[PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
OMAP2+ devices have an internal ROM that by default is typically mapped
to the first 1MB of the GPMC address space (0x0).
For OMAP24xx devices, GPMC chip-select 0 (CS0) may be mapped to address
0x0 instead of the internal ROM if configured for an external boot mode.
If configured for an internal boot mode then the internal ROM is mapped
to 0x0.
Currently, the function gpmc_mem_init() function reserves the first 1MB
of GPMC address space for the internal OMAP ROM with the exception of
the OMAP2 APOLLON board. This prevents any device (ethernet chip, flash
memories, etc) from using this address range. This causes the GPMC probe
to fail on the OMAP2420 H4 when NOR flash is mapped to address 0x0. Fix
this by testing the boot mode for OMAP24xx devices to see if the
SYS_BOOT3 is low, indicating an external boot, and thus GPMC CS0 is
mapped to 0x0.
Please note that for OMAP3-5 devices, when booting from NOR or NAND
memories connected to CS0, these memories are always mapped to address
0x0800 and so reserving this memory range does not present any
problems for these devices.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 441cc63..9486b8e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -32,6 +32,7 @@
#include "soc.h"
#include "common.h"
+#include "control.h"
#include "omap_device.h"
#include "gpmc.h"
@@ -778,18 +779,26 @@ static void gpmc_mem_exit(void)
static int gpmc_mem_init(void)
{
int cs, rc;
- unsigned long boot_rom_space = 0;
- /* never allocate the first page, to facilitate bug detection;
-* even if we didn't boot from ROM.
+ /*
+* The first 1MB of GPMC address space is mapped to the
+* internal ROM. OMAP2 devices are an exception to this
+* where the first 1MB may be mapped to the GPMC.
*/
- boot_rom_space = BOOT_ROM_SPACE;
- /* In apollon the CS0 is mapped as 0x */
- if (machine_is_omap_apollon())
- boot_rom_space = 0;
- gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
+ gpmc_mem_root.start = GPMC_MEM_START + BOOT_ROM_SPACE;
gpmc_mem_root.end = GPMC_MEM_END;
+ /*
+* OMAP2 devices that boot from external memory devices, will
+* map CS0 to the start of the GPMC address space (0x0). We can
+* test this by checking if SYS_BOOT3 pin is set. If not set
+* then CS0 is mapped to 0x0.
+*/
+ if (cpu_is_omap24xx())
+ if (!(omap_ctrl_readl(OMAP24XX_CONTROL_STATUS) &
+ OMAP2_SYSBOOT_3_MASK))
+ gpmc_mem_root.start = GPMC_MEM_START;
+
/* Reserve all regions that has been set up by bootloader */
for (cs = 0; cs < GPMC_CS_NUM; cs++) {
u32 base, size;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP2+: GPMC Fixes
A couple GPMC fixes for OMAP2+ devices which were causing boot problems on OMAP2420 H4. Please note that long term we need to remove the cpu_is_omap24xx() from the gpmc driver and pass the gpmc_mem_root information via platform data and figure out a way to pass this information for device tree. Boot tested on OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP and AM335x EVM. Jon Hunter (2): ARM: OMAP2+: Prevent potential crash if GPMC probe fails ARM: OMAP2: Fix GPMC memory initialisation arch/arm/mach-omap2/gpmc.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails
If the GPMC probe fails, devices that use the GPMC (such as ethernet chips, flash memories, etc) can still allocate a GPMC chip-select and register the device. On the OMAP2420 H4 board, this was causing the kernel to crash after the gpmc probe failed and the board attempted to start networking. Prevent this by marking all the chip-selects as reserved by default and only make them available for devices to request if the GPMC probe succeeds. Signed-off-by: Jon Hunter --- arch/arm/mach-omap2/gpmc.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 8033cb7..441cc63 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -145,7 +145,8 @@ static unsigned gpmc_irq_start; static struct resource gpmc_mem_root; static struct resource gpmc_cs_mem[GPMC_CS_NUM]; static DEFINE_SPINLOCK(gpmc_mem_lock); -static unsigned int gpmc_cs_map; /* flag for cs which are initialized */ +/* Define chip-selects as reserved by default until probe completes */ +static unsigned int gpmc_cs_map = ((1 << GPMC_CS_NUM) - 1); static struct device *gpmc_dev; static int gpmc_irq; static resource_size_t phys_base, mem_size; @@ -1174,6 +1175,9 @@ static int gpmc_probe(struct platform_device *pdev) if (IS_ERR_VALUE(gpmc_setup_irq())) dev_warn(gpmc_dev, "gpmc_setup_irq failed\n"); + /* Now the GPMC is initialised, unreserve the chip-selects */ + gpmc_cs_map = 0; + return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: OMAP2+: Display correct system timer name
On 02/01/2013 03:31 AM, Bedia, Vaibhav wrote: > On Fri, Feb 01, 2013 at 14:23:43, Hunter, Jon wrote: > [...] +/* Timer name needs to be big enough to store a string of "timerXX" */ +static char timer_name[10]; + >>> >>> Why not move this inside omap_dm_timer_init_one()? >> >> In the non-DT case, the name member of the clocksource/event struct will >> point to this array and so it needs to reside in memory permanently and >> not just temporary. Once we migrate completely to DT then we will be >> able to remove this completely. See following snippet ... >> >> -sprintf(name, "timer%d", gptimer_id); >> -oh_name = name; >> +sprintf(timer_name, "timer%d", gptimer_id); >> +*name = timer_name; > > Ok. But in case of non-DT boot if someone selects gptimers for both clkevt and > clksrc, both the name members will end up pointing to the same memory > location. > To be specific, in the current code the clkevt timer name will point to the > clksrc > name. This won't be noticeable during boot since the clkevt name gets printed > before it is over-written. Yes you are right! Good catch. Will fix that. 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 5/5] ARM: OMAP3: Update clocksource timer selection
On 02/01/2013 02:59 AM, Jon Hunter wrote: > > On 02/01/2013 02:41 AM, Bedia, Vaibhav wrote: >> Hi Jon, >> >> On Wed, Jan 30, 2013 at 22:34:31, Hunter, Jon wrote: >>> When booting with device-tree for OMAP3 and AM335x devices and a gptimer >>> is used as the clocksource (which is always the case for AM335x), a >>> gptimer located in a power domain that is not always-on is selected. >>> Ideally we should use a gptimer located in a power domain that is always >>> on (such as the wake-up domain) so that time can be maintained during a >>> kernel suspend without keeping on additional power domains unnecessarily. >>> >>> In order to fix this so that we can select a gptimer located in a power >>> domain that is always-on, the following changes were made ... >>> 1. Currently, only when selecting a gptimer to use for a clockevent >>>timer, do we pass a timer property that can be used to select a >>>specific gptimer. Change this so that we can pass a property when >>>selecting a gptimer to use for a clocksource timer too. >>> 2. Currently, when selecting either a gptimer to use for a clockevent >>>timer or a clocksource timer and no timer property is passed, then >>>the first available timer is selected regardless of the properties >>>it has. Change this so that if no properties are passed, then a timer >>>that does not have additional features (such as always-on, dsp-irq, >>>pwm, and secure) is selected. >>> >>> Please note that using a gptimer for both clocksource and clockevents >>> can have a system power impact during idle. The reason being is that >>> OMAP and AMxxx devices typically only have one gptimer in a power domain >>> that is always-on. Therefore when the kernel is idle both the clocksource >>> and clockevent timers will be active and this will keep additional power >>> domains on. During kernel suspend, only the clocksource timer is active >>> and therefore, it is better to use a gptimer in a power domain that is >>> always-on for clocksource. >>> >> >> It's always a pleasure reading the changelog in your patches :) > > Thanks. > >> [...] >>> >>> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) >>> -OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon", >>> - 2, "timer_sys_ck"); >>> +OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, >>> + 1, "timer_sys_ck", "ti,timer-alwon"); >>> #endif >>> >> >> Minor point... was the intention of changing of clkev_nr and clksrc_nr to >> make >> it consistent with what happens on AM33xx which is DT-only? > > I don't see this as being DT specific. It is more of a policy change to > ensure a wake-up domain timer is used for clocksource when we are using > gptimers for both clocksource and clockevents. It was your patch for > AM335x that made me see the need for this, if that makes sense. May be I > should have referenced that in the changelog. Sorry to be clear, I don't see the policy change as DT specific. In answer to your question, yes clkev_nr and clksrc_nr are changed so the policy it is consistent regardless of whether you use DT or not. In other words, an OMAP3 board using a gptimer for clocksource (such as cm-t3517) and does not use DT, would work the same as AM335x with 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 5/5] ARM: OMAP3: Update clocksource timer selection
On 02/01/2013 02:41 AM, Bedia, Vaibhav wrote: > Hi Jon, > > On Wed, Jan 30, 2013 at 22:34:31, Hunter, Jon wrote: >> When booting with device-tree for OMAP3 and AM335x devices and a gptimer >> is used as the clocksource (which is always the case for AM335x), a >> gptimer located in a power domain that is not always-on is selected. >> Ideally we should use a gptimer located in a power domain that is always >> on (such as the wake-up domain) so that time can be maintained during a >> kernel suspend without keeping on additional power domains unnecessarily. >> >> In order to fix this so that we can select a gptimer located in a power >> domain that is always-on, the following changes were made ... >> 1. Currently, only when selecting a gptimer to use for a clockevent >>timer, do we pass a timer property that can be used to select a >>specific gptimer. Change this so that we can pass a property when >>selecting a gptimer to use for a clocksource timer too. >> 2. Currently, when selecting either a gptimer to use for a clockevent >>timer or a clocksource timer and no timer property is passed, then >>the first available timer is selected regardless of the properties >>it has. Change this so that if no properties are passed, then a timer >>that does not have additional features (such as always-on, dsp-irq, >>pwm, and secure) is selected. >> >> Please note that using a gptimer for both clocksource and clockevents >> can have a system power impact during idle. The reason being is that >> OMAP and AMxxx devices typically only have one gptimer in a power domain >> that is always-on. Therefore when the kernel is idle both the clocksource >> and clockevent timers will be active and this will keep additional power >> domains on. During kernel suspend, only the clocksource timer is active >> and therefore, it is better to use a gptimer in a power domain that is >> always-on for clocksource. >> > > It's always a pleasure reading the changelog in your patches :) Thanks. > [...] >> >> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) >> -OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon", >> - 2, "timer_sys_ck"); >> +OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, >> + 1, "timer_sys_ck", "ti,timer-alwon"); >> #endif >> > > Minor point... was the intention of changing of clkev_nr and clksrc_nr to make > it consistent with what happens on AM33xx which is DT-only? I don't see this as being DT specific. It is more of a policy change to ensure a wake-up domain timer is used for clocksource when we are using gptimers for both clocksource and clockevents. It was your patch for AM335x that made me see the need for this, if that makes sense. May be I should have referenced that in the changelog. 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/5] ARM: OMAP2+: Display correct system timer name
Hi Vaibhav, On 02/01/2013 02:41 AM, Bedia, Vaibhav wrote: > Hi Jon, > > On Wed, Jan 30, 2013 at 22:34:27, Hunter, Jon wrote: >> Currently on boot, when displaying the name of the gptimer used for >> clockevents and clocksource timers, the timer ID is shown. However, >> when booting with device-tree, the timer ID is not used to select a >> gptimer but a timer property. Hence, it is possible that the timer >> selected when booting with device-tree does not match the ID shown. >> Therefore, instead display the HWMOD name of the gptimer and use >> the HWMOD name as the name of clockevent and clocksource timer (if a >> gptimer is used).no >> >> Signed-off-by: Jon Hunter >> --- >> arch/arm/mach-omap2/timer.c | 44 >> +-- >> 1 file changed, 22 insertions(+), 22 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c >> index 72c2ca1..18cb856 100644 >> --- a/arch/arm/mach-omap2/timer.c >> +++ b/arch/arm/mach-omap2/timer.c >> @@ -71,6 +71,9 @@ >> #define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14 >> #define NUMERATOR_DENUMERATOR_MASK 0xf000 >> >> +/* Timer name needs to be big enough to store a string of "timerXX" */ >> +static char timer_name[10]; >> + > > Why not move this inside omap_dm_timer_init_one()? In the non-DT case, the name member of the clocksource/event struct will point to this array and so it needs to reside in memory permanently and not just temporary. Once we migrate completely to DT then we will be able to remove this completely. See following snippet ... - sprintf(name, "timer%d", gptimer_id); - oh_name = name; + sprintf(timer_name, "timer%d", gptimer_id); + *name = timer_name; 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 5/5] ARM: OMAP3: Update clocksource timer selection
On 01/31/2013 03:08 AM, Igor Grinberg wrote: > On 01/30/13 19:04, Jon Hunter wrote: >> When booting with device-tree for OMAP3 and AM335x devices and a gptimer >> is used as the clocksource (which is always the case for AM335x), a >> gptimer located in a power domain that is not always-on is selected. >> Ideally we should use a gptimer located in a power domain that is always >> on (such as the wake-up domain) so that time can be maintained during a >> kernel suspend without keeping on additional power domains unnecessarily. >> >> In order to fix this so that we can select a gptimer located in a power >> domain that is always-on, the following changes were made ... >> 1. Currently, only when selecting a gptimer to use for a clockevent >>timer, do we pass a timer property that can be used to select a >>specific gptimer. Change this so that we can pass a property when >>selecting a gptimer to use for a clocksource timer too. >> 2. Currently, when selecting either a gptimer to use for a clockevent >>timer or a clocksource timer and no timer property is passed, then >>the first available timer is selected regardless of the properties >>it has. Change this so that if no properties are passed, then a timer >>that does not have additional features (such as always-on, dsp-irq, >>pwm, and secure) is selected. >> >> Please note that using a gptimer for both clocksource and clockevents >> can have a system power impact during idle. The reason being is that >> OMAP and AMxxx devices typically only have one gptimer in a power domain >> that is always-on. Therefore when the kernel is idle both the clocksource >> and clockevent timers will be active and this will keep additional power >> domains on. During kernel suspend, only the clocksource timer is active >> and therefore, it is better to use a gptimer in a power domain that is >> always-on for clocksource. > > This should explain the gptimer number switch in the > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) > section below, right? > I would really like to see that clearly stated in the commit message. > For instance: > ... it is better to use a gptimer in a power domain that is > always-on for clocksource. Therefore we switch to use the first gptimer > for clocksource and the second for clockevents. Yes exactly. Good point I can make that bit explicit. >> >> Signed-off-by: Jon Hunter > > Apart from above, > Acked-by: Igor Grinberg 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+: Fix selection of clockevent timer when using device-tree
On 01/30/2013 01:18 AM, Bedia, Vaibhav wrote: > On Wed, Jan 30, 2013 at 01:53:11, Hunter, Jon wrote: >> Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added >> device-tree support for selecting a clockevent timer by property. >> However, the code is currently ignoring the property passed and >> selecting the first available timer found. Hence, for the OMAP3 beagle >> board timer-12 is not being selected as expected. Fix this problem >> by ensuring the timer property is passed to omap_get_timer_dt(). > > I thought that was intentional ;) and had this change in the clkevt-clksrc > interchange patch for AM33xx. No definitely was not. Thanks, I had missed that detail in the patch you sent! > Anyways, this change works for me so... > > Tested-by: Vaibhav Bedia 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: [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
On 01/30/2013 11:48 AM, Jon Hunter wrote: > > On 01/24/2013 04:30 PM, Jon Hunter wrote: >> Hi Vaibhav, >> >> On 12/31/2012 07:07 AM, Vaibhav Bedia wrote: >>> AM33XX has two timers (DTIMER0/1) in the WKUP domain. >>> On GP devices the source of DMTIMER0 is fixed to an >>> inaccurate internal 32k RC oscillator and this makes >>> the DMTIMER0 practically either as a clocksource or >>> as clockevent. >>> >>> Currently the timer instance in WKUP domain is used >>> as the clockevent and the timer in non-WKUP domain >>> as the clocksource. DMTIMER1 in WKUP domain can keep >>> running in suspend from a 32K clock fed from external >>> OSC and can serve as the persistent clock for the kernel. >>> To enable this, interchange the timers used as clocksource >>> and clockevent for AM33XX. >> >> I have been thinking about this some more. In the case where we are >> using gptimers for both clock-events and clock-source (on both AM33xx >> and OMAP) and I am wondering if it makes sense to switch the timers so >> that we use the always-on timer for clock-source and a different one >> from clock-events. >> >> For OMAP, if we are not using the 32k-sync for clock-source, then we are >> never going to achieve low power states during idle as we will always >> have one gptimer running. And in this case, to your point below, it >> would be better to use the always-on for clock-source so that in suspend >> we can at least hit low power states and maintain time. > > I have posted a patch today [1] that I hope will address this issue for > you. Can you give that a try? By the way, this need to be applied on top of the fix I sent yesterday to pass the property. 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: [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
On 01/24/2013 04:30 PM, Jon Hunter wrote: > Hi Vaibhav, > > On 12/31/2012 07:07 AM, Vaibhav Bedia wrote: >> AM33XX has two timers (DTIMER0/1) in the WKUP domain. >> On GP devices the source of DMTIMER0 is fixed to an >> inaccurate internal 32k RC oscillator and this makes >> the DMTIMER0 practically either as a clocksource or >> as clockevent. >> >> Currently the timer instance in WKUP domain is used >> as the clockevent and the timer in non-WKUP domain >> as the clocksource. DMTIMER1 in WKUP domain can keep >> running in suspend from a 32K clock fed from external >> OSC and can serve as the persistent clock for the kernel. >> To enable this, interchange the timers used as clocksource >> and clockevent for AM33XX. > > I have been thinking about this some more. In the case where we are > using gptimers for both clock-events and clock-source (on both AM33xx > and OMAP) and I am wondering if it makes sense to switch the timers so > that we use the always-on timer for clock-source and a different one > from clock-events. > > For OMAP, if we are not using the 32k-sync for clock-source, then we are > never going to achieve low power states during idle as we will always > have one gptimer running. And in this case, to your point below, it > would be better to use the always-on for clock-source so that in suspend > we can at least hit low power states and maintain time. I have posted a patch today [1] that I hope will address this issue for you. Can you give that a try? Cheers Jon [1] http://www.spinics.net/lists/arm-kernel/msg221265.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On 01/21/2013 01:22 AM, Bedia, Vaibhav wrote:
> On Fri, Jan 18, 2013 at 10:55:43, Shilimkar, Santosh wrote:
>> On Friday 18 January 2013 12:15 AM, Jon Hunter wrote:
>>>
>>> On 01/10/2013 10:37 PM, Bedia, Vaibhav wrote:
>>>> On Tue, Jan 08, 2013 at 20:45:10, Shilimkar, Santosh wrote:
>>>>> On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
>>>>>> The current OMAP timer code registers two timers -
>>>>>> one as clocksource and one as clockevent.
>>>>>> AM33XX has only one usable timer in the WKUP domain
>>>>>> so one of the timers needs suspend-resume support
>>>>>> to restore the configuration to pre-suspend state.
>>>>>>
>>>>>> commit adc78e6 (timekeeping: Add suspend and resume
>>>>>> of clock event devices) introduced .suspend and .resume
>>>>>> callbacks for clock event devices. Leverages these
>>>>>> callbacks to have AM33XX clockevent timer which is
>>>>>> in not in WKUP domain to behave properly across system
>>>>>> suspend.
>>>>>>
>>>>>> Signed-off-by: Vaibhav Bedia
>>>>>> Cc: Santosh Shilimkar
>>>>>> Cc: Benoit Cousson
>>>>>> Cc: Paul Walmsley
>>>>>> Cc: Kevin Hilman
>>>>>> Cc: Vaibhav Hiremath
>>>>>> Cc: Jon Hunter
>>>>>> ---
>>>>>> v1->v2:
>>>>>> Get rid of harcoded timer id.
>>>>>> Note: since a platform device is not created for these timer
>>>>>> instances and because there's very minimal change needed for
>>>>>> restarting the timer a full blown context save and restore
>>>>>> has been skipped.
>>>>>>
>>>>>>arch/arm/mach-omap2/timer.c | 33 +
>>>>>>1 files changed, 33 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>>>>> index 691aa67..38f9cbc 100644
>>>>>> --- a/arch/arm/mach-omap2/timer.c
>>>>>> +++ b/arch/arm/mach-omap2/timer.c
>>>>>> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum
>>>>>> clock_event_mode mode,
>>>>>> }
>>>>>>}
>>>>>>
>>>>>> +static void omap_clkevt_suspend(struct clock_event_device *unused)
>>>>>> +{
>>>>>> +char name[10];
>>>>>> +struct omap_hwmod *oh;
>>>>>> +
>>>>>> +sprintf(name, "timer%d", clkev.id);
>>>>>> +oh = omap_hwmod_lookup(name);
>>>>>> +if (!oh)
>>>>>> +return;
>>>>>> +
>>>>>> +__omap_dm_timer_stop(&clkev, 1, clkev.rate);
>>>>>> +omap_hwmod_idle(oh);
>>>>>> +}
>>>>>> +
>>>>>> +static void omap_clkevt_resume(struct clock_event_device *unused)
>>>>>> +{
>>>>>> +char name[10];
>>>>>> +struct omap_hwmod *oh;
>>>>>> +
>>>>>> +sprintf(name, "timer%d", clkev.id);
>>>>>> +oh = omap_hwmod_lookup(name);
>>>>>> +if (!oh)
>>>>>> +return;
>>>>>> +
>>>>>> +omap_hwmod_enable(oh);
>>>>>> +__omap_dm_timer_load_start(&clkev,
>>>>>> +OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
>>>>>> +__omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
>>>>>> +}
>>>>>> +
>>>>> Am still bit uncomfortable with direct hwmod usage in the suspend/resmue
>>>>> hooks.
>>>>>
>>>>> Jon, Any alternatives you can think of ?
>>>>>
>>>>
>>>> Jon,
>>>>
>>>> Any suggestions here?
>>>
>>> Sorry completed this missed this!
>>>
>>> Unfortunately, I don't have any good suggestions here. However, I am
>>> wondering if the suspend/resume handlers can just be calls to
>>> omap_hwmod_idle/enable and we can remove these __omap_dm_timer_
>>> calls (I don't think they are needed). Furthermore, my understanding is
>>> this is only needed for AM335x (per the changelog), and so we should not
>>> add suspend/resume handlers for all OMAP2+ based devices.
>>>
>> I agree with the direction.
>>
>
> I need to retain the call to enable the interrupt but the others can be
> dropped.
> Will take care of this and the comment on invoking the suspend/resume handlers
> only for AM335x in the next version.
Ok fair enough. By the way, I posted a patch today [1] that will use the
hwmod name as the clockevent timer name. Care to try on top of that
patch and then we can eliminate the sprintf.
Cheers
Jon
[1] http://www.spinics.net/lists/arm-kernel/msg221262.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ARM: OMAP2+: timer: Update the OMAP5 clocksource name as per clock data
On 01/18/2013 09:32 AM, Santosh Shilimkar wrote:
> OMAP5 clockdata has different sys clock clock node name. Fix the timer code
> to take care of it.
>
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/timer.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 691aa67..a0a1b14 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -62,6 +62,7 @@
> #define OMAP2_MPU_SOURCE "sys_ck"
> #define OMAP3_MPU_SOURCE OMAP2_MPU_SOURCE
> #define OMAP4_MPU_SOURCE "sys_clkin_ck"
> +#define OMAP5_MPU_SOURCE "sys_clkin"
I would like to remove this definitions and in fact posted a patch today
to do that [1] ;-)
> #define OMAP2_32K_SOURCE "func_32k_ck"
> #define OMAP3_32K_SOURCE "omap_32k_fck"
> #define OMAP4_32K_SOURCE "sys_32k_ck"
> @@ -498,7 +499,7 @@ static void __init realtime_counter_init(void)
> pr_err("%s: ioremap failed\n", __func__);
> return;
> }
> - sys_clk = clk_get(NULL, "sys_clkin_ck");
> + sys_clk = clk_get(NULL, OMAP5_MPU_SOURCE);
> if (IS_ERR(sys_clk)) {
> pr_err("%s: failed to get system clock handle\n", __func__);
> iounmap(base);
> @@ -638,7 +639,7 @@ OMAP_SYS_TIMER(4, local);
>
> #ifdef CONFIG_SOC_OMAP5
> OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
> - 2, OMAP4_MPU_SOURCE);
> + 2, OMAP5_MPU_SOURCE);
I am hoping we can remove this completely for omap5 and use the same
function defined for omap2 [2].
Care to try your series on top of mine [3] on omap5?
Cheers
Jon
[1] http://www.spinics.net/lists/arm-kernel/msg221263.html
[2] http://www.spinics.net/lists/arm-kernel/msg221264.html
[3] http://www.spinics.net/lists/arm-kernel/msg221260.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
On 01/18/2013 09:27 AM, Santosh Shilimkar wrote:
> From: Rajendra Nayak
>
> Add the clock tree related data for OMAP54xx platforms.
[snip]
> + CLK("omap_timer.1", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.2", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.3", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.4", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.5", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.6", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.7", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.8", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.9", "32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.10","32k_ck", &sys_32k_ck,
> CK_54XX),
> + CLK("omap_timer.11","32k_ck", &sys_32k_ck,
> CK_54XX),
I have been trying to get away from having so many aliases for the same
clock for timers. Here we should replace all of the above and just have ...
+ CLK(NULL, "timer_32k_ck", &sys_32k_ck, CK_54XX),
For more details see [1].
> + CLK("omap_timer.1", "sys_ck", &sys_clkin,
> CK_54XX),
> + CLK("omap_timer.2", "sys_ck", &sys_clkin,
> CK_54XX),
> + CLK("omap_timer.3", "sys_ck", &sys_clkin,
> CK_54XX),
> + CLK("omap_timer.4", "sys_ck", &sys_clkin,
> CK_54XX),
> + CLK("omap_timer.9", "sys_ck", &sys_clkin,
> CK_54XX),
> + CLK("omap_timer.10","sys_ck", &sys_clkin,
> CK_54XX),
> + CLK("omap_timer.11","sys_ck", &sys_clkin,
> CK_54XX),
> + CLK("omap_timer.5", "sys_ck", &dss_syc_gfclk_div,
> CK_54XX),
> + CLK("omap_timer.6", "sys_ck", &dss_syc_gfclk_div,
> CK_54XX),
> + CLK("omap_timer.7", "sys_ck", &dss_syc_gfclk_div,
> CK_54XX),
> + CLK("omap_timer.8", "sys_ck", &dss_syc_gfclk_div,
> CK_54XX),
> +};
These aliases will not work with device-tree because the device-name is
formatted .. Hence, when configuring a the timer parent
clock via the dmtimer driver it will fail. So it should be more like ...
+ CLK("4ae18000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48032000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48034000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48036000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("40138000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013a000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013c000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013e000.timer", "timer_sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("4803e000.timer", "timer_sys_ck", &dss_syc_gfclk_div, CK_54XX),
+ CLK("48086000.timer", "timer_sys_ck", &dss_syc_gfclk_div, CK_54XX),
+ CLK("48088000.timer", "timer_sys_ck", &dss_syc_gfclk_div, CK_54XX),
For more details see [2].
If you would like to test the dmtimer driver on omap5, then you can grab
my omap-test module [3], build it (see README), load it and then ...
# echo 1 > /sys/kernel/debug/omap-test/timer/all
This will perform some basic tests on all the dmtimers. I would do it
myself, but there appears to be several issues getting this to boot on
an ES1.0 (which is probably expected).
Cheers
Jon
[1] http://www.spinics.net/lists/linux-omap/msg71272.html
[2] https://patchwork.kernel.org/patch/1204351/
[3] https://github.com/jonhunter/omap-test
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: OMAP3: Update clocksource timer selection
When booting with device-tree for OMAP3 and AM335x devices and a gptimer
is used as the clocksource (which is always the case for AM335x), a
gptimer located in a power domain that is not always-on is selected.
Ideally we should use a gptimer located in a power domain that is always
on (such as the wake-up domain) so that time can be maintained during a
kernel suspend without keeping on additional power domains unnecessarily.
In order to fix this so that we can select a gptimer located in a power
domain that is always-on, the following changes were made ...
1. Currently, only when selecting a gptimer to use for a clockevent
timer, do we pass a timer property that can be used to select a
specific gptimer. Change this so that we can pass a property when
selecting a gptimer to use for a clocksource timer too.
2. Currently, when selecting either a gptimer to use for a clockevent
timer or a clocksource timer and no timer property is passed, then
the first available timer is selected regardless of the properties
it has. Change this so that if no properties are passed, then a timer
that does not have additional features (such as always-on, dsp-irq,
pwm, and secure) is selected.
Please note that using a gptimer for both clocksource and clockevents
can have a system power impact during idle. The reason being is that
OMAP and AMxxx devices typically only have one gptimer in a power domain
that is always-on. Therefore when the kernel is idle both the clocksource
and clockevent timers will be active and this will keep additional power
domains on. During kernel suspend, only the clocksource timer is active
and therefore, it is better to use a gptimer in a power domain that is
always-on for clocksource.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index af20be7..acf9f82 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -163,6 +163,12 @@ static struct device_node * __init
omap_get_timer_dt(struct of_device_id *match,
if (property && !of_get_property(np, property, NULL))
continue;
+ if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
+ of_get_property(np, "ti,timer-dsp", NULL) ||
+ of_get_property(np, "ti,timer-pwm", NULL) ||
+ of_get_property(np, "ti,timer-secure", NULL)))
+ continue;
+
of_add_property(np, &device_disabled);
return np;
}
@@ -431,14 +437,16 @@ static int __init __maybe_unused
omap2_sync32k_clocksource_init(void)
}
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+ const char *fck_source,
+ const char *property)
{
int res;
clksrc.errata = omap_dm_timer_get_errata();
res = omap_dm_timer_init_one(&clksrc, gptimer_id, &clocksource_gpt.name,
-fck_source, NULL, OMAP_TIMER_NONPOSTED);
+fck_source, property,
+OMAP_TIMER_NONPOSTED);
BUG_ON(res);
__omap_dm_timer_load_start(&clksrc,
@@ -533,23 +541,25 @@ static inline void __init realtime_counter_init(void)
#endif
#define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
- clksrc_nr, clksrc_src) \
+ clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
- omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src);\
+ omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
+ clksrc_prop); \
}
#define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
- clksrc_nr, clksrc_src) \
+ clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
{ \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clo
[PATCH 4/5] ARM: OMAP2+: Simplify system timers definitions
There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function omap2_sync32k_timer_init() can be re-used for OMAP4/5 devices.
Therefore, consolidate the definitions to simplify the code.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/common.h |3 +--
arch/arm/mach-omap2/timer.c | 23 +--
4 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 6a9529a..7c1ad68 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -297,6 +297,6 @@ MACHINE_START(CM_T3517, "Compulab CM-T3517")
.handle_irq = omap3_intc_handle_irq,
.init_machine = cm_t3517_init,
.init_late = am35xx_init_late,
- .init_time = omap3_gp_gptimer_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.restart= omap3xxx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 2590463..dfd9f48 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -138,7 +138,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened
Device Tree)")
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
- .init_time = omap3_am33xx_gptimer_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.dt_compat = am33xx_boards_compat,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b435027..594ab3b 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -82,8 +82,7 @@ extern void omap2_init_common_infrastructure(void);
extern void omap2_sync32k_timer_init(void);
extern void omap3_sync32k_timer_init(void);
extern void omap3_secure_sync32k_timer_init(void);
-extern void omap3_gp_gptimer_timer_init(void);
-extern void omap3_am33xx_gptimer_timer_init(void);
+extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
extern void omap5_realtime_timer_init(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e7df00a..af20be7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -554,33 +554,30 @@ void __init omap##name##_sync32k_timer_init(void)
\
omap2_sync32k_clocksource_init(); \
}
-#ifdef CONFIG_ARCH_OMAP2
+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP4) ||
\
+ defined(CONFIG_SOC_OMAP5)
OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck");
-#endif /* CONFIG_ARCH_OMAP2 */
+#endif
#ifdef CONFIG_ARCH_OMAP3
OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck");
OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
2, "timer_sys_ck");
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, "timer_sys_ck", "ti,timer-alwon",
- 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP3 */
-#ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, "timer_sys_ck", "ti,timer-alwon",
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon",
2, "timer_sys_ck");
-#endif /* CONFIG_SOC_AM33XX */
+#endif
#ifdef CONFIG_ARCH_OMAP4
-OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
- 2, "timer_sys_ck");
#ifdef CONFIG_LOCAL_TIMERS
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
void __init omap4_local_timer_init(void)
{
- omap4_sync32k_timer_init();
+ omap2_sync32k_timer_init();
/* Local timers are not supprted on OMAP4430 ES1.0 */
if (omap_rev() != OMAP4430_REV_ES1_0) {
int err;
@@ -598,19 +595,17 @@ void __init omap4_local_timer_init(void)
#else /* CONFIG_LOCAL_TIMERS */
void __init omap4_local_timer_init(void)
{
- omap4_sync32k_timer_init();
+ omap2_sync32k_timer_init();
}
#endif /* CONFIG_LOCAL_TIMERS */
#endif /* CONFIG_ARCH_OMAP4 */
#ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, "timer_32k_ck", "ti,timer-alwon",
- 2, "timer_sys_ck");
void __init omap5_realtime_timer_init(void)
[PATCH 3/5] ARM: OMAP2+: Simplify system timer clock definitions
In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases), new
clock aliases for dmtimers were added to simplify the code. These clock
aliases can also be used when configuring the system timers and allow us
to remove the current definitions, simplifying the code.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 37 ++---
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 69fe623b..e7df00a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -57,15 +57,6 @@
#include "common.h"
#include "powerdomain.h"
-/* Parent clocks, eventually these will come from the clock framework */
-
-#define OMAP2_MPU_SOURCE "sys_ck"
-#define OMAP3_MPU_SOURCE OMAP2_MPU_SOURCE
-#define OMAP4_MPU_SOURCE "sys_clkin_ck"
-#define OMAP2_32K_SOURCE "func_32k_ck"
-#define OMAP3_32K_SOURCE "omap_32k_fck"
-#define OMAP4_32K_SOURCE "sys_32k_ck"
-
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
@@ -564,27 +555,27 @@ void __init omap##name##_sync32k_timer_init(void)
\
}
#ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, OMAP2_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP2_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP2 */
#ifdef CONFIG_ARCH_OMAP3
-OMAP_SYS_32K_TIMER_INIT(3, 1, OMAP3_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP3_MPU_SOURCE);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, OMAP3_32K_SOURCE, "ti,timer-secure",
- 2, OMAP3_MPU_SOURCE);
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, OMAP3_MPU_SOURCE, "ti,timer-alwon",
- 2, OMAP3_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
+OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
+ 2, "timer_sys_ck");
+OMAP_SYS_GP_TIMER_INIT(3_gp, 1, "timer_sys_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_ARCH_OMAP3 */
#ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, "timer_sys_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#endif /* CONFIG_SOC_AM33XX */
#ifdef CONFIG_ARCH_OMAP4
-OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
#ifdef CONFIG_LOCAL_TIMERS
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
void __init omap4_local_timer_init(void)
@@ -613,8 +604,8 @@ void __init omap4_local_timer_init(void)
#endif /* CONFIG_ARCH_OMAP4 */
#ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
- 2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(5, 1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck");
void __init omap5_realtime_timer_init(void)
{
int err;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] ARM: OMAP2+: Display correct system timer name
Currently on boot, when displaying the name of the gptimer used for
clockevents and clocksource timers, the timer ID is shown. However,
when booting with device-tree, the timer ID is not used to select a
gptimer but a timer property. Hence, it is possible that the timer
selected when booting with device-tree does not match the ID shown.
Therefore, instead display the HWMOD name of the gptimer and use
the HWMOD name as the name of clockevent and clocksource timer (if a
gptimer is used).
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 44 +--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 72c2ca1..18cb856 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -71,6 +71,9 @@
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
#define NUMERATOR_DENUMERATOR_MASK 0xf000
+/* Timer name needs to be big enough to store a string of "timerXX" */
+static char timer_name[10];
+
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -129,7 +132,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
static struct clock_event_device clockevent_gpt = {
- .name = "gp_timer",
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
@@ -214,13 +216,12 @@ static u32 __init omap_dm_timer_get_errata(void)
}
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
- int gptimer_id,
- const char *fck_source,
- const char *property,
- int posted)
+int gptimer_id,
+const char **name,
+const char *fck_source,
+const char *property,
+int posted)
{
- char name[10]; /* 10 = sizeof("gptXX_Xck0") */
- const char *oh_name;
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
@@ -231,8 +232,8 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!np)
return -ENODEV;
- of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
- if (!oh_name)
+ of_property_read_string_index(np, "ti,hwmods", 0, name);
+ if (!name)
return -ENODEV;
timer->irq = irq_of_parse_and_map(np, 0);
@@ -246,11 +247,11 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (omap_dm_timer_reserve_systimer(gptimer_id))
return -ENODEV;
- sprintf(name, "timer%d", gptimer_id);
- oh_name = name;
+ sprintf(timer_name, "timer%d", gptimer_id);
+ *name = timer_name;
}
- oh = omap_hwmod_lookup(oh_name);
+ oh = omap_hwmod_lookup(*name);
if (!oh)
return -ENODEV;
@@ -294,7 +295,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
}
}
- omap_hwmod_setup_one(oh_name);
+ omap_hwmod_setup_one(*name);
omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
@@ -326,8 +327,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
*/
__omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
- res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property,
-OMAP_TIMER_POSTED);
+ res = omap_dm_timer_init_one(&clkev, gptimer_id, &clockevent_gpt.name,
+fck_source, property, OMAP_TIMER_POSTED);
BUG_ON(res);
omap2_gp_timer_irq.dev_id = &clkev;
@@ -341,8 +342,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
3, /* Timer internal resynch latency */
0x);
- pr_info("OMAP clockevent source: GPTIMER%d at %lu Hz\n",
- gptimer_id, clkev.rate);
+ pr_info("OMAP clockevent source: %s at %lu Hz\n", clockevent_gpt.name,
+ clkev.rate);
}
/* Clocksource code */
@@ -359,7 +360,6 @@ static cycle_t clocksource_read_cycles(struct clocksource
*cs)
}
static struct clocksource clocksource_gpt = {
- .name = "gp_timer",
.rating = 300,
.r
[PATCH 2/5] ARM: OMAP2+: Remove hard-coded test on timer ID
Currently, when configuring the clock-events and clock-source timers
for OMAP2+ devices, we check whether the timer ID is 12 before
attempting to set the parent clock for the timer.
This test was added for OMAP3 general purpose devices (no security
features enabled) that a 12th timer available but unlike the other
timers only has a single functional clock source. Calling
clk_set_parent() for this 12th timer would always return an error
because there is only one choice for a parent clock. Therefore,
this hard-coded timer ID test was added.
To avoid this timer ID test, simply check to see if the timer's current
parent clock is the desired parent clock and only call clk_set_parent()
if this is not the case.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 18cb856..69fe623b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -225,6 +225,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;
+ struct clk *src;
int r = 0;
if (of_have_populated_dt()) {
@@ -279,22 +280,19 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(timer->fclk))
return -ENODEV;
- /* FIXME: Need to remove hard-coded test on timer ID */
- if (gptimer_id != 12) {
- struct clk *src;
-
- src = clk_get(NULL, fck_source);
- if (IS_ERR(src)) {
- r = -EINVAL;
- } else {
- 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);
- }
+ src = clk_get(NULL, fck_source);
+ if (IS_ERR(src))
+ return -EINVAL;
+
+ if (clk_get_parent(timer->fclk) != src) {
+ 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);
+
omap_hwmod_setup_one(*name);
omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] ARM: OMAP2+: System timer updates
This series consists mainly of clean-ups for clockevents and clocksource timers on OMAP2+ devices. The most significant change in functionality comes from the 5th patch which is changing the selection of the clocksource timer for OMAP3 and AM335x devices when gptimers are used for clocksource. This change came about from Vaibhav Bedia's series for AM335x [1]. See patch for more details on the exact nature of the change. Boot tested with and without device-tree on OMAP2420 H4, OMAP3430 SDP, OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only supports device-tree boot). This series is based upon ARM-SoC next branch. [1] https://patchwork.kernel.org/patch/1921421/ Jon Hunter (5): ARM: OMAP2+: Display correct system timer name ARM: OMAP2+: Remove hard-coded test on timer ID ARM: OMAP2+: Simplify system timer clock definitions ARM: OMAP2+: Simplify system timers definitions ARM: OMAP3: Update clocksource timer selection arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/common.h |3 +- arch/arm/mach-omap2/timer.c | 134 -- 4 files changed, 67 insertions(+), 74 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
device-tree support for selecting a clockevent timer by property.
However, the code is currently ignoring the property passed and
selecting the first available timer found. Hence, for the OMAP3 beagle
board timer-12 is not being selected as expected. Fix this problem
by ensuring the timer property is passed to omap_get_timer_dt().
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b8ad6e6..265de51 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -228,7 +228,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
int r = 0;
if (of_have_populated_dt()) {
- np = omap_get_timer_dt(omap_timer_match, NULL);
+ np = omap_get_timer_dt(omap_timer_match, property);
if (!np)
return -ENODEV;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] omap1 fails to boot on clock propagation
On 01/29/2013 03:53 AM, Łukasz Góralczyk wrote:
> Hello,
>
> Some background:
> Recently I've ported Linux to some custom omap1 based (5940 or 1510)
> hardware. I've had some initial problems, but after a "dirty" fix I
> have a running kernel and I can boot using NFS.
Do you mean 5910? I am not familiar with a 5940.
> Problem:
> On the very beginning kernel boot process stopped on clock propagation
> routine (simple freeze, no crash info, nothing). After investigation I
> have found that one memory read is at fault in function
> omap1_ckctl_recalc_dsp_domain() in clock.c file:
>
> dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
>
> My fix was to exchange read operation with default value of DSP_CKCTL
> register:
>
> dsor = 1 << (3 & (0x00990 >> clk->rate_offset));
>
> Since this fix I haven't dug deeper into this problem, but it keeps me
> thinking how to fix it properly. Any suggestions what might be the
> root cause of this?
Well looking at the code, in order to access the DSP_CKCTL register you
need to enable the api_ck first ...
omap1_clk_enable(api_ck_p);
dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
omap1_clk_disable(api_ck_p);
Therefore, I would check if the api_ck is actually being turned on, on
your platform. For example ...
omap1_clk_enable(api_ck_p);
pr_info("ARM_IDLECT2 = 0x%x\n", __raw_readw(ARM_IDLECT2));
omap1_clk_disable(api_ck_p);
Bit 6 in the ARM_IDLECT2 should be set if the api_ck is enabled.
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: gpmc: Remove unneeded of_node_put()
On 01/25/2013 06:19 AM, Ezequiel Garcia wrote:
> for_each_node_by_name() automatically calls of_node_put() on each
> node passed; so don't do it explicitly unless there's an error.
>
> Reported-by: Mark Rutland
> Signed-off-by: Ezequiel Garcia
> ---
> arch/arm/mach-omap2/gpmc.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 01ce462..c6255f7 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1271,9 +1271,10 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>
> for_each_node_by_name(child, "nand") {
> ret = gpmc_probe_nand_child(pdev, child);
> - of_node_put(child);
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(child);
> return ret;
> + }
> }
>
> return 0;
>
Acked-by: Jon Hunter
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: [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
Hi Vaibhav, On 12/31/2012 07:07 AM, Vaibhav Bedia wrote: > AM33XX has two timers (DTIMER0/1) in the WKUP domain. > On GP devices the source of DMTIMER0 is fixed to an > inaccurate internal 32k RC oscillator and this makes > the DMTIMER0 practically either as a clocksource or > as clockevent. > > Currently the timer instance in WKUP domain is used > as the clockevent and the timer in non-WKUP domain > as the clocksource. DMTIMER1 in WKUP domain can keep > running in suspend from a 32K clock fed from external > OSC and can serve as the persistent clock for the kernel. > To enable this, interchange the timers used as clocksource > and clockevent for AM33XX. I have been thinking about this some more. In the case where we are using gptimers for both clock-events and clock-source (on both AM33xx and OMAP) and I am wondering if it makes sense to switch the timers so that we use the always-on timer for clock-source and a different one from clock-events. For OMAP, if we are not using the 32k-sync for clock-source, then we are never going to achieve low power states during idle as we will always have one gptimer running. And in this case, to your point below, it would be better to use the always-on for clock-source so that in suspend we can at least hit low power states and maintain time. > For now a new DT property has been added to allow the timer code > to select the timer with the right property. > > It has been pointed out by Santosh Shilimkar and Kevin Hilman > that such a change will result in soc-idle never being achieved > on AM33XX. There are other reasons why soc-idle does not look > feasible on AM33XX so for now we go ahead with the interchange > of the the timers. If at a later point of time we do come up > with an approach which makes soc-idle possible on AM33XX, this > can be revisited. Right, but this would also be true for OMAP if we don't use the 32k-sync as we only have one gptimer in the wake-up domain. 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: Fix missing omap2xxx_clkt_vps_xxx function calls
Hi Paul, On 01/17/2013 05:24 PM, Paul Walmsley wrote: > > Here's the updated version (at the bottom of this message). Seems to work > based on a quick test on 2430SDP. > > # shutdown -r -n now > shutdown: sending all processes the TERM signal... > shutdown: sending all processes the KILL signal. > shutdown: turning off swap > shutdown: unmounting all file systems > umount: /debug: not mounted > umount: /run/shm: not mounted > umount: /dev: not mounted > umount: /tmp: not mounted > umount: /run/lock: not mounted > umount: /run: not mounted > umount: /lib/init/rw: not found > Please stand by while rebooting the system. > [ 79.635925] Disabling non-boot CPUs ... > [ 79.640197] Restarting system. > > > U-Boot 1.1.4 (Mar 18 2007 - 12:22:00) > > OMAP2430C-GP revision 3, PRCM #5A > TI 2430SDP 1.1 Version + mDDR (Boot NOR) > DRAM: 128 MB > Flash: 192 MB > NAND:64 MB > In:serial > Out: serial > Err: serial > Hit any key to stop autoboot: 0 > > > ... etc. ... > > > - Paul > > > From: Jon Hunter > Date: Thu, 10 Jan 2013 14:53:29 -0600 > Subject: [PATCH] ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function > calls > > During the migration to the common clock framework, calls to the > functions omap2xxx_clkt_vps_late_init() were not preserved for > OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and > "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the > following error message to be displayed because the appropriate MPU > clock frequency (derived from sys_ck_rate) cannot be found. > > "Could not set MPU rate to 4294MHz" > > Fix this by adding back calls to omap2xxx_clkt_vps_late_init() in the > OMAP2420 and OMAP2430 clock initialisation code. > > Signed-off-by: Jon Hunter > [p...@pwsan.com: dropped the duplicated call to > omap2xxx_clkt_vps_check_bootloader_rates() after consultation with Jon; > updated patch description] > Signed-off-by: Paul Walmsley > --- > arch/arm/mach-omap2/cclock2420_data.c |2 ++ > arch/arm/mach-omap2/cclock2430_data.c |2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/arch/arm/mach-omap2/cclock2420_data.c > b/arch/arm/mach-omap2/cclock2420_data.c > index 7e5febe..ab7e952 100644 > --- a/arch/arm/mach-omap2/cclock2420_data.c > +++ b/arch/arm/mach-omap2/cclock2420_data.c > @@ -1935,6 +1935,8 @@ int __init omap2420_clk_init(void) > omap2_init_clk_hw_omap_clocks(c->lk.clk); > } > > + omap2xxx_clkt_vps_late_init(); > + > omap2_clk_disable_autoidle_all(); > > omap2_clk_enable_init_clocks(enable_init_clks, > diff --git a/arch/arm/mach-omap2/cclock2430_data.c > b/arch/arm/mach-omap2/cclock2430_data.c > index eda079b..eb3dab6 100644 > --- a/arch/arm/mach-omap2/cclock2430_data.c > +++ b/arch/arm/mach-omap2/cclock2430_data.c > @@ -2050,6 +2050,8 @@ int __init omap2430_clk_init(void) > omap2_init_clk_hw_omap_clocks(c->lk.clk); > } > > + omap2xxx_clkt_vps_late_init(); > + > omap2_clk_disable_autoidle_all(); > > omap2_clk_enable_init_clocks(enable_init_clks, Thanks! Looks good to me. 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: Fix missing omap2xxx_clkt_vps_xxx function calls
Hi Paul, On 01/17/2013 12:51 PM, Paul Walmsley wrote: > Hi Jon > > On Thu, 10 Jan 2013, Jon Hunter wrote: > >> During the migration to the common clock framework, calls to the >> functions omap2xxx_clkt_vps_late_init() and >> omap2xxx_clkt_vps_check_bootloader_rates() were not preserved for >> OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and >> "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the >> following error message to be displayed because the appropriate MPU >> clock frequency (derived from sys_ck_rate) cannot be found. >> >> "Could not set MPU rate to 4294MHz" > > I don't see this message on 2430sdp or n800 with v3.8-rc3, but maybe > that's due to sys_clk differences. Do you still see this on v3.8-rc3 > with H4? Yes I still see it. You don't see it on reboot? The reason why there is such a large number is because omap2_round_to_table_rate() is returning the value -EINVAL. You could add a print to omap2_round_to_table_rate() to see what it returns on reboot. Or we could add a WARN to the function is sys_ck_rate is 0 for testing. > Also, there's already a call to omap2xxx_clkt_vps_check_bootloader_rates() > -- is it necessary to add another one? Thanks. I see that now and so that is not needed then. 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: [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
> AM33XX has two timers (DTIMER0/1) in the WKUP domain.
> On GP devices the source of DMTIMER0 is fixed to an
> inaccurate internal 32k RC oscillator and this makes
> the DMTIMER0 practically either as a clocksource or
> as clockevent.
>
> Currently the timer instance in WKUP domain is used
> as the clockevent and the timer in non-WKUP domain
> as the clocksource. DMTIMER1 in WKUP domain can keep
> running in suspend from a 32K clock fed from external
> OSC and can serve as the persistent clock for the kernel.
> To enable this, interchange the timers used as clocksource
> and clockevent for AM33XX.
>
> For now a new DT property has been added to allow the timer code
> to select the timer with the right property.
>
> It has been pointed out by Santosh Shilimkar and Kevin Hilman
> that such a change will result in soc-idle never being achieved
> on AM33XX. There are other reasons why soc-idle does not look
> feasible on AM33XX so for now we go ahead with the interchange
> of the the timers. If at a later point of time we do come up
> with an approach which makes soc-idle possible on AM33XX, this
> can be revisited.
>
> Signed-off-by: Vaibhav Bedia
> Signed-off-by: Vaibhav Hiremath
> Cc: Tony Lingren
> Cc: Santosh Shilimkar
> Cc: Benoit Cousson
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> Cc: Jon Hunter
>
> ---
> v1->v2:
> Use DT properties for changing the timers
>
> .../devicetree/bindings/arm/omap/timer.txt |2 ++
> arch/arm/boot/dts/am33xx.dtsi |1 +
> arch/arm/mach-omap2/timer.c|6 +++---
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/devicetree/bindings/arm/omap/timer.txt
> index 8732d4d..62d4f2c 100644
> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -18,6 +18,8 @@ Optional properties:
> - 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.
> +- ti,timer-non-wkup Indicates the timer is in non-wkup power domain and
> hence
> + will lose register context when the power domain
> transitions
I was hoping that we could avoid adding another property, especially
given that his equivalent to a timer that does not have the
"ti,timer-alwon" property.
> Example:
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4731748..b4e8bf7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -251,6 +251,7 @@
> reg = <0x4804 0x400>;
> interrupts = <68>;
> ti,hwmods = "timer2";
> + ti,timer-non-wkup;
Is this is only one not in the wake-up domain?
> };
>
> timer3: timer@48042000 {
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 38f9cbc..cfb3413 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -264,7 +264,7 @@ static int __init omap_dm_timer_init_one(struct
> omap_dm_timer *timer,
> int r = 0;
>
> if (of_have_populated_dt()) {
> - np = omap_get_timer_dt(omap_timer_match, NULL);
> + np = omap_get_timer_dt(omap_timer_match, property);
> if (!np)
> return -ENODEV;
>
> @@ -633,8 +633,8 @@ OMAP_SYS_TIMER(3_gp, gptimer);
> #endif /* CONFIG_ARCH_OMAP3 */
>
> #ifdef CONFIG_SOC_AM33XX
> -OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, "ti,timer-alwon",
> -2, OMAP4_MPU_SOURCE);
> +OMAP_SYS_GP_TIMER_INIT(3_am33xx, 2, OMAP4_MPU_SOURCE, "ti,timer-non-wkup",
> +1, OMAP4_MPU_SOURCE);
It seems to me here that we should specify the property "ti,timer-alwon"
for the clocksource and then no property for the clockevent. Hence, may
be the code needs to be adjusted so that if clockevent or clocksource
can use any timer (ie. no property specified), we look for a timer that
has no "ti-timer-" properties. This will ensure that if we need a
particular timer for clocksource, which we look for after clockevent, it
will be 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: [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On 01/10/2013 10:37 PM, Bedia, Vaibhav wrote:
> On Tue, Jan 08, 2013 at 20:45:10, Shilimkar, Santosh wrote:
>> On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
>>> The current OMAP timer code registers two timers -
>>> one as clocksource and one as clockevent.
>>> AM33XX has only one usable timer in the WKUP domain
>>> so one of the timers needs suspend-resume support
>>> to restore the configuration to pre-suspend state.
>>>
>>> commit adc78e6 (timekeeping: Add suspend and resume
>>> of clock event devices) introduced .suspend and .resume
>>> callbacks for clock event devices. Leverages these
>>> callbacks to have AM33XX clockevent timer which is
>>> in not in WKUP domain to behave properly across system
>>> suspend.
>>>
>>> Signed-off-by: Vaibhav Bedia
>>> Cc: Santosh Shilimkar
>>> Cc: Benoit Cousson
>>> Cc: Paul Walmsley
>>> Cc: Kevin Hilman
>>> Cc: Vaibhav Hiremath
>>> Cc: Jon Hunter
>>> ---
>>> v1->v2:
>>> Get rid of harcoded timer id.
>>> Note: since a platform device is not created for these timer
>>> instances and because there's very minimal change needed for
>>> restarting the timer a full blown context save and restore
>>> has been skipped.
>>>
>>> arch/arm/mach-omap2/timer.c | 33 +
>>> 1 files changed, 33 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>> index 691aa67..38f9cbc 100644
>>> --- a/arch/arm/mach-omap2/timer.c
>>> +++ b/arch/arm/mach-omap2/timer.c
>>> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum
>>> clock_event_mode mode,
>>> }
>>> }
>>>
>>> +static void omap_clkevt_suspend(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", clkev.id);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>> +
>>> + __omap_dm_timer_stop(&clkev, 1, clkev.rate);
>>> + omap_hwmod_idle(oh);
>>> +}
>>> +
>>> +static void omap_clkevt_resume(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", clkev.id);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>> +
>>> + omap_hwmod_enable(oh);
>>> + __omap_dm_timer_load_start(&clkev,
>>> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
>>> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
>>> +}
>>> +
>> Am still bit uncomfortable with direct hwmod usage in the suspend/resmue
>> hooks.
>>
>> Jon, Any alternatives you can think of ?
>>
>
> Jon,
>
> Any suggestions here?
Sorry completed this missed this!
Unfortunately, I don't have any good suggestions here. However, I am
wondering if the suspend/resume handlers can just be calls to
omap_hwmod_idle/enable and we can remove these __omap_dm_timer_
calls (I don't think they are needed). Furthermore, my understanding is
this is only needed for AM335x (per the changelog), and so we should not
add suspend/resume handlers for all OMAP2+ based devices.
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: [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
> The current OMAP timer code registers two timers -
> one as clocksource and one as clockevent.
> AM33XX has only one usable timer in the WKUP domain
> so one of the timers needs suspend-resume support
> to restore the configuration to pre-suspend state.
>
> commit adc78e6 (timekeeping: Add suspend and resume
> of clock event devices) introduced .suspend and .resume
> callbacks for clock event devices. Leverages these
> callbacks to have AM33XX clockevent timer which is
> in not in WKUP domain to behave properly across system
> suspend.
>
> Signed-off-by: Vaibhav Bedia
> Cc: Santosh Shilimkar
> Cc: Benoit Cousson
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> Cc: Vaibhav Hiremath
> Cc: Jon Hunter
> ---
> v1->v2:
> Get rid of harcoded timer id.
> Note: since a platform device is not created for these timer
> instances and because there's very minimal change needed for
> restarting the timer a full blown context save and restore
> has been skipped.
>
> arch/arm/mach-omap2/timer.c | 33 +
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 691aa67..38f9cbc 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum
> clock_event_mode mode,
> }
> }
>
> +static void omap_clkevt_suspend(struct clock_event_device *unused)
> +{
> + char name[10];
> + struct omap_hwmod *oh;
> +
> + sprintf(name, "timer%d", clkev.id);
> + oh = omap_hwmod_lookup(name);
> + if (!oh)
> + return;
> +
> + __omap_dm_timer_stop(&clkev, 1, clkev.rate);
I am not sure you need to call __omap_dm_timer_stop() here. This should
have already been called as timekeeping_suspend() will call
omap2_gp_timer_set_mode() to shutdown the timer.
> + omap_hwmod_idle(oh);
> +}
> +
> +static void omap_clkevt_resume(struct clock_event_device *unused)
> +{
> + char name[10];
> + struct omap_hwmod *oh;
> +
> + sprintf(name, "timer%d", clkev.id);
> + oh = omap_hwmod_lookup(name);
> + if (!oh)
> + return;
> +
> + omap_hwmod_enable(oh);
> + __omap_dm_timer_load_start(&clkev,
> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
Similarly here, I am not sure these __omap_dm_timer_ calls are needed.
> +}
> +
> static struct clock_event_device clockevent_gpt = {
> .name = "gp_timer",
> .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> @@ -135,6 +165,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,
AFAIK, this is only applicable for AM335x devices and so should not be
added for all.
> };
>
> static struct property device_disabled = {
> @@ -323,6 +355,7 @@ static void __init omap2_gp_clockevent_init(int
> gptimer_id,
> int res;
>
> clkev.errata = omap_dm_timer_get_errata();
> + clkev.id = gptimer_id;
We should not use gptimer_id anymore. This will go away once the
migration to dev-tree is completed. You may be better off storing the
oh_name in the clock_event_device name field and passing to the
suspend/resume handlers.
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: dts: OMAP3: Add support for OMAP3430 SDP board
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM and uses the TWL4030 power management IC.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 46
2 files changed, 47 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..5d6dff0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -104,6 +104,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3430-sdp.dtb \
omap3-tobi.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
new file mode 100644
index 000..be0650d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+ model = "TI OMAP3430 SDP";
+ compatible = "ti,omap3430-sdp", "ti,omap3";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+};
+
+&i2c1 {
+ clock-frequency = <260>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+/include/ "twl4030.dtsi"
+
+&mmc1 {
+ vmmc-supply = <&vmmc1>;
+ vmmc_aux-supply = <&vsim>;
+ bus-width = <8>;
+};
+
+&mmc2 {
+ status = "disabled";
+};
+
+&mmc3 {
+ status = "disabled";
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ARM: dts: OMAP2+: Add PMU nodes
Hi Benoit, On 01/11/2013 07:23 AM, Benoit Cousson wrote: > Hi Jon, > > On 12/17/2012 06:49 PM, Jon Hunter wrote: >> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices. >> >> Please note that the node for OMAP4460 has been placed in a separate >> header file for OMAP4460, because the node is not compatible with >> OMAP4430. The node for OMAP4430 is not included because PMU is not >> currently supported on OMAP4430 due to the absence of a cross-trigger >> interface driver. >> >> Signed-off-by: Jon Hunter > > I've just applied this patch in my for_3.9/dts branch. > > I'm wondering if there is any dependency with the previous patch? If > Tony ack it I can take it as well. I have been thinking about the best way to handle that. May be best for you to take both if Tony can ack the first. 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: OMAP2: Fix missing omap2xxx_clkt_vps_xxx function calls
During the migration to the common clock framework, calls to the functions omap2xxx_clkt_vps_late_init() and omap2xxx_clkt_vps_check_bootloader_rates() were not preserved for OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the following error message to be displayed because the appropriate MPU clock frequency (derived from sys_ck_rate) cannot be found. "Could not set MPU rate to 4294MHz" Fix this by adding back calls to omap2xxx_clkt_vps_late_init() and omap2xxx_clkt_vps_check_bootloader_rates() in the OMAP2420 and OMAP2430 clock initialisation code. Signed-off-by: Jon Hunter --- Tested on OMAP2420 H4 board only. arch/arm/mach-omap2/cclock2420_data.c |5 + arch/arm/mach-omap2/cclock2430_data.c |5 + 2 files changed, 10 insertions(+) diff --git a/arch/arm/mach-omap2/cclock2420_data.c b/arch/arm/mach-omap2/cclock2420_data.c index 7e5febe..0dadfb9 100644 --- a/arch/arm/mach-omap2/cclock2420_data.c +++ b/arch/arm/mach-omap2/cclock2420_data.c @@ -1935,8 +1935,13 @@ int __init omap2420_clk_init(void) omap2_init_clk_hw_omap_clocks(c->lk.clk); } + omap2xxx_clkt_vps_late_init(); + omap2_clk_disable_autoidle_all(); + /* XXX Can this be done from the virt_prcm_set clk init function? */ + omap2xxx_clkt_vps_check_bootloader_rates(); + omap2_clk_enable_init_clocks(enable_init_clks, ARRAY_SIZE(enable_init_clks)); diff --git a/arch/arm/mach-omap2/cclock2430_data.c b/arch/arm/mach-omap2/cclock2430_data.c index eda079b..722ff84 100644 --- a/arch/arm/mach-omap2/cclock2430_data.c +++ b/arch/arm/mach-omap2/cclock2430_data.c @@ -2050,8 +2050,13 @@ int __init omap2430_clk_init(void) omap2_init_clk_hw_omap_clocks(c->lk.clk); } + omap2xxx_clkt_vps_late_init(); + omap2_clk_disable_autoidle_all(); + /* XXX Can this be done from the virt_prcm_set clk init function? */ + omap2xxx_clkt_vps_check_bootloader_rates(); + omap2_clk_enable_init_clocks(enable_init_clks, ARRAY_SIZE(enable_init_clks)); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: DT node Timer iteration fix
Hi Pantelis,
On 01/08/2013 07:31 AM, Pantelis Antoniou wrote:
> The iterator correctly handles of_node_put() calls.
> Remove it before continue'ing the loop.
> Without this patch you get:
Thanks for the fix!
May be worth mentioning that this will only be seen with
"CONFIG_OF_DYNAMIC" (and explains why I did not catch this one!).
> ERROR: Bad of_node_put() on /ocp/timer@44e31000!
> [] (unwind_backtrace+0x0/0xe0) from []
> (of_node_release+0x2c/0xa0)!
> [] (of_node_release+0x2c/0xa0) from []
> (of_find_matching_node_and_match+0x78/0x90)!
> [] (of_find_matching_node_and_match+0x78/0x90) from []
> (omap_get_timer_dt+0x78/0x90)!
> [] (omap_get_timer_dt+0x78/0x90) from []
> (omap_dm_timer_init_one.clone.2+0x34/0x2bc)!
> [] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from []
> (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)!
> [] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from
> [] (time_init+0x20/0x30)!
> [] (time_init+0x20/0x30) from []
> (start_kernel+0x1a8/0x2fc)!
>
> Signed-off-by: Pantelis Antoniou
> ---
> arch/arm/mach-omap2/timer.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 691aa67..b8ad6e6 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -165,15 +165,11 @@ static struct device_node * __init
> omap_get_timer_dt(struct of_device_id *match,
> struct device_node *np;
>
> for_each_matching_node(np, match) {
> - if (!of_device_is_available(np)) {
> - of_node_put(np);
> + if (!of_device_is_available(np))
> continue;
> - }
>
> - if (property && !of_get_property(np, property, NULL)) {
> - of_node_put(np);
> + if (property && !of_get_property(np, property, NULL))
> continue;
> - }
>
> of_add_property(np, &device_disabled);
> return np;
Otherwise ...
Acked-by: Jon Hunter
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] OMAP: add pwm driver using dmtimers.
On 01/06/2013 03:12 PM, NeilBrown wrote:
[snip]
> I've been playing with off-mode and discovered that the first attempt to set
> the PWM after resume didn't work, but subsequent ones did.
> I did some digging and came up with the following patch.
> With this in place, the omap_pwm_suspend() above is definitely pointless (was
> wasn't really useful even without it).
Thanks for sending. I have given this patch a try on omap3 and I am still
some some failures with my timer read test. I need to dig into that further,
but I am guessing not related to your patch as there were problems there
before :-(
Some minor comments below ...
> NeilBrown
>
>
> From: NeilBrown
> Date: Mon, 7 Jan 2013 07:53:03 +1100
> Subject: [PATCH] OMAP dmtimer - simplify context-loss handling.
Nit, subject should formatted "ARM: OMAP: blah blah blah"
Also, may be worth calling this "fix context-loss" as this is really
fixing something that is broken.
> The context loss handling in dmtimer appears to assume that
>omap_dm_timer_set_load_start() or omap_dm_timer_start()
> and
>omap_dm_timer_stop()
>
> bracket all interactions. Only the first two restore the context and
> the last updates the context loss counter.
> However omap_dm_timer_set_load() or omap_dm_timer_set_match() can
> reasonably be called outside this bracketing, and the fact that they
> call omap_dm_timer_enable() / omap_dm_timer_disable() suggest that
> is expected.
>
> So if, after a transition into and out of off-mode which would cause
> the dm timer to loose all state, omap_dm_timer_set_match() is called
> before omap_dm_timer_start(), the value read from OMAP_TIMER_CTRL_REG
> will be 'wrong' and this wrong value will be stored context.tclr so
> a subsequent omap_dm_timer_start() can fail (As the control register
> is wrong).
>
> Simplify this be doing the restore-from-context in
> omap_dm_timer_enable() so that whenever the timer is enabled, the
> context is correct.
> Also update the ctx_loss_count at the same time as we notice it is
> wrong - these is no value in delaying this until the
> omap_dm_timer_disable() as it cannot change while the timer is
> enabled.
>
> Signed-off-by: NeilBrown
>
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index 938b50a..c216696 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -253,6 +253,15 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_free);
> void omap_dm_timer_enable(struct omap_dm_timer *timer)
> {
> pm_runtime_get_sync(&timer->pdev->dev);
> +
> + if (!(timer->capability & OMAP_TIMER_ALWON)) {
> + int loss_count =
> + omap_pm_get_dev_context_loss_count(&timer->pdev->dev);
> + if (loss_count != timer->ctx_loss_count) {
> + omap_timer_restore_context(timer);
> + timer->ctx_loss_count = loss_count;
> + }
> + }
> }
Can you rebase on v3.8-rc2? We no longer call
omap_pm_get_dev_context_loss_count() directly and so this
does not apply. Should be something like ...
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d51b75b..2c48182 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -315,7 +315,19 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_free);
void omap_dm_timer_enable(struct omap_dm_timer *timer)
{
+ int c;
+
pm_runtime_get_sync(&timer->pdev->dev);
+
+ if (!(timer->capability & OMAP_TIMER_ALWON)) {
+ if (timer->get_context_loss_count) {
+ c = timer->get_context_loss_count(&timer->pdev->dev);
+ if (c != timer->ctx_loss_count) {
+ omap_timer_restore_context(timer);
+ timer->ctx_loss_count = c;
+ }
+ }
+ }
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 1/2] ARM: OMAP4: clock data: Lock ABE DPLL on all revisions
On 01/04/2013 04:09 AM, Peter Ujfalusi wrote:
> To avoid issues with audio caused by non locked ABE DPLL we should
> make sure it is locked in all OMAP4 revisions.
>
> Signed-off-by: Peter Ujfalusi
>
> asda d
Not sure what the above is ;-)
> ---
> arch/arm/mach-omap2/cclock44xx_data.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
> b/arch/arm/mach-omap2/cclock44xx_data.c
> index 5789a5e..a2cc046 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -2026,14 +2026,13 @@ int __init omap4xxx_clk_init(void)
>* 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.
> + * Lock the ABE DPLL in any case to avoid issues with audio.
>*/
> - 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__);
> - }
> + 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;
> }
Acked-by: Jon Hunter
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/2] ARM: OMAP4: clock data: ABE DPLL need to be locked on all revisions
Hi Peter, On 01/03/2013 07:46 AM, Peter Ujfalusi wrote: > We need to lock ABE DPPL on al OMAP4 revisions, not only for OMAP446x > > Signed-off-by: Peter Ujfalusi > --- > arch/arm/mach-omap2/cclock44xx_data.c | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/mach-omap2/cclock44xx_data.c > b/arch/arm/mach-omap2/cclock44xx_data.c > index 5789a5e..79c32ce 100644 > --- a/arch/arm/mach-omap2/cclock44xx_data.c > +++ b/arch/arm/mach-omap2/cclock44xx_data.c > @@ -2023,17 +2023,15 @@ int __init omap4xxx_clk_init(void) >ARRAY_SIZE(enable_init_clks)); > > /* > - * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power > + * On OMAP4 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. I am not sure that this change to the comment is completely accurate. On OMAP4430 I did not see any issues with the DPLL failing to turn on if the DPLL was not locked. I only saw this particular problem on the 4460. Therefore, it may be better to leave the comment as-is and add an additional sentence to state that the DPLL should be locked for all OMAP4 devices for audio to work correctly. 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: [RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver
On 12/21/2012 04:27 PM, Pratik Patel wrote:
> On Wed, Dec 12, 2012 at 03:43:06PM -0600, Jon Hunter wrote:
>> +
>> +/**
>> + * cti_irq_ack - acknowledges the CTI trigger output
>> + * @cti: CTI instance
>> + *
>> + * Acknowledges the CTI trigger output by writting to the appropriate
>> + * bit in the CTI interrupt acknowledge register.
>> + */
>> +int cti_irq_ack(struct cti *cti)
>> +{
>> +u32 v;
>> +
>> +if (!cti || !cti->enabled)
>> +return -EINVAL;
>> +
>> +v = cti_readl(cti, CTIINTACK);
>
> Just curious if CTIINTACK is a read-write register? This is a
> read-only for us.
>
>> +v |= BIT(cti->trig_out);
>> +cti_writel(v, cti, CTIINTACK);
>> +
>> +return 0;
>> +}
>> +
>> +
>> +static int cti_probe(struct amba_device *dev, const struct amba_id *id)
>> +{
>> +struct cti *cti;
>> +struct device_node *np = dev->dev.of_node;
>> +int rc;
>> +
>> +if (!np) {
>> +dev_err(&dev->dev, "device-tree not found!\n");
>> +return -ENODEV;
>> +}
>> +
>> +cti = devm_kzalloc(&dev->dev, sizeof(struct cti), GFP_KERNEL);
>> +if (!cti) {
>> +dev_err(&dev->dev, "memory allocation failed!\n");
>> +return -ENOMEM;
>> +}
>> +
>> +rc = of_property_read_string_index(np, "arm,cti-name", 0, &cti->name);
>> +if (rc) {
>> +dev_err(&dev->dev, "no name found for CTI!\n");
>> +return rc;
>> +}
>
> Shouldn't the CTI driver have some kind of clock management that
> it does for itself?
It does by using runtime PM. If you look at the cti_get/put functions,
you will see calls to pm_runtime_get/put. These calls will enable the
AMBA apb-clock. If you need to enable additional clocks then you could
register pm runtime resume/idle call backs to do this.
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: [RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver
On 12/21/2012 04:35 PM, Pratik Patel wrote:
> On Fri, Dec 21, 2012 at 02:27:03PM -0800, Pratik Patel wrote:
>> On Wed, Dec 12, 2012 at 03:43:06PM -0600, Jon Hunter wrote:
>>> +
>>> +/**
>>> + * cti_irq_ack - acknowledges the CTI trigger output
>>> + * @cti: CTI instance
>>> + *
>>> + * Acknowledges the CTI trigger output by writting to the appropriate
>>> + * bit in the CTI interrupt acknowledge register.
>>> + */
>>> +int cti_irq_ack(struct cti *cti)
>>> +{
>>> + u32 v;
>>> +
>>> + if (!cti || !cti->enabled)
>>> + return -EINVAL;
>>> +
>>> + v = cti_readl(cti, CTIINTACK);
>>
>> Just curious if CTIINTACK is a read-write register? This is a
>> read-only for us.
>>
> Mistyped - its a write-only for us
You are right. Looking at the ARM documentation this is a write-only
register. I had copied this function from the original helpers but had
not checked if this was readable. I will correct this.
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: OMAP3: Add missing enable/disable for EMU clock
The ETM/ETB drivers for OMAP3, enable the emu_src_ck clock in order
to access the ETM/ETB hardware. The emu_src_ck should enable the EMU
clock domain so that the ETM/ETB hardware is accessible. However,
currently when enabling the emu_src_ck the EMU clock domain is not
being enabled and so the ETM/ETB drivers are failing. Add enable/disable
clock functions to enable the EMU clock domain when enabling the
emu_src_ck.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index bdf3948..6ef8758 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -1167,6 +1167,8 @@ static const struct clk_ops emu_src_ck_ops = {
.recalc_rate= &omap2_clksel_recalc,
.get_parent = &omap2_clksel_find_parent_index,
.set_parent = &omap2_clksel_set_parent,
+ .enable = &omap2_clkops_enable_clkdm,
+ .disable= &omap2_clkops_disable_clkdm,
};
static struct clk emu_src_ck;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: implement irq_enable/disable using mask/unmask.
On 12/19/2012 11:59 PM, Santosh Shilimkar wrote:
> On Monday 17 December 2012 02:57 PM, Andreas Fenkart wrote:
>
> Please add some changelog here too.
>
>> Signed-off-by: Andreas Fenkart
>> ---
> Patch seems straight forward thought will be interesting where you found
> the need of it.
The only item that I was thinking of if the behaviour of mask/unmask
should be different from enable/disable?
When a gpio interrupt is masked, the gpio event will still be latched in
the interrupt status register so when you unmask it later you may get an
interrupt straight away. However, if the interrupt is disabled then gpio
events occurring will not be latched/stored.
I am also interested in the need for this, and if we should have a true
enable/disable here.
Cheers
Jon
>
>> drivers/gpio/gpio-omap.c |2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index d335af1..c1951ec 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -815,6 +815,8 @@ static struct irq_chip gpio_irq_chip = {
>> .irq_unmask= gpio_unmask_irq,
>> .irq_set_type= gpio_irq_type,
>> .irq_set_wake= gpio_wake_enable,
>> +.irq_disable= gpio_mask_irq,
>> +.irq_enable = gpio_unmask_irq,
>> };
>>
>>
>> /*-*/
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/12] ARM: OMAP2+: powerdomain: skip register reads for powerdomains known to be on
Hi Paul,
On 12/09/2012 02:03 PM, Paul Walmsley wrote:
> There's no need to determine the current power state for powerdomains
> that must be on while the kernel is running. We mark these
> powerdomains with a new flag, PWRDM_ACTIVE_WITH_KERNEL. Any
> powerdomain marked with that flag is reported as being in the ON power
> state while the kernel is running.
>
> Signed-off-by: Paul Walmsley
> Cc: Benoît Cousson
> ---
> arch/arm/mach-omap2/powerdomain.c |9 ++---
> arch/arm/mach-omap2/powerdomain.h |4
> arch/arm/mach-omap2/powerdomains2xxx_data.c |2 ++
> arch/arm/mach-omap2/powerdomains33xx_data.c |3 ++-
> arch/arm/mach-omap2/powerdomains3xxx_data.c |9 ++---
> arch/arm/mach-omap2/powerdomains44xx_data.c |5 -
> 6 files changed, 24 insertions(+), 8 deletions(-)
[snip]
> diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
> b/arch/arm/mach-omap2/powerdomains44xx_data.c
> index 704664c..b64213c 100644
> --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
> +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
> @@ -53,7 +53,8 @@ static struct powerdomain core_44xx_pwrdm = {
> [3] = PWRSTS_ON,/* ducati_l2ram */
> [4] = PWRSTS_ON,/* ducati_unicache */
> },
> - .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
> + .flags= (PWRDM_HAS_LOWPOWERSTATECHANGE |
> + PWRDM_ACTIVE_WITH_KERNEL),
> };
My understanding is that for OMAP4 devices, the core power domain may
not be active the same time as the MPU power domain. The Cortex-A9 has
the ability to access some peripherals (such as timer, McBSP) via a
private bus that does not require the core domain to be active. This is
a difference from OMAP3 devices, where the core would always be on with
the MPU power domain.
Hopefully, Benoit will chime in if I have gotten this 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 V6 2/2] dmaengine: add helper function to request a slave DMA channel
Hi Vinod, On 11/15/2012 07:37 PM, Vinod Koul wrote: > On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: >> 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? >> > I have not been able to do much work on this for last couple of weeks. I > hope to do it in by this weekend. If not I will merge yours and then > uppdate. > > Anyway, DT would be there in 3.8 with or without my changes. I am not sure if I have missed your pull request, but wanted to see if you had or were going to send a pull request for the DT changes for v3.8? I believe that the merge window ends this week. 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: invalid references to vram.h
On 12/17/2012 04:14 PM, Carlos Hernandez wrote: > Just an fyi... am335x mainline compilation is broken due to invalid > references to vram.h > > | CC arch/arm/mach-omap2/common.o > | arch/arm/mach-omap2/common.c:19:23: fatal error: plat/vram.h: No such > file or directory > > Test run against commit fa4c95bfdb85d568ae327d57aa33a4f55bab79c4 I believe a fix is already queued [1]. Jon [1] http://marc.info/?l=linux-omap&m=135577145305783&w=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 V2 0/2] ARM: dts: Add PMU support for OMAP2+
On 12/17/2012 11:49 AM, Jon Hunter wrote: > Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. OMAP4430 > is not included because PMU is not currently supported on this device > due to absence of a cross-trigger interface driver. > > Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board. > Boot tested only on OMAP2420 H4. Forgot to mention that V2, addresses Mark Rutland's comment on interrupt syntax for omap4460 PMU node. I also added a comment on why OMAP4430 is not supported 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
[PATCH V2 2/2] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = "arm,arm1136-pmu";
+ interrupts = <3>;
+ };
+
soc {
compatible = "ti,omap-infra";
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ ti,hwmods = "debugss";
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ "omap4-panda.dts"
+/include/ "omap4460.dtsi"
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
&sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..0a1d38b
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <0 54 0x4>,
+<0 55 0x4>;
+ ti,hwmods = "debugss";
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/2] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include
+
#include
#include "soc.h"
@@ -64,6 +66,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -76,9 +87,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/2] ARM: dts: Add PMU support for OMAP2+
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. OMAP4430 is not included because PMU is not currently supported on this device due to absence of a cross-trigger interface driver. Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board. Boot tested only on OMAP2420 H4. Jon Hunter (2): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |6 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 ++ arch/arm/boot/dts/omap4460.dtsi | 18 ++ arch/arm/mach-omap2/pmu.c| 14 +++--- 5 files changed, 42 insertions(+), 3 deletions(-) create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes
On 12/17/2012 10:38 AM, Mark Rutland wrote:
> On Fri, Dec 14, 2012 at 09:26:37PM +0000, Jon Hunter wrote:
>> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
>>
>> Please note that the node for OMAP4460 has been placed in a separate
>> header file for OMAP4460, because the node is not compatible with
>> OMAP4430.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/boot/dts/omap2.dtsi |5 +
>> arch/arm/boot/dts/omap3.dtsi |6 ++
>> arch/arm/boot/dts/omap4-panda-es.dts |2 ++
>> arch/arm/boot/dts/omap4460.dtsi | 18 ++
>> 4 files changed, 31 insertions(+)
>> create mode 100644 arch/arm/boot/dts/omap4460.dtsi
>>
>> diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
>> index 761c4b6..27f5ea1 100644
>> --- a/arch/arm/boot/dts/omap2.dtsi
>> +++ b/arch/arm/boot/dts/omap2.dtsi
>> @@ -26,6 +26,11 @@
>> };
>> };
>>
>> +pmu {
>> +compatible = "arm,arm1136-pmu";
>> +interrupts = <3>;
>> +};
>> +
>> soc {
>> compatible = "ti,omap-infra";
>> mpu {
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 1acc261..6c63118 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -26,6 +26,12 @@
>> };
>> };
>>
>> +pmu {
>> +compatible = "arm,cortex-a8-pmu";
>> +interrupts = <3>;
>> +ti,hwmods = "debugss";
>> +};
>> +
>> /*
>> * The soc node represents the soc top level view. It is uses for IPs
>> * that are not memory mapped in the MPU view or for the MPU itself.
>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>> b/arch/arm/boot/dts/omap4-panda-es.dts
>> index 73bc1a6..2a6e344 100644
>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>> @@ -5,7 +5,9 @@
>> * it under the terms of the GNU General Public License version 2 as
>> * published by the Free Software Foundation.
>> */
>> +
>> /include/ "omap4-panda.dts"
>> +/include/ "omap4460.dtsi"
>>
>> /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
>> &sound {
>> diff --git a/arch/arm/boot/dts/omap4460.dtsi
>> b/arch/arm/boot/dts/omap4460.dtsi
>> new file mode 100644
>> index 000..1270890
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap4460.dtsi
>> @@ -0,0 +1,18 @@
>> +/*
>> + * Device Tree Source for OMAP4460 SoC
>> + *
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This file is licensed under the terms of the GNU General Public License
>> + * version 2. This program is licensed "as is" without any warranty of any
>> + * kind, whether express or implied.
>> + */
>> +
>> +/ {
>> +pmu {
>> +compatible = "arm,cortex-a9-pmu";
>> +interrupts = <0 54 0x4
>> + 0 55 0x4>;
>
> In other places I've seen interrupts properties written as:
>
> interrupts = < irq1... >,
> < irq2... >,
>< irqN... >;
>
> Where each individual interrupt is surrounded by angle brackets. This produces
> the exact same dtb, but may appear easier to read.
>
> This might not be the right time and place to raise it, but it'd be nice if we
> used one style consistently.
I see that we do define interrupts like that for other OMAP devices and
so I can update this to be consistent.
Benoit, let me know if you want me to resend or if you want to update
locally.
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: [RFC 2/5] ARM: dts: Add Cross Trigger Interface binding
On 12/17/2012 10:20 AM, Mark Rutland wrote: > On Thu, Dec 13, 2012 at 07:21:30PM +0000, Jon Hunter wrote: >> >> On 12/13/2012 11:41 AM, Will Deacon wrote: >>> On Wed, Dec 12, 2012 at 09:43:05PM +, Jon Hunter wrote: >>>> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI). >>>> The ARM Cross Trigger Interface provides a way to route events between >>>> processor modules. For example, on OMAP4430 we use the CTI module to >>>> route PMU events to the GIC interrupt module. >>>> >>>> Signed-off-by: Jon Hunter >>>> --- >>>> Documentation/devicetree/bindings/arm/cti.txt | 32 >>>> + >>>> 1 file changed, 32 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/arm/cti.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/cti.txt >>>> b/Documentation/devicetree/bindings/arm/cti.txt >>>> new file mode 100644 >>>> index 000..4a0e2d3 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/arm/cti.txt >>>> @@ -0,0 +1,32 @@ >>>> +* ARM Cross Trigger Interface (CTI) >>>> + >>>> +The ARM Cross Trigger Interface provides a way to route events between >>>> +processor modules. For example, debug events from one processor can be >>>> +broadcasted to other processors. The events that can be routed between >>>> +processors are specific to the device. >>>> + >>>> +Required properties: >>>> + >>>> +- compatible: Should be "arm,primecell". >>>> +- interrupts: Interrupt associated with CTI module. >>>> +- reg:Contains timer register address range >>>> (base >>>> + address and length). >>>> +- arm,cti-name: A unique name for the CTI module, that >>>> will be >>>> + used when requesting the CTI module instance. >>>> + >>>> + >>>> +Optional properties: >>>> + >>>> +- arm-primecell-periphid: Primecell peripheral ID associated with CTI >>>> + module. >>> >>> For multi-cluster systems, I wouldn't be surprised to see multiple CTI >>> instances, each with different CPU affinities. Can we include an affinity >>> property following Mark's proposed binding? >>> >>> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html >> >> Yes I can take a look. Would something like that be applicable to pmu as >> well or is that unlikely to have different affinities? I am just >> wondering if there is something that we should implement in general for >> the various primecell components. > > Do you mean for describing the PMU's affinity to the perf subsystem or its > wiring to the CTI? Yes the PMU's affinity in general, ignoring CTI for now. > It's certainly applicable for the former; I've been working on a series to > enable support for the PMUs in both clusters in a A15x2 A7x3 coretile using > the > binding, and I intend to post a series shortly. I'm not sure about the latter, > as I don't have much of an understanding about the CTI. Ok great. I think that this use-case of PMU+CTI is a special case for OMAP. CTI could be used for many things and for some reason TI hooked up the PMU interrupt via the CTI on OMAP4430 (which has been giving me grief ;-) So if there is a general way to describe the affinity of a module, such as PMU, I could re-use this and add to the CTI binding as Will suggested. > I'm not sure how many other components have affinity concerns, but the > intention is for the binding to be reusable. Great. 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 2/2] ARM: dts: OMAP2+: Add PMU nodes
On 12/17/2012 02:16 AM, Benoit Cousson wrote: > Hi Jon, > > On 12/14/2012 10:18 PM, Jon Hunter wrote: >> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices. >> >> Please note that the node for OMAP4460 has been placed in a separate >> header file for OMAP4460, because the node is not compatible with >> OMAP4430. > > But where is the omap4430 node then? I have left it out deliberately because OMAP4430 is not yet supported by PMU as it is dependent on having a driver for the cross-trigger interface. If you prefer to stick the node in the omap4.dtsi for now then that is ok, but I wanted to make it clear that this is for omap4460. 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: dts: Add build target for omap4-panda-a4
Commit 0d9250c (ARM: dts: omap4-panda: Add pinmux configuration for HDMI) added a new device-tree source file for Rev A4 of the OMAP4430 Panda board but it did not add this version to the makefile. Hence, add this file to the makefile. Signed-off-by: Jon Hunter --- arch/arm/boot/dts/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 2af359c..f8b4ff4 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -105,6 +105,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap3-evm.dtb \ omap3-tobi.dtb \ omap4-panda.dtb \ + omap4-panda-a4.dtb \ omap4-panda-es.dtb \ omap4-var-som.dtb \ omap4-sdp.dtb \ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = "arm,arm1136-pmu";
+ interrupts = <3>;
+ };
+
soc {
compatible = "ti,omap-infra";
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ ti,hwmods = "debugss";
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ "omap4-panda.dts"
+/include/ "omap4460.dtsi"
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
&sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..1270890
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <0 54 0x4
+ 0 55 0x4>;
+ ti,hwmods = "debugss";
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 1/2] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include
+
#include
#include "soc.h"
@@ -64,6 +66,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -76,9 +87,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 0/2] ARM: dts: Add PMU support for OMAP2+
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board. Boot tested only on OMAP2420 H4. Jon Hunter (2): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |6 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 ++ arch/arm/boot/dts/omap4460.dtsi | 18 ++ arch/arm/mach-omap2/pmu.c| 14 +++--- 5 files changed, 42 insertions(+), 3 deletions(-) create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes
On 12/14/2012 03:18 PM, Jon Hunter wrote:
> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
>
> Please note that the node for OMAP4460 has been placed in a separate
> header file for OMAP4460, because the node is not compatible with
> OMAP4430.
>
> Signed-off-by: Jon Hunter
> ---
> arch/arm/boot/dts/omap2.dtsi |5 +
> arch/arm/boot/dts/omap3.dtsi |6 ++
> arch/arm/boot/dts/omap4-panda-es.dts |2 ++
> arch/arm/boot/dts/omap4460.dtsi | 18 ++
> arch/arm/mach-omap2/pmu.c|2 ++
> 5 files changed, 33 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap4460.dtsi
>
> diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
> index 761c4b6..27f5ea1 100644
> --- a/arch/arm/boot/dts/omap2.dtsi
> +++ b/arch/arm/boot/dts/omap2.dtsi
> @@ -26,6 +26,11 @@
> };
> };
>
> + pmu {
> + compatible = "arm,arm1136-pmu";
> + interrupts = <3>;
> + };
> +
> soc {
> compatible = "ti,omap-infra";
> mpu {
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 1acc261..6c63118 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -26,6 +26,12 @@
> };
> };
>
> + pmu {
> + compatible = "arm,cortex-a8-pmu";
> + interrupts = <3>;
> + ti,hwmods = "debugss";
> + };
> +
> /*
>* The soc node represents the soc top level view. It is uses for IPs
>* that are not memory mapped in the MPU view or for the MPU itself.
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 73bc1a6..2a6e344 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -5,7 +5,9 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> +
> /include/ "omap4-panda.dts"
> +/include/ "omap4460.dtsi"
>
> /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
> &sound {
> diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
> new file mode 100644
> index 000..1270890
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4460.dtsi
> @@ -0,0 +1,18 @@
> +/*
> + * Device Tree Source for OMAP4460 SoC
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/ {
> + pmu {
> + compatible = "arm,cortex-a9-pmu";
> + interrupts = <0 54 0x4
> + 0 55 0x4>;
> + ti,hwmods = "debugss";
> + };
> +};
> diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
> index 6e620eb..1a0799c 100644
> --- a/arch/arm/mach-omap2/pmu.c
> +++ b/arch/arm/mach-omap2/pmu.c
> @@ -11,6 +11,8 @@
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> */
> +#include
> +
Oops! I screwed something up here when rebasing. Resending this shortly ...
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 2/2] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
arch/arm/mach-omap2/pmu.c|2 ++
5 files changed, 33 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = "arm,arm1136-pmu";
+ interrupts = <3>;
+ };
+
soc {
compatible = "ti,omap-infra";
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ ti,hwmods = "debugss";
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ "omap4-panda.dts"
+/include/ "omap4460.dtsi"
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
&sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..1270890
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <0 54 0x4
+ 0 55 0x4>;
+ ti,hwmods = "debugss";
+ };
+};
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 6e620eb..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include
+
#include
#include "soc.h"
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..6e620eb 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -64,6 +64,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -76,9 +85,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: dts: Add PMU support for OMAP2+
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board. Boot tested only on OMAP2420 H4. Jon Hunter (2): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |6 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 ++ arch/arm/boot/dts/omap4460.dtsi | 18 ++ arch/arm/mach-omap2/pmu.c| 14 +++--- 5 files changed, 42 insertions(+), 3 deletions(-) create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: OMAP2420: Correct H4 board memory size
The system memory node for the OMAP2420 H4 was incorrectly defined as
start address followed by end address, instead of start address and
size. No noticable side-effects were observed but fix this for
correctness.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 77b84e1..9b0d077 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -15,6 +15,6 @@
memory {
device_type = "memory";
- reg = <0x8000 0x8400>; /* 64 MB */
+ reg = <0x8000 0x400>; /* 64 MB */
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: PMU: Remove unused header
Commit 2ac29a1 (ARM: PMU: fix runtime PM enable) moved the call to pm_runtime_enable() from the OMAP2+ PMU code into the ARM PERF core code. However, header for pm_runtime which should have been removed from the OMAP2+ PMU code was not. It is no longer necessary to include this header in the OMAP2+ PMU code and so remove it. Signed-off-by: Jon Hunter --- arch/arm/mach-omap2/pmu.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c index 250d909..eb78ae7 100644 --- a/arch/arm/mach-omap2/pmu.c +++ b/arch/arm/mach-omap2/pmu.c @@ -11,8 +11,6 @@ * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. */ -#include - #include #include "soc.h" -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: Timer build warnings fixes for v3.8-rc
The following changes since commit 698d601224824bc1a5bf17f3d86be902e2aabff0: Merge tag 'drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-12-13 10:59:11 -0800) are available in the git repository at: git://github.com/jonhunter/linux.git fixes-timer-build for you to fetch changes up to bf85f205d95eb223e849914101e0db1a5a576a3c: ARM: OMAP2+: Fix sparse warnings in timer.c (2012-12-14 10:14:55 -0600) Fixes for a few timer warnings observed with different kernel configurations for OMAP2+ devices. I have dropped the patch to fix a build error for OMAP4 in the timer code as Olof already has this fix merged. ---- Jon Hunter (2): ARM: OMAP2+: Fix realtime_counter_init warning in timer.c ARM: AM335x: Fix warning in timer.c Vaibhav Hiremath (1): ARM: OMAP2+: Fix sparse warnings in timer.c arch/arm/mach-omap2/Kconfig |3 ++- arch/arm/mach-omap2/timer.c |6 +++--- 2 files changed, 5 insertions(+), 4 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
