Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
Kumar,
>>
>> On 09/03/2013 01:50 PM, Kumar Gala wrote:
>>>
>>> On Sep 3, 2013, at 12:52 PM, Suman Anna wrote:
>>>
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60
--
drivers/hwspinlock/omap_hwspinlock.c | 21 ++--
4 files changed, 45 insertions(+), 67 deletions(-)
create mode 100644
Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..adfb8ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,28 @@
+OMAP4+ HwSpinlock Driver
+
+Required properties:
+- compatible: Currently supports only "ti,omap4-hwspinlock"
for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg:Contains the hwspinlock register address range
(base
+ address and length)
+- ti,hwmods: Name of the hwmod associated with the
hwspinlock device
+
+Optional properties:
+- base_id:Base Id for the locks for a particular
hwspinlock
+ device. If not mentioned, a default value of 0 is used.
+ This property is mandatory ONLY if a SoC has several
+ hwspinlock devices. There are currently no such OMAP
+ SoCs.
>>>
>>> Should this be ti,base_id ? [ I know its kinda generic in its intent for
>>> any SoC w/multiple blocks ]
>>
>> I didn't add the "ti," prefix exactly for the same reason - it is
>> generic w.r.t the hwspinlock core irrespective of the SoC family, and
>> there is nothing ti or OMAP specific about it. I have added it to keep
>> the DT node definition in sync with the driver code. If it is too
>> generic a name, it can always be renamed as hwlock_base_id. This will be
>> SoC agnostic property for the hwspinlock driver. What do you think?
>
> I'm wondering if we should use cell-index for this purpose.
I didn't get you completely. Do you intend to compute the base_id using
cell-index and number of locks (which may be a separate field altogether
if this information cannot be read from the h/w)? My understanding is
that cell-index is primarily used for identifying the h/w instance number.
regards
Suman
>>
>>>
+
+ See documentation on struct hwspinlock_pdata in
+ linux/hwspinlock.h for more details.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = "ti,omap4-hwspinlock";
+ reg = <0x4a0f6000 0x1000>;
+ ti,hwmods = "spinlock";
+};
>>>
>>> [ snip ]
>>>
>>> - k
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.12 take #2
Hi Olof, On 03/09/2013 17:06, Olof Johansson wrote: Benoit, On Fri, Aug 30, 2013 at 1:30 PM, Benoit Cousson wrote: Hi Kevin & Olof, Here is the updated version without the conflicting patch (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) and with the signed tag. There is still a small conflict with usb-next, but it is easily fixable, and already fixed by Stephen. Sorry, I wasn't able to get this pulled in before the merge window opened, so it'll unfortunately have to wait until 3.13. Please send a fresh pull request as soon as -rc1 is out. Gosh :-( That was just the update of the previous conflicting one. Did you remove the older version as well? It looks like a few of these are fixes (at least from the patch topics), we'd of course be happy to take those. OK, I'll extract the fixes for 3.12-rc. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
On Sep 3, 2013, at 2:10 PM, Suman Anna wrote:
> Kumar,
>
> On 09/03/2013 01:50 PM, Kumar Gala wrote:
>>
>> On Sep 3, 2013, at 12:52 PM, Suman Anna wrote:
>>
>>> HwSpinlock IP is present only on OMAP4 and other newer SoCs,
>>> which are all device-tree boot only. This patch adds the
>>> base support for parsing the DT nodes, and removes the code
>>> dealing with the traditional platform device instantiation.
>>>
>>> Signed-off-by: Suman Anna
>>> ---
>>> .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++
>>> arch/arm/mach-omap2/Makefile | 3 --
>>> arch/arm/mach-omap2/hwspinlock.c | 60
>>> --
>>> drivers/hwspinlock/omap_hwspinlock.c | 21 ++--
>>> 4 files changed, 45 insertions(+), 67 deletions(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>> delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>> b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>> new file mode 100644
>>> index 000..adfb8ad
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>> @@ -0,0 +1,28 @@
>>> +OMAP4+ HwSpinlock Driver
>>> +
>>> +Required properties:
>>> +- compatible: Currently supports only "ti,omap4-hwspinlock"
>>> for
>>> + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
>>> +- reg: Contains the hwspinlock register address range
>>> (base
>>> + address and length)
>>> +- ti,hwmods: Name of the hwmod associated with the
>>> hwspinlock device
>>> +
>>> +Optional properties:
>>> +- base_id: Base Id for the locks for a particular hwspinlock
>>> + device. If not mentioned, a default value of 0 is used.
>>> + This property is mandatory ONLY if a SoC has several
>>> + hwspinlock devices. There are currently no such OMAP
>>> + SoCs.
>>
>> Should this be ti,base_id ? [ I know its kinda generic in its intent for any
>> SoC w/multiple blocks ]
>
> I didn't add the "ti," prefix exactly for the same reason - it is
> generic w.r.t the hwspinlock core irrespective of the SoC family, and
> there is nothing ti or OMAP specific about it. I have added it to keep
> the DT node definition in sync with the driver code. If it is too
> generic a name, it can always be renamed as hwlock_base_id. This will be
> SoC agnostic property for the hwspinlock driver. What do you think?
I'm wondering if we should use cell-index for this purpose.
- k
>
> regards
> Suman
>
>>
>>> +
>>> + See documentation on struct hwspinlock_pdata in
>>> + linux/hwspinlock.h for more details.
>>> +
>>> +
>>> +Example:
>>> +
>>> +/* OMAP4 */
>>> +hwspinlock: spinlock@4a0f6000 {
>>> + compatible = "ti,omap4-hwspinlock";
>>> + reg = <0x4a0f6000 0x1000>;
>>> + ti,hwmods = "spinlock";
>>> +};
>>
>> [ snip ]
>>
>> - k
>>
>
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe 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] hwspinlock/omap: add support for dt nodes
Kumar,
On 09/03/2013 01:50 PM, Kumar Gala wrote:
>
> On Sep 3, 2013, at 12:52 PM, Suman Anna wrote:
>
>> HwSpinlock IP is present only on OMAP4 and other newer SoCs,
>> which are all device-tree boot only. This patch adds the
>> base support for parsing the DT nodes, and removes the code
>> dealing with the traditional platform device instantiation.
>>
>> Signed-off-by: Suman Anna
>> ---
>> .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++
>> arch/arm/mach-omap2/Makefile | 3 --
>> arch/arm/mach-omap2/hwspinlock.c | 60
>> --
>> drivers/hwspinlock/omap_hwspinlock.c | 21 ++--
>> 4 files changed, 45 insertions(+), 67 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>> delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>> b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>> new file mode 100644
>> index 000..adfb8ad
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>> @@ -0,0 +1,28 @@
>> +OMAP4+ HwSpinlock Driver
>> +
>> +Required properties:
>> +- compatible: Currently supports only "ti,omap4-hwspinlock"
>> for
>> +OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
>> +- reg: Contains the hwspinlock register address range
>> (base
>> +address and length)
>> +- ti,hwmods:Name of the hwmod associated with the
>> hwspinlock device
>> +
>> +Optional properties:
>> +- base_id: Base Id for the locks for a particular hwspinlock
>> +device. If not mentioned, a default value of 0 is used.
>> +This property is mandatory ONLY if a SoC has several
>> +hwspinlock devices. There are currently no such OMAP
>> +SoCs.
>
> Should this be ti,base_id ? [ I know its kinda generic in its intent for any
> SoC w/multiple blocks ]
I didn't add the "ti," prefix exactly for the same reason - it is
generic w.r.t the hwspinlock core irrespective of the SoC family, and
there is nothing ti or OMAP specific about it. I have added it to keep
the DT node definition in sync with the driver code. If it is too
generic a name, it can always be renamed as hwlock_base_id. This will be
SoC agnostic property for the hwspinlock driver. What do you think?
regards
Suman
>
>> +
>> +See documentation on struct hwspinlock_pdata in
>> +linux/hwspinlock.h for more details.
>> +
>> +
>> +Example:
>> +
>> +/* OMAP4 */
>> +hwspinlock: spinlock@4a0f6000 {
>> +compatible = "ti,omap4-hwspinlock";
>> +reg = <0x4a0f6000 0x1000>;
>> +ti,hwmods = "spinlock";
>> +};
>
> [ snip ]
>
> - k
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
On Tue, Sep 3, 2013 at 11:55 AM, Russ Dill wrote: > On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman wrote: >> Well, I was thinking of something much dumber. >> >> I was thinking about just _carefully_ writing a single, self-contained C >> function, with all of its data on the stack (and consts as #defines). >> Think of it is a step up in readability from straight assembly (which >> was the stated reason for moving the code to the M3 in the first place.) >> >> Kevin > > That can only give you your suspend function. You need a resume > function to undo everything before calling cpu_resume, and the resume > function needs access to the data that was in the suspend function. Well, it can be done (and I've seen it done) with various hacks, but I agree it's not pretty, but it is at least slightly prettier than piles of asm. That being said, I saw you posted a more generic solution that looks like a real solution that can scale. I'll have a closer look at that. Thanks for working on it. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman wrote: > Well, I was thinking of something much dumber. > > I was thinking about just _carefully_ writing a single, self-contained C > function, with all of its data on the stack (and consts as #defines). > Think of it is a step up in readability from straight assembly (which > was the stated reason for moving the code to the M3 in the first place.) > > Kevin That can only give you your suspend function. You need a resume function to undo everything before calling cpu_resume, and the resume function needs access to the data that was in the suspend function. -- To unsubscribe from this list: send the line "unsubscribe 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] hwspinlock/omap: add support for dt nodes
On Sep 3, 2013, at 12:52 PM, Suman Anna wrote:
> HwSpinlock IP is present only on OMAP4 and other newer SoCs,
> which are all device-tree boot only. This patch adds the
> base support for parsing the DT nodes, and removes the code
> dealing with the traditional platform device instantiation.
>
> Signed-off-by: Suman Anna
> ---
> .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++
> arch/arm/mach-omap2/Makefile | 3 --
> arch/arm/mach-omap2/hwspinlock.c | 60 --
> drivers/hwspinlock/omap_hwspinlock.c | 21 ++--
> 4 files changed, 45 insertions(+), 67 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
> delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
>
> diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
> b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
> new file mode 100644
> index 000..adfb8ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
> @@ -0,0 +1,28 @@
> +OMAP4+ HwSpinlock Driver
> +
> +Required properties:
> +- compatible:Currently supports only "ti,omap4-hwspinlock"
> for
> + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
> +- reg: Contains the hwspinlock register address range
> (base
> + address and length)
> +- ti,hwmods: Name of the hwmod associated with the hwspinlock device
> +
> +Optional properties:
> +- base_id: Base Id for the locks for a particular hwspinlock
> + device. If not mentioned, a default value of 0 is used.
> + This property is mandatory ONLY if a SoC has several
> + hwspinlock devices. There are currently no such OMAP
> + SoCs.
Should this be ti,base_id ? [ I know its kinda generic in its intent for any
SoC w/multiple blocks ]
> +
> + See documentation on struct hwspinlock_pdata in
> + linux/hwspinlock.h for more details.
> +
> +
> +Example:
> +
> +/* OMAP4 */
> +hwspinlock: spinlock@4a0f6000 {
> + compatible = "ti,omap4-hwspinlock";
> + reg = <0x4a0f6000 0x1000>;
> + ti,hwmods = "spinlock";
> +};
[ snip ]
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP4: Add hwspinlock node
Add the hwspinlock device tree node for OMAP4 family
of SoCs.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..a8cc274 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -248,6 +248,12 @@
clock-frequency = <4800>;
};
+ hwspinlock: spinlock@4a0f6000 {
+ compatible = "ti,omap4-hwspinlock";
+ reg = <0x4a0f6000 0x1000>;
+ ti,hwmods = "spinlock";
+ };
+
i2c1: i2c@4807 {
compatible = "ti,omap4-i2c";
reg = <0x4807 0x100>;
--
1.8.3.3
--
To unsubscribe from this list: send the line "unsubscribe 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] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60 --
drivers/hwspinlock/omap_hwspinlock.c | 21 ++--
4 files changed, 45 insertions(+), 67 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..adfb8ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,28 @@
+OMAP4+ HwSpinlock Driver
+
+Required properties:
+- compatible: Currently supports only "ti,omap4-hwspinlock" for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock register address range (base
+ address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+
+Optional properties:
+- base_id: Base Id for the locks for a particular hwspinlock
+ device. If not mentioned, a default value of 0 is used.
+ This property is mandatory ONLY if a SoC has several
+ hwspinlock devices. There are currently no such OMAP
+ SoCs.
+
+ See documentation on struct hwspinlock_pdata in
+ linux/hwspinlock.h for more details.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = "ti,omap4-hwspinlock";
+ reg = <0x4a0f6000 0x1000>;
+ ti,hwmods = "spinlock";
+};
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..a17b5b8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -288,9 +288,6 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que
- * Hari Kanigeri
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include
-#include
-#include
-#include
-
-#include "soc.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = "spinlock";
- const char *dev_name = "omap_hwspinlock";
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, &omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err("Can't build omap_device for %s:%s\n", dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..d928235 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinl
[PATCH 0/2] omap hwspinlock dt support
Hi, This series adds the device tree support to the OMAP hwspinlock driver. The series is based on 3.11 kernel, and currently adds the DT node for OMAP4. Since all the OMAP SoCs on which hwspinlock is supported are currently DT-boot only, I have combined the dt parsing support and removing the mach-omap2/hwspinlock.c cleanup into the first patch. This mandates that a DT node be defined to use a hwspinlock on an OMAP SoC, even though the 3.11 kernel could instantiate the devices normally even in a DT-boot mode. The DT binding documentation is added using the folder name hwlock (same name from the MSM HW Mutex driver support series in [1]). [1] https://lkml.org/lkml/2013/8/14/528 Suman Anna (2): hwspinlock/omap: add support for dt nodes ARM: dts: OMAP4: Add hwspinlock node .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++ arch/arm/boot/dts/omap4.dtsi | 6 +++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/omap_hwspinlock.c | 21 ++-- 5 files changed, 51 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c -- 1.8.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap: panda rcu stall on 3.10.1
On Fri, Aug 30, 2013 at 08:27:32AM +0200, Christian Hoffmann wrote:
>
> > This also went to: linaro-ker...@lists.linaro.org
>
> Hi,
>
> current linaro kernel on 13.07 (3.10.1.0-1-linaro-omap) shows stack
> below. System is generally quite unstable. Light usage
> (postfix+dovecot...)
>
> Full dmesg here:
> https://dl.dropboxusercontent.com/u/21820416/rcu.stall.panda
Looks to me like the CPU stall is cascaded problem. Prior to this in
dmesg, you have several "terminated with status N" messages, where N!=0.
I believe that fixing the problems leading to these messages would be
a good first step.
Thanx, Paul
> Rgds,
> Chris
>
> [ 4538.880432] INFO: rcu_sched detected stalls on CPUs/tasks: { 1}
> (detected by 0, t=2103 jiffies, g=1649, c=1648, q=18)
> [ 4538.891723] Backtrace for cpu 0 (current):
> [ 4538.891723] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
> [ 4538.891754] [] (unwind_backtrace+0x1/0x9c) from
> [] (show_stack+0x11/0x14)
> [ 4538.891815] [] (show_stack+0x11/0x14) from []
> (smp_send_all_cpu_backtrace+0x49/0x98)
> [ 4538.891815] [] (smp_send_all_cpu_backtrace+0x49/0x98) from
> [] (rcu_check_callbacks+0x439/0x4ac)
> [ 4538.891815] [] (rcu_check_callbacks+0x439/0x4ac) from
> [] (update_process_times+0x2d/0x4c)
> [ 4538.891876] [] (update_process_times+0x2d/0x4c) from
> [] (tick_sched_handle+0x35/0x40)
> [ 4538.891906] [] (tick_sched_handle+0x35/0x40) from
> [] (tick_sched_timer+0x31/0x54)
> [ 4538.891937] [] (tick_sched_timer+0x31/0x54) from
> [] (__run_hrtimer+0x5b/0x138)
> [ 4538.891937] [] (__run_hrtimer+0x5b/0x138) from []
> (hrtimer_interrupt+0xdb/0x22c)
> [ 4538.891967] [] (hrtimer_interrupt+0xdb/0x22c) from
> [] (twd_handler+0x1b/0x28)
> [ 4538.891998] [] (twd_handler+0x1b/0x28) from []
> (handle_percpu_devid_irq+0x4d/0xac)
> [ 4538.891998] [] (handle_percpu_devid_irq+0x4d/0xac) from
> [] (generic_handle_irq+0x19/0x24)
> [ 4538.892028] [] (generic_handle_irq+0x19/0x24) from
> [] (handle_IRQ+0x29/0x68)
> [ 4538.892059] [] (handle_IRQ+0x29/0x68) from []
> (gic_handle_irq+0x27/0x50)
> [ 4538.892059] [] (gic_handle_irq+0x27/0x50) from []
> (__irq_svc+0x3b/0x5c)
> [ 4538.892059] Exception stack(0xc06e3f68 to 0xc06e3fb0)
> [ 4538.892059] 3f60:
> c06e2000 c075f130
> [ 4538.892120] 3f80: c06e2000 c075ea93 c075f130 c06ea594 c045c2e0
> c06e2000 c0fe5908 c06e3fb0
> [ 4538.892120] 3fa0: c007bab1 c0058b48 400f0133
> [ 4538.892120] [] (__irq_svc+0x3b/0x5c) from []
> (cpu_startup_entry+0xbc/0x164)
> [ 4538.892120] [] (cpu_startup_entry+0xbc/0x164) from
> [] (start_kernel+0x251/0x2ac)
> [ 4538.892120]
> [ 4538.892120] sending IPI to all other CPUs:
> [ 4538.892211] IPI backtrace for cpu 1
> [ 4538.892211]
> [ 4538.892242] CPU: 1 PID: 2064 Comm: clamd Not tainted
> 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
> [ 4538.892242] task: edb09500 ti: ec91e000 task.ti: ec91e000
> [ 4538.892272] PC is at 0xb6e2f0d4
> [ 4538.892272] LR is at 0xb6eeec01
> [ 4538.892272] pc : []lr : []psr: 000f0130
> [ 4538.892272] sp : be8b472c ip : 62323337 fp : 684a
> [ 4538.892303] r10: 0084d750 r9 : 0200 r8 : e86d6a2f
> [ 4538.892303] r7 : 0a0a0a0a r6 : 69393e32 r5 : 0080bf24 r4 : 0080bf28
> [ 4538.892333] r3 : 81010100 r2 : 6438 r1 : 000a r0 : 0080bf24
> [ 4538.892333] Flags: nzcv IRQs on FIQs on Mode USER_32 ISA Thumb
> Segment user
> [ 4538.892333] Control: 50c5387d Table: acbd404a DAC:
> [ 4538.892364]
> [ 4538.892364] R8: 0xe86d69af:
> [ 4538.892364] 69ac 6a6f7254 412e6e61 746e6567 3939332d 00303934
> b1aa3270 2506 47a83ca7
> [ 4538.892395] 69cc e4ebc453 91ad979e 23363f8b fd49d9d0 773b48ba
> ad58f7d3 04c351eb 96e4414f
> [ 4538.892395] 69ec 7e1a3ac7 f39072a5 e362cedb b119b3e0 b595375e
> b2137762 b19f99a8 b10dc638
> [ 4538.892395] 6a0c 1806 2e6e6957 6a6f7254 412e6e61 746e6567
> 3939332d 00303534 b23ade28
> [ 4538.892395] 6a2c 1806 2e6e6957 6a6f7254 462e6e61 61656b61
> 37342d76 00373131 ac58376e
> [ 4538.892395] 6a4c 72542e6e 6e616a6f 3434382e 35313336 3e55c600
> 412e6eb2 72617764 61472e65
> [ 4538.892517] 6a6c 6176656d 2d65636e 34393132 55b20037 1604b173
> 2e6e6957 6a6f7254 462e6e61
> [ 4538.892547] 6a8c 61656b61 37342d76 00343131 b652e2c0 72542e6e
> 6e616a6f 7075532e 756a7265
> [ 4538.892547] 6aac 322d6e61 fb003731 15b23a2b 2e6e6957 6a6f7254
> 412e6e61 746e6567 3939332d
> [ 4538.892547] CPU: 1 PID: 2064 Comm: clamd Not tainted
> 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
> [ 4538.892547] [] (unwind_backtrace+0x1/0x9c) from
> [] (show_stack+0x11/0x14)
> [ 4538.892639] [] (show_stack+0x11/0x14) from []
> (handle_IPI+0xd5/0x158)
> [ 4538.892669] [] (handle_IPI+0xd5/0x158) from []
> (gic_handle_irq+0x4b/0x50)
> [ 4538.892669] [] (gic_handle_irq+0x4b/0x50) from []
> (__irq_usr+0x49/0x60)
> [ 4538.892700] Exception stack(0xec91ffb0 to 0xec91fff8)
> [ 4538.89270
Re: [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 08/29/2013 06:02 PM, Kevin Hilman wrote: On Thu, Aug 29, 2013 at 3:43 PM, Russ Dill wrote: On Thu, Aug 29, 2013 at 3:20 PM, Kevin Hilman wrote: Dave Gerlach writes: [...] The working repo for this version of the patch series can be found here: git://github.com/dgerlach/linux-pm.git am335x-3.11rc4-suspend-resume I tried this branch on my beaglebone black, and it's not fully resuming. Suspend seems to be working (power draw goes from ~1W to ~130mW) and pressing a key on the UART seems to be waking up the SoC (power draw goes to ~600mW) but I don't ever get the console back. Is there a specific version of the firmware I should be using? Kevin Kevin, I agree there does seem to be some issues with Beaglebone black. I can confirm it works on BeagleBone White and the large am335 EVM, I am working on pinpointing the issue on beaglebone black, seems that support isn't quite there yet. OK, I tried the above branch on my BB white, using prebuilt firmware from the next3 branch of the am33x-cm3 repo and it's suspending/resuming fine. Thanks for the pointer. FYI, measuring at the 5V supply, it goes from ~1.6W at idle down to ~700mW in suspend. The black goes from ~1W down to an impressive 130mW but of course, it doesn't wake up so maybe it's not that impressive. ;) Just a reminder, the next3 firmware is built to be compatible with older kernel revisions whereas the next2 firmware is not. In order for that compatibility to work, the CMD_ID_DS0 that mainline uses should change from 0x3 to 0x4 Thanks, i switched to the next2 firmware since I'm only using current kernels. Kevin Kevin, Thanks for taking the time to try this out, it does seem there are a few kinks with BeagleBone Black but we'll get those worked out. Regards, Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/4] ARM: SRAM: Add macro for generating SRAM resume trampoline
Add a helper that generates a short snippet of code that loads
the stack pointer and calls a c (or asm) function. The code gets
placed into a SRAM section for loading into SRAM.
Signed-off-by: Russ Dill
---
arch/arm/include/asm/suspend.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/include/asm/suspend.h b/arch/arm/include/asm/suspend.h
index cd20029..d23d004 100644
--- a/arch/arm/include/asm/suspend.h
+++ b/arch/arm/include/asm/suspend.h
@@ -9,4 +9,18 @@ struct sleep_save_sp {
extern void cpu_resume(void);
extern int cpu_suspend(unsigned long, int (*)(unsigned long));
+/*
+ * Generate a SRAM trampoline for resume.
+ * @proc: SoC, should match argument used with SRAM_SECTIONS().
+ * @func: C or asm function to call at resume.
+ * @stack: Stack to use before calling func.
+ */
+#define ARM_SRAM_RESUME(proc, func, stack) \
+void __naked __noreturn __sram_##proc proc##_resume_trampoline(void) \
+{ \
+ __asm__ __volatile__("mov sp, %0" : : "r"((stack)) : "sp"); \
+ func(); \
+}
+
+
#endif
--
1.8.3.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
[RFC 4/4] ARM: AM33XX: Move suspend/resume assembly to C
This provides a proof of concept of the SRAM helpers. The
SRAM_SECTIONS macro is added to vmlinux.lds.S, the code
in sleep33xx.S is translated to C and moved to sleep33xx.c.
In the process, a struct used for passing arguments is
removed and instead the fixed arguments are only passed
once at init time, only an argument with some flags
remains.
Signed-off-by: Russ Dill
---
arch/arm/kernel/vmlinux.lds.S | 2 +
arch/arm/mach-omap2/Makefile| 2 +-
arch/arm/mach-omap2/pm33xx.c| 50 ++---
arch/arm/mach-omap2/pm33xx.h| 23 +--
arch/arm/mach-omap2/sleep33xx.S | 394
arch/arm/mach-omap2/sleep33xx.c | 309 +++
arch/arm/mach-omap2/sram.c | 15 --
7 files changed, 339 insertions(+), 456 deletions(-)
delete mode 100644 arch/arm/mach-omap2/sleep33xx.S
create mode 100644 arch/arm/mach-omap2/sleep33xx.c
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 7bcee5c..21c3b64 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -112,6 +112,8 @@ SECTIONS
ARM_CPU_KEEP(PROC_INFO)
}
+ SRAM_SECTIONS(am33xx)
+
RO_DATA(PAGE_SIZE)
. = ALIGN(4);
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dcf5d89..195485c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -95,7 +95,7 @@ obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec)
+CFLAGS_sleep33xx.o += -fPIC -march=armv7-a
endif
diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c
index ea36415..0cd3e76 100644
--- a/arch/arm/mach-omap2/pm33xx.c
+++ b/arch/arm/mach-omap2/pm33xx.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -45,8 +46,8 @@
#include "omap_hwmod.h"
#include "omap_device.h"
#include "soc.h"
-#include "sram.h"
+static unsigned long am33xx_wfi_flags;
static void __iomem *am33xx_emif_base;
static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm;
static struct clockdomain *gfx_l4ls_clkdm;
@@ -61,9 +62,6 @@ struct forced_standby_module am33xx_mod[] = {
{.oh_name = "cpgmac0"},
};
-static void (*am33xx_do_wfi_sram)(struct am33xx_suspend_params *);
-static struct am33xx_suspend_params susp_params;
-
#ifdef CONFIG_SUSPEND
struct wakeup_src wakeups[] = {
@@ -87,11 +85,6 @@ static DECLARE_COMPLETION(am33xx_pm_sync);
#endif
-static int am33xx_do_sram_idle(long unsigned int arg)
-{
- am33xx_do_wfi_sram((struct am33xx_suspend_params *) arg);
- return 0;
-}
int am33xx_do_sram_cpuidle(u32 wfi_flags, u32 m3_flags)
{
@@ -158,8 +151,7 @@ static int am33xx_pm_suspend(void)
/* Try to put GFX to sleep */
omap_set_pwrdm_state(gfx_pwrdm, PWRDM_POWER_OFF);
- ret = cpu_suspend((long unsigned int) &susp_params,
- am33xx_do_sram_idle);
+ ret = cpu_suspend(am33xx_wfi_flags, am33xx_suspend);
status = pwrdm_read_prev_pwrst(gfx_pwrdm);
if (status != PWRDM_POWER_OFF)
@@ -366,6 +358,7 @@ static void am33xx_pm_firmware_cb(const struct firmware
*fw, void *context)
{
struct am33xx_pm_context *am33xx_pm = context;
int ret = 0;
+ unsigned long sram_trampoline;
/* no firmware found */
if (!fw) {
@@ -395,8 +388,8 @@ static void am33xx_pm_firmware_cb(const struct firmware
*fw, void *context)
}
/* Physical resume address to be used by ROM code */
- am33xx_pm->ipc.resume_addr = (AM33XX_OCMC_END -
- am33xx_do_wfi_sz + am33xx_resume_offset + 0x4);
+ sram_trampoline = (long) kern_to_sram(&am33xx_resume_trampoline);
+ am33xx_pm->ipc.resume_addr = sram_to_phys(sram_trampoline);
am33xx_pm->mbox = omap_mbox_get("wkup_m3", &wkup_mbox_notifier);
@@ -413,15 +406,6 @@ static void am33xx_pm_firmware_cb(const struct firmware
*fw, void *context)
#endif /* CONFIG_SUSPEND */
-/*
- * Push the minimal suspend-resume code to SRAM
- */
-void am33xx_push_sram_idle(void)
-{
- am33xx_do_wfi_sram = (void *)omap_sram_push
- (am33xx_do_wfi, am33xx_do_wfi_sz);
-}
-
static int __init am33xx_map_emif(void)
{
am33xx_emif_base = ioremap(AM33XX_EMIF_BASE, SZ_32K);
@@ -480,21 +464,27 @@ int __init am33xx_pm_init(void)
temp = readl(am33xx_emif_base + EMIF_SDRAM_CONFIG);
temp = (temp & SDRAM_TYPE_MASK) >> SDRAM_TYPE_SHIFT;
/* Parameters to pass to assembly code */
- susp_params.wfi_flags = 0;
- susp_params.emif_addr_virt = am33xx_emif_base;
- susp_params.dram_sync = am33xx_dram_sync;
+ am33xx_wfi_flags = 0;
[RFC 1/4] Misc: SRAM: Create helpers for loading C code into SRAM
This commit adds helpers for loading, tracking, and running code from
SRAM. Some platforms need to run code from SRAM, such as during
suspend/resume when the access to SDRAM is disabled.
Currently, this is done in assembly. By using the assembler, labels can
be added in order to mark the size of the code, and areas can be added
for position independent access to data for when the code is copied
into SRAM. As more and more such code is added, the maintenance
burden grows.
This commit adds mechanisms to allow C code to be run from SRAM.
The first step is to put code and data that will be needed when running
from SRAM into special sections. The sections should follow the naming
convention of .sram... For example:
#define __sram_am33xx __section(.sram.am33xx.text)
#define __sram_am33xxdata __section(.sram.am33xx.data)
Functions can then be marked with __sram_am33xx and data with
__sram_am33xxdata. These sections and markers to them can be added
to the kernel image by inserting a "SRAM_SECTIONS()" into
your architecture's vmlinux.lds.S file.
A call to sram_load_sections("", ) will copy
the sections into SRAM:
sram_load_sections("/ocp/ocmcram@4030", am33xx);
Because the code is now relocated to SRAM, special accessors must
be used when accessing functions or variables.
- kern_to_sram(ptr): Translate a pointer to a function or variable that
is contained in a .sram..* section to the address it has
been loaded to in SRAM. For instance, when calling a function in
sram, one would use: "ret = kern_to_sram(&am33xx_suspend)(flags);"
- sram_to_phys(addr): Translate an pointer into SRAM to a physical
address. This is useful for obtaining a physical pointer to a resume
function contained in SRAM.
Any compilation unit that will be copied to SRAM that accesses other
functions or variables that are also copied to SRAM should be
compiled with -fPIC as calling the kern_to_sram accessors
requires reads from SDRAM.
Functions within a SRAM section group can access functions and
data also within the same SRAM section group without using
kern_to_sram accessors so long as the unit is compiled with -fPIC.
Care should be taken to use a method for obtaining an absolute
address when accessing functions or data outside of the SRAM
section group.
Signed-off-by: Russ Dill
---
drivers/misc/sram.c | 103 ++
include/asm-generic/vmlinux.lds.h | 7 +++
include/linux/sram.h | 44
3 files changed, 154 insertions(+)
create mode 100644 include/linux/sram.h
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index d87cc91..08baaab 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -25,17 +25,110 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+#include
#define SRAM_GRANULARITY 32
+static DEFINE_SPINLOCK(sram_lock);
+static LIST_HEAD(chunk_list);
+
struct sram_dev {
struct gen_pool *pool;
struct clk *clk;
};
+struct sram_chunk {
+ struct gen_pool *pool;
+ struct list_head node;
+ struct rcu_head head;
+ void *kern;
+ unsigned long addr;
+ size_t sz;
+};
+
+int sram_load_data(const char *of_path, void *data, size_t sz)
+{
+ struct device_node *np;
+ struct platform_device *pdev;
+ struct sram_chunk *chunk;
+ struct sram_dev *sram;
+
+ np = of_find_node_by_path(of_path);
+ if (!np)
+ return -ENODEV;
+
+ pdev = of_find_device_by_node(np);
+ if (!pdev)
+ return -ENODEV;
+
+ sram = platform_get_drvdata(pdev);
+
+ chunk = kzalloc(sizeof(*chunk), GFP_KERNEL);
+ if (!chunk)
+ return -ENOMEM;
+
+ chunk->pool = sram->pool;
+ chunk->kern = data;
+ chunk->sz = sz;
+
+ chunk->addr = gen_pool_alloc(sram->pool, sz);
+ if (!chunk->addr) {
+ kfree(chunk);
+ return -ENOMEM;
+ }
+
+ memcpy((void *) chunk->addr, data, sz);
+ flush_icache_range(chunk->addr, chunk->addr + sz);
+
+ spin_lock(&sram_lock);
+ list_add_rcu(&chunk->node, &chunk_list);
+ spin_unlock(&sram_lock);
+
+ return 0;
+
+}
+EXPORT_SYMBOL_GPL(sram_load_data);
+
+phys_addr_t sram_to_phys(unsigned long addr)
+{
+ struct sram_chunk *chunk;
+ phys_addr_t ret = -1;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(chunk, &chunk_list, node) {
+ ret = gen_pool_virt_to_phys(chunk->pool, addr);
+ if (ret != -1)
+ break;
+ }
+ rcu_read_unlock();
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(sram_to_phys);
+
+void __iomem *__kern_to_sram(void *ptr)
+{
+ struct sram_chunk *chunk;
+ void __iomem *ret = NULL;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(chunk, &chunk_list, node) {
+ if (ptr >= chunk->kern && ptr < chunk->kern + chunk->sz) {
+
[RFC 3/4] Misc: SRAM: Hack for allowing executable code in SRAM.
The generic SRAM mechanism does not ioremap memory in a manner that allows code to be executed from SRAM. There is currently no generic way to request ioremap to return a memory area with execution allowed. Insert a temporary hack for proof of concept on ARM. Signed-off-by: Russ Dill --- drivers/misc/sram.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c index 08baaab..e059a23 100644 --- a/drivers/misc/sram.c +++ b/drivers/misc/sram.c @@ -31,6 +31,7 @@ #include #include #include +#include #define SRAM_GRANULARITY 32 @@ -138,7 +139,7 @@ static int sram_probe(struct platform_device *pdev) int ret; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - virt_base = devm_ioremap_resource(&pdev->dev, res); + virt_base = __arm_ioremap_exec(res->start, resource_size(res), false); if (IS_ERR(virt_base)) return PTR_ERR(virt_base); -- 1.8.3.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
[RFC 0/4] Create infrastructure for running C code from SRAM.
This RFC patchset explores an idea for loading C code into SRAM.
Currently, all the code I'm aware of that needs to run from SRAM is written
in assembler. The most common reason for code needing to run from SRAM is
that the memory controller is being disabled/ enabled or is already
disabled. arch/arm has by far the most examples, but code also exists in
powerpc and sh.
The code is written in asm for two primary reasons. First so that markers
can be put in indicating the size of the code they it can be copied. Second
so that data can be placed along with text and accessed in a position
independant manner.
SRAM handling code is in the process of being moved from arch directories
into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
patchset builds on that, including the limitation that the SRAM address is
not known at compile time. Because the SRAM address is not known at compile
time, the code that runs from SRAM must be compiled with -fPIC. Even if
the code were loaded to a fixed virtual address, portions of the code must
often be run with the MMU disabled.
The general idea is that for each SRAM user (such as an SoC specific
suspend/resume mechanism) to create a group of sections. The section group
is created with a single macro for each user, but end up looking like this:
.sram.am33xx : AT(ADDR(.sram.am33xx) - 0) {
__sram_am33xx_start = .;
*(.sram.am33xx.*)
__sram_am33xx_end = .;
}
Any data or functions that should be copied to SRAM for this use should be
maked with an appropriate __section() attribute. A helper is then added for
translating between the original kernel symbol, and the address of that
function or variable once it has been copied into SRAM. Once control is
passed to a function within the SRAM section grouping, it can access any
variables or functions within that same SRAM section grouping without
translation.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4984c6
[2] http://www.spinics.net/lists/linux-omap/msg96504.html
Russ Dill (4):
Misc: SRAM: Create helpers for loading C code into SRAM
ARM: SRAM: Add macro for generating SRAM resume trampoline
Misc: SRAM: Hack for allowing executable code in SRAM.
ARM: AM33XX: Move suspend/resume assembly to C
arch/arm/include/asm/suspend.h| 14 ++
arch/arm/kernel/vmlinux.lds.S | 2 +
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/pm33xx.c | 50 ++---
arch/arm/mach-omap2/pm33xx.h | 23 +--
arch/arm/mach-omap2/sleep33xx.S | 394 --
arch/arm/mach-omap2/sleep33xx.c | 309 ++
arch/arm/mach-omap2/sram.c| 15 --
drivers/misc/sram.c | 106 +-
include/asm-generic/vmlinux.lds.h | 7 +
include/linux/sram.h | 44 +
11 files changed, 509 insertions(+), 457 deletions(-)
delete mode 100644 arch/arm/mach-omap2/sleep33xx.S
create mode 100644 arch/arm/mach-omap2/sleep33xx.c
create mode 100644 include/linux/sram.h
--
1.8.3.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 v11 0/8] PHY framework
Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: > Hi, > > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: >>> Added a generic PHY framework that provides a set of APIs for the PHY >>> drivers >>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to >>> the PHY with or without using phandle. >>> >>> This framework will be of use only to devices that uses external PHY (PHY >>> functionality is not embedded within the controller). >>> >>> The intention of creating this framework is to bring the phy drivers spread >>> all over the Linux kernel to drivers/phy to increase code re-use and to >>> increase code maintainability. >>> >>> Comments to make PHY as bus wasn't done because PHY devices can be part of >>> other bus and making a same device attached to multiple bus leads to bad >>> design. >>> >>> If the PHY driver has to send notification on connect/disconnect, the PHY >>> driver should make use of the extcon framework. Using this susbsystem >>> to use extcon framwork will have to be analysed. >>> >>> You can find this patch series @ >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing >> >> Looks like there are not further comments on this series. Can you take this >> in >> your misc tree? > > Do you want me to queue these for you ? There are quite a few users for > this framework already and I know of at least 2 others which will show > up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe 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 v11 0/8] PHY framework
On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: > >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: > >>> Added a generic PHY framework that provides a set of APIs for the PHY > >>> drivers > >>> to create/destroy a PHY and APIs for the PHY users to obtain a reference > >>> to > >>> the PHY with or without using phandle. > >>> > >>> This framework will be of use only to devices that uses external PHY (PHY > >>> functionality is not embedded within the controller). > >>> > >>> The intention of creating this framework is to bring the phy drivers > >>> spread > >>> all over the Linux kernel to drivers/phy to increase code re-use and to > >>> increase code maintainability. > >>> > >>> Comments to make PHY as bus wasn't done because PHY devices can be part of > >>> other bus and making a same device attached to multiple bus leads to bad > >>> design. > >>> > >>> If the PHY driver has to send notification on connect/disconnect, the PHY > >>> driver should make use of the extcon framework. Using this susbsystem > >>> to use extcon framwork will have to be analysed. > >>> > >>> You can find this patch series @ > >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing > >> > >> Looks like there are not further comments on this series. Can you take > >> this in > >> your misc tree? > > > > Do you want me to queue these for you ? There are quite a few users for > > this framework already and I know of at least 2 others which will show > > up for v3.13. > > Can you queue this patch series? There are quite a few users already for this > framework. It will have to wait for 3.13 as the merge window for new features has been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 is out. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.12 take #2
Benoit, On Fri, Aug 30, 2013 at 1:30 PM, Benoit Cousson wrote: > Hi Kevin & Olof, > > Here is the updated version without the conflicting patch (ARM: dts: AM33XX: > don't redefine OCP bus and device nodes) and with the signed tag. > There is still a small conflict with usb-next, but it is easily fixable, and > already fixed by Stephen. Sorry, I wasn't able to get this pulled in before the merge window opened, so it'll unfortunately have to wait until 3.13. Please send a fresh pull request as soon as -rc1 is out. It looks like a few of these are fixes (at least from the patch topics), we'd of course be happy to take those. -Olof -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP4+: Move SRAM data to DT
On Tue, Sep 3, 2013 at 7:35 AM, Lucas Stach wrote: > Am Dienstag, den 03.09.2013, 06:56 -0700 schrieb Russ Dill: >> On Tue, Aug 27, 2013 at 3:11 AM, Rajendra Nayak wrote: >> > Use drivers/misc/sram.c driver to manage SRAM on all DT only >> > OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of >> > the existing private implementation. >> > >> > Address and size related data is removed from mach-omap2/sram.c >> > and now passed to drivers/misc/sram.c from DT. >> > >> > Users can hence use general purpose allocator apis instead of >> > OMAP private ones to manage and use SRAM. >> > >> > Currently there are no users on SRAM on these platfoms. >> > >> > Signed-off-by: Rajendra Nayak >> >> I was trying to experiment with this on am33xx, but I noticed that the >> ioremap region is not marked exec, so it cannot be used to run code. > > Could you outline a use-case where you would need to execute code from > SRAM while running in a linux system? I'm curious what you would use > this for. Code that needs to disable or reconfigure the memory controller is the common use case. Some suspend/resume code even goes beyond that and performs steps that must be done *after* the memory controller has powered down, such as putting PLLs in bypass, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/6] dma: edma: Write out and handle MAX_NR_SG at a given time
On 09/02/2013 11:08 PM, Vinod Koul wrote:
> On Thu, Aug 29, 2013 at 06:05:41PM -0500, Joel Fernandes wrote:
>> Process SG-elements in batches of MAX_NR_SG if they are greater
>> than MAX_NR_SG. Due to this, at any given time only those many
>> slots will be used in the given channel no matter how long the
>> scatter list is. We keep track of how much has been written
>> inorder to process the next batch of elements in the scatter-list
>> and detect completion.
>>
>> For such intermediate transfer completions (one batch of MAX_NR_SG),
>> make use of pause and resume functions instead of start and stop
>> when such intermediate transfer is in progress or completed as we
>> donot want to clear any pending events.
>>
>> Signed-off-by: Joel Fernandes
>> ---
>> drivers/dma/edma.c | 79
>> --
>> 1 file changed, 53 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>> index e522ad5..732829b 100644
>> --- a/drivers/dma/edma.c
>> +++ b/drivers/dma/edma.c
>> @@ -56,6 +56,7 @@ struct edma_desc {
>> struct list_headnode;
>> int absync;
>> int pset_nr;
>> +int processed;
>> struct edmacc_param pset[0];
>> };
>>
>> @@ -104,22 +105,34 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
>> /* Dispatch a queued descriptor to the controller (caller holds lock) */
>> static void edma_execute(struct edma_chan *echan)
>> {
>> -struct virt_dma_desc *vdesc = vchan_next_desc(&echan->vchan);
>> +struct virt_dma_desc *vdesc;
>> struct edma_desc *edesc;
>> -int i;
>> -
>> -if (!vdesc) {
>> -echan->edesc = NULL;
>> -return;
>> +struct device *dev = echan->vchan.chan.device->dev;
>> +int i, j, left, nslots;
>> +
>> +/* If either we processed all psets or we're still not started */
>> +if (!echan->edesc ||
>> +echan->edesc->pset_nr == echan->edesc->processed) {
>> +/* Get next vdesc */
>> +vdesc = vchan_next_desc(&echan->vchan);
>> +if (!vdesc) {
>> +echan->edesc = NULL;
>> +return;
>> +}
>> +list_del(&vdesc->node);
>> +echan->edesc = to_edma_desc(&vdesc->tx);
>> }
>>
>> -list_del(&vdesc->node);
>> +edesc = echan->edesc;
>>
>> -echan->edesc = edesc = to_edma_desc(&vdesc->tx);
>> +/* Find out how many left */
>> +left = edesc->pset_nr - edesc->processed;
>> +nslots = min(MAX_NR_SG, left);
>>
>> /* Write descriptor PaRAM set(s) */
>> -for (i = 0; i < edesc->pset_nr; i++) {
>> -edma_write_slot(echan->slot[i], &edesc->pset[i]);
>> +for (i = 0; i < nslots; i++) {
>> +j = i + edesc->processed;
>> +edma_write_slot(echan->slot[i], &edesc->pset[j]);
>> dev_dbg(echan->vchan.chan.device->dev,
>> "\n pset[%d]:\n"
>> " chnum\t%d\n"
>> @@ -132,24 +145,31 @@ static void edma_execute(struct edma_chan *echan)
>> " bidx\t%08x\n"
>> " cidx\t%08x\n"
>> " lkrld\t%08x\n",
>> -i, echan->ch_num, echan->slot[i],
>> -edesc->pset[i].opt,
>> -edesc->pset[i].src,
>> -edesc->pset[i].dst,
>> -edesc->pset[i].a_b_cnt,
>> -edesc->pset[i].ccnt,
>> -edesc->pset[i].src_dst_bidx,
>> -edesc->pset[i].src_dst_cidx,
>> -edesc->pset[i].link_bcntrld);
>> +j, echan->ch_num, echan->slot[i],
>> +edesc->pset[j].opt,
>> +edesc->pset[j].src,
>> +edesc->pset[j].dst,
>> +edesc->pset[j].a_b_cnt,
>> +edesc->pset[j].ccnt,
>> +edesc->pset[j].src_dst_bidx,
>> +edesc->pset[j].src_dst_cidx,
>> +edesc->pset[j].link_bcntrld);
>> /* Link to the previous slot if not the last set */
>> -if (i != (edesc->pset_nr - 1))
>> +if (i != (nslots - 1))
>> edma_link(echan->slot[i], echan->slot[i+1]);
>> /* Final pset links to the dummy pset */
>> else
>> edma_link(echan->slot[i], echan->ecc->dummy_slot);
>> }
>>
>> -edma_start(echan->ch_num);
>> +edesc->processed += nslots;
>> +
>> +edma_resume(echan->ch_num);
>> +
>> +if (edesc->processed <= MAX_NR_SG) {
>> +dev_dbg(dev, "first transfer starting %d\n", echan->ch_num);
>> +edma_start(echan->ch_num);
>> +}
>> }
>>
>> static int edma_terminate_all(struct edma_chan *echan)
>> @@ -368,19 +388,26 @@ static void edma_callback(unsigned ch
Re: [PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT
Am Dienstag, den 03.09.2013, 06:56 -0700 schrieb Russ Dill: > On Tue, Aug 27, 2013 at 3:11 AM, Rajendra Nayak wrote: > > Use drivers/misc/sram.c driver to manage SRAM on all DT only > > OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of > > the existing private implementation. > > > > Address and size related data is removed from mach-omap2/sram.c > > and now passed to drivers/misc/sram.c from DT. > > > > Users can hence use general purpose allocator apis instead of > > OMAP private ones to manage and use SRAM. > > > > Currently there are no users on SRAM on these platfoms. > > > > Signed-off-by: Rajendra Nayak > > I was trying to experiment with this on am33xx, but I noticed that the > ioremap region is not marked exec, so it cannot be used to run code. Could you outline a use-case where you would need to execute code from SRAM while running in a linux system? I'm curious what you would use this for. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
On Tue, Sep 03, 2013 at 07:06:01AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown wrote: > > I was thinking about the majority of regulators where setting a voltage > > would be a single bitfield update (plus ramp delay, which is going to > > need to be accounted for in the power on case). If we need to do longer > > sequences things get a bit more tricky in terms of interface but it > > seems doable. > The sequence for TPS65217 on beaglebone is rather long, it's 8 > register writes. It has to write the new value to the DCDC3 register > and the apply bit to the DCDC register, but both registers are > password locked registers. The password sequence is to write the > password register, then the register, then the password register > again, then the register again. Oh dear, that's a bit annoying. It's doable obviously if people decide to go down that route but it's work and this is a very common system. signature.asc Description: Digital signature
Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown wrote: > On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote: >> On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown wrote: > >> > Making it write only seems to be a mistake - like I said in my other >> > mail I'd expect you'd want bitfield updates here. The read and modify >> > could be done earlier by Linux though. > >> Updating bitfields in memory is pretty basic, but with I2C, each >> device has its own register sizes and methods of accessing registers. >> The first byte of an I2C sequence being a register address is pretty >> common though. You'd need a method of defining in the device tree >> piece how to modify bitfields. > > I'd not assume byte based addressing for a PMIC, it's very common but > not universal. The difficulties here assume putting this in the device > tree as explicit register I/O - I do tend to agree with Kevin that this > doesn't seem like the right abstraction. > >> > If it's just setting a single voltage then extracting the bitfield to >> > update shouldn't be too hard for regmap based regulators. Off the top >> > of my head I'd expect either the driver for the M3 or the cpuidle driver >> > that talks to it to be a consumer of the regulator and then go from >> > there. > >> It'd be a list of bitfields. So are you suggesting a regulator_ops >> call that would return a list of bitfield updates along with an I2C >> controller, an I2C device address, I2C register addressing scheme (8 >> bit, 16 bit, or other) and the info for each bitfield (register size)? >> And then each regulator driver would be updated as needed with this >> code. Would this be a way forward? Would regmap actually tie into this >> at all? > > I was thinking about the majority of regulators where setting a voltage > would be a single bitfield update (plus ramp delay, which is going to > need to be accounted for in the power on case). If we need to do longer > sequences things get a bit more tricky in terms of interface but it > seems doable. The sequence for TPS65217 on beaglebone is rather long, it's 8 register writes. It has to write the new value to the DCDC3 register and the apply bit to the DCDC register, but both registers are password locked registers. The password sequence is to write the password register, then the register, then the password register again, then the register again. > regmap would tie in in that it already has a way of describing the > format for interactions with the device so we could just reuse the same > description, and with some work we can probably reuse the code that > generates the bitstreams for sending to the devices too (though I don't > immediately see a nice way of doing that). > > Not sure if this is worth the effort or not though, but then there's the > whole DT as ABI thing to worry about... > >> This is VDD core, so its not related to cpuidle or the M3. > > It's related to the M3 if the M3 is managing it; you can have multiple > consumers for a regulator so it doesn't need to be one or the other. Ah. > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT
On Tue, Aug 27, 2013 at 3:11 AM, Rajendra Nayak wrote: > Use drivers/misc/sram.c driver to manage SRAM on all DT only > OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of > the existing private implementation. > > Address and size related data is removed from mach-omap2/sram.c > and now passed to drivers/misc/sram.c from DT. > > Users can hence use general purpose allocator apis instead of > OMAP private ones to manage and use SRAM. > > Currently there are no users on SRAM on these platfoms. > > Signed-off-by: Rajendra Nayak I was trying to experiment with this on am33xx, but I noticed that the ioremap region is not marked exec, so it cannot be used to run code. -- To unsubscribe from this list: send the line "unsubscribe 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/3] ARM: OMAP4+: Move SRAM data to DT
On 9/2/2013 10:33 PM, Sekhar Nori wrote:
> On 8/29/2013 7:21 PM, Santosh Shilimkar wrote:
>> On Thursday 29 August 2013 09:50 AM, Rajendra Nayak wrote:
>>> On Thursday 29 August 2013 07:01 PM, Santosh Shilimkar wrote:
On Thursday 29 August 2013 09:26 AM, Sekhar Nori wrote:
> On 8/29/2013 4:53 PM, Rajendra Nayak wrote:
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 22d9f2b..1ba6a77 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -126,6 +126,11 @@
>> pinctrl-single,function-mask = <0x7fff>;
>> };
>>
>> +ocmcram: ocmcram@40304000 {
>
> This can now be changed to 0x4030 now that you have moved to
> gen_pool_alloc()?
>
NO.
It won't work on secure devices since first 16 KB is occupied for
default configuration. Its not worth trouble also to handle
secure/non-secure considering the use of SRAM which is actually just
limited to errata. 40304000 will work for both devices.
>>>
>>> Right. Sekhar, you might have confused because of the existing buggy code
>>> in sram.c and sram.h which did this (and is removed in this series)
>>>
>>> from sram.c
>>> ---
>>> #define OMAP2_SRAM_PUB_PA (OMAP2_SRAM_PA + 0xf800)
>>> #define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
>>> -#ifdef CONFIG_OMAP4_ERRATA_I688
>>> -#define OMAP4_SRAM_PUB_PA OMAP4_SRAM_PA
>>> -#else
>>> -#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
>>> -#endif
>>> -#define OMAP5_SRAM_PA 0x4030
>>>
>>> from sram.h
>>> ---
>>> #define OMAP2_SRAM_PA 0x4020
>>> #define OMAP3_SRAM_PA 0x4020
>>> -#ifdef CONFIG_OMAP4_ERRATA_I688
>>> -#define OMAP4_SRAM_PA 0x40304000
>>> -#define OMAP4_SRAM_VA 0xfe404000
>>> -#else
>>> -#define OMAP4_SRAM_PA 0x4030
>>> -#endif
>>>
>>> I am not sure where the checks for CONFIG_OMAP4_ERRATA_I688
>>> came in from, but these are done, like Santosh said, to handle
>>> secure and non-secure sram across GP and HS devices and in
>>> no way related to handling errata I688.
>>>
>> The check was to ensure that with errata enabled, we don't care
>> about first 16 KB ;-)
>
> Hi Rajendra, thanks for the explanation. Other devices like AM437x which
> have HS variants might need such adjustment too. It will be nice to
> check that.
So I checked with folks working on the HS variant and what you have for
AM437x is just fine. The secure runtime uses a different SRAM bank and
even if there is a need to use the GP SRAM, the space will first be
carved using gen_pool APIs on Linux. Only requirement from secure
runtime software is physically contiguous area - which I think
gen_pool_alloc() guarantees.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe 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: AM4372: Add node for dma-controller
Adds AM4372 EDMA support to the am4372.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/am4372.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..bfc556c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -41,6 +41,20 @@
#size-cells = <1>;
ranges;
+ edma: dma-controller@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = ,
+,
+;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
uart0: serial@44e09000 {
compatible = "ti,am4372-uart","ti,omap2-uart";
reg = <0x44e09000 0x2000>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/22] OMAPDSS: DT support
Hi Tomi, On Monday 02 September 2013 11:00:15 Tomi Valkeinen wrote: > On 22/08/13 00:07, Laurent Pinchart wrote: > > Thanks for the comments! You're welcome. > >> The exception to the above are DSI and DBI. DSI and DBI are combined > >> control and video busses, but the use of the busses for control purposes > >> is not independent of the video stream. Also, the the busses are, in > >> practice, one-to-one links. And last, DSI and DBI display entities are > >> often also controllable via, say, i2c. For these reasons there is no > >> real Linux bus for DSI and DBI and thus the DSI and DBI devices are > >> either platform devices or i2c devices. > > > > That's something I'm less convinced about, but I don't have a too strong > > feeling. The best implementation should get to mainline, I won't nack this > > architecture just for theoretical reasons. > > Ok. I posted a response to your DBI bus patch about the issues I see. I'll reply in that mail thread then. > >> DSI Module ID > >> = > >> > >> On OMAP4 we have two DSI modules. To configure the clock routing and pin > >> muxing, we need to know the hardware module ID for the DSI device, i.e. > >> is this Linux platform device DSI1 or DSI2. The same issue exists with > >> other SoCs with multiple outputs of the same kind. > >> > >> With non-DT case, we used the platform device's ID directly. With DT, > >> that doesn't work. I don't currently have a good solution for this, so as > >> a temporary solution the DSI driver contains a table, from which it can > >> find the HW module ID by using the device's base address. > > > > You could add two output ports to the DSS, one for each DSI, and link the > > DSI modules to the DSS output ports in DT. That would represent the > > hardware topology, and would allow the DSI driver to know its ID based on > > the DSS output port it's connected to. It's still a bit hackish in the > > sense that the DSI driver will use information provided by the DSS (the > > output port number), but not more than the current method. > > Hmm, yep. That's kind of the same as having an explicit 'module-id' > property in the DSI node. I had implemented that solution at some point, > but considered it too ugly. But I agree that deducing the module-id from > the DSS output port is a bit cleaner, as it doesn't need any special > properties. And it's maybe also better than the address table I have > now, as the address table requires special code for each SoC. > > I have to try the V4L2 ports to understand fully how to use them. Feel free to ask questions :-) > In the end, I hope to get rid of the module-id totally. It's really not > a DSI-thing at all. The DSI hardware does not use the module-id for > anything, it's more about how the DSI module is glued in the DSS/SoC. > > >> I have some ideas how to deduce the DSS version by poking to certain DSS > >> registers, but it is not yet tested so I don't know if it will work. > > > > That might be a stupid question, but can't you just encode the version in > > the compatible string of the DSS DT node (the one currently compatible > > with "ti,omap[34]-dss") ? > > That would require having separate DT files for each revision. For > example, we have Beagle boards with different OMAP reversions. > > It's fine to have the version encoded in the compatible string for major > versions, but having all minor revisions encoded there could result in a > mess. Obviously if you can detect the version at runtime that would be best. Let's see if that can be done and then decide on what solution to implement. > > Version information might also need to be split/duplicated in several of > > the DSS DT nodes. A quick grep through the driver source code shows that > > the version is used by the submodules to infer SoC glue information. For > > instance dsi_get_channel() uses the version to find the DSI module > > channel ID. That information could possibly be retrieved from the links > > between the DSS DT nodes. > > Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3, > TV (depending on the SoC). These outputs go to encoders, and the routing > can be configured. If we consider only DSI encoders on OMAP4, the LCD2 > output can be configured to go to DSI1 or DSI2 modules. LCD1 output can > be configured to go to DSI1 (but not to DSI2). > > Because the routing has restrictions like mentioned above, it's somewhat > difficult to allocate the DISPC output channels during runtime in a > totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1, > and later we'd want to use DSI2, there would be no DISPC output to use. > > That's why we currently have them hardcoded in the driver, and it works > ok in all the use cases we have now. However, some board could need to > setup the channels in some other way for some particular use case. > > So, I'm not totally comfortable with hardcoding the DISPC output - DSS > encoder connections in the DT data. While it'd work f
