Re: [PATCH v4 08/14] v4l: ti-vpe: Rename csc memory resource name
Hi Kamil, On Thursday 13 March 2014 08:14 PM, Kamil Debski wrote: Hi, From: Archit Taneja [mailto:arc...@ti.com] Sent: Thursday, March 13, 2014 12:44 PM Rename the memory block resource vpe_csc to csc since it also exists within the VIP IP block. This would make the name more generic, and both VPE and VIP DT nodes in the future can use it. I understand that this is not yet used in any public dts files. Right? Best wishes, Yes, a VPE DT node doesn't exist in any public dts files yet. So it's safe to change the name. It should eventually come in dra7.dtsi. There is a dependency on a crossbar IP module, which provides us with an IRQ line for VPE going to the GIC. Once that is merged, I can add the VPE DT node. Thanks, Archit -- 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: OMAP2+: timer: Add clocksource initialization and powerup support
On 03/14/2014 01:36 AM, Joel Fernandes wrote:
On 03/13/2014 04:52 PM, Rob Herring wrote:
On Thu, Mar 13, 2014 at 3:35 PM, Joel Fernandes jo...@ti.com wrote:
Introduce a generic omap timer initialization function that can
be used by all SoCs for which support is available in the clocksource
driver introduced in the series.
The function will also be responsible for calling clock initialization
required for everything else to work.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/timer.c | 28
2 files changed, 29 insertions(+)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index a6aae30..e58d9a4 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -92,6 +92,7 @@ extern void omap3_secure_sync32k_timer_init(void);
extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
extern void omap5_realtime_timer_init(void);
+void omap_generic_timer_init(void);
void omap2420_init_early(void);
void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 74044aa..08c73a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -324,6 +324,25 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
return r;
}
+int __init omap_dmtimer_powerup(struct omap_dm_timer *timer,
+ struct device_node *np) {
This function seems unrelated to the commit message.
Ok, I'll add it in the message.
+ struct omap_hwmod *oh;
+ const char *oh_name = NULL;
+
+ of_property_read_string_index(np, ti,hwmods, 0, oh_name);
+ if (!oh_name)
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
+
+ omap_hwmod_setup_one(oh_name);
+
+ omap_hwmod_enable(oh);
+ return 0;
+}
+
static void __init omap2_gp_clockevent_init(int gptimer_id,
const char *fck_source,
const char *property)
@@ -615,6 +634,15 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck,
ti,timer-alwon,
2, sys_clkin_ck, NULL);
#endif
+void omap_generic_timer_init(void)
+{
+ if (!of_have_populated_dt())
+ BUG_ON(Generic timer init should only be used for DT boot\n);
I thought omap2 is always DT boot now.
That's right, sorry- I'll get rid of the check.
+
+ omap_clk_init();
Can't you use CLK_OF_DECLARE and remove this? Then you can remove the
init_time function hook completely.
There is some dev-id conn-id - DT node mapping done. I'll let Tero comment
more on this.
It is actually more complicated than this, the reason we have
omap_clk_init() is the static dependencies between the init order of
various components in the system (slab, clocks, hwmod), and also because
OMAP clks have pretty much different basic clock init compared to the
generic DT clk init (memory mappings done differently etc.) and, it
was impossible to get the generic init modified to support OMAP clk init
due to various sources of resistance so here we are. I hope we are able
to merge the required stuff from omap_clk_init towards the generic clk
init eventually and get rid of OMAP specific stuff.
-Tero
Thanks,
-Joel
+ clocksource_of_init();
+}
+
#ifdef CONFIG_ARCH_OMAP4
#ifdef CONFIG_HAVE_ARM_TWD
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
--
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 2/5] ARM: dts: am33xx: Set parent clock for timer through DT
On 03/13/2014 10:35 PM, Joel Fernandes wrote:
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4e6c959..51b7008 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,7 @@
interrupts = 67;
ti,hwmods = timer1;
ti,timer-alwon;
+ ti,default-parent = sys_clkin_ck;
};
timer2: timer@4804 {
@@ -360,6 +361,7 @@
reg = 0x4804 0x400;
interrupts = 68;
ti,hwmods = timer2;
+ ti,default-parent = sys_clkin_ck;
};
timer3: timer@48042000 {
I don't think this works, the ti,default-parent property is only
supported for clock nodes (at least I didn't quickly find anything from
your clocksource driver that would handle this.) You should do something
like this:
timer1_fck {
ti,default-parent = sys_clkin_ck;
};
timer2_fck {
ti,default-parent = sys_clkin_ck;
};
-Tero
--
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: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
Hi Suman, On Tue, Mar 4, 2014 at 7:38 PM, Suman Anna s-a...@ti.com wrote: Do you have any objections to the return code convention change? Unless strictly needed, I prefer we don't switch to the ERR_PTR code convention, as it reduces code readability and increases chances of user bugs. In our case, switching to ERR_PTR and friends seems only to optimize a few error paths, and I'm not sure it's a big win over simplicity. When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of initialization failed or device not yet probed; so that the client knows if it should fail or retry later. Can you confirm the changes you want me to make, so that I can refresh and post a v5 for 3.15? Sorry, I missed your replies for some reason. I prefer we stick with the current error handling code because I find the alternative inferior (as long as it's not strictly needed). Thanks, Ohad. -- 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 4/4] ARM: DTS: AM43x: Add DSS node
On Thu, Mar 13, 2014 at 06:22:54PM +, Tomi Valkeinen wrote:
On 13/03/14 19:46, Mark Rutland wrote:
On Thu, Mar 13, 2014 at 08:58:29AM +, Sathya Prakash M R wrote:
Add device node for DSS module for AM4372. Both the
AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Also set the right parent clock to the DSS clock.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 28 +
arch/arm/boot/dts/am437x-gp-evm.dts | 77
++
arch/arm/boot/dts/am43x-epos-evm.dts | 73
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
4 files changed, 180 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..b72a7df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,34 @@
num-cs = 4;
status = disabled;
};
+
+ dss: dss@4832A000 {
+ compatible = ti,omap3-dss, simple-bus;
This doesn't look right to me. I'm not sure it makes sense for
simple-bus to be in the compatible list.
Are the child nodes usable in isolation, or are they dependent on the
ti,omap3-dss node? What exactly does the ti,omap3-dss node
represent?
The child nodes are dependent on the dss node.
Ok. Then simple-bus is not appropriate, as the dss node cannot be
ignored for the children to function.
The ti,omap3-dss represents the dss_core block of the OMAP display
subsystem. The dss_core is a small IP, a wrapper for the submodules,
handling things like clock and video path routing between the submodules
and the OMAP's other components (like the PRCM where we get clocks). It
also handles reset, so when dss_core is reset, all the submodules are reset.
The HW design is a bit odd, in my opinion, as the submodules are proper
IP blocks, and as far as I see, they could be designed to be independent
of each others. But they have not been designed so.
Having dss_core as the parent node for the submodules gives us automatic
runtime-pm handling, so when one submodule is enabled, it forces
dss_core to be enabled first. This makes the reset work right (i.e. we
don't accidentally reset dss_core when one of the submodules is in use),
and, as the dss_core is always needed to setup the clock and video path
routing, it gets properly initialized before any of the submodules will
use it.
What simple-bus mostly gives us here is automatic creation of the
platform devices for the submodules. We could also create the devices
for submodules in the driver of the dss_core. I did have that at some
point, but the simple-bus does identical job, and it seemed to make
sense to me.
The simple-bus compatible string is intended for busses which are
transparent (bar some address remapping expressed via ranges), and is
not intended as an annotation to get Linux to probe child nodes.
Any node with a simple-bus entry in the compatible list should either
be handled as a transparent bus, or optionally as the more specific bus
it claims to be (where some hardware configuration may be required
before children can be probed). Unfortunately Linux probes chidlren
regardless, which is arguable a Linux bug.
There's no reason to leak this issue into dts files. Please remove the
simple-bus string, and get the dss driver to probe children as
required -- as described above the dss node never makes sense as a
simple-bus.
Note that the same method is used for omap2/3/4 also, in the patches
that have been going around for some time in the lists.
And those should be fixed.
Cheers,
Mark.
--
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+: hwmod: fix missing braces in _init()
From: Suman Anna s-a...@ti.com
Bug was introduced by commit 'f92d959: ARM: OMAP2+: hwmod:
Extract no-idle and no-reset info from DT'
There were 2 versions of the patch posted which resulted in the above
commit. While v1 [1] had the bug, v2 [2] had it fixed.
However v1 apparently seemed to have been pulled in by mistake
introducing the bug.
Given of_find_property() does return NULL when the node passed is
NULL, it did not introduce any functional issues as such, just the
fact that the second if check was executed unnecessarily.
[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg94220.html
[2] http://www.spinics.net/lists/linux-omap/msg98490.html
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 1f33f5d..66c60fe 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2546,11 +2546,12 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
return -EINVAL;
}
- if (np)
+ if (np) {
if (of_find_property(np, ti,no-reset-on-init, NULL))
oh-flags |= HWMOD_INIT_NO_RESET;
if (of_find_property(np, ti,no-idle-on-init, NULL))
oh-flags |= HWMOD_INIT_NO_IDLE;
+ }
oh-_state = _HWMOD_STATE_INITIALIZED;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Documentation: dts: OMAP: Fix typos in DRA752 device name
DRA752 device is wrongly documented as DRA742 device. Fix the typo. Signed-off-by: Rajendra Nayak rna...@ti.com --- .../devicetree/bindings/arm/omap/omap.txt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index af9b4a0..0491868 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -48,7 +48,7 @@ SoC Families: compatible = ti,omap4 - OMAP5 generic - defaults to OMAP5430 compatible = ti,omap5 -- DRA7 generic - defaults to DRA742 +- DRA7 generic - defaults to DRA752 compatible = ti,dra7 - AM43x generic - defaults to AM4372 compatible = ti,am43 @@ -79,7 +79,7 @@ SoCs: - OMAP5432 compatible = ti,omap5432, ti,omap5 -- DRA742 +- DRA752 compatible = ti,dra7xx, ti,dra7 - AM4372 -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] arm: dts: Add support for DRA72x family of devices
DRA72x is a single core cortex A15 device with most infrastructure IPs otherwise
same as whats on the DRA75x devices.
So move the cpu nodes into dra75x.dtsi and dra72x.dtsi respectively.
Also add a minimal dra72-evm dts file.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |6
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts |4 +--
arch/arm/boot/dts/dra7.dtsi| 22
arch/arm/boot/dts/dra72-evm.dts| 24 +
arch/arm/boot/dts/dra72x.dtsi | 25 ++
arch/arm/boot/dts/dra75x.dtsi | 36
7 files changed, 95 insertions(+), 25 deletions(-)
create mode 100644 arch/arm/boot/dts/dra72-evm.dts
create mode 100644 arch/arm/boot/dts/dra72x.dtsi
create mode 100644 arch/arm/boot/dts/dra75x.dtsi
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 0491868..a8b1a69 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -82,6 +82,9 @@ SoCs:
- DRA752
compatible = ti,dra7xx, ti,dra7
+- DRA72x
+ compatible = ti,dra72x, ti,dra7
+
- AM4372
compatible = ti,am4372, ti,am43
@@ -116,3 +119,6 @@ Boards:
- DRA7 EVM: Software Developement Board for DRA7XX
compatible = ti,dra7-evm, ti,dra7
+
+- DRA72 EVM: Software Development Board for DRA72x
+ compatible = ti,dra72-evm, ti,dra72x, ti,dra7
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..c0231da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -231,7 +231,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb \
- dra7-evm.dtb
+ dra7-evm.dtb \
+ dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += ste-snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..f344de2 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -7,10 +7,10 @@
*/
/dts-v1/;
-#include dra7.dtsi
+#include dra75x.dtsi
/ {
- model = TI DRA7;
+ model = TI DRA75x;
compatible = ti,dra7-evm, ti,dra752, ti,dra7;
memory {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..a1da2c71 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -33,28 +33,6 @@
serial5 = uart6;
};
- cpus {
- #address-cells = 1;
- #size-cells = 0;
-
- cpu0: cpu@0 {
- device_type = cpu;
- compatible = arm,cortex-a15;
- reg = 0;
-
- operating-points =
- /* kHzuV */
- 100 106
- 1176000 116
- ;
- };
- cpu@1 {
- device_type = cpu;
- compatible = arm,cortex-a15;
- reg = 1;
- };
- };
-
timer {
compatible = arm,armv7-timer;
interrupts = GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
new file mode 100644
index 000..d105e66
--- /dev/null
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014 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 dra72x.dtsi
+
+/ {
+ model = TI DRA72x;
+ compatible = ti,dra72-evm, ti,dra72x, ti,dra7;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1024 MB */
+ };
+};
+
+uart1 {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
new file mode 100644
index 000..701e40c
--- /dev/null
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2014 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.
+ * Based on omap4.dtsi
+ */
+
+#include dra7.dtsi
+
+/ {
+ compatible = ti,dra72x, ti,dra7xx;
+
+ cpus {
+ #address-cells =
[PATCH 0/3] ARM: DRA7: Add support for DRA72x devices
DRA72x devices are single core Cortex A15 devices belonging to the DRA7 family (Similar to the DRA75x devices which are dual core Cortex A15 based) The patches add minimal DT/kernel modifications to add boot support for DRA72x devices resuing all the kernel data for DRA75x devices. Rajendra Nayak (3): Documentation: dts: OMAP: Fix typos in DRA752 device name arm: dts: Add support for DRA72x family of devices ARM: OMAP2+: Add machine entry for dra72x devices .../devicetree/bindings/arm/omap/omap.txt | 10 -- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts |4 +-- arch/arm/boot/dts/dra7.dtsi| 22 arch/arm/boot/dts/dra72-evm.dts| 24 + arch/arm/boot/dts/dra72x.dtsi | 25 ++ arch/arm/boot/dts/dra75x.dtsi | 36 arch/arm/mach-omap2/board-generic.c| 18 ++ 8 files changed, 115 insertions(+), 27 deletions(-) create mode 100644 arch/arm/boot/dts/dra72-evm.dts create mode 100644 arch/arm/boot/dts/dra72x.dtsi create mode 100644 arch/arm/boot/dts/dra75x.dtsi -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP2+: Add machine entry for dra72x devices
The only difference from the dra75x devices is the missing .smp entry.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 8e3daa1..d803d99 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -253,4 +253,22 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened
Device Tree))
.dt_compat = dra7xx_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
+
+static const char *dra72_boards_compat[] __initdata = {
+ ti,dra72x,
+ ti,dra7,
+ NULL,
+};
+
+DT_MACHINE_START(DRA72_DT, Generic DRA72 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_late = dra7xx_init_late,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra72_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
On 03/13/2014 03:46 PM, Mark Brown wrote: On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote: With this series AM335x and AM447x will use the dmaengine PCM for audio. The daVinci devices will keep using the davinci-pcm for now since I do not have means to test them but the code is written in a way that they can be switched to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was working fine). Can you please not resend the ASoC portions of this series until the EDMA portion is stable (and ideally committed)? I'm not quite sure why but every EDMA patch series seems to go through lots of iterations which gets rather noisy - my initial reaction to seeing EDMA in a subject is to just delete the thread. Sure, I'm not planning to spam alsa-devel however the switch to dmaengine PCM for AM335x/AM447x needs the edma patches, otherwise it is not going to work. AFAIK I have not sent patch to edma as of now so I have no idea how long it takes to get stuff in (the good thing is that the edma part does not touch DT, which is alone can reduce the number of iterations). Anyway, what I can - and already did is: Reorder the ASoC patches and I can leave out the switch to dmaengine PCM patch for davinci-mcasp for now. The edma-pcm and the other patches for McASP can go in right away (I will not add the edma-pcm to the Makefile/Kconfig to avoid issues). I will detach the edma stuff and follow it up outside of alsa-devel. The only thing I'm afraid off is that it is going to take two release cycle to get this in: first cycle edma part, next cycle for the ASoC to switch to use the edma-pcm. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On 14/03/14 11:10, Mark Rutland wrote: The simple-bus compatible string is intended for busses which are transparent (bar some address remapping expressed via ranges), and is not intended as an annotation to get Linux to probe child nodes. Any node with a simple-bus entry in the compatible list should either be handled as a transparent bus, or optionally as the more specific bus it claims to be (where some hardware configuration may be required before children can be probed). Unfortunately Linux probes chidlren regardless, which is arguable a Linux bug. There's no reason to leak this issue into dts files. Please remove the simple-bus string, and get the dss driver to probe children as required -- as described above the dss node never makes sense as a simple-bus. Ok. I'll remove the simple-bus, and make the dss_core register the devices. I presume of_platform_populate() is fine for this? Seems to work fine for registration, but I haven't figured out yet how to unregister the devices (I get a crash in platform_device_del() if I just call platform_device_unregister for the submodules). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 5/5] iommu/omap: Fix map protection value handling
Hi Suman,
Thank you for the review.
On Thursday 13 March 2014 19:07:33 Suman Anna wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The prot flags passed to the IOMMU map handler are defined in
include/linux/iommu.h as IOMMU_(READ|WRITE|CACHE|EXEC). However, the
driver expects to receive MMU_RAM_* OMAP-specific flags. This causes
IOMMU flags being interpreted as page sizes, leading to failures.
Hardcode the OMAP mapping parameters to little-endian, 8-bits and
non-mixed page attributes. Furthermore, as the OMAP IOMMU doesn't
support read-only or write-only mappings, ignore the prot value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 59de3fc..9f7f1d4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1016,8 +1016,7 @@ static void iopte_cachep_ctor(void *iopte)
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
}
-static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa,
- u32 flags)
+static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa, int
pgsz)
{
memset(e, 0, sizeof(*e));
@@ -1025,10 +1024,10 @@ static u32 iotlb_init_entry(struct iotlb_entry *e,
u32 da, u32 pa,
e-pa = pa;
e-valid= 1;
As I was looking through this, I found a small bug here. This is unrelated
to this patch, but you can fix it in the same patch. The e-valid value is
directly used in omap2_alloc_cr, so it should be initialized to MMU_CAM_V.
It is not a problem currently as PREFETCH_IOTLB is not used, if used, this
is overriding the size bit-fields when it prefetches the entry, which may
lead to an MMU fault.
Good catch. As it's a separate issue, do you mind if I fix that in a separate
patch in v2 ?
/* FIXME: add OMAP1 support */
- e-pgsz = flags MMU_CAM_PGSZ_MASK;
- e-endian = flags MMU_RAM_ENDIAN_MASK;
- e-elsz = flags MMU_RAM_ELSZ_MASK;
- e-mixed= flags MMU_RAM_MIXED_MASK;
+ e-pgsz = pgsz;
+ e-endian = MMU_RAM_ENDIAN_LITTLE;
+ e-elsz = MMU_RAM_ELSZ_8;
+ e-mixed= 0;
Thanks, the change of these settings looks good overall. The only ones for
which it may apply anyway is just the Camera in OMAP2/OMAP3 (as per TRM,
endianness conversion supported only on writes anyway, so I am assuming that
we never use the combination), and OMAP2420 DSP, for which there is no
driver currently nor is the MMU being instantiated. All other processors are
pure little endian, and they even ignore the values written in these fields.
Please recheck the Camera subsystem once, and see if the e-elsz should be
set as MMU_RAM_ELSZ_NONE (I am not too familiar with the Camera usage, so
you are probably in a better place than me).
I've tested MMU_RAM_ELSZ_NONE and it works fine. I'll update the patch in v2.
--
Regards,
Laurent Pinchart
--
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] iommu/omap: Fix 'no page for' debug message in flush_iotlb_page()
Hi Suman,
On Thursday 13 March 2014 17:16:07 Suman Anna wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The flush_iotlb_page() function prints a debug message when no
corresponding page was found in the TLB. That condition is incorrectly
checked and always resolves to true, given that the for_each_iotlb_cr()
loop is never interrupted and always reaches obj-nr_tlb_entries.
Nice catch.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bb605c9..cb1e1de 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -376,6 +376,7 @@ static void flush_iotlb_page(struct omap_iommu *obj,
u32 da)
{
int i;
struct cr_regs cr;
+ bool found = false;
pm_runtime_get_sync(obj-dev);
@@ -394,11 +395,12 @@ static void flush_iotlb_page(struct omap_iommu *obj,
u32 da)
__func__, start, da, bytes);
iotlb_load_cr(obj, cr);
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
+ found = true;
The patch is fine as it is, but I think the loop can be breaked when an
entry is found for simplification. I do not expect that we will have
multiple entries with the same da in the TLBs (it is a multi-hit fault
scenario) to continue looping through all entries. The only means for the
multi-hit scenario to happen is user error with programming TLBs directly.
OK. I wasn't sure whether we could have two TLB entries for the same VA. I'll
update the patch accordingly.
This function call seems to be added in general to take care of any
prefetching. I don't have the complete history on the PREFETCH_IOTLB on why
it was added, it doesn't seem to be enabled but this should ideally be left
to the h/w unless you are locking a TLB entry. DSP/Bridge is the only one
that uses locked TLB entries at the moment, but it is not using the OMAP
IOMMU driver yet.
}
}
pm_runtime_put_sync(obj-dev);
- if (i == obj-nr_tlb_entries)
+ if (!found)
dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
}
--
Regards,
Laurent Pinchart
--
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 02/14] v4l: ti-vpe: register video device only when firmware is loaded
Hi, On Thursday 13 March 2014 07:59 PM, Kamil Debski wrote: Hi, From: Archit Taneja [mailto:arc...@ti.com] Sent: Thursday, March 13, 2014 1:09 PM Hi Kamil, On Thursday 13 March 2014 05:18 PM, Kamil Debski wrote: Hi Archit, From: Archit Taneja [mailto:arc...@ti.com] Sent: Tuesday, March 11, 2014 9:34 AM vpe fops(vpe_open in particular) should be called only when VPDMA firmware is loaded. File operations on the video device are possible the moment it is registered. Currently, we register the video device for VPE at driver probe, after calling a vpdma helper to initialize VPDMA and load firmware. This function is non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the firmware is actually loaded when it returns. We remove the device registration from vpe probe, and move it to a callback provided by the vpe driver to the vpdma library, through vpdma_create(). The ready field in vpdma_data is no longer needed since we always have firmware loaded before the device is registered. A minor problem with this approach is that if the video_register_device fails(which doesn't really happen), the vpe platform device would be registered. however, there won't be any v4l2 device corresponding to it. Could you explain to me one thing. request_firmware cannot be used in probe, thus you are using request_firmware_nowait. Why cannot the firmware be loaded on open with a regular request_firmware that is waiting? I totally agree with you here. Placing the firmware in open() would probably make more sense. The reason I didn't place it in open() is because I didn't want to release firmware in a corresponding close(), and be in a situation where the firmware is loaded multiple times in the driver's lifetime. Would it be possible to load firmware in open and release it in remove? I know that this would disturb the symmetry between open-release and probe-remove. But this could work. That might work. Currently, the driver doesn't do any clock management, it just enables the clocks in probe, and disables them in remove. I need to check how the firmware is dependent on clocks. We could make a better decision about where to release the firmware with that information. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] iommu/omap: Flush the TLB only after updating translation table entries
Hi Suman,
On Thursday 13 March 2014 17:27:38 Suman Anna wrote:
Hi Laurent,
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
Flushing the TLB before updating translation entries creates a race
condition and can lead to stale TLB entries if a translation request
arrives between flushing the TLB and updating the translation entries.
As there's no requirement to flush the TLB before updating the entries,
flush it after only.
I do not expect a device to be actively using a region if we are about
to change its mapping, we expect the access from the device to be only
between a map and an unmap. The race condition (if any in such
scenarios) would exist even after this patch, like after you programmed
the entry, and the translation request comes before you flush the page.
Then it is still operating on an older address, while you have already
programmed a new one. An unmap currently clears the entry and flushes
any TLB as well, so I don't think this patch makes a big difference.
I agree that the patch won't make a difference in practice. Should I drop it
from v2 ?
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index cb1e1de..fedd303 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -662,10 +662,11 @@ int omap_iopgtable_store_entry(struct omap_iommu
*obj, struct iotlb_entry *e)
{
int err;
- flush_iotlb_page(obj, e-da);
err = iopgtable_store_entry_core(obj, e);
- if (!err)
+ if (!err) {
+ flush_iotlb_page(obj, e-da);
prefetch_iotlb_entry(obj, e);
+ }
return err;
}
EXPORT_SYMBOL_GPL(omap_iopgtable_store_entry);
--
Regards,
Laurent Pinchart
--
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 4/4] ARM: DTS: AM43x: Add DSS node
On Fri, Mar 14, 2014 at 09:42:26AM +, Tomi Valkeinen wrote: On 14/03/14 11:10, Mark Rutland wrote: The simple-bus compatible string is intended for busses which are transparent (bar some address remapping expressed via ranges), and is not intended as an annotation to get Linux to probe child nodes. Any node with a simple-bus entry in the compatible list should either be handled as a transparent bus, or optionally as the more specific bus it claims to be (where some hardware configuration may be required before children can be probed). Unfortunately Linux probes chidlren regardless, which is arguable a Linux bug. There's no reason to leak this issue into dts files. Please remove the simple-bus string, and get the dss driver to probe children as required -- as described above the dss node never makes sense as a simple-bus. Ok. I'll remove the simple-bus, and make the dss_core register the devices. I presume of_platform_populate() is fine for this? Seems to work fine for registration, but I haven't figured out yet how to unregister the devices (I get a crash in platform_device_del() if I just call platform_device_unregister for the submodules). I think of_platform_populate should be ok. It's not fantastic -- all child nodes will be probed, regardless of whether you expect them to exist, but it's not as broken as using simple-bus. I'm unfortunately not familiar with how unregistration works. I can't see anything obviously wrong in platform_device_del. Do you have a backtrace? Thanks, Mark. -- 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 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
On Fri, Mar 14, 2014 at 11:38:58AM +0200, Peter Ujfalusi wrote: The only thing I'm afraid off is that it is going to take two release cycle to get this in: first cycle edma part, next cycle for the ASoC to switch to use the edma-pcm. We can do a cross tree merge, or the EDMA code can be applied to ASoC directly if that's what people want. signature.asc Description: Digital signature
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On 14/03/14 12:14, Mark Rutland wrote: I can't see anything obviously wrong in platform_device_del. Do you have a backtrace? Yes, below. I can see at least drivers/usb/dwc3/dwc3-exynos.c doing the exact same thing I do, so maybe I've got something wrong with the omapdss driver. Tomi [ 62.987335] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 62.995910] pgd = eb6b8000 [ 62.998779] [0018] *pgd=aa127831, *pte=, *ppte= [ 63.005462] Internal error: Oops: 17 [#1] SMP ARM [ 63.005462] Modules linked in: omapdss(-) [last unloaded: encoder_tfp410] [ 63.011779] CPU: 1 PID: 1021 Comm: rmmod Not tainted 3.14.0-rc2-00057-gacd3401a1fea-dirty #69 [ 63.025909] task: eb17a040 ti: ea14e000 task.ti: ea14e000 [ 63.032287] PC is at release_resource+0x1c/0x84 [ 63.032287] LR is at _raw_write_lock+0x50/0x58 [ 63.041748] pc : [c004adc8]lr : [c05bbd5c]psr: 6113 [ 63.041748] sp : ea14fde0 ip : ea14fdb8 fp : ea14fdf4 [ 63.053833] r10: r9 : ea14e000 r8 : c000f704 [ 63.053833] r7 : 0081 r6 : bf0004fc r5 : eb714400 r4 : eb6a9600 [ 63.061798] r3 : r2 : 0001 r1 : 0011 r0 : c08cec3c [ 63.071746] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 63.071746] Control: 10c53c7d Table: ab6b804a DAC: 0015 [ 63.081787] Process rmmod (pid: 1021, stack limit = 0xea14e248) [ 63.091735] Stack: (0xea14fde0 to 0xea15) [ 63.093109] fde0: 0001 eb714400 ea14fe0c ea14fdf8 c03953dc c004adb8 eb714400 [ 63.101806] fe00: ea14fe24 ea14fe10 c0395808 c0395374 eb17a040 eb714400 ea14fe3c ea14fe28 [ 63.114715] fe20: bf000530 c0395800 eb714410 ea14fe64 ea14fe40 c038fa5c bf000508 [ 63.121795] fe40: eb214b80 eb6a9d30 ea14fe7c eb204410 bf032d98 eb20 ea14fe7c ea14fe68 [ 63.123352] fe60: bf022574 c038fa2c bf02254c eb204410 ea14fe8c ea14fe80 c0395080 bf022558 [ 63.140136] fe80: ea14fea4 ea14fe90 c0393494 c039506c eb204410 bf032d98 ea14fec4 ea14fea8 [ 63.149200] fea0: c0393efc c0393428 bf032d98 bf034438 bf0342b8 ea14fedc ea14fec8 [ 63.154327] fec0: c0393244 c0393e4c eb6fa300 bf032d98 ea14fef4 ea14fee0 c0394570 c03931ec [ 63.166442] fee0: bf022800 0005 ea14ff04 ea14fef8 c03951d0 c039454c ea14ff14 ea14ff08 [ 63.175048] ff00: bf0010e8 c03951c8 ea14ff34 ea14ff18 bf022534 bf0010e0 bf0224f4 [ 63.183685] ff20: bf0342d0 0880 ea14ffa4 ea14ff38 c00b7f50 bf022500 c000f564 [ 63.183685] ff40: bf0342d0 0880 ea14ff3c 70616d6f 00737364 00088ec9 ea14ff84 ea14ff68 [ 63.200927] ff60: c008fff0 c008fdd8 0001cec8 70616d6f 00737364 0081 ea14ff94 ea14ff88 [ 63.209533] ff80: c00900dc 0008ff08 0001cec8 70616d6f 00737364 ea14ffa8 [ 63.218170] ffa0: c000f540 c00b7e0c 0001cec8 70616d6f bea28b10 0880 bea28b10 0880 [ 63.226776] ffc0: 0001cec8 70616d6f 00737364 0081 000acc00 0042 00088ec9 [ 63.234619] ffe0: bea28b08 bea28af8 0001cda4 b6ed3390 6110 bea28b10 [ 63.234619] Backtrace: [ 63.246612] [c004adac] (release_resource) from [c03953dc] (platform_device_del+0x74/0xa4) [ 63.246612] r5:eb714400 r4:0001 [ 63.246612] [c0395368] (platform_device_del) from [c0395808] (platform_device_unregister+0x14/0x20) [ 63.267150] r5: r4:eb714400 [ 63.273223] [c03957f4] (platform_device_unregister) from [bf000530] (dss_uninit_submodule_dev+0x34/0x40 [omapdss]) [ 63.281799] r4:eb714400 r3:eb17a040 [ 63.281799] [bf0004fc] (dss_uninit_submodule_dev [omapdss]) from [c038fa5c] (device_for_each_child+0x3c/0x7c) [ 63.291839] r4: r3:eb714410 [ 63.303070] [c038fa20] (device_for_each_child) from [bf022574] (omap_dsshw_remove+0x28/0x70 [omapdss]) [ 63.312255] r6:eb20 r5:bf032d98 r4:eb204410 [ 63.318237] [bf02254c] (omap_dsshw_remove [omapdss]) from [c0395080] (platform_drv_remove+0x20/0x24) [ 63.321807] r4:eb204410 r3:bf02254c [ 63.331848] [c0395060] (platform_drv_remove) from [c0393494] (__device_release_driver+0x78/0xd0) [ 63.341644] [c039341c] (__device_release_driver) from [c0393efc] (driver_detach+0xbc/0xc0) [ 63.350708] r5:bf032d98 r4:eb204410 [ 63.352874] [c0393e40] (driver_detach) from [c0393244] (bus_remove_driver+0x64/0xcc) [ 63.352874] r6:bf0342b8 r5:bf034438 r4:bf032d98 r3: [ 63.369018] [c03931e0] (bus_remove_driver) from [c0394570] (driver_unregister+0x30/0x50) [ 63.372894] r4:bf032d98 r3:eb6fa300 [ 63.381713] [c0394540] (driver_unregister) from [c03951d0] (platform_driver_unregister+0x14/0x18) [ 63.391418] r4:0005 r3:bf022800 [ 63.391845] [c03951bc] (platform_driver_unregister) from [bf0010e8] (dss_uninit_platform_driver+0x14/0x1c [omapdss]) [ 63.401794] [bf0010d4] (dss_uninit_platform_driver [omapdss]) from [bf022534] (omap_dss_exit+0x40/0x58 [omapdss]) [ 63.406951] [bf0224f4] (omap_dss_exit [omapdss]) from [c00b7f50] (SyS_delete_module+0x150/0x1e0) [
Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver
On Thu, Mar 13, 2014 at 10:12 AM, Pavel Machek pa...@ucw.cz wrote: Hi! 30*HZ means 30 seconds in the kernel... what is hard to understand about it? Well I might be picky, but since it is a charging algorithm dealing with ampères, volts, constant-current/constant-voltage, watchdogs and timeouts, all stated in SI units, it would be nice if all such constants were specified in simple units instead of kernel-specific terms. I agree HZ is badly named, but hopefully anyone working on kernel is already familiar with it. But... what would actually help: I believe we should introduce milivolt_t, miliamp_t, milisec_t etc... types. Storing milivolts in int, then having comment saying milivolts is just wrong. Hm! I bet the regulator subsystem maintainers have opinions on that. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] ARM: dts: dra7: Add USB related nodes
Hi Roger,
On Friday 07 March 2014 06:39 PM, Roger Quadros wrote:
Add nodes for the Super Speed USB controllers, omap-control-usb,
USB2 PHY and USB3 PHY devices.
Remove ocp2scp1 address space from hwmod data as it is
now provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 110 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 ---
2 files changed, 110 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 597979b..1e73900 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -811,6 +811,116 @@
clocks = sata_ref_clk;
ti,hwmods = sata;
};
+
+ omap_control_usb2phy1: control-phy@4a002300 {
+ compatible = ti,control-phy-usb2;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usb3phy1: control-phy@4a002370 {
+ compatible = ti,control-phy-pipe3;
+ reg = 0x4a002370 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usb2phy2: control-phy@0x4a002e74 {
+ compatible = ti,control-phy-usb2-dra7;
+ reg = 0x4a002e74 0x4;
+ reg-names = power;
+ };
+
+ /* OCP2SCP1 */
+ ocp2scp@4a08 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ reg = 0x4a08 0x20;
+ ti,hwmods = ocp2scp1;
+
+ usb2_phy1: phy@4a084000 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a084000 0x400;
+ ctrl-module = omap_control_usb2phy1;
+ clocks = usb_phy1_always_on_clk32k,
+usb_otg_ss1_refclk960m;
+ clock-names = wkupclk,
+ refclk;
+ #phy-cells = 0;
+ };
+
+ usb2_phy2: phy@4a085000 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a085000 0x400;
+ ctrl-module = omap_control_usb2phy2;
+ clocks = usb_phy2_always_on_clk32k,
+usb_otg_ss2_refclk960m;
+ clock-names = wkupclk,
+ refclk;
+ #phy-cells = 0;
+ };
+
+ usb3_phy1: phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_usb3phy1;
+ clocks = usb_phy3_always_on_clk32k,
+sys_clkin1,
+usb_otg_ss1_refclk960m,
+dpll_core_h13x2_ck;
+ clock-names = wkupclk,
+ sysclk,
+ refclk,
+ optclk;
Do we use this 'optclk' in driver?
-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 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Suman, (CC'ing Joerg Roedel and Marek Szyprowski for the core IOMMU discussion) On Thursday 13 March 2014 21:33:37 Suman Anna wrote: On 03/07/2014 06:46 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 5/5, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I'd like to take this as an opportunity to discuss OMAP IOMMU integration with the ARM DMA mapping implementation. The idea is to hide the IOMMU completely behind the DMA mapping API, making it completely transparent to drivers. Thanks for starting the discussion. A drivers will only need to allocate memory with dma_alloc_*, and behind the scene the ARM DMA mapping implementation will find out that the device is behind an IOMMU and will map the buffers through the IOMMU, returning an I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to the IOMMU core should be necessary anymore. To use the IOMMU the ARM DMA implementation requires a VA mapping to be created with a call to arm_iommu_create_mapping() and to then be attached to the device with arm_iommu_attach_device(). This is currently not performed by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP driver for now. I believe this to still be an improvement compared to the current situation, as it allows getting rid of custom memory allocation code in the OMAP3 ISP driver and custom I/O VA space management in omap-iovmm. However, that code should ideally be removed from the driver. The question is, where should it be moved to ? One possible solution would be to add the code to the OMAP IOMMU driver. However, this would require all OMAP IOMMU users to be converted to the ARM DMA API. I assume there would be issues that I don't foresee though. Yeah, I think this will pose some problems for the other main user of IOMMUs - the remoteproc devices (DSP, Dual-Cortex M3/M4 processors in OMAP4 and beyond). A remoteproc device also needs to map memory at specific addresses for its code and data sections, and not rely on a I/O VA address being given to it. The firmware sections are already linked at specific addresses, and so remoteproc needs to allocate memory, load the firmware and map into appropriate device addresses. We are doing this currently usage a combination of CMA memory to get contiguous memory (there are some restrictions for certain sections) and iommu_map/unmap API to program the MMU with these pages. This usage is different from what is expected from exchanging buffers, which can be allocated from a predefined mapping range. Even that one is tricky if we need to support different cache properties/attributes as the cache configuration is in general local to these processors. Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed ? I'm not even sure whether the OMAP IOMMU driver would be the best place to put that code. Ideally VA spaces should be created by the platform somehow, and mapping of devices to IOMMUs should be handled by the IOMMU core instead of the IOMMU drivers. We're not there yet, and the path might not be straightforward, hence this attempt to start a constructive discussion. A second completely unrelated problem that I'd like to get feedback on is the suspend/resume support in the OMAP IOMMU driver, or rather the lack thereof. The driver exports omap_iommu_save_ctx() and omap_iommu_restore_ctx() functions and expects the IOMMU users to call them directly. This is really hackish to say the least. A proper suspend/resume implementation shouldn't be difficult to implement, and I'm wondering whether the lack of proper power management support comes from historical reasons only, or if there are problems I might not have considered. Agreed, the current code definitely needs a cleanup and better organization (like folding into runtime suspend ops). The main thing is that we need the IOMMU to be activated as long as its parent device is active (like the omap3isp or a remoteproc device). And this behaviour needs separation from configuring it and
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On 14/03/14 12:19, Tomi Valkeinen wrote: On 14/03/14 12:14, Mark Rutland wrote: I can't see anything obviously wrong in platform_device_del. Do you have a backtrace? Yes, below. I can see at least drivers/usb/dwc3/dwc3-exynos.c doing the exact same thing I do, so maybe I've got something wrong with the omapdss driver. Looks to me that the devices created by of_platform_populate() are not unregisterable in all cases. The address resource created via of_platform_populate() had NULL res-parent, which causes release_resource to crash. I can as well call of_platform_populate() in the platform init code at boot time, and create the devices there for now. Tomi signature.asc Description: OpenPGP digital signature
UOB-X1H: Message..
I have proposal for you. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] ARM: dts: dra7: Add USB related nodes
On 03/14/2014 12:38 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 07 March 2014 06:39 PM, Roger Quadros wrote:
Add nodes for the Super Speed USB controllers, omap-control-usb,
USB2 PHY and USB3 PHY devices.
Remove ocp2scp1 address space from hwmod data as it is
now provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 110
++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 ---
2 files changed, 110 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 597979b..1e73900 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -811,6 +811,116 @@
clocks = sata_ref_clk;
ti,hwmods = sata;
};
+
+omap_control_usb2phy1: control-phy@4a002300 {
+compatible = ti,control-phy-usb2;
+reg = 0x4a002300 0x4;
+reg-names = power;
+};
+
+omap_control_usb3phy1: control-phy@4a002370 {
+compatible = ti,control-phy-pipe3;
+reg = 0x4a002370 0x4;
+reg-names = power;
+};
+
+omap_control_usb2phy2: control-phy@0x4a002e74 {
+compatible = ti,control-phy-usb2-dra7;
+reg = 0x4a002e74 0x4;
+reg-names = power;
+};
+
+/* OCP2SCP1 */
+ocp2scp@4a08 {
+compatible = ti,omap-ocp2scp;
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+reg = 0x4a08 0x20;
+ti,hwmods = ocp2scp1;
+
+usb2_phy1: phy@4a084000 {
+compatible = ti,omap-usb2;
+reg = 0x4a084000 0x400;
+ctrl-module = omap_control_usb2phy1;
+clocks = usb_phy1_always_on_clk32k,
+ usb_otg_ss1_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb2_phy2: phy@4a085000 {
+compatible = ti,omap-usb2;
+reg = 0x4a085000 0x400;
+ctrl-module = omap_control_usb2phy2;
+clocks = usb_phy2_always_on_clk32k,
+ usb_otg_ss2_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb3_phy1: phy@4a084400 {
+compatible = ti,omap-usb3;
+reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+reg-names = phy_rx, phy_tx, pll_ctrl;
+ctrl-module = omap_control_usb3phy1;
+clocks = usb_phy3_always_on_clk32k,
+ sys_clkin1,
+ usb_otg_ss1_refclk960m,
+ dpll_core_h13x2_ck;
+clock-names =wkupclk,
+sysclk,
+refclk,
+optclk;
Do we use this 'optclk' in driver?
No we don't. Still the device seems to work without it.
This is supposed to be USB_LFPS_TX_GFCLK or USB3PHY_REF_CLK.
Any idea why it works without that on OMAP5 as well?
cheers,
-roger
--
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: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
On Sun, Mar 2, 2014 at 10:19 PM, Bjorn Andersson bj...@kryo.se wrote: When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of initialization failed or device not yet probed; so that the client knows if it should fail or retry later. I'm not convinced. The only advantage this brings is to avoid retrying in case a fatal error has occurred. Such fatal errors are extremely rare, and when they show up - extremely painful, and I suspect that optimizing them wouldn't be a big win. OTOH, keeping the code easier to read and less error prone is a big win. I prefer we keep it simple for now. Thanks, Ohad. -- 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 4/4] ARM: DTS: AM43x: Add DSS node
On Fri, Mar 14, 2014 at 11:07:05AM +, Tomi Valkeinen wrote:
On 14/03/14 12:19, Tomi Valkeinen wrote:
On 14/03/14 12:14, Mark Rutland wrote:
I can't see anything obviously wrong in platform_device_del. Do you have
a backtrace?
Yes, below.
I can see at least drivers/usb/dwc3/dwc3-exynos.c doing the exact same thing
I do, so maybe I've got something wrong with the omapdss driver.
Looks to me that the devices created by of_platform_populate() are not
unregisterable in all cases. The address resource created via
of_platform_populate() had NULL res-parent, which causes
release_resource to crash.
Hmm. I can't see that unregistering such devices ever works as you say,
given that __release_resource expects a non-NULL parent pointer. Either
we should be setting the parent pointer when initialising devices from
dt or we should teach __release_resource to not care. I'll have a go at
fixing that.
It looks like drivers/usb/dwc3/dwc3-exynos.c only unregisters the
top-level device, not children. This top-level device has no
IORESOURCE_{IO,MEM} resources judging by
arch/arm/boot/dts/exynos5250.dtsi, which would explain why that driver
isn't exploding: __release_resource will never get called.
Anton, Felipe:
Does unregistering the parent ensure the children get cleaned up, or
does it leave them dangling in the dwc3-exynos driver?
Cheers,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] ARM: dts: dra7: Add USB related nodes
On Friday 14 March 2014 05:41 PM, Roger Quadros wrote:
On 03/14/2014 12:38 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 07 March 2014 06:39 PM, Roger Quadros wrote:
Add nodes for the Super Speed USB controllers, omap-control-usb,
USB2 PHY and USB3 PHY devices.
Remove ocp2scp1 address space from hwmod data as it is
now provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 110
++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 ---
2 files changed, 110 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 597979b..1e73900 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -811,6 +811,116 @@
clocks = sata_ref_clk;
ti,hwmods = sata;
};
+
+omap_control_usb2phy1: control-phy@4a002300 {
+compatible = ti,control-phy-usb2;
+reg = 0x4a002300 0x4;
+reg-names = power;
+};
+
+omap_control_usb3phy1: control-phy@4a002370 {
+compatible = ti,control-phy-pipe3;
+reg = 0x4a002370 0x4;
+reg-names = power;
+};
+
+omap_control_usb2phy2: control-phy@0x4a002e74 {
+compatible = ti,control-phy-usb2-dra7;
+reg = 0x4a002e74 0x4;
+reg-names = power;
+};
+
+/* OCP2SCP1 */
+ocp2scp@4a08 {
+compatible = ti,omap-ocp2scp;
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+reg = 0x4a08 0x20;
+ti,hwmods = ocp2scp1;
+
+usb2_phy1: phy@4a084000 {
+compatible = ti,omap-usb2;
+reg = 0x4a084000 0x400;
+ctrl-module = omap_control_usb2phy1;
+clocks = usb_phy1_always_on_clk32k,
+ usb_otg_ss1_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb2_phy2: phy@4a085000 {
+compatible = ti,omap-usb2;
+reg = 0x4a085000 0x400;
+ctrl-module = omap_control_usb2phy2;
+clocks = usb_phy2_always_on_clk32k,
+ usb_otg_ss2_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb3_phy1: phy@4a084400 {
+compatible = ti,omap-usb3;
+reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+reg-names = phy_rx, phy_tx, pll_ctrl;
+ctrl-module = omap_control_usb3phy1;
+clocks = usb_phy3_always_on_clk32k,
+ sys_clkin1,
+ usb_otg_ss1_refclk960m,
+ dpll_core_h13x2_ck;
+clock-names =wkupclk,
+sysclk,
+refclk,
+optclk;
Do we use this 'optclk' in driver?
No we don't. Still the device seems to work without it.
This is supposed to be USB_LFPS_TX_GFCLK or USB3PHY_REF_CLK.
I think it should be enabled. Did you check the status of this clock in
CM_L3INIT_CLKSTCTRL? Moreover USB_LFPS_TX_GFCLK is an interface clock,
so IIUC setting the module mode will enable it.
Btw how did you tell dpll_core_h13x2_ck enables USB_LFPS_TX_GFCLK?
Cheers
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: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
On Fri, Mar 14, 2014 at 03:12:26PM +0200, Ohad Ben-Cohen wrote: On Sun, Mar 2, 2014 at 10:19 PM, Bjorn Andersson bj...@kryo.se wrote: When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of initialization failed or device not yet probed; so that the client knows if it should fail or retry later. I'm not convinced. The only advantage this brings is to avoid retrying in case a fatal error has occurred. Such fatal errors are extremely rare, and when they show up - extremely painful, and I suspect that optimizing them wouldn't be a big win. So, are you suggesting that because fatal errors should be extremely rare, a consuming driver should just assume that if NULL is returned from a hwspin_lock_request*() function that it was the device not yet probed case that was hit? Note that having the consumer/hwspinlock device relationship modeled in devicetree introduces more potential failure cases... -- 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: [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs
* Joel Fernandes jo...@ti.com [140313 16:52]: On 03/13/2014 03:48 PM, Tony Lindgren wrote: * Joel Fernandes jo...@ti.com [140313 13:43]: We introduce functions to initialize clocksource and clockevent, use CLOCKSOURCE_OF_DECLARE to declare the clocksource, and handle the clocksource selection on a per-SoC basis (Currently only AM335x is supported). Powering up of the timer will be done with the help of the mach-omap layer function that's introduced earlier in the series. We make a local copy of dmtimer API for use by clocksource, the original dmtimer API in plat-omap is kept as-is till the migration of all SoCs is completed after which it can't be deleted. Signed-off-by: Joel Fernandes jo...@ti.com --- drivers/clocksource/Makefile |1 + drivers/clocksource/omap-timer.c | 1157 ++ drivers/clocksource/omap-timer.h | 422 ++ 3 files changed, 1580 insertions(+) create mode 100644 drivers/clocksource/omap-timer.c create mode 100644 drivers/clocksource/omap-timer.h Hmm this leaves duplicate arch/arm/plat-omap/dmtimer.c code, please Sure, ofcourse- but how else can we make sure everything works while we do the migration in steps. We can get rid of the duplicate once everything is migrated. That's not doing incremental changes then. You're not even modifying the existing omap_dm_timer functions, so please do the changes in incremental steps where things keep working throughout the series. sort out that issue too by allowing omap1 and omap3 still to use the legacy timer init functions but with timer code under drivers/clocksource/omap-timer.c. Sorry, I didn't follow. I didn't see OMAP3 using legacy timer stuff. To me it looks like OMAP3 migration should be straight forward along the same lines as this RFC patchset. Could you elaborate a bit more what the legacy functions you mentioned for OMAP1 are? I will just like to keep everything in drivers/clocksource/ private for now till we're done migrating most platforms. IMO once we get system timers working for omap2+, then we can look into omap1 :) Well omap3 is still also booting in legacy mode too. And not the that drivers/clocksource/omap-timer.h won't be needed at all, those defines can stay private to the drivers/clocksource/omap-timer.c. Actually- I wanted it separate because omap-timer.c is already huge at 1157 lines. Infact the largest among the clocksource drivers. Is that fair? No need for it. We want to keep these functions private to the driver. So this patch really should just be moving of the code to the new location. To be honest, its not just a simple moving of code, there are new things such as selecting correct timer, new functions for clockevent and clocksource init, different handling of clocks etc. Those changes should then be separate patches to prepare things so people can see what changes in arch/arm/plat-omap/dmtimer.c code. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On Fri, Mar 14, 2014 at 02:07:45PM +, Mark Rutland wrote:
On Fri, Mar 14, 2014 at 11:07:05AM +, Tomi Valkeinen wrote:
On 14/03/14 12:19, Tomi Valkeinen wrote:
On 14/03/14 12:14, Mark Rutland wrote:
I can't see anything obviously wrong in platform_device_del. Do you have
a backtrace?
Yes, below.
I can see at least drivers/usb/dwc3/dwc3-exynos.c doing the exact same
thing
I do, so maybe I've got something wrong with the omapdss driver.
Looks to me that the devices created by of_platform_populate() are not
unregisterable in all cases. The address resource created via
of_platform_populate() had NULL res-parent, which causes
release_resource to crash.
Hmm. I can't see that unregistering such devices ever works as you say,
given that __release_resource expects a non-NULL parent pointer. Either
we should be setting the parent pointer when initialising devices from
dt or we should teach __release_resource to not care. I'll have a go at
fixing that.
It looks like drivers/usb/dwc3/dwc3-exynos.c only unregisters the
top-level device, not children. This top-level device has no
IORESOURCE_{IO,MEM} resources judging by
arch/arm/boot/dts/exynos5250.dtsi, which would explain why that driver
isn't exploding: __release_resource will never get called.
Anton, Felipe:
Does unregistering the parent ensure the children get cleaned up, or
does it leave them dangling in the dwc3-exynos driver?
you should platform_device_unregister() for each children and
dwc3-exynos does that just fine:
167 static int dwc3_exynos_remove(struct platform_device *pdev)
168 {
169 struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
170
171 device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
^^
172 platform_device_unregister(exynos-usb2_phy);
173 platform_device_unregister(exynos-usb3_phy);
174
175 clk_disable_unprepare(exynos-clk);
176
177 return 0;
178 }
for each child of this device, we call dwc3_exynos_remove_child(), which
will:
94 static int dwc3_exynos_remove_child(struct device *dev, void *unused)
95 {
96 struct platform_device *pdev = to_platform_device(dev);
97
98 platform_device_unregister(pdev);
99
100return 0;
101 }
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 7/8] ARM: dts: dra7: Add USB related nodes
On 03/14/2014 04:54 PM, Kishon Vijay Abraham I wrote:
On Friday 14 March 2014 05:41 PM, Roger Quadros wrote:
On 03/14/2014 12:38 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 07 March 2014 06:39 PM, Roger Quadros wrote:
Add nodes for the Super Speed USB controllers, omap-control-usb,
USB2 PHY and USB3 PHY devices.
Remove ocp2scp1 address space from hwmod data as it is
now provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 110
++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 ---
2 files changed, 110 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 597979b..1e73900 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -811,6 +811,116 @@
clocks = sata_ref_clk;
ti,hwmods = sata;
};
+
+omap_control_usb2phy1: control-phy@4a002300 {
+compatible = ti,control-phy-usb2;
+reg = 0x4a002300 0x4;
+reg-names = power;
+};
+
+omap_control_usb3phy1: control-phy@4a002370 {
+compatible = ti,control-phy-pipe3;
+reg = 0x4a002370 0x4;
+reg-names = power;
+};
+
+omap_control_usb2phy2: control-phy@0x4a002e74 {
+compatible = ti,control-phy-usb2-dra7;
+reg = 0x4a002e74 0x4;
+reg-names = power;
+};
+
+/* OCP2SCP1 */
+ocp2scp@4a08 {
+compatible = ti,omap-ocp2scp;
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+reg = 0x4a08 0x20;
+ti,hwmods = ocp2scp1;
+
+usb2_phy1: phy@4a084000 {
+compatible = ti,omap-usb2;
+reg = 0x4a084000 0x400;
+ctrl-module = omap_control_usb2phy1;
+clocks = usb_phy1_always_on_clk32k,
+ usb_otg_ss1_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb2_phy2: phy@4a085000 {
+compatible = ti,omap-usb2;
+reg = 0x4a085000 0x400;
+ctrl-module = omap_control_usb2phy2;
+clocks = usb_phy2_always_on_clk32k,
+ usb_otg_ss2_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb3_phy1: phy@4a084400 {
+compatible = ti,omap-usb3;
+reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+reg-names = phy_rx, phy_tx, pll_ctrl;
+ctrl-module = omap_control_usb3phy1;
+clocks = usb_phy3_always_on_clk32k,
+ sys_clkin1,
+ usb_otg_ss1_refclk960m,
+ dpll_core_h13x2_ck;
+clock-names =wkupclk,
+sysclk,
+refclk,
+optclk;
Do we use this 'optclk' in driver?
No we don't. Still the device seems to work without it.
This is supposed to be USB_LFPS_TX_GFCLK or USB3PHY_REF_CLK.
I think it should be enabled. Did you check the status of this clock in
CM_L3INIT_CLKSTCTRL? Moreover USB_LFPS_TX_GFCLK is an interface clock, so
IIUC setting the module mode will enable it.
Btw how did you tell dpll_core_h13x2_ck enables USB_LFPS_TX_GFCLK?
From the clock tree tool. It looks like the clock is gated automatically with
the module mode
as you suggested. I'll get rid of this clock reference then.
cheers,
-roger
--
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] iommu/omap: Use the cache cleaning API
+ Russell, Arnd
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
Hi Laurent,
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management manually
(and ignoring L2 cache), use clean_dcache_area() to make sure the
entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been some
previous attempts at this as well by Ramesh Gupta, with the last thread
(a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++---
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
* H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
-/* FIXME: L2 cache should be taken care of if it exists */
-do {
-asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
-: : r (first));
-first += L1_CACHE_BYTES / sizeof(*first);
-} while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
-/* FIXME: L2 cache should be taken care of if it exists */
-do {
-asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
-: : r (first));
-first += L1_CACHE_BYTES / sizeof(*first);
-} while (first = last);
+clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
Russell, Arnd might have more ideas.
}
static void iopte_free(u32 *iopte)
@@ -546,7 +531,7 @@ static u32 *iopte_alloc(struct omap_iommu *obj, u32
*iopgd, u32 da)
return ERR_PTR(-ENOMEM);
*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
-flush_iopgd_range(iopgd, iopgd);
+flush_pgtable(iopgd, sizeof(*iopgd));
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
@@ -575,7 +560,7 @@ static int iopgd_alloc_section(struct omap_iommu *obj,
u32 da, u32 pa, u32 prot)
}
*iopgd = (pa IOSECTION_MASK) | prot | IOPGD_SECTION;
-flush_iopgd_range(iopgd, iopgd);
+flush_pgtable(iopgd, sizeof(*iopgd));
return 0;
}
@@ -592,7 +577,7 @@ static int iopgd_alloc_super(struct omap_iommu *obj, u32
da, u32 pa, u32 prot)
for (i = 0; i 16; i++)
*(iopgd + i) = (pa IOSUPER_MASK) | prot | IOPGD_SUPER;
-flush_iopgd_range(iopgd, iopgd + 15);
+flush_pgtable(iopgd, sizeof(*iopgd) * 16);
return 0;
}
@@ -605,7 +590,7 @@ static int iopte_alloc_page(struct omap_iommu *obj, u32
da, u32 pa, u32 prot)
return PTR_ERR(iopte);
*iopte = (pa IOPAGE_MASK) | prot | IOPTE_SMALL;
-flush_iopte_range(iopte, iopte);
+flush_pgtable(iopte, sizeof(*iopte));
dev_vdbg(obj-dev, %s: da:%08x pa:%08x pte:%p *pte:%08x\n,
__func__, da, pa, iopte, *iopte);
@@ -619,18 +604,12 @@ static int iopte_alloc_large(struct omap_iommu *obj,
u32 da, u32 pa, u32 prot)
u32 *iopte = iopte_alloc(obj, iopgd, da);
int i;
-if ((da | pa) ~IOLARGE_MASK) {
-dev_err(obj-dev, %s: %08x:%08x should aligned on %08lx\n,
-__func__, da, pa, IOLARGE_SIZE);
-return -EINVAL;
-}
-
if (IS_ERR(iopte))
return PTR_ERR(iopte);
for (i = 0; i 16; i++)
*(iopte + i) = (pa IOLARGE_MASK) | prot | IOPTE_LARGE;
-flush_iopte_range(iopte, iopte + 15);
+flush_pgtable(iopte, sizeof(*iopte) * 16);
return 0;
}
@@ -733,7 +712,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
}
bytes *= nent;
memset(iopte, 0, nent * sizeof(*iopte));
-flush_iopte_range(iopte, iopte + (nent - 1) * sizeof(*iopte));
+flush_pgtable(iopte, sizeof(*iopte) * nent);
/*
* do table walk to check if this table is necessary or not
@@ -755,7 +734,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
bytes *= nent;
}
memset(iopgd, 0, nent * sizeof(*iopgd));
-flush_iopgd_range(iopgd, iopgd + (nent - 1) * sizeof(*iopgd));
+
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On 14/03/14 18:04, Felipe Balbi wrote:
On Fri, Mar 14, 2014 at 02:07:45PM +, Mark Rutland wrote:
On Fri, Mar 14, 2014 at 11:07:05AM +, Tomi Valkeinen wrote:
On 14/03/14 12:19, Tomi Valkeinen wrote:
On 14/03/14 12:14, Mark Rutland wrote:
I can't see anything obviously wrong in platform_device_del. Do you have
a backtrace?
Yes, below.
I can see at least drivers/usb/dwc3/dwc3-exynos.c doing the exact same
thing
I do, so maybe I've got something wrong with the omapdss driver.
Looks to me that the devices created by of_platform_populate() are not
unregisterable in all cases. The address resource created via
of_platform_populate() had NULL res-parent, which causes
release_resource to crash.
Hmm. I can't see that unregistering such devices ever works as you say,
given that __release_resource expects a non-NULL parent pointer. Either
we should be setting the parent pointer when initialising devices from
dt or we should teach __release_resource to not care. I'll have a go at
fixing that.
It looks like drivers/usb/dwc3/dwc3-exynos.c only unregisters the
top-level device, not children. This top-level device has no
IORESOURCE_{IO,MEM} resources judging by
arch/arm/boot/dts/exynos5250.dtsi, which would explain why that driver
isn't exploding: __release_resource will never get called.
Anton, Felipe:
Does unregistering the parent ensure the children get cleaned up, or
does it leave them dangling in the dwc3-exynos driver?
you should platform_device_unregister() for each children and
dwc3-exynos does that just fine:
Yes, that's what I do also, and it crashes. What Mark said above about
unregistering never working for such devices is correct, but I don't
know why he said dwc3-exynos only unregisters the top level device.
such devices above meaning devices with a 'reg' defined in the DT
data, if I'm not mistaken.
So at the moment, I think of_platform_populate() and
platform_device_unregister() combination in a driver is a bit risky.
Work fine for certain cases, not for some other.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API
Hi Santosh,
On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
+ Russell, Arnd
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management manually
(and ignoring L2 cache), use clean_dcache_area() to make sure the
entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been some
previous attempts at this as well by Ramesh Gupta, with the last thread
(a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++-
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
* H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
Please note that the omap-iommu driver already uses clean_dcache_area().
That's where I got the idea :-)
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
I can replace clean_dcache_area() with dma_map_page() as done by the arm-smmu
driver. If that's fine I'll modify this patch accordingly in v2.
Russell, Arnd might have more ideas.
}
static void iopte_free(u32 *iopte)
--
Regards,
Laurent Pinchart
--
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] iommu/omap: Use the cache cleaning API
On Friday 14 March 2014, Santosh Shilimkar wrote: I remember NAKing this approach in past and my stand remains same. The cache APIs which you are trying to use here are not suppose to be used outside. I think the right way to fix this is to make use of streaming APIs. If needed, IOMMU can have its own dma_ops for special case handling if any. Russell, Arnd might have more ideas. I have a bad feeling about using the dma-mapping API within the IOMMU code, because that driver is also used to implement the dma-mapping API for devices attached to the IOMMU. It's possible that it just works. Is the IOMMU actually designed to have page tables in noncoherent memory? I would have expected that the iopt accesses must all be done on dma_alloc_coherent() provided memory to guarantee proper accesses. Arnd -- 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] iommu/omap: Use the cache cleaning API
On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
Hi Santosh,
On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
+ Russell, Arnd
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management manually
(and ignoring L2 cache), use clean_dcache_area() to make sure the
entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been some
previous attempts at this as well by Ramesh Gupta, with the last thread
(a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++-
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
* H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
Please note that the omap-iommu driver already uses clean_dcache_area().
That's where I got the idea :-)
So that fall through the cracks then ;-)
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
I can replace clean_dcache_area() with dma_map_page() as done by the arm-smmu
driver. If that's fine I'll modify this patch accordingly in v2.
That will be definitely a better option than the APIs used. Those streaming
APIs will take care of L2 cache as well if present.
Regards,
Santosh
--
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] iommu/omap: Use the cache cleaning API
On Friday 14 March 2014 12:57 PM, Arnd Bergmann wrote: On Friday 14 March 2014, Santosh Shilimkar wrote: I remember NAKing this approach in past and my stand remains same. The cache APIs which you are trying to use here are not suppose to be used outside. I think the right way to fix this is to make use of streaming APIs. If needed, IOMMU can have its own dma_ops for special case handling if any. Russell, Arnd might have more ideas. I have a bad feeling about using the dma-mapping API within the IOMMU code, because that driver is also used to implement the dma-mapping API for devices attached to the IOMMU. It's possible that it just works. Thats a good point. Is the IOMMU actually designed to have page tables in noncoherent memory? I would have expected that the iopt accesses must all be done on dma_alloc_coherent() provided memory to guarantee proper accesses. At least the OMAP one seems to use non-coherent memory which will need CMO. Regards, Santosh -- 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 4/4] ARM: DTS: AM43x: Add DSS node
On Fri, Mar 14, 2014 at 04:34:19PM +, Tomi Valkeinen wrote:
On 14/03/14 18:04, Felipe Balbi wrote:
On Fri, Mar 14, 2014 at 02:07:45PM +, Mark Rutland wrote:
On Fri, Mar 14, 2014 at 11:07:05AM +, Tomi Valkeinen wrote:
On 14/03/14 12:19, Tomi Valkeinen wrote:
On 14/03/14 12:14, Mark Rutland wrote:
I can't see anything obviously wrong in platform_device_del. Do you have
a backtrace?
Yes, below.
I can see at least drivers/usb/dwc3/dwc3-exynos.c doing the exact same
thing
I do, so maybe I've got something wrong with the omapdss driver.
Looks to me that the devices created by of_platform_populate() are not
unregisterable in all cases. The address resource created via
of_platform_populate() had NULL res-parent, which causes
release_resource to crash.
Hmm. I can't see that unregistering such devices ever works as you say,
given that __release_resource expects a non-NULL parent pointer. Either
we should be setting the parent pointer when initialising devices from
dt or we should teach __release_resource to not care. I'll have a go at
fixing that.
It looks like drivers/usb/dwc3/dwc3-exynos.c only unregisters the
top-level device, not children. This top-level device has no
IORESOURCE_{IO,MEM} resources judging by
arch/arm/boot/dts/exynos5250.dtsi, which would explain why that driver
isn't exploding: __release_resource will never get called.
Anton, Felipe:
Does unregistering the parent ensure the children get cleaned up, or
does it leave them dangling in the dwc3-exynos driver?
you should platform_device_unregister() for each children and
dwc3-exynos does that just fine:
Yes, that's what I do also, and it crashes. What Mark said above about
unregistering never working for such devices is correct, but I don't
know why he said dwc3-exynos only unregisters the top level device.
Because I'd failed to read the code correctly. It does indeed unregister
each of the children via platform_device_unregister.
Apologies for the confusion there.
such devices above meaning devices with a 'reg' defined in the DT
data, if I'm not mistaken.
Yes. As far as I can see, IORESOURCE_MEM resources instantiated from reg
entries in dt do not have their parent pointer initialised, and will
cause __release_resource to blow up. A quick inspection of resources on
my TC2 shows this to be the case -- the parent, sibling, and child
pointers are all NULL.
I'm at a loss to explain how the dwc3-exynos driver can call
platform_device_unregister on devices with such resource and not blow
up. Is anyone able to test dwc3_exynos_remove?
So at the moment, I think of_platform_populate() and
platform_device_unregister() combination in a driver is a bit risky.
Work fine for certain cases, not for some other.
It certainly looks to be broken at the moment, but it should be fixable.
Thanks,
Mark.
--
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 3/9] PM / OPP: Add hook to modify OPPs after they are loaded.
Add a hook inside opp_init_cpufreq_table to allow all cpufreq drivers
to utilize OPP modifier functionality. Hook will return success if no
phandle is present for devices that do not use opp-modifier.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
drivers/base/power/opp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index fa41874..eaedc6b 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -24,6 +24,7 @@
#include linux/pm_opp.h
#include linux/of.h
#include linux/export.h
+#include linux/opp-modifier.h
/*
* Internal data structure organization with the OPP layer library is as
@@ -629,6 +630,13 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct dev_pm_opp *opp;
struct cpufreq_frequency_table *freq_table;
int i = 0;
+ int ret;
+
+ ret = opp_modify_dev_table(dev);
+ if (ret) {
+ pr_err(failed to modify OPP table: %d\n, ret);
+ return ret;
+ }
/* Pretend as if I am an updater */
mutex_lock(dev_opp_list_lock);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 8/9] ARM: dts: dra7: Add opp-modifier device entry and add higher OPPs
Add an entry for opp-modifier which configures OPPs on 43xx. Within
this, nodes are defined with the opp-modifier propety that are defined as
a list of frequency, offset from base register, and efuse value.
The CPU node passes a phandle to the appropriate child node to get the
correct table.
This patch also adds higher eFused OPPs for dra7.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 18 ++
include/dt-bindings/opp/ti.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..ffd0bae 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -9,6 +9,7 @@
#include dt-bindings/interrupt-controller/arm-gic.h
#include dt-bindings/pinctrl/dra.h
+#include dt-bindings/opp/ti.h
#include skeleton.dtsi
@@ -46,7 +47,10 @@
/* kHzuV */
100 106
1176000 116
+ 150 126
;
+
+ platform-opp-modifier = mpu_opp_modifier;
};
cpu@1 {
device_type = cpu;
@@ -621,6 +625,20 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ opp_modifier: opp_modifier@0x4AE0C20C {
+ compatible = opp-modifier-reg-val;
+ reg = 0x4AE0C20C 0x04;
+ opp,reg-mask = 0x00F7;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 150 0 DRA7_EFUSE_HAS_HIGH_MPU_OPP
+ 1176000 0 DRA7_EFUSE_HAS_OD_MPU_OPP
+ ;
+ };
+ };
};
};
diff --git a/include/dt-bindings/opp/ti.h b/include/dt-bindings/opp/ti.h
index cb62c32..0f5efe8 100644
--- a/include/dt-bindings/opp/ti.h
+++ b/include/dt-bindings/opp/ti.h
@@ -27,4 +27,7 @@
#define OMAP4_EFUSE_HAS_PERF_SILICON_BIT (1 17)
+#define DRA7_EFUSE_HAS_OD_MPU_OPP 11
+#define DRA7_EFUSE_HAS_HIGH_MPU_OPP15
+
#endif /* __DT_BINDINGS_OPP_TI_H__ */
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/9] Introduce OPP modifier for ARM SoCs
There are many SoCs that can have different operating points supported depending on different conditions even for otherwise identical parts. It does not make sense to define many different iterations of a device tree file for each possible permutation of the same device especially when this data may exist within the part. This proposal introduces a framework and example driver to help in enabling or disabling appropriate OPPs based on a register value. The information needed for deciding which OPPs are to be enabled is defined in the device tree in a table so that one device tree file is able to support any version of the part. This series is mostly untested besides 335x and only is intended to demonstrate the approach for dynamically changing available OPPs. The framework allows other drivers to register themselves and then through a single function call modify which OPPs are available for a device. The included opp-modifier-reg driver can already support many different SoCs that have a manufacturer modifiable register defining which OPPs are possible on the SoC. This series includes example entries for am335x, am437x, omap4, dra7, and imx6q. The opp-modifier-reg driver expects all possible OPPs to be loaded for the device already and then is able to modify the table based on the details passed compared to the defined register. This RFC only applies to MPU OPPs and only supports modifying the OPP list to contain supported OPPs during boot but this driver could easily be extended to support modifying the OPPs of other IPs that have them easily by placing the hook (in patch 3 here) elsewhere. The hook for opp-modifier was placed in its current only as a proof of concept; if there is a better location it should be moved. This series is tested on am33xx but must be used with 2.x+ silicon as the earlier revision does not support the same OPPs. Also for the additional OPPs the maximum voltage supplied by the regulator for the MPU rail on both am335 and am437x would need to be extended but those patches were left out of this series to focus on opp-modifier. Comments? Is this a reasonable direction to take? Dave Gerlach (9): opp-modifier: Introduce OPP Modifier Framework opp-modifier: Add opp-modifier-reg driver PM / OPP: Add hook to modify OPPs after they are loaded. ARM: dts: AM33XX: Add opp-modifier device entry and add higher OPPs ARM: dts: AM4372: Add opp-modifier device entry and add higher OPPs ARM: dts: omap443x: Add opp-modifier entry and add higher OPPs ARM: dts: omap4460: Add opp-modifier entry and add higher OPPs ARM: dts: dra7: Add opp-modifier device entry and add higher OPPs ARM: dts: imx6q: Add opp-modifier device entry .../devicetree/bindings/power/opp-modifier.txt | 111 + arch/arm/boot/dts/am33xx.dtsi | 27 ++- arch/arm/boot/dts/am4372.dtsi | 30 +++ arch/arm/boot/dts/dra7.dtsi| 18 ++ arch/arm/boot/dts/imx6q.dtsi | 18 ++ arch/arm/boot/dts/omap443x.dtsi| 16 ++ arch/arm/boot/dts/omap4460.dtsi| 17 ++ drivers/base/power/opp.c | 8 + drivers/power/Makefile | 2 + drivers/power/opp/Makefile | 2 + drivers/power/opp/core.c | 126 ++ drivers/power/opp/opp-modifier-reg.c | 259 + include/dt-bindings/opp/imx.h | 17 ++ include/dt-bindings/opp/ti.h | 33 +++ include/linux/opp-modifier.h | 35 +++ 15 files changed, 717 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt create mode 100644 drivers/power/opp/Makefile create mode 100644 drivers/power/opp/core.c create mode 100644 drivers/power/opp/opp-modifier-reg.c create mode 100644 include/dt-bindings/opp/imx.h create mode 100644 include/dt-bindings/opp/ti.h create mode 100644 include/linux/opp-modifier.h -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/9] ARM: dts: AM4372: Add opp-modifier device entry and add higher OPPs
Add an entry for opp_modifier which configures OPPs on AM4372. Within
this, nodes are defined with the opp-modifier propety that are defined as
a list of frequency, offset from base register, and efuse value.
The CPU node passes a phandle to the appropriate child node to get the
correct table.
This patch also adds higher eFused OPPs for AM4372.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 30 ++
include/dt-bindings/opp/ti.h | 6 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c6bd4d9..dbaa2e3 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -9,6 +9,7 @@
*/
#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/opp/ti.h
#include skeleton.dtsi
@@ -33,6 +34,17 @@
compatible = arm,cortex-a9;
device_type = cpu;
reg = 0;
+
+ operating-points =
+ /* kHzuV */
+ 30 95
+ 60 110
+ 72 120
+ 80 126
+ 100 1325000
+ ;
+
+ platform-opp-modifier = mpu_opp_modifier;
};
};
@@ -662,6 +674,24 @@
dma-names = tx, rx;
};
+ opp_modifier: opp_modifier@0x44e10610 {
+ compatible = opp-modifier-reg-bit;
+ reg = 0x44e10610 0x04;
+
+ opp,reg-bit-enable-low;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 100 0
AM43XX_EFUSE_SMA_OPP_NITRO_1GHZ_BIT
+ 80 0
AM43XX_EFUSE_SMA_OPP_TURBO_800MHZ_BIT
+ 72 0
AM43XX_EFUSE_SMA_OPP_120_720MHZ_BIT
+ 60 0
AM43XX_EFUSE_SMA_OPP_100_600MHZ_BIT
+ 30 0
AM43XX_EFUSE_SMA_OPP_50_300MHZ_BIT
+ ;
+ };
+ };
+
mcasp0: mcasp@48038000 {
compatible = ti,am33xx-mcasp-audio;
ti,hwmods = mcasp0;
diff --git a/include/dt-bindings/opp/ti.h b/include/dt-bindings/opp/ti.h
index 58436c1..d3717be 100644
--- a/include/dt-bindings/opp/ti.h
+++ b/include/dt-bindings/opp/ti.h
@@ -19,4 +19,10 @@
#define AM33XX_EFUSE_SMA_OPP_TURBO_800MHZ_BIT (1 8)
#define AM33XX_EFUSE_SMA_OPP_NITRO_1GHZ_BIT (1 9)
+#define AM43XX_EFUSE_SMA_OPP_50_300MHZ_BIT (1 0)
+#define AM43XX_EFUSE_SMA_OPP_100_600MHZ_BIT (1 2)
+#define AM43XX_EFUSE_SMA_OPP_120_720MHZ_BIT (1 3)
+#define AM43XX_EFUSE_SMA_OPP_TURBO_800MHZ_BIT (1 4)
+#define AM43XX_EFUSE_SMA_OPP_NITRO_1GHZ_BIT (1 5)
+
#endif /* __DT_BINDINGS_OPP_TI_H__ */
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/9] opp-modifier: Introduce OPP Modifier Framework
Introduce framework to allow an OPP modifier driver to selectively
determine which possible OPPs for an SoC are available based on
register values found in SoC through a common API.
Three functions are exported, a register and unregister function for
the opp modifier drivers to notify the API of their existence, and
opp_modify_dev_table which looks up the appropriate driver and
DT information to use for a device and then uses enable/disable to
change which previously loaded OPPs are available on the device.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
drivers/power/Makefile | 2 +
drivers/power/opp/Makefile | 1 +
drivers/power/opp/core.c | 126 +++
include/linux/opp-modifier.h | 35
4 files changed, 164 insertions(+)
create mode 100644 drivers/power/opp/Makefile
create mode 100644 drivers/power/opp/core.c
create mode 100644 include/linux/opp-modifier.h
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ee54a3e..ed379cf 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -58,3 +58,5 @@ obj-$(CONFIG_POWER_AVS) += avs/
obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
obj-$(CONFIG_POWER_RESET) += reset/
+
+obj-y += opp/
diff --git a/drivers/power/opp/Makefile b/drivers/power/opp/Makefile
new file mode 100644
index 000..820eb10
--- /dev/null
+++ b/drivers/power/opp/Makefile
@@ -0,0 +1 @@
+obj-y += core.o
diff --git a/drivers/power/opp/core.c b/drivers/power/opp/core.c
new file mode 100644
index 000..403013b
--- /dev/null
+++ b/drivers/power/opp/core.c
@@ -0,0 +1,126 @@
+/*
+ * OPP Modifier framework
+ *
+ * Copyright (C) 2013 Texas Instruments Inc.
+ * Dave Gerlach d-gerl...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/export.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/slab.h
+#include linux/opp-modifier.h
+
+static DEFINE_MUTEX(opp_modifier_list_mutex);
+static LIST_HEAD(opp_modifier_list);
+
+static int opp_modify_dev_opp_table(struct opp_modifier_dev *opp_dev,
+ struct device *dev)
+{
+ if (opp_dev-ops-modify)
+ return opp_dev-ops-modify(dev);
+
+ return -EINVAL;
+}
+
+static struct opp_modifier_dev *opp_modifier_get(struct device *dev)
+{
+ struct opp_modifier_dev *o, *opp_dev;
+ struct device_node *np;
+
+ if (!dev)
+ return ERR_PTR(-EINVAL);
+
+ np = of_parse_phandle(dev-of_node, platform-opp-modifier, 0);
+
+ if (!np)
+ return ERR_PTR(-ENOSYS);
+
+ opp_dev = NULL;
+
+ mutex_lock(opp_modifier_list_mutex);
+
+ list_for_each_entry(o, opp_modifier_list, list) {
+ if (of_get_parent(np) == o-of_node) {
+ opp_dev = o;
+ break;
+ }
+ }
+
+ if (!opp_dev) {
+ mutex_unlock(opp_modifier_list_mutex);
+ return ERR_PTR(-EINVAL);
+ }
+
+ of_node_put(np);
+
+ try_module_get(opp_dev-owner);
+ mutex_unlock(opp_modifier_list_mutex);
+
+ return opp_dev;
+}
+
+static void opp_modifier_put(struct opp_modifier_dev *opp_dev)
+{
+ if (IS_ERR(opp_dev))
+ return;
+
+ module_put(opp_dev-owner);
+}
+
+int opp_modifier_register(struct opp_modifier_dev *opp_dev)
+{
+ mutex_lock(opp_modifier_list_mutex);
+ list_add(opp_dev-list, opp_modifier_list);
+ mutex_unlock(opp_modifier_list_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(opp_modifier_register);
+
+void opp_modifier_unregister(struct opp_modifier_dev *opp_dev)
+{
+ mutex_lock(opp_modifier_list_mutex);
+ list_del(opp_dev-list);
+ mutex_unlock(opp_modifier_list_mutex);
+}
+EXPORT_SYMBOL_GPL(opp_modifier_unregister);
+
+int opp_modify_dev_table(struct device *dev)
+{
+ struct opp_modifier_dev *opp_dev;
+ int ret;
+
+ opp_dev = opp_modifier_get(dev);
+
+ /*
+* It is a valid case for a device to not implement
+* an OPP modifier table so return 0 if not present
+*/
+
+ if (IS_ERR(opp_dev) PTR_ERR(opp_dev) == -ENOSYS) {
+ dev_dbg(dev, No platform-opp-modifier entry present\n);
+ return 0;
+ } else if (IS_ERR(opp_dev)) {
+ return PTR_ERR(opp_dev);
+ }
+
+ ret = opp_modify_dev_opp_table(opp_dev,
[RFC 9/9] ARM: dts: imx6q: Add opp-modifier device entry
Add an entry for opp_modifier which configures OPPs on imx6q. Within
this nodes are defined with opp-modifier propety that are defined as a list
of frequency, offset from base register, and efuse value.
This is an untested example patch to show how opp-modifier could be used
for this platform.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/imx6q.dtsi | 18 ++
include/dt-bindings/opp/imx.h | 17 +
2 files changed, 35 insertions(+)
create mode 100644 include/dt-bindings/opp/imx.h
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..4cc48ef 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -10,6 +10,7 @@
#include imx6q-pinfunc.h
#include imx6qdl.dtsi
+#include dt-bindings/opp/imx.h
/ {
cpus {
@@ -36,6 +37,8 @@
arm-supply = reg_arm;
pu-supply = reg_pu;
soc-supply = reg_soc;
+
+ platform-opp-modifier = mpu_opp_modifier;
};
cpu@1 {
@@ -140,6 +143,21 @@
clock-names = bus, di0, di1;
resets = src 4;
};
+
+ opp_modifier: opp_modifier@0x021bc440 {
+ compatible = opp-modifier-reg-val;
+ reg = 0x021bc440 0x04;
+ opp,reg-mask = 0x0003;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 120 0 OPP_OCOTP_CFG3_SPEED_1P2GHZ
+ 996000 0 OPP_OCOTP_CFG3_SPEED_996MHZ
+ ;
+ };
+ };
+
};
};
diff --git a/include/dt-bindings/opp/imx.h b/include/dt-bindings/opp/imx.h
new file mode 100644
index 000..2700ab9
--- /dev/null
+++ b/include/dt-bindings/opp/imx.h
@@ -0,0 +1,17 @@
+/*
+ * This header provides constants for iMX SoC OPP bindings.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DT_BINDINGS_OPP_IMX_H__
+#define __DT_BINDINGS_OPP_IMX_H__
+
+#define OPP_OCOTP_CFG3_SPEED_1P2GHZ(0x3 16)
+#define OPP_OCOTP_CFG3_SPEED_996MHZ(0x2 16)
+#define OPP_OCOTP_CFG3_SPEED_852MHZ(0x1 16)
+
+#endif /* __DT_BINDINGS_OPP_IMX_H__ */
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/9] ARM: dts: AM33XX: Add opp-modifier device entry and add higher OPPs
Add an entry for opp_modifier which configures OPPs on am33xx. Within this
nodes are defined with opp-modifier propety that are defined as a list
of frequency, offset from base register, and efuse value. The CPU node
passes a phandle to the appropriate child node of the efuse node.
This patch also adds the ES2.x OPPs for am33xx.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 27 +--
include/dt-bindings/opp/ti.h | 22 ++
2 files changed, 47 insertions(+), 2 deletions(-)
create mode 100644 include/dt-bindings/opp/ti.h
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..a09f4fb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -10,6 +10,7 @@
#include dt-bindings/gpio/gpio.h
#include dt-bindings/pinctrl/am33xx.h
+#include dt-bindings/opp/ti.h
#include skeleton.dtsi
@@ -52,12 +53,17 @@
*/
operating-points =
/* kHzuV */
+ 100 1351000
+ 80 1285000
72 1285000
60 1225000
- 50 1125000
- 275000 1125000
+ 30 1125000
;
+
voltage-tolerance = 2; /* 2 percentage */
+
+ platform-opp-modifier = mpu_opp_modifier;
+
clock-latency = 30; /* From omap-cpufreq driver */
};
};
@@ -818,6 +824,23 @@
reg = 0x4831 0x2000;
interrupts = 111;
};
+
+ opp_modifier: opp_modifier@0x44e107fc {
+ compatible = opp-modifier-reg-bit;
+ reg = 0x44e107fc 0x04;
+
+ opp,reg-bit-enable-low;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 100 0
AM33XX_EFUSE_SMA_OPP_NITRO_1GHZ_BIT
+ 80 0
AM33XX_EFUSE_SMA_OPP_TURBO_800MHZ_BIT
+ 72 0
AM33XX_EFUSE_SMA_OPP_120_720MHZ_BIT
+ 60 0
AM33XX_EFUSE_SMA_OPP_100_600MHZ_BIT
+ ;
+ };
+ };
};
};
diff --git a/include/dt-bindings/opp/ti.h b/include/dt-bindings/opp/ti.h
new file mode 100644
index 000..58436c1
--- /dev/null
+++ b/include/dt-bindings/opp/ti.h
@@ -0,0 +1,22 @@
+/*
+ * This header provides constants for TI SoC OPP bindings.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DT_BINDINGS_OPP_TI_H__
+#define __DT_BINDINGS_OPP_TI_H__
+
+#define AM33XX_EFUSE_SMA_OPP_50_300MHZ_BIT (1 4)
+#define AM33XX_EFUSE_SMA_OPP_100_300MHZ_BIT (1 5)
+#define AM33XX_EFUSE_SMA_OPP_100_600MHZ_BIT (1 6)
+#define AM33XX_EFUSE_SMA_OPP_120_720MHZ_BIT (1 7)
+#define AM33XX_EFUSE_SMA_OPP_TURBO_800MHZ_BIT (1 8)
+#define AM33XX_EFUSE_SMA_OPP_NITRO_1GHZ_BIT (1 9)
+
+#endif /* __DT_BINDINGS_OPP_TI_H__ */
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/9] opp-modifier: Add opp-modifier-reg driver
Driver to read from a register and depending on either set bits or
a specific known selectively enable or disable OPPs based on DT node.
Can support opp-modifier-reg-bit where single bits within the register
determine the availability of an OPP or opp-modifier-reg-val where a
certain value inside the register or a portion of it determine what the
maximum allowed OPP is.
The driver expects a device that has already has its OPPs loaded
and then will disable the OPPs not matching the criteria specified in
the opp-modifier table.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
.../devicetree/bindings/power/opp-modifier.txt | 111 +
drivers/power/opp/Makefile | 1 +
drivers/power/opp/opp-modifier-reg.c | 259 +
3 files changed, 371 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt
create mode 100644 drivers/power/opp/opp-modifier-reg.c
diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt
b/Documentation/devicetree/bindings/power/opp-modifier.txt
new file mode 100644
index 000..af8a2e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/opp-modifier.txt
@@ -0,0 +1,111 @@
+* OPP-Modifier - opp modifier to selectively enable operating points
+
+Many SoCs that have selectively modifiable OPPs can specify
+all available OPPs in their operating-points listing and then define
+opp_modifiers to enable or disable the OPPs that are actually available
+on the specific hardware.
+
+* OPP Modifier Provider
+
+For single bits that define the availability of an OPP:
+---
+Some SoCs define a bit in a register that indicates whether an OPP is
+available. This will disable any OPP with a frequency corresponding to
+the bit given if it is not set appropriately.
+
+properties:
+- compatible : Should be opp-modifier-reg-bit
+- reg : Address and length of the registers needed to identify available
+ OPPs, here we provide just the register containing OPP data.
+
+Optional Properties:
+- opp,reg-bit-enable-low: Take the complement of register before comparing mask
+defined below under opp-modifier.
+
+Sub-nodes:
+Sub-nodes are defined as a container to hold opp modifier table for a
+specific device with an operating-points table already defined
+
+Sub-node properties:
+- opp-modifier: A collection of rows consisting of the following entries to
+ allow specification of available OPPs:
+ -kHz: The opp to be enabled based on following criteria
+ -offset: Offset into register where relevant bits are located
+ -value: Bit that indicates availability of OPP
+
+Example:
+
+ opp_modifier: opp_modifier@0x44e107fc {
+ compatible = opp-modifier-reg-bit;
+ reg = 0x44e107fc 0x04;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 100 0 BIT_1
+ 72 0 BIT_2
+ ;
+ };
+ };
+
+For a value that defines the maximum available OPP:
+---
+Some SoCs define a value in a register that corresponds to an OPP. If
+that value is matched this will disable all OPPs greater than the
+associated frequency.
+
+properties:
+- compatible : Should be opp-modifier-reg-val
+- reg : Address and length of the registers needed to identify available
+ OPPs, here we provide just the register containing OPP data.
+
+Optional Properties:
+- opp,reg-mask: Only compare the bits masked off by this value.
+
+Sub-nodes:
+Sub-nodes are defined as a container to hold opp modifier table for a
+specific device with an operating-points table already defined
+
+Sub-node properties:
+- opp-modifier: A collection of rows consisting of the following entries to
+ allow specification of available OPPs:
+ -kHz: The opp to be enabled based on following criteria
+ -offset: Offset into register where relevant bits are located
+ -value: Value that indicates maximum available OPP
+
+Example:
+
+ opp_modifier: opp_modifier@0x44e107fc {
+ compatible = opp-modifier-reg-val;
+ reg = 0x44e107fc 0x04;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 100 0 VAL_1
+ 72 0 VAL_2
+ ;
+ };
+ };
+
+* OPP Modifier Consumer
+
+Properties:
+- platform-opp-modifier: phandle to the sub-node of the proper opp-modifier
+ provider that contains the appropriate opp-modifier table
+
+Example:
+
+cpu@0 {
+compatible = arm,cortex-a8;
+device_type = cpu;
+
+operating-points =
+/* kHz
[RFC 7/9] ARM: dts: omap4460: Add opp-modifier entry and add higher OPPs
Add an entry for opp_modifier which configures OPPs on omap4460. Within
this, nodes are defined with the opp-modifier propety that are defined
as a list of frequency, offset from base register, and register value.
The CPU node passes a phandle to the appropriate child node to get the
correct table.
This patch also adds higher eFused OPPs for omap4460.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 6b32f52..5271121 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
#include omap4.dtsi
+#include dt-bindings/opp/ti.h
/ {
cpus {
@@ -18,9 +19,13 @@
35 1025000
70 120
92 1313000
+ 120 138
+ 150 139
;
clock-latency = 30; /* From legacy driver */
+ platform-opp-modifier = mpu_opp_modifier;
+
/* cooling options */
cooling-min-level = 0;
cooling-max-level = 2;
@@ -50,6 +55,18 @@
#thermal-sensor-cells = 0;
};
+
+ opp_modifier: opp_modifier@0x4A002218 {
+ compatible = opp-modifier-reg-bit;
+ reg = 0x4A002218 0x04;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 150 0 OMAP4_EFUSE_HAS_PERF_SILICON_BIT
+ ;
+ };
+ };
};
};
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 6/9] ARM: dts: omap443x: Add opp-modifier entry and add higher OPPs
Add an entry for opp_modifier which configures OPPs on omap443x. Within
this, nodes are defined with the opp-modifier propety that are defined as
a list of frequency, offset from base register, and register value. The
CPU node passes a phandle to the appropriate child node to get the correct
table.
This patch also adds higher eFused OPPs for omap443x.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 16
include/dt-bindings/opp/ti.h| 2 ++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 8c1cfad..1c7e730 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -9,6 +9,7 @@
*/
#include omap4.dtsi
+#include dt-bindings/opp/ti.h
/ {
cpus {
@@ -20,9 +21,12 @@
60 120
80 1313000
1008000 1375000
+ 120 1388000
;
clock-latency = 30; /* From legacy driver */
+ platform-opp-modifier = mpu_opp_modifier;
+
/* cooling options */
cooling-min-level = 0;
cooling-max-level = 3;
@@ -42,6 +46,18 @@
#thermal-sensor-cells = 0;
};
+
+ opp_modifier: opp_modifier@0x4A002218 {
+ compatible = opp-modifier-reg-bit;
+ reg = 0x4A002218 0x04;
+
+ mpu_opp_modifier: mpu_opp_modifier {
+ opp-modifier =
+ /* kHz offset value */
+ 120 0 OMAP4_EFUSE_HAS_PERF_SILICON_BIT
+ ;
+ };
+ };
};
};
diff --git a/include/dt-bindings/opp/ti.h b/include/dt-bindings/opp/ti.h
index d3717be..cb62c32 100644
--- a/include/dt-bindings/opp/ti.h
+++ b/include/dt-bindings/opp/ti.h
@@ -25,4 +25,6 @@
#define AM43XX_EFUSE_SMA_OPP_TURBO_800MHZ_BIT (1 4)
#define AM43XX_EFUSE_SMA_OPP_NITRO_1GHZ_BIT (1 5)
+#define OMAP4_EFUSE_HAS_PERF_SILICON_BIT (1 17)
+
#endif /* __DT_BINDINGS_OPP_TI_H__ */
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs
On 03/14/2014 10:52 AM, Tony Lindgren wrote: * Joel Fernandes jo...@ti.com [140313 16:52]: On 03/13/2014 03:48 PM, Tony Lindgren wrote: * Joel Fernandes jo...@ti.com [140313 13:43]: We introduce functions to initialize clocksource and clockevent, use CLOCKSOURCE_OF_DECLARE to declare the clocksource, and handle the clocksource selection on a per-SoC basis (Currently only AM335x is supported). Powering up of the timer will be done with the help of the mach-omap layer function that's introduced earlier in the series. We make a local copy of dmtimer API for use by clocksource, the original dmtimer API in plat-omap is kept as-is till the migration of all SoCs is completed after which it can't be deleted. Signed-off-by: Joel Fernandes jo...@ti.com --- drivers/clocksource/Makefile |1 + drivers/clocksource/omap-timer.c | 1157 ++ drivers/clocksource/omap-timer.h | 422 ++ 3 files changed, 1580 insertions(+) create mode 100644 drivers/clocksource/omap-timer.c create mode 100644 drivers/clocksource/omap-timer.h Hmm this leaves duplicate arch/arm/plat-omap/dmtimer.c code, please Sure, ofcourse- but how else can we make sure everything works while we do the migration in steps. We can get rid of the duplicate once everything is migrated. That's not doing incremental changes then. You're not even modifying the existing omap_dm_timer functions, so please do the changes in incremental steps where things keep working throughout the series. That is much more work than appears- it is much easier to remove what you don't want after everything is moved, than to pick things up part by part and move it.. That way we also don't accidentally remove something we shouldn't be and introduced more regressions.. right? Plus this is an RFC that I whipped up in 2 days so I didn't this expectations should be too high ;-) And not the that drivers/clocksource/omap-timer.h won't be needed at all, those defines can stay private to the drivers/clocksource/omap-timer.c. Actually- I wanted it separate because omap-timer.c is already huge at 1157 lines. Infact the largest among the clocksource drivers. Is that fair? No need for it. We want to keep these functions private to the driver. Ok, I can do that. I don't mind either way. Thanks, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs
On 03/14/2014 02:32 PM, Joel Fernandes wrote: On 03/14/2014 10:52 AM, Tony Lindgren wrote: * Joel Fernandes jo...@ti.com [140313 16:52]: On 03/13/2014 03:48 PM, Tony Lindgren wrote: * Joel Fernandes jo...@ti.com [140313 13:43]: We introduce functions to initialize clocksource and clockevent, use CLOCKSOURCE_OF_DECLARE to declare the clocksource, and handle the clocksource selection on a per-SoC basis (Currently only AM335x is supported). Powering up of the timer will be done with the help of the mach-omap layer function that's introduced earlier in the series. We make a local copy of dmtimer API for use by clocksource, the original dmtimer API in plat-omap is kept as-is till the migration of all SoCs is completed after which it can't be deleted. Signed-off-by: Joel Fernandes jo...@ti.com --- drivers/clocksource/Makefile |1 + drivers/clocksource/omap-timer.c | 1157 ++ drivers/clocksource/omap-timer.h | 422 ++ 3 files changed, 1580 insertions(+) create mode 100644 drivers/clocksource/omap-timer.c create mode 100644 drivers/clocksource/omap-timer.h Hmm this leaves duplicate arch/arm/plat-omap/dmtimer.c code, please Sure, ofcourse- but how else can we make sure everything works while we do the migration in steps. We can get rid of the duplicate once everything is migrated. That's not doing incremental changes then. You're not even modifying the existing omap_dm_timer functions, so please do the changes in incremental steps where things keep working throughout the series. That is much more work than appears- it is much easier to remove what you don't want after everything is moved, than to pick things up part by part and move it.. That way we also don't accidentally remove something we shouldn't be and introduced more regressions.. right? Plus this is an RFC that I whipped up in 2 days so I didn't this expectations should be too high ;-) s/this/think/ -- 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/4] power_supply: Introduce generic psy charging driver
On Fri, Mar 14, 2014 at 11:36:40AM +0100, Linus Walleij wrote: On Thu, Mar 13, 2014 at 10:12 AM, Pavel Machek pa...@ucw.cz wrote: But... what would actually help: I believe we should introduce milivolt_t, miliamp_t, milisec_t etc... types. Storing milivolts in int, then having comment saying milivolts is just wrong. Hm! I bet the regulator subsystem maintainers have opinions on that. The regulator subsystem is quite happily using unsigned ints here, usually we're using hungarian style names to clarify the type where that's useful (it tends to be closer to the usual naming conventions when representing these things mathematically). I'm not sure that having a typedef is going to buy us terribly much unless we convert the kernel to C++ where we can do more exciting stuff. I would say that we are using microvolts rather than milivolts since it does occasionally matter. signature.asc Description: Digital signature
Re: [PATCH 7/8] ARM: dts: dra7: Add USB related nodes
On Fri, Mar 14, 2014 at 05:34:29PM +0200, Roger Quadros wrote:
On 03/14/2014 04:54 PM, Kishon Vijay Abraham I wrote:
On Friday 14 March 2014 05:41 PM, Roger Quadros wrote:
On 03/14/2014 12:38 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 07 March 2014 06:39 PM, Roger Quadros wrote:
Add nodes for the Super Speed USB controllers, omap-control-usb,
USB2 PHY and USB3 PHY devices.
Remove ocp2scp1 address space from hwmod data as it is
now provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 110
++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 ---
2 files changed, 110 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 597979b..1e73900 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -811,6 +811,116 @@
clocks = sata_ref_clk;
ti,hwmods = sata;
};
+
+omap_control_usb2phy1: control-phy@4a002300 {
+compatible = ti,control-phy-usb2;
+reg = 0x4a002300 0x4;
+reg-names = power;
+};
+
+omap_control_usb3phy1: control-phy@4a002370 {
+compatible = ti,control-phy-pipe3;
+reg = 0x4a002370 0x4;
+reg-names = power;
+};
+
+omap_control_usb2phy2: control-phy@0x4a002e74 {
+compatible = ti,control-phy-usb2-dra7;
+reg = 0x4a002e74 0x4;
+reg-names = power;
+};
+
+/* OCP2SCP1 */
+ocp2scp@4a08 {
+compatible = ti,omap-ocp2scp;
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+reg = 0x4a08 0x20;
+ti,hwmods = ocp2scp1;
+
+usb2_phy1: phy@4a084000 {
+compatible = ti,omap-usb2;
+reg = 0x4a084000 0x400;
+ctrl-module = omap_control_usb2phy1;
+clocks = usb_phy1_always_on_clk32k,
+ usb_otg_ss1_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb2_phy2: phy@4a085000 {
+compatible = ti,omap-usb2;
+reg = 0x4a085000 0x400;
+ctrl-module = omap_control_usb2phy2;
+clocks = usb_phy2_always_on_clk32k,
+ usb_otg_ss2_refclk960m;
+clock-names =wkupclk,
+refclk;
+#phy-cells = 0;
+};
+
+usb3_phy1: phy@4a084400 {
+compatible = ti,omap-usb3;
+reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+reg-names = phy_rx, phy_tx, pll_ctrl;
+ctrl-module = omap_control_usb3phy1;
+clocks = usb_phy3_always_on_clk32k,
+ sys_clkin1,
+ usb_otg_ss1_refclk960m,
+ dpll_core_h13x2_ck;
+clock-names =wkupclk,
+sysclk,
+refclk,
+optclk;
Do we use this 'optclk' in driver?
No we don't. Still the device seems to work without it.
This is supposed to be USB_LFPS_TX_GFCLK or USB3PHY_REF_CLK.
I think it should be enabled. Did you check the status of this clock
in CM_L3INIT_CLKSTCTRL? Moreover USB_LFPS_TX_GFCLK is an interface
clock, so IIUC setting the module mode will enable it.
Btw how did you tell dpll_core_h13x2_ck enables USB_LFPS_TX_GFCLK?
From the clock tree tool. It looks like the clock is gated
automatically with the module mode as you suggested. I'll get rid of
this clock reference then.
note that we can change the input clock of some parts of dwc3, maybe
that's why it works without, we're probably using another clock as
input.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, Mark, On Mon, Feb 24, 2014 at 8:14 PM, Suman Anna s-a...@ti.com wrote: Mark, Ohad, ... Gentle reminder, can you provide your acks/comments? Sorry for the late jump in. I have a few comments: - Hardware spinlocks must have global and system-wide id numbers; these numbers cannot be maintained internally by the Linux Kernel. Think of an SoC with several asynchronous heterogeneous processors, each of which is running a different OS, and they all need to use a specific hardware spinlock in order to share some resource. For that to happen, every hwlock must have a predefined and deterministic id number which is global in the system. We can't have those id numbers be relative to an hwlock controller, and we can't have two hwlock controllers share the same id numbers. - I suspect the simplest and most straight forward way to achieve this is by (a) bringing back the concept of the base_id property, and (b) letting the global hwlock id be the DT identifier (plus the base_id) and then providing it directly to the drivers when needed. The latter is required in order to support dynamically allocation of hwlocks, in which case Linux must know the global system-wide id number, and then share it with the other asynchronous OSes via some IPC. - If we feel there's no way any system is going to have more than a single hwlock controller, then we can live without a base_id property, but then this needs to be clearly documented and prohibited. Today both the hwlock DT representation, and the coupled kernel code, implicitly allow this anomaly to exist. - Hwlock controller nodes should have a list of reserved locks (those locks for which other nodes have a phandle+identifier pointing at) to prevent those locks from being dynamically allocated by eager drivers. Most of these issues were discussed Arnd, Benoit and myself back then, please see below: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064265.html Let's discuss, Thanks, Ohad. -- 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/9] opp-modifier: Add opp-modifier-reg driver
On Fri, Mar 14, 2014 at 2:25 PM, Dave Gerlach d-gerl...@ti.com wrote: Driver to read from a register and depending on either set bits or a specific known selectively enable or disable OPPs based on DT node. Can support opp-modifier-reg-bit where single bits within the register determine the availability of an OPP or opp-modifier-reg-val where a certain value inside the register or a portion of it determine what the maximum allowed OPP is. The driver expects a device that has already has its OPPs loaded and then will disable the OPPs not matching the criteria specified in the opp-modifier table. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- .../devicetree/bindings/power/opp-modifier.txt | 111 + drivers/power/opp/Makefile | 1 + drivers/power/opp/opp-modifier-reg.c | 259 + 3 files changed, 371 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt create mode 100644 drivers/power/opp/opp-modifier-reg.c diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt b/Documentation/devicetree/bindings/power/opp-modifier.txt new file mode 100644 index 000..af8a2e9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/opp-modifier.txt @@ -0,0 +1,111 @@ +* OPP-Modifier - opp modifier to selectively enable operating points + +Many SoCs that have selectively modifiable OPPs can specify +all available OPPs in their operating-points listing and then define +opp_modifiers to enable or disable the OPPs that are actually available +on the specific hardware. + +* OPP Modifier Provider Uggg. Please stop designing around the current OPP binding which has the problem that the OPP table is not extensible to add more data. Define a new OPP binding that solves these problems. This is at least the 3rd OPP related binding addition I've seen recently. But I wouldn't spend a lot of effort on a new OPP binding just to add the functionality you are adding here because I don't like the whole concept in general. This might be a common way to determine valid OPPs on TI chips, but I think it is too low level and I don't want to see bindings for every different possible way. Just add platform code to do the OPP setup you need. Frankly, I prefer the bootloader/firmware fixup the OPP table approach mentioned in the cpufreq-cpu0 thread. Somewhat less desirable, but the kernel could do the fixups as well (via of_update_property). Rob -- 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: OMAP2+: timer: Add clocksource initialization and powerup support
Joel Fernandes jo...@ti.com writes:
On 03/13/2014 04:52 PM, Rob Herring wrote:
On Thu, Mar 13, 2014 at 3:35 PM, Joel Fernandes jo...@ti.com wrote:
Introduce a generic omap timer initialization function that can
be used by all SoCs for which support is available in the clocksource
driver introduced in the series.
The function will also be responsible for calling clock initialization
required for everything else to work.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/timer.c | 28
2 files changed, 29 insertions(+)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index a6aae30..e58d9a4 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -92,6 +92,7 @@ extern void omap3_secure_sync32k_timer_init(void);
extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
extern void omap5_realtime_timer_init(void);
+void omap_generic_timer_init(void);
void omap2420_init_early(void);
void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 74044aa..08c73a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -324,6 +324,25 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
return r;
}
+int __init omap_dmtimer_powerup(struct omap_dm_timer *timer,
+ struct device_node *np) {
This function seems unrelated to the commit message.
Ok, I'll add it in the message.
+ struct omap_hwmod *oh;
+ const char *oh_name = NULL;
+
+ of_property_read_string_index(np, ti,hwmods, 0, oh_name);
+ if (!oh_name)
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
+
+ omap_hwmod_setup_one(oh_name);
+
+ omap_hwmod_enable(oh);
+ return 0;
+}
+
static void __init omap2_gp_clockevent_init(int gptimer_id,
const char *fck_source,
const char *property)
@@ -615,6 +634,15 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck,
ti,timer-alwon,
2, sys_clkin_ck, NULL);
#endif
+void omap_generic_timer_init(void)
+{
+ if (!of_have_populated_dt())
+ BUG_ON(Generic timer init should only be used for DT
boot\n);
I thought omap2 is always DT boot now.
That's right, sorry- I'll get rid of the check.
Actually, mainline still supports legacy boot and has board files for
OMAP3 platforms, and we shouldn't break legacy boot on purpose IMO.
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: [RFC 3/5] ARM: OMAP2+: timer: Add clocksource initialization and powerup support
On Fri, Mar 14, 2014 at 4:09 PM, Kevin Hilman khil...@linaro.org wrote:
Joel Fernandes jo...@ti.com writes:
On 03/13/2014 04:52 PM, Rob Herring wrote:
On Thu, Mar 13, 2014 at 3:35 PM, Joel Fernandes jo...@ti.com wrote:
Introduce a generic omap timer initialization function that can
be used by all SoCs for which support is available in the clocksource
driver introduced in the series.
The function will also be responsible for calling clock initialization
required for everything else to work.
Signed-off-by: Joel Fernandes jo...@ti.com
[snip]
+void omap_generic_timer_init(void)
+{
+ if (!of_have_populated_dt())
+ BUG_ON(Generic timer init should only be used for DT
boot\n);
I thought omap2 is always DT boot now.
That's right, sorry- I'll get rid of the check.
Actually, mainline still supports legacy boot and has board files for
OMAP3 platforms, and we shouldn't break legacy boot on purpose IMO.
It is not breaking anything. You'd have to call this function
mistakenly from a legacy machine desc or other non-DT boot path. It's
a question of how paranoid you are adding checks. IMHO, the BUG_ON is
quite pointless here. You are not likely to progress much further
anyway, and you won't see the BUG print because the serial port is not
up yet.
Rob
--
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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/14/2014 03:10 PM, Ohad Ben-Cohen wrote: Hi Suman, Mark, On Mon, Feb 24, 2014 at 8:14 PM, Suman Anna s-a...@ti.com wrote: Mark, Ohad, ... Gentle reminder, can you provide your acks/comments? Sorry for the late jump in. I have a few comments: Thanks for the comments. It probably covers few topics that are slightly beyond the scope of the series, but nevertheless are good discussion points for finalizing the series. - Hardware spinlocks must have global and system-wide id numbers; these numbers cannot be maintained internally by the Linux Kernel. Think of an SoC with several asynchronous heterogeneous processors, each of which is running a different OS, and they all need to use a specific hardware spinlock in order to share some resource. For that to happen, every hwlock must have a predefined and deterministic id number which is global in the system. We can't have those id numbers be relative to an hwlock controller, and we can't have two hwlock controllers share the same id numbers. The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. - I suspect the simplest and most straight forward way to achieve this is by (a) bringing back the concept of the base_id property, and I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. (b) letting the global hwlock id be the DT identifier (plus the base_id) and then providing it directly to the drivers when needed.The latter is required in order to support dynamically allocation of hwlocks, in which case Linux must know the global system-wide id number, and then share it with the other asynchronous OSes via some IPC. Each lock still retains a global lock id value, and you can retrieve it using the existing hwspin_lock_get_id(). Why is the latter required for dynamic allocation, isn't it the other way around, allocate a lock, and you will be able to get the lock id. If wanting to request a specific lock received across, the regular hwspin_lock_request_specific should be used. - If we feel there's no way any system is going to have more than a single hwlock controller, then we can live without a base_id property, but then this needs to be clearly documented and prohibited. Today both the hwlock DT representation, and the coupled kernel code, implicitly allow this anomaly to exist. I haven't removed the concept of base_id, it is just not defined in the DT-bindings, and am currently expecting the drivers to manage it and use it for registration. - Hwlock controller nodes should have a list of reserved locks (those locks for which other nodes have a phandle+identifier pointing at) to prevent those locks from being dynamically allocated by eager drivers. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. There were some slightly similar comments from Kumar earlier on the v2 series, please see the thread in [1]. Most of these issues were discussed Arnd, Benoit and myself back then, please see below: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064265.html Thanks for the pointer to the previous discussion, I wasn't aware of an earlier attempt. The primary approach on requesting locks is actually no different from what Arnd suggested originally. regards Suman [1] http://marc.info/?l=linux-omapm=138031002012191w=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: [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs
Hi Joel,
On 03/13/2014 03:35 PM, Joel Fernandes wrote:
We introduce functions to initialize clocksource and clockevent, use
CLOCKSOURCE_OF_DECLARE to declare the clocksource, and handle the clocksource
selection on a per-SoC basis (Currently only AM335x is supported). Powering up
of the timer will be done with the help of the mach-omap layer function that's
introduced earlier in the series.
We make a local copy of dmtimer API for use by clocksource, the original
dmtimer API in plat-omap is kept as-is till the migration of all SoCs is
completed after which it can't be deleted.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/clocksource/Makefile |1 +
drivers/clocksource/omap-timer.c | 1157 ++
drivers/clocksource/omap-timer.h | 422 ++
3 files changed, 1580 insertions(+)
create mode 100644 drivers/clocksource/omap-timer.c
create mode 100644 drivers/clocksource/omap-timer.h
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index c7ca50a..2ffe698 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER)+= arm_global_timer.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC)+= metag_generic.o
obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
+obj-y += omap-timer.o
diff --git a/drivers/clocksource/omap-timer.c b/drivers/clocksource/omap-timer.c
new file mode 100644
index 000..91593d8
--- /dev/null
+++ b/drivers/clocksource/omap-timer.c
@@ -0,0 +1,1157 @@
+/*
+ * drivers/clocksource/omap-timer.c
+ *
+ * OMAP Dual-Mode Timers
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Joel Fernandes jo...@ti.com
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * dmtimer adaptation to platform_driver.
+ *
+ * Copyright (C) 2005 Nokia Corporation
+ * OMAP2 support by Juha Yrjola
+ * API improvements and OMAP2 clock framework support by Timo Teras
+ *
+ * Copyright (C) 2014 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/init.h
+#include linux/time.h
+#include linux/interrupt.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/irq.h
+#include linux/clocksource.h
+#include linux/clockchips.h
+#include linux/slab.h
+#include linux/sched_clock.h
+
+#include linux/clk.h
+#include linux/module.h
+#include linux/io.h
+#include linux/device.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
+
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/platform_data/dmtimer-omap.h
+#include omap-timer.h
+/*
+ * TODO: OMAP1 support removed due to need for header mach/hardware.h
+ *OMAP2 support may be broken due to lack of cpu_is stuff, see
omap_dm_timer_get_errata
+ */
+
+/**
+ * omap_dm_timer_get_errata - get errata flags for a timer
+ *
+ * Get the timer errata flags that are specific to the OMAP device being used.
+ */
+static u32 __init omap_dm_timer_get_errata(void)
+{
+ /* ifdef'd out due to lack of availaibility of soc.h */
+#if 0
+ if (cpu_is_omap24xx())
+ return 0;
You should be able to fix this using some compatible checks.
regards
Suman
+#endif
+ return OMAP_TIMER_ERRATA_I103_I767;
+}
+
+
-snip-
--
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] iommu/omap: Fix map protection value handling
Hi Laurent,
On 03/14/2014 04:46 AM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the review.
On Thursday 13 March 2014 19:07:33 Suman Anna wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The prot flags passed to the IOMMU map handler are defined in
include/linux/iommu.h as IOMMU_(READ|WRITE|CACHE|EXEC). However, the
driver expects to receive MMU_RAM_* OMAP-specific flags. This causes
IOMMU flags being interpreted as page sizes, leading to failures.
Hardcode the OMAP mapping parameters to little-endian, 8-bits and
non-mixed page attributes. Furthermore, as the OMAP IOMMU doesn't
support read-only or write-only mappings, ignore the prot value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 59de3fc..9f7f1d4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1016,8 +1016,7 @@ static void iopte_cachep_ctor(void *iopte)
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
}
-static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa,
- u32 flags)
+static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa, int
pgsz)
{
memset(e, 0, sizeof(*e));
@@ -1025,10 +1024,10 @@ static u32 iotlb_init_entry(struct iotlb_entry *e,
u32 da, u32 pa,
e-pa= pa;
e-valid = 1;
As I was looking through this, I found a small bug here. This is unrelated
to this patch, but you can fix it in the same patch. The e-valid value is
directly used in omap2_alloc_cr, so it should be initialized to MMU_CAM_V.
It is not a problem currently as PREFETCH_IOTLB is not used, if used, this
is overriding the size bit-fields when it prefetches the entry, which may
lead to an MMU fault.
Good catch. As it's a separate issue, do you mind if I fix that in a separate
patch in v2 ?
I actually have couple of minor cleanup patches as well. I will send
them out and you can include them with your series when you post v2.
/* FIXME: add OMAP1 support */
- e-pgsz = flags MMU_CAM_PGSZ_MASK;
- e-endian= flags MMU_RAM_ENDIAN_MASK;
- e-elsz = flags MMU_RAM_ELSZ_MASK;
- e-mixed = flags MMU_RAM_MIXED_MASK;
+ e-pgsz = pgsz;
+ e-endian= MMU_RAM_ENDIAN_LITTLE;
+ e-elsz = MMU_RAM_ELSZ_8;
+ e-mixed = 0;
Thanks, the change of these settings looks good overall. The only ones for
which it may apply anyway is just the Camera in OMAP2/OMAP3 (as per TRM,
endianness conversion supported only on writes anyway, so I am assuming that
we never use the combination), and OMAP2420 DSP, for which there is no
driver currently nor is the MMU being instantiated. All other processors are
pure little endian, and they even ignore the values written in these fields.
Please recheck the Camera subsystem once, and see if the e-elsz should be
set as MMU_RAM_ELSZ_NONE (I am not too familiar with the Camera usage, so
you are probably in a better place than me).
I've tested MMU_RAM_ELSZ_NONE and it works fine. I'll update the patch in v2.
Thanks for checking and confirming this.
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] iommu/omap: Flush the TLB only after updating translation table entries
Hi Laurent,
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
Flushing the TLB before updating translation entries creates a race
condition and can lead to stale TLB entries if a translation request
arrives between flushing the TLB and updating the translation entries.
As there's no requirement to flush the TLB before updating the entries,
flush it after only.
I do not expect a device to be actively using a region if we are about
to change its mapping, we expect the access from the device to be only
between a map and an unmap. The race condition (if any in such
scenarios) would exist even after this patch, like after you programmed
the entry, and the translation request comes before you flush the page.
Then it is still operating on an older address, while you have already
programmed a new one. An unmap currently clears the entry and flushes
any TLB as well, so I don't think this patch makes a big difference.
I agree that the patch won't make a difference in practice. Should I drop it
from v2 ?
Yes, that should be safe.
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index cb1e1de..fedd303 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -662,10 +662,11 @@ int omap_iopgtable_store_entry(struct omap_iommu
*obj, struct iotlb_entry *e)
{
int err;
- flush_iotlb_page(obj, e-da);
err = iopgtable_store_entry_core(obj, e);
- if (!err)
+ if (!err) {
+ flush_iotlb_page(obj, e-da);
prefetch_iotlb_entry(obj, e);
+ }
return err;
}
EXPORT_SYMBOL_GPL(omap_iopgtable_store_entry);
--
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 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs
On 03/14/2014 07:13 PM, Suman Anna wrote:
Hi Joel,
On 03/13/2014 03:35 PM, Joel Fernandes wrote:
We introduce functions to initialize clocksource and clockevent, use
CLOCKSOURCE_OF_DECLARE to declare the clocksource, and handle the
clocksource
selection on a per-SoC basis (Currently only AM335x is supported).
Powering up
of the timer will be done with the help of the mach-omap layer function
that's
introduced earlier in the series.
We make a local copy of dmtimer API for use by clocksource, the original
dmtimer API in plat-omap is kept as-is till the migration of all SoCs is
completed after which it can't be deleted.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/clocksource/Makefile |1 +
drivers/clocksource/omap-timer.c | 1157
++
drivers/clocksource/omap-timer.h | 422 ++
3 files changed, 1580 insertions(+)
create mode 100644 drivers/clocksource/omap-timer.c
create mode 100644 drivers/clocksource/omap-timer.h
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index c7ca50a..2ffe698 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_ARM_ARCH_TIMER)+= arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER)+= arm_global_timer.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC)+= metag_generic.o
obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST)+= dummy_timer.o
+obj-y+= omap-timer.o
diff --git a/drivers/clocksource/omap-timer.c
b/drivers/clocksource/omap-timer.c
new file mode 100644
index 000..91593d8
--- /dev/null
+++ b/drivers/clocksource/omap-timer.c
@@ -0,0 +1,1157 @@
+/*
+ * drivers/clocksource/omap-timer.c
+ *
+ * OMAP Dual-Mode Timers
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Joel Fernandes jo...@ti.com
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * dmtimer adaptation to platform_driver.
+ *
+ * Copyright (C) 2005 Nokia Corporation
+ * OMAP2 support by Juha Yrjola
+ * API improvements and OMAP2 clock framework support by Timo Teras
+ *
+ * Copyright (C) 2014 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/init.h
+#include linux/time.h
+#include linux/interrupt.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/irq.h
+#include linux/clocksource.h
+#include linux/clockchips.h
+#include linux/slab.h
+#include linux/sched_clock.h
+
+#include linux/clk.h
+#include linux/module.h
+#include linux/io.h
+#include linux/device.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
+
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/platform_data/dmtimer-omap.h
+#include omap-timer.h
+/*
+ * TODO: OMAP1 support removed due to need for header mach/hardware.h
+ *OMAP2 support may be broken due to lack of cpu_is stuff, see
omap_dm_timer_get_errata
+ */
+
+/**
+ * omap_dm_timer_get_errata - get errata flags for a timer
+ *
+ * Get the timer errata flags that are specific to the OMAP device being
used.
+ */
+static u32 __init omap_dm_timer_get_errata(void)
+{
+/* ifdef'd out due to lack of availaibility of soc.h */
+#if 0
+if (cpu_is_omap24xx())
+return 0;
You should be able to fix this using some compatible checks.
Thanks. I'll use of_device_is_compatible to check for that.
-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API
Hi Santosh, Laurent, Russell, Arnd,
On 03/14/2014 12:51 PM, Santosh Shilimkar wrote:
On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
Hi Santosh,
On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
+ Russell, Arnd
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management manually
(and ignoring L2 cache), use clean_dcache_area() to make sure the
entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been some
previous attempts at this as well by Ramesh Gupta, with the last thread
(a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++-
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
* H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcr p15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcr p15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
So this particular change has a long history (have to dig through to
educate myself). I have not seen clean_dcache_area attempted before, and
I wasn't sure myself it it can be used here. Ramesh and Fernando
definitely did start out with dmac_flush_range and outer_flush_range
which was definitely nacked [1].
Please note that the omap-iommu driver already uses clean_dcache_area().
That's where I got the idea :-)
So that fall through the cracks then ;-)
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
I can replace clean_dcache_area() with dma_map_page() as done by the arm-smmu
driver. If that's fine I'll modify this patch accordingly in v2.
Ramesh had also attempted to use dma_page_single() previously [2], and
Russell has instead suggested to extend the cpu cache operations [3].
Ramesh had worked based on this suggestion and the series reached v6 [4]
(same as link I mentioned above) and this is the last attempt on this,
but the thread went silent.
I am wondering if that is still valid and is the right way to go, as
this seems to be a common problem. I do see dmac_flush_range being used
for similar purposes in msm_iommu.c and exynos-iommu.c, so looks like
they also fell through the cracks.
Laurent,
Can you drop this patch out from v2 so that it is not clubbed with the
small cleanup patches, and we can track this separately?
regards
Suman
[1] http://marc.info/?l=linux-omapm=129907009019355w=2
[2] http://marc.info/?t=13028180495r=1w=2
[3] http://marc.info/?l=linux-omapm=131310179423214w=2
[4] http://marc.info/?t=13475203541r=1w=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 3/3] ARM: OMAP2+: Add machine entry for dra72x devices
Hi Rajendra,
On 03/14/2014 04:20 AM, Nayak, Rajendra wrote:
The only difference from the dra75x devices is the missing .smp entry.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 8e3daa1..d803d99 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -253,4 +253,22 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device
Tree))
.dt_compat = dra7xx_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
+
+static const char *dra72_boards_compat[] __initdata = {
How about using dra72x_ instead of dra72_ and keeping it consistent
at the other places as well?
regards
Suman
+ ti,dra72x,
+ ti,dra7,
+ NULL,
+};
+
+DT_MACHINE_START(DRA72_DT, Generic DRA72 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_late = dra7xx_init_late,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra72_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
#endif
--
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
