Re: [PATCH 6/7] ARM: OMAP2+: Fix reboot for 81xx
On Wed, Jan 14, 2015 at 11:04:19AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [150113 17:28]:
On Tue, Jan 13, 2015 at 03:13:56PM -0800, Tony Lindgren wrote:
+
+#define TI81XX_PRM_DEVICE_RSTCTRL0x00a0
+#define TI81XX_GLOBAL_RST_COLD BIT(1)
+
+/**
+ * ti81xx_restart - trigger a software restart of the SoC
+ * @mode: the reboot mode, see arch/arm/kernel/{setup,process}.c
+ * @cmd: passed from the userspace program rebooting the system (if
provided)
+ *
+ * Resets the SoC. For @cmd, see the 'reboot' syscall in
+ * kernel/sys.c. No return value.
+ */
+void ti81xx_restart(enum reboot_mode mode, const char *cmd)
+{
+ omap2_prm_set_mod_reg_bits(TI81XX_GLOBAL_RST_COLD, 0,
+TI81XX_PRM_DEVICE_RSTCTRL);
do you need to check that mode == REBOOT_COLD here ?
Looks like not, trying to use the warm reset bit does not seem to do
anything and probably requires manually resetting clocks into bypass
mode or something.
I'll just add a comment about that.
alright, in that case:
Reviewed-by: Felipe Balbi ba...@ti.com
:-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/6] net: davinci_emac: Free clock after checking the frequency
* David Miller da...@davemloft.net [150113 13:08]: From: Tony Lindgren t...@atomide.com Date: Tue, 13 Jan 2015 11:54:16 -0800 * Tom Lendacky thomas.lenda...@amd.com [150113 11:51]: On 01/13/2015 01:29 PM, Tony Lindgren wrote: We only use clk_get() to get the frequency, the rest is done by the runtime PM calls. Let's free the clock too. Cc: Brian Hutchinson b.hutch...@gmail.com Cc: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/net/ethernet/ti/davinci_emac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index deb43b3..e9efc74 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1881,6 +1881,7 @@ static int davinci_emac_probe(struct platform_device *pdev) return -EBUSY; } emac_bus_frequency = clk_get_rate(emac_clk); + clk_put(emac_clk); The devm_clk_get call is used to get the clock so either a devm_clk_put needs to be used here or just let the devm_ call do its thing and automatically do the put when the module is unloaded. Thanks good catch, updated patch below. Please, once all the feedback has been addressed, repost the entire series. Sure, will repost on Thursday in case there will be more comments. 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
[PATCH] ARM: dts: OMAP: Add hwlock-base-id property to hwspinlock nodes
Add the generic property hwlock-base-id to the hwspinlock DT nodes on all applicable OMAP SoCS (OMAP4, OMAP5, DRA7, AM33xx and AM43xx). This common property is required by the hwspinlock core to be able to translate client locks properly. All the current OMAP SoCs only have a single instance of the IP, and so will use a common value of 0. Cc: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Suman Anna s-a...@ti.com --- This is required for the OMAP Hwspinlock driver with the latest DT series, http://marc.info/?l=linux-omapm=142126914027417w=2 arch/arm/boot/dts/am33xx.dtsi | 1 + arch/arm/boot/dts/am4372.dtsi | 1 + arch/arm/boot/dts/dra7.dtsi | 1 + arch/arm/boot/dts/omap4.dtsi | 1 + arch/arm/boot/dts/omap5.dtsi | 1 + 5 files changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index acd37057bca9..9ee1f44f0f4b 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -334,6 +334,7 @@ compatible = ti,omap4-hwspinlock; reg = 0x480ca000 0x1000; ti,hwmods = spinlock; + hwlock-base-id = 0; #hwlock-cells = 1; }; diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index b62a1cd776cd..98eebedb1430 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -371,6 +371,7 @@ compatible = ti,omap4-hwspinlock; reg = 0x480ca000 0x1000; ti,hwmods = spinlock; + hwlock-base-id = 0; #hwlock-cells = 1; }; diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 22771bc1643a..cf7ebdc95b4a 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -752,6 +752,7 @@ compatible = ti,omap4-hwspinlock; reg = 0x4a0f6000 0x1000; ti,hwmods = spinlock; + hwlock-base-id = 0; #hwlock-cells = 1; }; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 074147cebae4..77197e5454e8 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -344,6 +344,7 @@ compatible = ti,omap4-hwspinlock; reg = 0x4a0f6000 0x1000; ti,hwmods = spinlock; + hwlock-base-id = 0; #hwlock-cells = 1; }; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index b321fdf42c9f..c2fc81724308 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -393,6 +393,7 @@ compatible = ti,omap4-hwspinlock; reg = 0x4a0f6000 0x1000; ti,hwmods = spinlock; + hwlock-base-id = 0; #hwlock-cells = 1; }; -- 2.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support
* Tony Lindgren t...@atomide.com [150113 15:29]: Add minimal hwmod support that works at least on dm8168. This is based on the code in the earlier TI CDP tree, and an earlier patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru. I've set up things to work pretty much the same way as for am33xx. We are basically using cm33xx.c with a different set of clocks and clockdomains. This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches published at: http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru Cc: Brian Hutchinson b.hutch...@gmail.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/io.c |8 +- arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/omap_hwmod.h |1 + arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 1025 5 files changed, 1034 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_81xx_data.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 352873c..926bc39 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -226,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_43xx_ipblock_data.o obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_interconnect_data.o obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o +obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o obj-$(CONFIG_SOC_OMAP5) += omap_hwmod_54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o Looks like the Makefile needs the following addition for make randconfig builds to work properly. Regards, Tony --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common) am33xx-43xx-prcm-common+= prm33xx.o cm33xx.o +obj-$(CONFIG_SOC_TI81XX) += $(am33xx-43xx-prcm-common) obj-$(CONFIG_SOC_AM33XX) += $(am33xx-43xx-prcm-common) obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) \ $(am33xx-43xx-prcm-common) -- 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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. This base id
needs to be unique across multiple IP instances of a hwspinlock
device, so that each hwlock can be represented uniquely in a
system.
The number of locks is represented by 'hwlock-num-locks' property,
and the base id is represented by the 'hwlock-base-id' property.
The args specifier length is dependent on each vendor-specific
implementation and is represented through the '#hwlock-cells'
property. Client users need to use the property 'hwlocks' for
requesting specific lock(s).
Note that the document is named hwlock.txt deliberately to keep
it a bit more generic.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
v7: Revised binding info for hwlock-base-id, it is mandatory now
.../devicetree/bindings/hwlock/hwlock.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index ..8de7aaf878f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,55 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if an optional property is used. Please also look through the individual
+platform specific hwlock binding documentations for identifying the applicable
+properties.
+
+Common properties:
+- #hwlock-cells: Specifies the number of cells needed to represent a
+ specific lock. This property is mandatory for all
+ platform implementations.
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the number
+ of supported locks within a hwlock device cannot be
+ read from a register.
+- hwlock-base-id: An unique base Id for the locks for a particular hwlock
+ device. This property is mandatory for all platform
+ implementations.
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using the property
+hwlocks, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+ node {
+ ...
+ hwlocks = hwlock1 2;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+ node {
+ ...
+ hwlocks = hwlock1 2, hwlock2 0 3;
+ ...
+ };
--
2.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
* Russell King - ARM Linux li...@arm.linux.org.uk [150114 09:54]: On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: The combined kernel boot follows a similar pattern, but yets a bit further before oopsing, with ASoC DAPM code printing random bits of kernel memory. Note that the combined kernel (which is OMAP4 + Versatile Express) has for a while now also spat out this: WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 Hardware name: Generic OMAP4 (Flattened Device Tree) Backtrace: [c0011bdc] (dump_backtrace) from [c0011e9c] (show_stack+0x18/0x1c) r6:c04c073e r5:0009 r4: r3:00200040 [c0011e84] (show_stack) from [c0466380] (dump_stack+0x78/0x94) [c0466308] (dump_stack) from [c00379ec] (warn_slowpath_common+0x8c/0xb8) r4:ce461b38 r3:ce458000 [c0037960] (warn_slowpath_common) from [c0037abc] (warn_slowpath_fmt+0x38/0x40) r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 [c0037a88] (warn_slowpath_fmt) from [c02098f8] (l3_interrupt_handler+0x218/0x2f0) r3:ce54ad40 r2:c04c0772 [c02096e0] (l3_interrupt_handler) from [c0076444] (handle_irq_event_percpu+0x38/0x13c) r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 r4:ce54f480 [c007640c] (handle_irq_event_percpu) from [c007658c] (handle_irq_event+0x44/0x64) r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 r4:ce440700 [c0076548] (handle_irq_event) from [c00795f4] (handle_fasteoi_irq+0xb0/0x128) r6:ce440760 r5:c06c5fec r4:ce440700 r3: [c0079544] (handle_fasteoi_irq) from [c0075d60] (generic_handle_irq+0x28/0x38) r6:ce408000 r5: r4:0013 r3:c0079544 [c0075d38] (generic_handle_irq) from [c0075ebc] (__handle_domain_irq+0x90/0xb8) r4: r3:0110 [c0075e2c] (__handle_domain_irq) from [c0008858] (gic_handle_irq+0x44/0x68) r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 [c0008814] (gic_handle_irq) from [c00129c4] (__irq_svc+0x44/0x5c) Exception stack(0xce461cd8 to 0xce461d20) 1cc0: 0001 ce458508 1ce0: 6113 ce5b1960 002c ce5b1960 ce5b1938 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 r6: r5:2113 r4:c046df64 r3:ce458000 [c046df1c] (_raw_spin_unlock_irqrestore) from [c0077dd0] (__setup_irq+0x3bc/0x4e4) r5:c06b7c00 r4:ce5b1900 [c0077a14] (__setup_irq) from [c00780ec] (setup_irq+0x50/0x90) r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c r4:ce5b1900 [c007809c] (setup_irq) from [c0032768] (omap_system_dma_probe+0x20c/0x2a4) r6:ce67ec10 r5:002c r4:0020 r3:0002 [c003255c] (omap_system_dma_probe) from [c0298788] (platform_drv_probe+0x50/0x98) r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed r4:ce67ec10 [c0298738] (platform_drv_probe) from [c0296fa8] (driver_probe_device+0x13c/0x34c) r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 [c0296e6c] (driver_probe_device) from [c0297230] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10 [c02971b8] (__driver_attach) from [c0295424] (bus_for_each_dev+0x5c/0x98) r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 [c02953c8] (bus_for_each_dev) from [c02969c0] (driver_attach+0x20/0x28) r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 [c02969a0] (driver_attach) from [c02965ec] (bus_add_driver+0xf8/0x1fc) [c02964f4] (bus_add_driver) from [c0297914] (driver_register+0xa4/0xe8) r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 [c0297870] (driver_register) from [c029861c] (__platform_driver_register+0x50/0x64) r5:c068d0e8 r4:ce621f80 [c02985cc] (__platform_driver_register) from [c0646240] (omap_system_dma_init+0x18/0x20) [c0646228] (omap_system_dma_init) from [c0008c44] (do_one_initcall+0x114/0x1e0) [c0008b30] (do_one_initcall) from [c0632e3c] (kernel_init_freeable+0x110/0x1dc) r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 r4:0003 [c0632d2c] (kernel_init_freeable) from [c0460840] (kernel_init+0x10/0xec) r10: r8: r7: r6: r5:c0460830 r4: [c0460830] (kernel_init) from [c000f0d0] (ret_from_fork+0x14/0x24) r4: r3: ---[ end trace bcb85e0273c31888 ]--- OMAP DMA hardware revision 0.0 This does not occur when booting the plain omap4 kernel. I thought it may be related to another error which people have been reporting, but as it's still there, I thought I should report it. To me, this suggests that Versatile Express code may be initialising on non-Versatile Express hardware, possibly touching hardware, but it looks like it's
[PATCH v7 2/4] Documentation: dt: add the omap hwspinlock bindings document
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
v7: Added information about hwlock-base-id and updated example to use it
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index ..935173ec6b58
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,28 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible: Should be ti,omap4-hwspinlock for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+ (base address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+- hwlock-base-id: Should be 0 for the first IP block instance, or a proper
+ positive value for any subsequent instance (if present)
+ of the IP block.
+- #hwlock-cells: Should be 1. The OMAP hwspinlock users will use a
+ 0-indexed relative hwlock number as the argument
+ specifier value for requesting a specific hwspinlock
+ within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+ hwlock-base-id = 0;
+ #hwlock-cells = 1;
+};
--
2.2.1
--
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 v7 3/4] hwspinlock/core: add common OF helpers
This patch adds two new OF helper functions for platform
implementations and one new API to use/request locks from a
hwspinlock device instantiated through a device-tree blob.
1. The of_hwspin_lock_get_num_locks() is a common OF helper
function to read the 'hwlock-num-locks' property.
2. The of_hwspin_lock_get_base_id() is a common OF helper
function to read the 'hwlock-base-id' property.
3. The of_hwspin_lock_get_id() API can be used by hwspinlock
clients to get the id for a specific lock using the phandle
+ args specifier, so that it can be requested using the
available hwspin_lock_request_specific() API.
Signed-off-by: Suman Anna s-a...@ti.com
---
v7:
- Moved of_hwspin_lock_get_base_id() and of_hwspin_lock_get_num_locks
into hwspinlock_internal.h
- Simplified of_hwspin_lock_get_id(), removed deferred probing and
args specifier validation
- updated comments and documentation
Documentation/hwspinlock.txt | 25
drivers/hwspinlock/hwspinlock_core.c | 65
drivers/hwspinlock/hwspinlock_internal.h | 47 +++
include/linux/hwspinlock.h | 7
4 files changed, 144 insertions(+)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4ea6e26..a29bb47e4637 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,16 @@ independent, drivers.
ids for predefined purposes.
Should be called from a process context (might sleep).
+ int of_hwspin_lock_get_id(struct device_node *np, int index);
+ - retrieve the global lock id for an OF phandle-based specific lock.
+ This function provides a means for DT users of a hwspinlock module
+ to get the global lock id of a specific hwspinlock, so that it can
+ be requested using the normal hwspin_lock_request_specific() API.
+ The function returns a lock id number on success, or other error
+ values. The function does not perform any validation of the args
+ specifier lock values, this burden is placed on the user.
+ Should be called from a process context (might sleep).
+
int hwspin_lock_free(struct hwspinlock *hwlock);
- free a previously-assigned hwspinlock; returns 0 on success, or an
appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +253,21 @@ int hwspinlock_example2(void)
Returns the address of hwspinlock on success, or NULL on error (e.g.
if the hwspinlock is still in use).
+ int of_hwspin_lock_get_num_locks(struct device_node *dn);
+ - is a common OF helper function that can be used by some underlying
+ vendor-specific implementations. This can be used by implementations
+ that require and define the number of locks supported within a hwspinlock
+ bank as a device tree node property. This function should be called by
+ needed implementations before registering a hwspinlock device with the
+ hwspinlock core.
+
+ int of_hwspin_lock_get_base_id(struct device_node *dn);
+ - is a common OF helper function that can be used by the underlying
+ vendor-specific implementations. This function should be called by
+ implementations to retrieve the base index for a block of locks present
+ within a hwspinlock device for registering that device with the
+ hwspinlock core.
+
5. Important structs
struct hwspinlock_device is a device which usually contains a bank
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d739d75..8f107bc34281 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
#include linux/hwspinlock.h
#include linux/pm_runtime.h
#include linux/mutex.h
+#include linux/of.h
#include hwspinlock_internal.h
@@ -257,6 +258,70 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
}
EXPORT_SYMBOL_GPL(__hwspin_unlock);
+/**
+ * of_hwspin_lock_simple_xlate - translate hwlock_spec to return a lock id
+ * @bank: the hwspinlock device bank
+ * @hwlock_spec: hwlock specifier as found in the device tree
+ *
+ * This is a simple translation function, suitable for hwspinlock platform
+ * drivers that only has a lock specifier length of 1.
+ *
+ * Returns a relative index of the lock within a specified bank on success,
+ * or -EINVAL on invalid specifier cell count.
+ */
+static inline int
+of_hwspin_lock_simple_xlate(const struct of_phandle_args *hwlock_spec)
+{
+ if (WARN_ON(hwlock_spec-args_count != 1))
+ return -EINVAL;
+
+ return hwlock_spec-args[0];
+}
+
+/**
+ * of_hwspin_lock_get_id() - get lock id for an OF phandle-based specific lock
+ * @np: device node from which to request the specific hwlock
+ * @index: index of the hwlock in the list of values
+ *
+ * This function provides a means for DT users of the hwspinlock module to
+ * get the global lock id of a specific hwspinlock using the
[PATCH v7 0/4] hwspinlock core omap dt support
Hi Ohad, This is an updated version of the hwspinlock dt support series, rebased onto v3.19-rc3 and mainly addresses the continued discussion on the need to maintain a list of registered spinlock banks [1]. I have removed this patch as per your wish, and as a result the burden of the spinlock validation and deferred probing is pushed onto the hwspinlock clients. Sorry for the delay in refreshing this series, hopefully this can be the last revision. Following are the main changes in v7 w.r.t v6: - Dropped the patch hwspinlock/core: maintain a list of registered hwspinlock banks - Updated generic hwspinlock bindings to make hwlock-base-id property mandatory. - Updated the OMAP hwspinlock binding and DT support patches to correct for the mandatory hwlock-base-id property. - Updated the common OF helpers patch to move the of_hwspin_lock_get_base_id() and of_hwspin_lock_get_num_locks() functions into the internal header, these are no longer exported, but available for platform implementations. of_hwspin_lock_get_id() is also simplified now. The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://slexy.org/view/s21Mh1SqP8 OMAP5 - http://slexy.org/view/s21TYWxoKu DRA74x - http://slexy.org/view/s2dQdghLPr DRA72x - http://slexy.org/view/s2QajhhWYu AM33xx - http://slexy.org/view/s21DvKQOpa AM43xx - http://slexy.org/view/s21L3YB95Q The above logs are generated with some additional test patches staged here for reference, https://github.com/sumananna/omap-kernel/commits/hwspinlock/test/3.19-rc3-dt-v7 The test branch also includes a required patch that adds the hwlock-base-id to all the OMAP hwspinlock DT nodes (will submit that patch separately for Tony to pick it up). Bjorn, I didn't add your Tested-by: or Reviewed-by as I have modified the series a bit. Care to give those once again, thanks. regards Suman [1] https://patchwork.kernel.org/patch/4898041/ --- v6: http://marc.info/?l=linux-omapm=141055365213895w=2 - of_hwspin_lock_request_specific() is replaced with of_hwspin_lock_get_id(). of_hwspin_lock_simple_xlate() is made internal, and of_hwspin_lock_get_base_id() is added. - Updated the OMAP hwspinlock DT support patch to assign base-id from DT if present - RFC patches adding the concept of reserved locks and return code change convention dropped. v5: http://marc.info/?l=linux-omapm=139890478402807w=2 - Rebased v4 patches plus additional RFC patches. - Added back the patch to support DT-based hwlock-base-id property, for registration purposes. - RFC patches introducing the concept of reserved locks. - Staged patches for converting return convention to better support deferred probing of client drivers. v4: - The DT bindings are split into separate patches, and updated to add comments about #hwlock-cells - Fixed a registration issue with repeated module installation and removal. - Added a new OF helper to support #hwlock-cells in addition to the previous OF functions. The OMAP adaptation patch is updated to use the default translate function - Updated hwspinlock documentation to adjust for the structure changes and the new api additions. - Added build support for AM335x, AM43xx and DRA7xx http://marc.info/?l=linux-omapm=138965904015225w=2 v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document http://marc.info/?l=linux-omapm=138143992932197w=2 v2: - Added a new common DT binding documentation and OF helpers. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335. - OMAP4 DT node patch is unchanged http://marc.info/?l=linux-omapm=137944644112727w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 --- Suman Anna (4): Documentation: dt: add common bindings for hwspinlock Documentation: dt: add the omap hwspinlock bindings document hwspinlock/core: add common OF helpers hwspinlock/omap: add support for dt nodes .../devicetree/bindings/hwlock/hwlock.txt | 55 ++ .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++ Documentation/hwspinlock.txt | 25 + MAINTAINERS| 1 - arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/hwspinlock.c | 60 drivers/hwspinlock/hwspinlock_core.c | 65 ++ drivers/hwspinlock/hwspinlock_internal.h | 47
[PATCH v7 4/4] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna s-a...@ti.com
[t...@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren t...@atomide.com
---
v7: hwlock-base-id is no longer optional, probe will fail now
if property is absent.
MAINTAINERS | 1 -
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60
drivers/hwspinlock/omap_hwspinlock.c | 22 ++---
4 files changed, 17 insertions(+), 69 deletions(-)
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8d32b3..3de03037e90a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6861,7 +6861,6 @@ M:Ohad Ben-Cohen o...@wizery.com
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/hwspinlock/omap_hwspinlock.c
-F: arch/arm/mach-omap2/hwspinlock.c
OMAP MMC SUPPORT
M: Jarkko Lavinen jarkko.lavi...@nokia.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d27dfdef66b..6fa36846d5b4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -282,9 +282,6 @@ obj-y += $(nand-m)
$(nand-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175acaeaa2..
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que s...@ti.com
- * Hari Kanigeri h-kanige...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/err.h
-#include linux/hwspinlock.h
-
-#include soc.h
-#include omap_hwmod.h
-#include omap_device.h
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = spinlock;
- const char *dev_name = omap_hwspinlock;
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err(Can't build omap_device for %s:%s\n, dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 47a275c6ece1..18edb3b4ab32 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
/*
* OMAP hardware spinlock driver
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2015 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Simon Que s...@ti.com
* Hari Kanigeri h-kanige...@ti.com
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/spinlock.h
#include linux/hwspinlock.h
+#include linux/of.h
#include linux/platform_device.h
#include hwspinlock_internal.h
@@ -80,16 +81,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
struct hwspinlock_device *bank;
struct
Re: [PATCH 6/7] ARM: OMAP2+: Fix reboot for 81xx
* Felipe Balbi ba...@ti.com [150113 17:28]:
On Tue, Jan 13, 2015 at 03:13:56PM -0800, Tony Lindgren wrote:
+
+#define TI81XX_PRM_DEVICE_RSTCTRL 0x00a0
+#define TI81XX_GLOBAL_RST_COLD BIT(1)
+
+/**
+ * ti81xx_restart - trigger a software restart of the SoC
+ * @mode: the reboot mode, see arch/arm/kernel/{setup,process}.c
+ * @cmd: passed from the userspace program rebooting the system (if
provided)
+ *
+ * Resets the SoC. For @cmd, see the 'reboot' syscall in
+ * kernel/sys.c. No return value.
+ */
+void ti81xx_restart(enum reboot_mode mode, const char *cmd)
+{
+ omap2_prm_set_mod_reg_bits(TI81XX_GLOBAL_RST_COLD, 0,
+ TI81XX_PRM_DEVICE_RSTCTRL);
do you need to check that mode == REBOOT_COLD here ?
Looks like not, trying to use the warm reset bit does not seem to do
anything and probably requires manually resetting clocks into bypass
mode or something.
I'll just add a comment about that.
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 0/2] Minimal FAPLL clock support for dm816x
Quoting Tony Lindgren (2015-01-13 14:51:26) Hi all, Here's a minimal support for the FAPLL (Flying Adder PLL) on dm816x which is a omap variant. Tony, Patches look fine to me. I'll give it a few days for Paul or Tero to comment if they have any concerns. Also, flying adder pll is a pretty badass pll name. Regards, Mike Regards, Tony Tony Lindgren (2): clk: ti: Add support for FAPLL on dm816x clk: ti: Initialize clocks for dm816x .../devicetree/bindings/clock/ti/fapll.txt | 33 ++ drivers/clk/ti/Makefile| 1 + drivers/clk/ti/clk-3xxx.c | 8 +- drivers/clk/ti/clk-816x.c | 53 +++ drivers/clk/ti/fapll.c | 410 + 5 files changed, 498 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/fapll.txt create mode 100644 drivers/clk/ti/clk-816x.c create mode 100644 drivers/clk/ti/fapll.c -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
* Sergei Shtylyov sergei.shtyl...@cogentembedded.com [150114 05:54]: Hello. On 1/14/2015 2:37 AM, Tony Lindgren wrote: This allows booting ti81xx boards with with when a .dts So, with, with or when? :-) Heh thanks will updated to: This allows booting ti81xx boards when a .dts file is in place. 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 v3 13/21] ARM: omap: convert wakeupgen to stacked domains
* Marc Zyngier marc.zyng...@arm.com [150112 10:30]: OMAP4/5 has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the WUGEN HW block, kernels with this patch applied won't have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs won't even boot. On a platform with this patch applied, the system looks like this: root@bacon-fat:~# cat /proc/interrupts CPU0 CPU1 16: 0 0 WUGEN 37 gp_timer 19: 233799 155916 GIC 27 arch_timer 23: 0 0 WUGEN 9 l3-dbg-irq 24: 1 0 WUGEN 10 l3-app-irq 27:282 0 WUGEN 13 omap-dma-engine 44: 0 0 4ae1.gpio 13 DMA FYI, the legacy irq numbers are now all wrong since commit 9a1091ef0017 (irqchip: gic: Support hierarchy irq domain.). Started a separate thread Regression with legacy IRQ numbers caused by 9a1091ef0017 on it, will give these a try once that's sorted out. 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: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Jan 14, 2015 at 11:09:26AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150114 09:54]: On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: The combined kernel boot follows a similar pattern, but yets a bit further before oopsing, with ASoC DAPM code printing random bits of kernel memory. Note that the combined kernel (which is OMAP4 + Versatile Express) has for a while now also spat out this: WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 Hardware name: Generic OMAP4 (Flattened Device Tree) Backtrace: [c0011bdc] (dump_backtrace) from [c0011e9c] (show_stack+0x18/0x1c) r6:c04c073e r5:0009 r4: r3:00200040 [c0011e84] (show_stack) from [c0466380] (dump_stack+0x78/0x94) [c0466308] (dump_stack) from [c00379ec] (warn_slowpath_common+0x8c/0xb8) r4:ce461b38 r3:ce458000 [c0037960] (warn_slowpath_common) from [c0037abc] (warn_slowpath_fmt+0x38/0x40) r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 [c0037a88] (warn_slowpath_fmt) from [c02098f8] (l3_interrupt_handler+0x218/0x2f0) r3:ce54ad40 r2:c04c0772 [c02096e0] (l3_interrupt_handler) from [c0076444] (handle_irq_event_percpu+0x38/0x13c) r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 r4:ce54f480 [c007640c] (handle_irq_event_percpu) from [c007658c] (handle_irq_event+0x44/0x64) r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 r4:ce440700 [c0076548] (handle_irq_event) from [c00795f4] (handle_fasteoi_irq+0xb0/0x128) r6:ce440760 r5:c06c5fec r4:ce440700 r3: [c0079544] (handle_fasteoi_irq) from [c0075d60] (generic_handle_irq+0x28/0x38) r6:ce408000 r5: r4:0013 r3:c0079544 [c0075d38] (generic_handle_irq) from [c0075ebc] (__handle_domain_irq+0x90/0xb8) r4: r3:0110 [c0075e2c] (__handle_domain_irq) from [c0008858] (gic_handle_irq+0x44/0x68) r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 [c0008814] (gic_handle_irq) from [c00129c4] (__irq_svc+0x44/0x5c) Exception stack(0xce461cd8 to 0xce461d20) 1cc0: 0001 ce458508 1ce0: 6113 ce5b1960 002c ce5b1960 ce5b1938 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 r6: r5:2113 r4:c046df64 r3:ce458000 [c046df1c] (_raw_spin_unlock_irqrestore) from [c0077dd0] (__setup_irq+0x3bc/0x4e4) r5:c06b7c00 r4:ce5b1900 [c0077a14] (__setup_irq) from [c00780ec] (setup_irq+0x50/0x90) r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c r4:ce5b1900 [c007809c] (setup_irq) from [c0032768] (omap_system_dma_probe+0x20c/0x2a4) r6:ce67ec10 r5:002c r4:0020 r3:0002 [c003255c] (omap_system_dma_probe) from [c0298788] (platform_drv_probe+0x50/0x98) r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed r4:ce67ec10 [c0298738] (platform_drv_probe) from [c0296fa8] (driver_probe_device+0x13c/0x34c) r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 [c0296e6c] (driver_probe_device) from [c0297230] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10 [c02971b8] (__driver_attach) from [c0295424] (bus_for_each_dev+0x5c/0x98) r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 [c02953c8] (bus_for_each_dev) from [c02969c0] (driver_attach+0x20/0x28) r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 [c02969a0] (driver_attach) from [c02965ec] (bus_add_driver+0xf8/0x1fc) [c02964f4] (bus_add_driver) from [c0297914] (driver_register+0xa4/0xe8) r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 [c0297870] (driver_register) from [c029861c] (__platform_driver_register+0x50/0x64) r5:c068d0e8 r4:ce621f80 [c02985cc] (__platform_driver_register) from [c0646240] (omap_system_dma_init+0x18/0x20) [c0646228] (omap_system_dma_init) from [c0008c44] (do_one_initcall+0x114/0x1e0) [c0008b30] (do_one_initcall) from [c0632e3c] (kernel_init_freeable+0x110/0x1dc) r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 r4:0003 [c0632d2c] (kernel_init_freeable) from [c0460840] (kernel_init+0x10/0xec) r10: r8: r7: r6: r5:c0460830 r4: [c0460830] (kernel_init) from [c000f0d0] (ret_from_fork+0x14/0x24) r4: r3: ---[ end trace bcb85e0273c31888 ]--- OMAP DMA hardware revision 0.0 This does not occur when booting the plain omap4 kernel. I thought it may be related to another error which people have been reporting, but as it's still there, I thought I
[PATCH] ARM: OMAP4: Remove legacy PMIC platform code
We've had omap4 booting in DT only mode for quite some time
now, let's remove the legacy PMIC code that's no longer
needed.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -39,7 +39,7 @@ static struct i2c_board_info __initdata pmic_i2c_board_info =
{
.flags = I2C_CLIENT_WAKE,
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP3)
static int twl_set_voltage(void *data, int target_uV)
{
struct voltagedomain *voltdm = (struct voltagedomain *)data;
@@ -66,20 +66,6 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, pmic_i2c_board_info, 1);
}
-void __init omap4_pmic_init(const char *pmic_type,
- struct twl4030_platform_data *pmic_data,
- struct i2c_board_info *devices, int nr_devices)
-{
- /* PMIC part*/
- omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
- omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT);
- omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START,
pmic_data);
-
- /* Register additional devices on i2c1 bus if needed */
- if (devices)
- i2c_register_board_info(1, devices, nr_devices);
-}
-
void __init omap_pmic_late_init(void)
{
/* Init the OMAP TWL parameters (if PMIC has been registerd) */
@@ -236,297 +222,6 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
#endif /* CONFIG_ARCH_OMAP3 */
-#if defined(CONFIG_ARCH_OMAP4)
-static struct twl4030_usb_data omap4_usb_pdata = {
-};
-
-static struct regulator_consumer_supply omap4_vdda_hdmi_dac_supplies[] = {
- REGULATOR_SUPPLY(vdda_hdmi_dac, omapdss_hdmi),
-};
-
-static struct regulator_init_data omap4_vdac_idata = {
- .constraints = {
- .min_uV = 180,
- .max_uV = 180,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vdda_hdmi_dac_supplies),
- .consumer_supplies = omap4_vdda_hdmi_dac_supplies,
- .supply_regulator = V2V1,
-};
-
-static struct regulator_init_data omap4_vaux2_idata = {
- .constraints = {
- .min_uV = 120,
- .max_uV = 280,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_init_data omap4_vaux3_idata = {
- .constraints = {
- .min_uV = 100,
- .max_uV = 300,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_consumer_supply omap4_vmmc_supply[] = {
- REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
-};
-
-/* VMMC1 for MMC1 card */
-static struct regulator_init_data omap4_vmmc_idata = {
- .constraints = {
- .min_uV = 120,
- .max_uV = 300,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vmmc_supply),
- .consumer_supplies = omap4_vmmc_supply,
-};
-
-static struct regulator_init_data omap4_vpp_idata = {
- .constraints = {
- .min_uV = 180,
- .max_uV = 250,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
-
Re: [PATCH 1/3] input: tsc2007: Add pre-calibration, flipping and rotation
On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote: Ping for input maintainer. DT changes was acked. Thanks. On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko ma...@goldelico.com wrote: This patch adds new parameters that allow to address typical hardware design differences: touch screens may be wired or oriented differently (portrait or landscape). And usually the active area of the touch is a little larger than the active area of the LCD. This results in the touch coordinates that have some significant deviation from LCD coordinates. Usually this is addressed in user space by a calibration tool (e.g. tslib or xinput-calibrator) but some systems don't have these tools or require that the screen is already roughly calibrated (e.g. Replicant) to operate the device until a better calibration can be done. And, some systems react very strangely if the touch event stream reports coordinates outside of the active area. This makes it necessry to be able to configure: 1. swapping x and y wires (coordinate values) 2. flipping of x (left - right) or y (top - bottom) or even both 3. define an active area so that an uncalibrated screen already roughly matches the LCD to be useful. 4. clip reported coordinates to the active area. If none of the new parameters is defined (in DT) or set in a board file, the driver behaves the same as without this patch. Author (12): H. Nikolaus Schaller h...@goldelico.com Author (34): Paul Kocialkowski cont...@paulk.fr Signed-off-by: H. Nikolaus Schaller h...@goldelico.com OK, I was hesitant of adding these as normally we have tslib to perform the conversion, but maybe it is time to allow it in the kernel and standardize users. However, this seems like a general issue and we should: 1. Perform conversion in input core rather than individual drivers. I think we should allocate a new bitmaps for some transformations and have the code do X/Y flip/clip of the coordinates. 2. Standardize on bindings. We already have of-touchscreen.c doing rudimentary parsing, we shoudl look into extending it rather than creating myriad of driver-specific bindings. Also, do we need swap and flip or do we simply need rotation (like the proposed Broadcom iproc driver has)? Thanks. -- Dmitry -- 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
Regression with legacy IRQ numbers caused by 9a1091ef0017
Hi all, Looks like the legacy IRQ numbers are now all wrong at least for omap4 since commit 9a1091ef0017 (irqchip: gic: Support hierarchy irq domain.). Instead of this: # cat /proc/interrupts CPU0 CPU1 29: 1124981 GIC 29 twd 39: 0 0 GIC 39 TWL6030-PIH 41: 0 0 GIC 41 l3-dbg-irq 42: 0 0 GIC 42 l3-app-irq 44: 0 0 GIC 44 DMA 45: 7854 0 GIC 45 omap-dma-engine 52: 0 0 GIC 52 gpmc ... We now have: # cat /proc/interrupts CPU0 CPU1 16:343 0 GIC 69 gp_timer 17: 1160 1017 GIC 29 twd 18: 0 0 GIC 41 l3-dbg-irq 19: 1 0 GIC 42 l3-app-irq 22: 7850 0 GIC 45 omap-dma-engine 44: 0 0 4a31.gpio 18 DMA 61: 2730 0 48055000.gpio 2 eth0 223: 0 0 GIC 52 gpmc ... So the DMA interrupt using the legacy mapping with something like irq = 12 + OMAP44XX_IRQ_GIC_START now is wrong and unfortunately at least omaps still have a bunch of the legacy interrupts still around. And that naturally produces all kinds of strange errors like: WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [c05f21e4] (__irq_svc) from [c05f1974] (_raw_spin_unlock_irqrestore+0x34/0x44) [c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] (__setup_irq+0x244/0x530) [c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c) [c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4) [c0039c8c] (omap_system_dma_probe) from [c03b2200] (platform_drv_probe+0x44/0xa4) ... Looks like the logic changed from: if (of_property_read_u32(node, arm,routable-irqs, nr_routable_irqs)) to just if (node) Which now causes irq_domain_add_linear() to be called instead of irq_domain_add_legacy(), which causes the breakage. Anybody got a sane fix in mind for the -rc series, or should we just revert it for now? 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: OMAP 4430 SDP: rather sick with recent kernels
* Tony Lindgren t...@atomide.com [150114 11:16]: * Russell King - ARM Linux li...@arm.linux.org.uk [150114 09:54]: On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: The combined kernel boot follows a similar pattern, but yets a bit further before oopsing, with ASoC DAPM code printing random bits of kernel memory. Note that the combined kernel (which is OMAP4 + Versatile Express) has for a while now also spat out this: WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 Hardware name: Generic OMAP4 (Flattened Device Tree) Backtrace: [c0011bdc] (dump_backtrace) from [c0011e9c] (show_stack+0x18/0x1c) r6:c04c073e r5:0009 r4: r3:00200040 [c0011e84] (show_stack) from [c0466380] (dump_stack+0x78/0x94) [c0466308] (dump_stack) from [c00379ec] (warn_slowpath_common+0x8c/0xb8) r4:ce461b38 r3:ce458000 [c0037960] (warn_slowpath_common) from [c0037abc] (warn_slowpath_fmt+0x38/0x40) r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 [c0037a88] (warn_slowpath_fmt) from [c02098f8] (l3_interrupt_handler+0x218/0x2f0) r3:ce54ad40 r2:c04c0772 [c02096e0] (l3_interrupt_handler) from [c0076444] (handle_irq_event_percpu+0x38/0x13c) r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 r4:ce54f480 [c007640c] (handle_irq_event_percpu) from [c007658c] (handle_irq_event+0x44/0x64) r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 r4:ce440700 [c0076548] (handle_irq_event) from [c00795f4] (handle_fasteoi_irq+0xb0/0x128) r6:ce440760 r5:c06c5fec r4:ce440700 r3: [c0079544] (handle_fasteoi_irq) from [c0075d60] (generic_handle_irq+0x28/0x38) r6:ce408000 r5: r4:0013 r3:c0079544 [c0075d38] (generic_handle_irq) from [c0075ebc] (__handle_domain_irq+0x90/0xb8) r4: r3:0110 [c0075e2c] (__handle_domain_irq) from [c0008858] (gic_handle_irq+0x44/0x68) r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 [c0008814] (gic_handle_irq) from [c00129c4] (__irq_svc+0x44/0x5c) Exception stack(0xce461cd8 to 0xce461d20) 1cc0: 0001 ce458508 1ce0: 6113 ce5b1960 002c ce5b1960 ce5b1938 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 r6: r5:2113 r4:c046df64 r3:ce458000 [c046df1c] (_raw_spin_unlock_irqrestore) from [c0077dd0] (__setup_irq+0x3bc/0x4e4) r5:c06b7c00 r4:ce5b1900 [c0077a14] (__setup_irq) from [c00780ec] (setup_irq+0x50/0x90) r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c r4:ce5b1900 [c007809c] (setup_irq) from [c0032768] (omap_system_dma_probe+0x20c/0x2a4) r6:ce67ec10 r5:002c r4:0020 r3:0002 [c003255c] (omap_system_dma_probe) from [c0298788] (platform_drv_probe+0x50/0x98) r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed r4:ce67ec10 [c0298738] (platform_drv_probe) from [c0296fa8] (driver_probe_device+0x13c/0x34c) r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 [c0296e6c] (driver_probe_device) from [c0297230] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10 [c02971b8] (__driver_attach) from [c0295424] (bus_for_each_dev+0x5c/0x98) r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 [c02953c8] (bus_for_each_dev) from [c02969c0] (driver_attach+0x20/0x28) r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 [c02969a0] (driver_attach) from [c02965ec] (bus_add_driver+0xf8/0x1fc) [c02964f4] (bus_add_driver) from [c0297914] (driver_register+0xa4/0xe8) r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 [c0297870] (driver_register) from [c029861c] (__platform_driver_register+0x50/0x64) r5:c068d0e8 r4:ce621f80 [c02985cc] (__platform_driver_register) from [c0646240] (omap_system_dma_init+0x18/0x20) [c0646228] (omap_system_dma_init) from [c0008c44] (do_one_initcall+0x114/0x1e0) [c0008b30] (do_one_initcall) from [c0632e3c] (kernel_init_freeable+0x110/0x1dc) r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 r4:0003 [c0632d2c] (kernel_init_freeable) from [c0460840] (kernel_init+0x10/0xec) r10: r8: r7: r6: r5:c0460830 r4: [c0460830] (kernel_init) from [c000f0d0] (ret_from_fork+0x14/0x24) r4: r3: ---[ end trace bcb85e0273c31888 ]--- OMAP DMA hardware revision 0.0 This does not occur when booting the plain omap4 kernel. I thought it may be related to another error which people have been reporting, but as it's still there, I thought I should report it.
Re: [PATCH 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
On Wed, Jan 14, 2015 at 02:39:55PM +0530, Amit Virdi wrote: Alright, I just applied your patches to testing/fixes. I'll start testing today and should be able to send a pull request to Greg by the end of the week, hopefully. Thanks! Just a small clarification - git failed to send patches to stable kernel list again (unfortunately I used the older configuration; so older git version - my bad). Does these patches land up in the stable trees through maintainers or I should explicitly cc sta...@vger.kernel.org now? Please read Documentation/stable_kernel_rules.txt for how to get patches accepted into the stable trees. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dwc3 gadget fails on dra7-evm
Hi, In 3.19-rc4 on dra7-evm or dra72-evm modprobe g_zero [ 34.680683] zero gadget: Gadget Zero, version: Cinco de Mayo 2008 [ 34.687074] zero gadget: zero ready [ 34.694133] dwc3 4889.usb: failed to enable ep0out [ 34.701600] zero 4889.usb: failed to start zero: -110 ERROR: could not insert 'g_zero': Connection timed out my u-boot version is v2015.01 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/3] input: tsc2007: Add pre-calibration, flipping and rotation
Hi, Am 15.01.2015 um 01:59 schrieb Dmitry Torokhov dmitry.torok...@gmail.com: On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote: Ping for input maintainer. DT changes was acked. Thanks. On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko ma...@goldelico.com wrote: This patch adds new parameters that allow to address typical hardware design differences: touch screens may be wired or oriented differently (portrait or landscape). And usually the active area of the touch is a little larger than the active area of the LCD. This results in the touch coordinates that have some significant deviation from LCD coordinates. Usually this is addressed in user space by a calibration tool (e.g. tslib or xinput-calibrator) but some systems don't have these tools or require that the screen is already roughly calibrated (e.g. Replicant) to operate the device until a better calibration can be done. And, some systems react very strangely if the touch event stream reports coordinates outside of the active area. This makes it necessry to be able to configure: 1. swapping x and y wires (coordinate values) 2. flipping of x (left - right) or y (top - bottom) or even both 3. define an active area so that an uncalibrated screen already roughly matches the LCD to be useful. 4. clip reported coordinates to the active area. If none of the new parameters is defined (in DT) or set in a board file, the driver behaves the same as without this patch. Author (12): H. Nikolaus Schaller h...@goldelico.com Author (34): Paul Kocialkowski cont...@paulk.fr Signed-off-by: H. Nikolaus Schaller h...@goldelico.com OK, I was hesitant of adding these as normally we have tslib to perform the conversion, but maybe it is time to allow it in the kernel and standardize users. Well, tslib isn’t a good replacement for this problem any more and pre-initializing tslib makes some deep hardware dependency visible in user space (each board needs a different tslib config and pointercal default - and on some user spaces tslib is broken with Xorg). But the issue to be solved is more hardware related, i.e. if the Y- and Y+ pins of the controller are connected in a swapped way to the resistor ends of the panel. Hence in a DT based system, this must IMHO be described by the DT and can not be left to some user-space functions any more. However, this seems like a general issue and we should: 1. Perform conversion in input core rather than individual drivers. I think we should allocate a new bitmaps for some transformations and have the code do X/Y flip/clip of the coordinates. Do you have a suggestion where this should be (I have no clue how the input system works or is structured - we just know how to extend a driver that uses it)? 2. Standardize on bindings. We already have of-touchscreen.c doing rudimentary parsing, we shoudl look into extending it rather than creating myriad of driver-specific bindings. Ok, looks reasonable. Also, do we need swap and flip or do we simply need rotation (like the proposed Broadcom iproc driver has)? Well, since the DT should describe hardware, there are 3 sets of wires which can have a cross-over: X+ and X-, Y+ and Y-, X and Y. So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an interpretation of the result of these connections in combination with some panel the touch is glued to and should therefore not be represented in the DT. As a result we have proposed a scheme without explicit rotation. We specify what coordinates X- and X+ should report at their ends (min, max) because the DT programmer has to specify them anyways. Flipping is a result of defining these coordinates in an ascending or descending way. Only swapping of the X and Y wires can’t be implicitly defined so it has its own property. So the scheme we have proposed tries to optimize the efforts needed to adapt new boards and write DTs and focus the DT on hardware description. As a bonus we also specify the min and max value to be reported for the touch pressure (Z axis) using the same basic principle. And it is a pure add-on on top of the existing driver so that it attempts not to break existing device trees. Maybe could you accept it as a first step for this specific driver (and let’s do the big standardization work later on)? — hns -- 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-net-next v2 3/3] net: ethernet: cpsw: don't requests IRQs we don't use
On Wednesday 14 January 2015 10:28 PM, Felipe Balbi wrote: CPSW never uses RX_THRESHOLD or MISC interrupts. In fact, they are always kept masked in their appropriate IRQ Enable register. Instead of allocating an IRQ that never fires, it's best to remove that code altogether and let future patches implement it if anybody needs those. Signed-off-by: Felipe Balbi ba...@ti.com Instead of introducing dummy ISR in previous patch and then removing in this patch, both can be squashed into a single patch. Regards Mugunthan V N -- 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: [v3,15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
+CC: Thomas Abraham thomas...@samsung.com Hi Mark, On Monday 12 January 2015 11:56 PM, Marc Zyngier wrote: Exynos has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the fact that the PMU block is actually the first interrupt controller in the chain for RTC, kernels with this patch applied wont have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs may not even boot. Also, I stronly suspect that there is more than two wake-up interrupts on these platforms, but I leave it to the maintainers to fix their mess. Signed-off-by: Marc Zyngier marc.zyng...@arm.com I tested this series on Exynos5250, using kgene/for-next and linux-next/next-20150114, but S2R failed on Exynos5250 based SMDK board. Following is the log I got on SMDK5250 board, (note I have added some debugging log to know what is happening) I can see is S3C-RTC's enable_irq_wake is failing with error -6. I also observed that even though we are adding pmu_domain_ops using irq_domain_add_hierarchy, but none of pmu_domain_ops are getting called. Please let me know if I am missing anything or do I need to modify anything to test S2R on Exynos SoC. - echo +10 /sys/class/rtc/rtc1/wakealarm; sleep 1; echo mem /sys/power/sta te [ 257.428163] PM: Syncing filesystems ... done. [ 257.431786] Freezing user space processes ... (elapsed 0.003 seconds) done. [ 257.439680] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 257.544451] wake enabled for irq 116 [ 257.546916] CPU: 0 PID: 1311 Comm: ash Not tainted 3.19.0-rc4-next-20150114-00023-g492ff37 #15 [ 257.555141] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 257.561231] [c0014430] (unwind_backtrace) from [c0011594] (show_stack+0x10/0x14) [ 257.568948] [c0011594] (show_stack) from [c0418b00] (dump_stack+0x84/0xc4) [ 257.576151] [c0418b00] (dump_stack) from [c005ce30] (set_irq_wake_real+0x58/0x8c) [ 257.583961] [c005ce30] (set_irq_wake_real) from [c005cef0] (irq_set_irq_wake+0x8c/0xf0) [ 257.592295] [c005cef0] (irq_set_irq_wake) from [c02e9d94] (s3c_rtc_suspend+0xb8/0xdc) [ 257.600456] [c02e9d94] (s3c_rtc_suspend) from [c0298c80] (dpm_run_callback.isra.13+0x1c/0x60) [ 257.609308] [c0298c80] (dpm_run_callback.isra.13) from [c02996a0] (__device_suspend+0x128/0x2d0) [ 257.618422] [c02996a0] (__device_suspend) from [c029a850] (dpm_suspend+0x64/0x22c) [ 257.626320] [c029a850] (dpm_suspend) from [c0058488] (suspend_devices_and_enter+0x88/0x3dc) [ 257.634999] [c0058488] (suspend_devices_and_enter) from [c00589c8] (pm_suspend+0x1ec/0x24c) [ 257.643680] [c00589c8] (pm_suspend) from [c00576e0] (state_store+0x68/0xb8) [ 257.650972] [c00576e0] (state_store) from [c012835c] (kernfs_fop_write+0xb8/0x19c) [ 257.658870] [c012835c] (kernfs_fop_write) from [c00cf620] (vfs_write+0xa0/0x1ac) [ 257.666595] [c00cf620] (vfs_write) from [c00cfc78] (SyS_write+0x44/0x9c) [ 257.673625] [c00cfc78] (SyS_write) from [c000e6e0] (ret_fast_syscall+0x0/0x30) [ 257.681176] genirq: PKD: irq_desc-name: (null): irq: 60 [ 257.686469] genirq: PKD: set_irq_wake_real: ret: -6 [ 257.691349] s3c-rtc 101e.rtc: enable_irq_wake failed: -6 [ 257.708926] PM: suspend of devices complete after 260.482 msecs [ 257.713362] BUCK9: No configuration [ 257.716840] BUCK8: No configuration [ 257.720309] BUCK7: No configuration [ 257.723776] BUCK6: No configuration [ 257.727254] P1.8V_BUCK_OUT5: No configuration [ 257.731597] LDO26: No configuration [ 257.735066] LDO25: No configuration [ 257.738532] LDO24: No configuration [ 257.742009] LDO23: No configuration [ 257.745481] LDO22: No configuration [ 257.748954] LDO21: No configuration [ 257.752419] LDO20: No configuration [ 257.755897] LDO19: No configuration [ 257.759370] LDO18: No configuration [ 257.762835] LDO17: No configuration [ 257.766314] P1.8V_LDO_OUT16: No configuration [ 257.770653] P1.0V_LDO_OUT15: No configuration [ 257.774994] P1.8V_LDO_OUT14: No configuration [ 257.779334] P1.8V_LDO_OUT13: No configuration [ 257.783668] P3.0V_LDO_OUT12: No configuration [ 257.788013] P1.8V_LDO_OUT11: No configuration [ 257.792353] P1.8V_LDO_OUT10: No configuration [ 257.796693] LDO9: No configuration [ 257.800079] P1.0V_LDO_OUT8: No configuration [ 257.804332] P1.1V_LDO_OUT7: No configuration [ 257.808579] P1.1V_LDO_OUT6: No configuration [ 257.812838] P1.8V_LDO_OUT5: No configuration [ 257.817091] P2.8V_LDO_OUT4: No configuration [ 257.821345] P1.8V_LDO_OUT3: No configuration [ 257.825599] P1.2V_LDO_OUT2: No configuration [ 257.829851] P1.0V_LDO_OUT1: No configuration [ 257.835786] PM: late suspend of devices complete after 1.676 msecs [ 257.841913] PM: noirq suspend of devices
Re: [PATCH v5 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
On Wed, Jan 14, 2015 at 04:46:03PM +0100, Alexandre Belloni wrote: Hi, This patch set hasn't moved since while. We actually need patch 4 to properly configure prefetch on sama5d4. What would be needed to come to an agreement ? What do you mean hasn't moved since a while - there has been movement. It was discovered that it breaks OMAP4 platforms. Since then, work has been done to resolve that breakage, and I've merged the recent patch set into my tree for further regression testing, and I'm going to push it out to linux-next later this week. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 v5 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
Hi,
This patch set hasn't moved since while. We actually need patch 4 to
properly configure prefetch on sama5d4. What would be needed to come to
an agreement ?
On 24/09/2014 at 13:05:34 +0200, Marek Szyprowski wrote :
This is an updated patchset, which intends to add support for L2 cache
on Exynos4 SoCs on boards running under secure firmware, which requires
certain initialization steps to be done with help of firmware, as
selected registers are writable only from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further three patches add implementation of .write_sec and .configure
callbacks for Exynos secure firmware and necessary DT nodes to enable
L2 cache.
Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
boards (both with secure firmware). There should be no functional change
for Exynos boards running without secure firmware. I do not have access
to affected non-Exynos boards, so I could not test on them.
Depends on:
- [PATCH v3 0/5] Firmware-assisted suspend/resume of Exynos SoCs
(https://lkml.org/lkml/2014/8/26/445)
Changelog:
Changes since v4:
(https://lkml.org/lkml/2014/8/26/461)
- rewrote the code accessing l2x0_saved_regs from assembly code
- added comment and reworked unconditional call to SMC_CMD_L2X0INVALL
Changes since v3:
(https://lkml.org/lkml/2014/7/17/600)
- fixed issues with references to initdata on resume path by creating
a copy of affected structure (pointed out by Russell King),
- fixed unnecessary full reconfiguration of L2C controller on resume
(configuration is already determined after initialization, so the
only thing to do is to push those values to the controller),
- rebased on next-20140717 tag of linux-next tree and last versions
of dependencies.
Changes since v2:
(https://lkml.org/lkml/2014/6/25/416)
- refactored L2C driver to use commit-like interface and make it no longer
depend on availability of writes to individual registers,
- moved L2C resume to assembly code, because doing it later makes some
systems unstable - this is also needed for deeper cpuidle modes,
- dropped unnecessary patch hacking around the .write_sec interface,
- dropped patch making the driver use l2c_write_sec() for LATENCY_CTRL
registers as Exynos is no longer affected and I'm not aware of any
reports that this is also needed on other platforms (can be applied
separately if it turns out to be so),
- rebased onto next-20140717 tag of linux-next tree.
Changes since v1:
(https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106323.html)
- rebased onto for-next branch of linux-samsung tree,
- changed argument order of outer_cache.write_sec() callback to match
l2c_write_sec() function in cache-l2x0.c,
- added support of overriding of prefetch settings to work around incorrect
default settings on certain Exynos4x12-based boards,
- added call to firmware to invalidate whole L2 cache before setting enable
bit in L2C control register (required by Exynos secure firmware).
Patch summary:
Tomasz Figa (7):
ARM: l2c: Refactor the driver to use commit-like interface
ARM: l2c: Add interface to ask hypervisor to configure L2C
ARM: l2c: Get outer cache .write_sec callback from mach_desc only if
not NULL
ARM: l2c: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: EXYNOS: Add support for non-secure L2X0 resume
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/outercache.h | 3 +
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/firmware.c| 50 +
arch/arm/mach-exynos/sleep.S | 46 +
arch/arm/mm/cache-l2x0.c | 255
-
8 files changed, 294 insertions(+), 96
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: The combined kernel boot follows a similar pattern, but yets a bit further before oopsing, with ASoC DAPM code printing random bits of kernel memory. Note that the combined kernel (which is OMAP4 + Versatile Express) has for a while now also spat out this: WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 Hardware name: Generic OMAP4 (Flattened Device Tree) Backtrace: [c0011bdc] (dump_backtrace) from [c0011e9c] (show_stack+0x18/0x1c) r6:c04c073e r5:0009 r4: r3:00200040 [c0011e84] (show_stack) from [c0466380] (dump_stack+0x78/0x94) [c0466308] (dump_stack) from [c00379ec] (warn_slowpath_common+0x8c/0xb8) r4:ce461b38 r3:ce458000 [c0037960] (warn_slowpath_common) from [c0037abc] (warn_slowpath_fmt+0x38/0x40) r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 [c0037a88] (warn_slowpath_fmt) from [c02098f8] (l3_interrupt_handler+0x218/0x2f0) r3:ce54ad40 r2:c04c0772 [c02096e0] (l3_interrupt_handler) from [c0076444] (handle_irq_event_percpu+0x38/0x13c) r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 r4:ce54f480 [c007640c] (handle_irq_event_percpu) from [c007658c] (handle_irq_event+0x44/0x64) r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 r4:ce440700 [c0076548] (handle_irq_event) from [c00795f4] (handle_fasteoi_irq+0xb0/0x128) r6:ce440760 r5:c06c5fec r4:ce440700 r3: [c0079544] (handle_fasteoi_irq) from [c0075d60] (generic_handle_irq+0x28/0x38) r6:ce408000 r5: r4:0013 r3:c0079544 [c0075d38] (generic_handle_irq) from [c0075ebc] (__handle_domain_irq+0x90/0xb8) r4: r3:0110 [c0075e2c] (__handle_domain_irq) from [c0008858] (gic_handle_irq+0x44/0x68) r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 [c0008814] (gic_handle_irq) from [c00129c4] (__irq_svc+0x44/0x5c) Exception stack(0xce461cd8 to 0xce461d20) 1cc0: 0001 ce458508 1ce0: 6113 ce5b1960 002c ce5b1960 ce5b1938 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 r6: r5:2113 r4:c046df64 r3:ce458000 [c046df1c] (_raw_spin_unlock_irqrestore) from [c0077dd0] (__setup_irq+0x3bc/0x4e4) r5:c06b7c00 r4:ce5b1900 [c0077a14] (__setup_irq) from [c00780ec] (setup_irq+0x50/0x90) r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c r4:ce5b1900 [c007809c] (setup_irq) from [c0032768] (omap_system_dma_probe+0x20c/0x2a4) r6:ce67ec10 r5:002c r4:0020 r3:0002 [c003255c] (omap_system_dma_probe) from [c0298788] (platform_drv_probe+0x50/0x98) r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed r4:ce67ec10 [c0298738] (platform_drv_probe) from [c0296fa8] (driver_probe_device+0x13c/0x34c) r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 [c0296e6c] (driver_probe_device) from [c0297230] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10 [c02971b8] (__driver_attach) from [c0295424] (bus_for_each_dev+0x5c/0x98) r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 [c02953c8] (bus_for_each_dev) from [c02969c0] (driver_attach+0x20/0x28) r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 [c02969a0] (driver_attach) from [c02965ec] (bus_add_driver+0xf8/0x1fc) [c02964f4] (bus_add_driver) from [c0297914] (driver_register+0xa4/0xe8) r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 [c0297870] (driver_register) from [c029861c] (__platform_driver_register+0x50/0x64) r5:c068d0e8 r4:ce621f80 [c02985cc] (__platform_driver_register) from [c0646240] (omap_system_dma_init+0x18/0x20) [c0646228] (omap_system_dma_init) from [c0008c44] (do_one_initcall+0x114/0x1e0) [c0008b30] (do_one_initcall) from [c0632e3c] (kernel_init_freeable+0x110/0x1dc) r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 r4:0003 [c0632d2c] (kernel_init_freeable) from [c0460840] (kernel_init+0x10/0xec) r10: r8: r7: r6: r5:c0460830 r4: [c0460830] (kernel_init) from [c000f0d0] (ret_from_fork+0x14/0x24) r4: r3: ---[ end trace bcb85e0273c31888 ]--- OMAP DMA hardware revision 0.0 This does not occur when booting the plain omap4 kernel. I thought it may be related to another error which people have been reporting, but as it's still there, I thought I should report it. To me, this suggests that Versatile Express code may be initialising on non-Versatile Express hardware, possibly touching hardware, but it looks like it's happening within the setup_irq() called from the legacy OMAP DMA code, though it's possible that could be because Versatile Express code could be hitting some register which
Re: [PATCH v5 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
Hi, On 14/01/2015 at 16:21:50 +, Russell King - ARM Linux wrote : On Wed, Jan 14, 2015 at 04:46:03PM +0100, Alexandre Belloni wrote: Hi, This patch set hasn't moved since while. We actually need patch 4 to properly configure prefetch on sama5d4. What would be needed to come to an agreement ? What do you mean hasn't moved since a while - there has been movement. It was discovered that it breaks OMAP4 platforms. Since then, work has been done to resolve that breakage, and I've merged the recent patch set into my tree for further regression testing, and I'm going to push it out to linux-next later this week. Indeed, my searching skills are not great. I was actually looking for mails from Tomasz but he is not taking care of it now... Thanks for the info! -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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-net-next v2 2/3] net: ethernet: cpsw: split out IRQ handler
Now we can introduce dedicated IRQ handlers
for each of the IRQ events. This helps with
cleaning up a little bit of the clutter in
cpsw_interrupt() while also making sure that
TX IRQs will try to handle TX buffers while
RX IRQs will try to handle RX buffers.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 41 ++---
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8e1af51e4b76..c6c483f3e49f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -754,18 +754,36 @@ requeue:
dev_kfree_skb_any(new_skb);
}
-static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
+static irqreturn_t cpsw_dummy_interrupt(int irq, void *dev_id)
{
struct cpsw_priv *priv = dev_id;
int value = irq - priv-irqs_table[0];
- /* NOTICE: Ending IRQ here. The trick with the 'value' variable above
-* is to make sure we will always write the correct value to the EOI
-* register. Namely 0 for RX_THRESH Interrupt, 1 for RX Interrupt, 2
-* for TX Interrupt and 3 for MISC Interrupt.
-*/
cpdma_ctlr_eoi(priv-dma, value);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
+{
+ struct cpsw_priv *priv = dev_id;
+
+ cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_TX);
+ cpdma_chan_process(priv-txch, 128);
+
+ priv = cpsw_get_slave_priv(priv, 1);
+ if (priv)
+ cpdma_chan_process(priv-txch, 128);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
+{
+ struct cpsw_priv *priv = dev_id;
+
+ cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_RX);
+
cpsw_intr_disable(priv);
if (priv-irq_enabled == true) {
cpsw_disable_irq(priv);
@@ -1617,7 +1635,8 @@ static void cpsw_ndo_poll_controller(struct net_device
*ndev)
cpsw_intr_disable(priv);
cpdma_ctlr_int_ctrl(priv-dma, false);
- cpsw_interrupt(ndev-irq, priv);
+ cpsw_rx_interrupt(priv-irq[1], priv);
+ cpsw_tx_interrupt(priv-irq[2], priv);
cpdma_ctlr_int_ctrl(priv-dma, true);
cpsw_intr_enable(priv);
}
@@ -2351,7 +2370,7 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
priv-irqs_table[0] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ ret = devm_request_irq(pdev-dev, irq, cpsw_dummy_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
dev_err(priv-dev, error attaching irq (%d)\n, ret);
@@ -2363,7 +2382,7 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
priv-irqs_table[1] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ ret = devm_request_irq(pdev-dev, irq, cpsw_rx_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
dev_err(priv-dev, error attaching irq (%d)\n, ret);
@@ -2375,7 +2394,7 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
priv-irqs_table[2] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ ret = devm_request_irq(pdev-dev, irq, cpsw_tx_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
dev_err(priv-dev, error attaching irq (%d)\n, ret);
@@ -2387,7 +2406,7 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
priv-irqs_table[3] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ ret = devm_request_irq(pdev-dev, irq, cpsw_dummy_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
dev_err(priv-dev, error attaching irq (%d)\n, ret);
--
2.2.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
[patch-net-next v2 3/3] net: ethernet: cpsw: don't requests IRQs we don't use
CPSW never uses RX_THRESHOLD or MISC interrupts. In
fact, they are always kept masked in their appropriate
IRQ Enable register.
Instead of allocating an IRQ that never fires, it's best
to remove that code altogether and let future patches
implement it if anybody needs those.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 55 --
1 file changed, 15 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c6c483f3e49f..ba09ff3c1695 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -754,16 +754,6 @@ requeue:
dev_kfree_skb_any(new_skb);
}
-static irqreturn_t cpsw_dummy_interrupt(int irq, void *dev_id)
-{
- struct cpsw_priv *priv = dev_id;
- int value = irq - priv-irqs_table[0];
-
- cpdma_ctlr_eoi(priv-dma, value);
-
- return IRQ_HANDLED;
-}
-
static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
{
struct cpsw_priv *priv = dev_id;
@@ -1635,8 +1625,8 @@ static void cpsw_ndo_poll_controller(struct net_device
*ndev)
cpsw_intr_disable(priv);
cpdma_ctlr_int_ctrl(priv-dma, false);
- cpsw_rx_interrupt(priv-irq[1], priv);
- cpsw_tx_interrupt(priv-irq[2], priv);
+ cpsw_rx_interrupt(priv-irq[0], priv);
+ cpsw_tx_interrupt(priv-irq[1], priv);
cpdma_ctlr_int_ctrl(priv-dma, true);
cpsw_intr_enable(priv);
}
@@ -2358,30 +2348,27 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_dma_ret;
}
- ndev-irq = platform_get_irq(pdev, 0);
+ ndev-irq = platform_get_irq(pdev, 1);
if (ndev-irq 0) {
dev_err(priv-dev, error getting irq resource\n);
ret = -ENOENT;
goto clean_ale_ret;
}
- irq = platform_get_irq(pdev, 0);
- if (irq 0)
- goto clean_ale_ret;
-
- priv-irqs_table[0] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_dummy_interrupt,
- 0, dev_name(pdev-dev), priv);
- if (ret 0) {
- dev_err(priv-dev, error attaching irq (%d)\n, ret);
- goto clean_ale_ret;
- }
+ /* Grab RX and TX IRQs. Note that we also have RX_THRESHOLD and
+* MISC IRQs which are always kept disabled with this driver so
+* we will not request them.
+*
+* If anyone wants to implement support for those, make sure to
+* first request and append them to irqs_table array.
+*/
+ /* RX IRQ */
irq = platform_get_irq(pdev, 1);
if (irq 0)
goto clean_ale_ret;
- priv-irqs_table[1] = irq;
+ priv-irqs_table[0] = irq;
ret = devm_request_irq(pdev-dev, irq, cpsw_rx_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
@@ -2389,31 +2376,19 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
}
+ /* TX IRQ */
irq = platform_get_irq(pdev, 2);
if (irq 0)
goto clean_ale_ret;
- priv-irqs_table[2] = irq;
+ priv-irqs_table[1] = irq;
ret = devm_request_irq(pdev-dev, irq, cpsw_tx_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
dev_err(priv-dev, error attaching irq (%d)\n, ret);
goto clean_ale_ret;
}
-
- irq = platform_get_irq(pdev, 3);
- if (irq 0)
- goto clean_ale_ret;
-
- priv-irqs_table[3] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_dummy_interrupt,
- 0, dev_name(pdev-dev), priv);
- if (ret 0) {
- dev_err(priv-dev, error attaching irq (%d)\n, ret);
- goto clean_ale_ret;
- }
-
- priv-num_irqs = 4;
+ priv-num_irqs = 2;
ndev-features |= NETIF_F_HW_VLAN_CTAG_FILTER;
--
2.2.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: [PATCH 3/3] usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core
Hi,
On Wed, Jan 14, 2015 at 03:08:43PM +0800, Sneeker Yeh wrote:
Hi Felipe:
thanks for suggestion,
2015-01-13 1:20 GMT+08:00 Felipe Balbi ba...@ti.com:
Hi,
On Sun, Jan 11, 2015 at 11:19:55PM +0800, Sneeker Yeh wrote:
enable the quirk only for you. Isn't there a better way of
enabling the
quirk based off of revision detection couple with a look on
GHWPARAMS*
registers ?
What's tricking me is this claim that only config-free PHYs would
be
affected, why ?
i'm still struggling now to try to get more information about this.
some security policy inside Fujitsu make me unable to access full
information of this errata today.
Someday after i get enough information,
i shall take your suggestion here that seems better to incur quirk
dynamically via GHWPARAMS,
and then send it here again.
ok, hopefully you'll find a way ;-)
I got some update information here finally~
in case i express unclearly i also put a pdf:
https://drive.google.com/file/d/0B18MmcvvKjNNbDF6eEdHSzZCazA/view
This issue is defined by a two-way race at disconnect, between
1) class driver interrupt endpoint resheduling attempts if the ISR gave
an
ep error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
asynchronously
3) The hardware IP was configured in silicon with
- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 (this is an IP configuration
yeah, aparently this is another configuration which is not exposed on
HWPARAMS registers. Paul, can you confirm for us ? I couldn't find it on
Databook on any of the HWPARAMS registers.
port whose state cannot be checked from software)
- Synopsys IP version is 3.00a
heh, so pretty much everybody :-)
yeah, and I'm really lucky to encounter this @@
The IP will auto-suspend itself on device detach with some
phy-specific interval after CSC is cleared by 2)
If 2) and 3) complete before 1), the interrupts it expects will not be
generated by the autosuspended IP, leading to a deadlock. Even later
disconnection procedure would detect that corresponding urb is still
in-progress and issue a ep stop command, auto-suspended IP still won't
respond to that command.
this defect would result in this when device detached:
---
[ 99.603544] usb 4-1: USB disconnect, device number 2
[ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
endpoint command.
[ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting
host.
[ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
[ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
halting.
[ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
As a result, when device detached, we desired to postpone PORTCSC clear
behind disable slot. it's found that all executed ep command related to
disconnetion, are executed before disable slot.
Now this is all great information and they should all be part of your
commit log and probably a big comment should be added to code as well.
I see, thanks.
Thanks for going after all these details, now let's figure out a way to
pass dwc3 revision to xhci, or maybe we pass just a flag for the quirk,
something like:
if (dwc-revision 3.00a dwc-has_suspend_on_disconnect)
xhci_pdata.delay_portcsc_clear = true;
or something similar to that.
Sure, how about i write these like this, that i learn from the way dwc3
inject XHCI_LPM_SUPPORT to xhci via platform data:
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -53,6 +53,10 @@ int dwc3_host_init(struct dwc3 *dwc)
pdata.usb3_lpm_capable = 1;
#endif
+ if ((dwc-revision DWC3_REVISION_300A)
+ dwc-suspend_on_disconnect_quirk)
+ pdata.delay_portcsc_clear = 1;
+
ret = platform_device_add_data(xhci, pdata, sizeof(pdata));
if (ret) {
dev_err(dwc-dev, couldn't add platform data to xHCI
device\n);
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node of_property_read_bool(node, usb3-lpm-capable)) ||
(pdata pdata-usb3_lpm_capable))
xhci-quirks |= XHCI_LPM_SUPPORT;
+
+ if (pdata pdata-delay_portcsc_clear)
+ xhci-quirks |= XHCI_DISCONNECT_QUIRK;
/*
* Set the xHCI pointer before xhci_plat_setup() (aka
hcd_driver.reset)
* is called by usb_add_hcd().
but I'm a little confused about how we decide
Re: [PATCH 1/5] mfd: tps65218: make INT[12] and STATUS registers volatile
* Felipe Balbi ba...@ti.com [150112 08:50]: Hi, On Thu, Jan 08, 2015 at 10:25:12AM -0600, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 11:37:34AM -0600, Felipe Balbi wrote: On Fri, Dec 26, 2014 at 01:28:20PM -0600, Felipe Balbi wrote: STATUS register can be modified by the HW, so we should bypass cache because of that. In the case of INT[12] registers, they are the ones that actually clear the IRQ source at the time they are read. If we rely on the cache for them, we will never be able to clear the interrupt, which will cause our IRQ line to be disabled due to IRQ throttling. Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC Cc: sta...@vger.kernel.org # v3.15+ Cc: Keerthy j-keer...@ti.com Cc: Lee Jones lee.jo...@linaro.org Signed-off-by: Felipe Balbi ba...@ti.com ping another ping. Without this and the following patch TPS65218 power button driver which was already applied by Dmitry, won't work. Anybody ? -rc4 is out and tps65218 is still broken because nobody has acted on these two patches. All other patches which are meant for 3.20 merge window are applied and because of these pending, those patches won't work. Lee, are you planning to pick these two drivers/mfd patches? 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: dwc3 gadget fails on dra7-evm
Hi, On Wed, Jan 14, 2015 at 05:44:08PM +0200, Roger Quadros wrote: In 3.19-rc4 on dra7-evm or dra72-evm modprobe g_zero [ 34.680683] zero gadget: Gadget Zero, version: Cinco de Mayo 2008 [ 34.687074] zero gadget: zero ready [ 34.694133] dwc3 4889.usb: failed to enable ep0out [ 34.701600] zero 4889.usb: failed to start zero: -110 ERROR: could not insert 'g_zero': Connection timed out my u-boot version is v2015.01 hmm... it could be that DRA7x also needs the suspend phy quirk. Can you try this ? diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 22771bc1643a..63f8b007bdc5 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -1257,6 +1257,8 @@ tx-fifo-resize; maximum-speed = super-speed; dr_mode = otg; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; }; }; @@ -1278,6 +1280,8 @@ tx-fifo-resize; maximum-speed = high-speed; dr_mode = otg; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; }; }; @@ -1299,6 +1303,8 @@ tx-fifo-resize; maximum-speed = high-speed; dr_mode = otg; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; }; }; Weird, I remeber testing on X15 and not needing this quirk :-s -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/7] ARM: OMAP2+: Fix error handling for omap2_clk_enable_init_clocks
* Felipe Balbi ba...@ti.com [150113 17:25]:
On Tue, Jan 13, 2015 at 03:13:52PM -0800, Tony Lindgren wrote:
We need to check if we got the clock before trying to do anything
with it. Otherwise we will get something like this:
Unable to handle kernel paging request at virtual address fffe
...
[c04bef78] (clk_prepare) from [c00338a4]
(omap2_clk_enable_init_clocks+0x50/0x8)
[c00338a4] (omap2_clk_enable_init_clocks) from [c0876838]
(dm816x_dt_clk_init+0)
...
Let's add check for the clock and WARN if the init clock was not
found.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Just one minor nit below, other than that:
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/clock.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 6ad5b4d..89a0732 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -620,6 +620,11 @@ void omap2_clk_enable_init_clocks(const char
**clk_names, u8 num_clocks)
for (i = 0; i num_clocks; i++) {
init_clk = clk_get(NULL, clk_names[i]);
+ if (IS_ERR(init_clk)) {
+ WARN(1, omap clock: could not find init clock %s\n,
+clk_names[i]);
you can combine the if with the WARN():
if (WARN(IS_ERR(init_clk), could not find init clock %s\n,
clk_names[i]))
not that I also removed that omap clock prefix because WARN() will
print the file name anyway.
+ continue;
+ }
clk_prepare_enable(init_clk);
}
}
Sure makes sense to me. Updated patch below.
Regards,
Tony
8 -
From: Tony Lindgren t...@atomide.com
Date: Mon, 22 Dec 2014 08:19:07 -0800
Subject: [PATCH] ARM: OMAP2+: Fix error handling for
omap2_clk_enable_init_clocks
We need to check if we got the clock before trying to do anything
with it. Otherwise we will get something like this:
Unable to handle kernel paging request at virtual address fffe
...
[c04bef78] (clk_prepare) from [c00338a4]
(omap2_clk_enable_init_clocks+0x50/0x8)
[c00338a4] (omap2_clk_enable_init_clocks) from [c0876838]
(dm816x_dt_clk_init+0)
...
Let's add check for the clock and WARN if the init clock was not
found.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -620,6 +620,9 @@ void omap2_clk_enable_init_clocks(const char **clk_names,
u8 num_clocks)
for (i = 0; i num_clocks; i++) {
init_clk = clk_get(NULL, clk_names[i]);
+ if (WARN(IS_ERR(init_clk), could not find init clock %s\n,
+ clk_names[i]))
+ continue;
clk_prepare_enable(init_clk);
}
}
--
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-net-next v2 1/3] net: ethernet: cpsw: unroll IRQ request loop
This patch is in preparation for a nicer IRQ
handling scheme where we use different IRQ
handlers for each IRQ line (as it should be).
Later, we will also drop IRQs offset 0 and 3
because they are always disabled in this driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 62 --
1 file changed, 47 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index e61ee8351272..8e1af51e4b76 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2156,7 +2156,8 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
u32 slave_offset, sliver_offset, slave_size;
- int ret = 0, i, k = 0;
+ int ret = 0, i;
+ int irq;
ndev = alloc_etherdev(sizeof(struct cpsw_priv));
if (!ndev) {
@@ -2345,24 +2346,55 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
}
- while ((res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k))) {
- if (k = ARRAY_SIZE(priv-irqs_table)) {
- ret = -EINVAL;
- goto clean_ale_ret;
- }
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0)
+ goto clean_ale_ret;
- ret = devm_request_irq(pdev-dev, res-start, cpsw_interrupt,
- 0, dev_name(pdev-dev), priv);
- if (ret 0) {
- dev_err(priv-dev, error attaching irq (%d)\n, ret);
- goto clean_ale_ret;
- }
+ priv-irqs_table[0] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
+ }
- priv-irqs_table[k] = res-start;
- k++;
+ irq = platform_get_irq(pdev, 1);
+ if (irq 0)
+ goto clean_ale_ret;
+
+ priv-irqs_table[1] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
+ }
+
+ irq = platform_get_irq(pdev, 2);
+ if (irq 0)
+ goto clean_ale_ret;
+
+ priv-irqs_table[2] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
+ }
+
+ irq = platform_get_irq(pdev, 3);
+ if (irq 0)
+ goto clean_ale_ret;
+
+ priv-irqs_table[3] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
}
- priv-num_irqs = k;
+ priv-num_irqs = 4;
ndev-features |= NETIF_F_HW_VLAN_CTAG_FILTER;
--
2.2.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: [PATCH 1/7] ARM: OMAP2+: Remove unused ti81xx platform init code
* Felipe Balbi ba...@ti.com [150113 17:23]: On Tue, Jan 13, 2015 at 03:13:51PM -0800, Tony Lindgren wrote: The support for 81xx was never working in mainline, and it will be only supported in device tree mode. Let's remove all the remaining 81xx related platform code. you should probably also mention here that you're dropping unnecessary non-DT AM33xx support since that has never booted on legacy mode. Other than that Reviewed-by: Felipe Balbi ba...@ti.com Thanks, the 81xx legacy booting support already got removed, these are just left overs I noticed. I've updated the description with the following: The support for 81xx was never working in mainline, and the broken legacy booting support has been removed. There are patches coming to make 81xx boot with device tree, and for that we won't need any of this legacy platform code, so let's just remove it. 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 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
Alright, I just applied your patches to testing/fixes. I'll start testing today and should be able to send a pull request to Greg by the end of the week, hopefully. Thanks! Just a small clarification - git failed to send patches to stable kernel list again (unfortunately I used the older configuration; so older git version - my bad). Does these patches land up in the stable trees through maintainers or I should explicitly cc sta...@vger.kernel.org now? -- 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 RFC 0/3] Make ti,tilcdc,slave DT binding more sensible
On 01/14/2015 08:57 AM, Jean-Francois Moine wrote: On Tue, 13 Jan 2015 19:12:25 +0200 Jyri Sarha jsa...@ti.com wrote: These patches are needed for Beaglebone-back HDMI audio. There is no direct dependency between these patches and the other (dts and ASoC) changes needed for the HDMI audio so these changes can be merged independently. I also feel that these changes make sense even without the HDMI audio. Best regards, Jyri Jyri Sarha (3): drm: encoder_slave: Add drm_i2c_encoder_attach() drm/tilcdc: slave: Add support for i2c-slave DT-parameter ARM: dts: am335x-boneblack: Use new binding in ti,tilcdc,slave node .../devicetree/bindings/drm/tilcdc/slave.txt |4 +- arch/arm/boot/dts/am335x-boneblack.dts |9 +++- drivers/gpu/drm/drm_encoder_slave.c| 51 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 50 +++ include/drm/drm_encoder_slave.h|3 ++ 5 files changed, 95 insertions(+), 22 deletions(-) Instead of adding code to have the slave encoder working, it would be simpler to change the way tilcdc uses the tda998x. I already proposed such a patch: http://lists.freedesktop.org/archives/dri-devel/2014-March/056065.html and the changes in the tda998x driver have been done by Russell: commit: a8f4d4d63739e4bca459ff40636f1d9e4b7ef5e6 drm/i2c: tda998x: allow re-use of tda998x support code and commit: c707c3619ca81f499a5ce032021405e989a96ff0 drm/i2c: tda998x: add component support Interesting. Would you still have the original branch somewhere? Manual applying the patches from the web-page is time consuming. Best regards, Jyri -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: pcf857x: restore the initial line state of all pcf lines
On Mon, Jan 5, 2015 at 7:26 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Thursday 18 December 2014 07:41 PM, Nishanth Menon wrote:
On 12/18/2014 12:18 AM, Kishon Vijay Abraham I wrote:
On Tuesday 16 December 2014 02:20 AM, Nishanth Menon wrote:
On 12/12/2014 02:06 AM, Kishon Vijay Abraham I wrote:
The reset values for all the PCF lines are high and hence on shutdown
we should drive all the lines high in order to bring it to the reset
state.
This is actually required since pcf doesn't have a reset line and even
after
warm reset (by invoking reboot in prompt) the pcf lines maintains it's
previous programmed state. This becomes a problem if the boards are
designed
to work with the default initial state.
DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to MMC/SD
and
this line should be driven high in order for the MMC/SD to be detected.
This line is modelled as regulator and the hsmmc driver takes care of
enabling
and disabling it. In the case of 'reboot', during shutdown path as part
of it's
cleanup process the hsmmc driver disables this regulator. This makes MMC
boot
not functional.
Fixed it by driving high all the pcf lines.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/gpio/gpio-pcf857x.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 236708a..00b15b2 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -448,6 +448,14 @@ static int pcf857x_remove(struct i2c_client *client)
return status;
}
+static void pcf857x_shutdown(struct i2c_client *client)
+{
+ struct pcf857x *gpio = i2c_get_clientdata(client);
+
+ /* Drive all the I/O lines high */
+ gpio-write(gpio-client, BIT(gpio-chip.ngpio) - 1);
you might force a contention here - depending on System configuration.
example:
+---+
| |
| U1 | +--+ +---+
| +- | | |
+---+ | | | |
| Switch-+SoC|
+---+ | | | |
| | | | | |
| U2-+--^---+ +---+
| ||
| ||
+---+|
+--+--+
| |
| PCF |
| |
+-+
At low, SoC pin is connected to U2 as drive. when reset to high, you
now have U1 driving to the same pin that SoC has, potentially
resulting in contention.
Unfortunately, at this level, you do not know what the state of the
system is, blindly forcing a pin level will potentially cause
contention risk depending on pin configuration.
Assume we are doing a reset when the system is powered on, irrespective of
the
state of the system, we'll be forcing the pin level to the default state.
Yes, I dont deny that system will be fine *after* reset sequence is
started or completed. However there is a duration between the pcf
shutdown handler is called and the final reset handler is invoked -
that is the duration when the contention might cause device behavior.
Essentially ignoring the state various drivers have asked PCF to setup
the pins and doing a hands down configuration may have side effects we
cant properly expect.
The solution might be to invoke the shutdown handler of the various drivers
using the PCF before the shutdown handler of the PCF driver itself gets
invoked? But I'm not sure how can that be achieved in linux kernel :-(
#include linux/reboot.h
static int foo_reboot_handler(struct notifier_block *this,
unsigned long code,
void *unused)
{
pr_crit(do some last minute stuff\n);
return NOTIFY_OK;
}
static struct notifier_block foo_reboot_notifier = {
.notifier_call = foo_reboot_handler,
};
register_reboot_notifier(foo_reboot_notifier);
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 0/3] ARM: edma: Correct header file usage
On Thursday 27 November 2014 04:11 PM, Peter Ujfalusi wrote: Hi, The linux/platform_data/edma.h file was used for API definition as well, which is not correct since the header should only contain platform data related structures, defines, etc. I would like to queue this series through ARM-SoC for v3.20 with Mark's and Ulf's acks added. I know its not the complete clean-up everyone wanted to see but I also know Peter working on doing the complete clean-up as well. So we are firmly on the path to removing arch/arm/common/edma.c. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
Hello. On 1/14/2015 2:37 AM, Tony Lindgren wrote: This allows booting ti81xx boards with with when a .dts So, with, with or when? :-) file is in place. Cc: Brian Hutchinson b.hutch...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
On 14/01/15 01:46, Paul Walmsley wrote:
On Wed, 7 Jan 2015, Roger Quadros wrote:
From: Paul Walmsley p...@pwsan.com
Date: Mon, 5 Jan 2015 15:49:57 -0700
Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
registers. Experimental.
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..03df8833d399 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1938,6 +1938,8 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
if (oh-class-reset) {
+ WARN(!oh-_mpu_rt_va, Attempt to call custom reset with no MPU
register target ioremapped: %s,
+oh-name);
Not part of $subject.
Hmm, how do you mean? If we skip the ioremap(), wouldn't you like to know
before some custom reset code gets called that pretty much always depends
on the ioremap() succeeding? :-)
Ah yes. you are right.
r = oh-class-reset(oh);
} else {
if (oh-rst_lines_cnt 0) {
@@ -2358,15 +2360,19 @@ static int of_dev_hwmod_lookup(struct device_node
*np,
}
/**
- * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * _init_mpu_rt_base - populate the MPU port and virtual address
* @oh: struct omap_hwmod * to locate the virtual address
* @data: (unused, caller should pass NULL)
* @index: index of the reg entry iospace in device tree
* @np: struct device_node * of the IP block's device node in the DT data
*
- * Cache the virtual address used by the MPU to access this IP block's
- * registers. This address is needed early so the OCP registers that
- * are part of the device's address space can be ioremapped properly.
+ * Cache the interconnect target port and the virtual address used by
+ * the MPU to access this IP block's registers. The address is needed
+ * early so the OCP registers that are part of the device's address
+ * space can be ioremapped properly. The presence or absence of the
+ * interconnect target port also indicates whether the hwmod code
+ * should wait for the IP block to indicate readiness after it is
+ * enabled.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
@@ -2385,6 +2391,13 @@ static int __init _init_mpu_rt_base(struct
omap_hwmod *oh, void *data,
if (oh-_int_flags _HWMOD_NO_MPU_PORT)
return -ENXIO;
+ /*
+* If there's no need for the hwmod code to read or write to
+* the IP block registers, bail out early before the ioremap()
+*/
+ if (!oh-class-sysc)
+ return 0;
+
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
@@ -2451,14 +2464,10 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-name, np-name);
}
- if (oh-class-sysc) {
- r = _init_mpu_rt_base(oh, NULL, index, np);
- if (r 0) {
- WARN(1, omap_hwmod: %s: doesn't have mpu register
target base\n,
-oh-name);
- return 0;
- }
- }
+ r = _init_mpu_rt_base(oh, NULL, index, np);
+ if (r 0)
+ pr_debug(omap_hwmod: %s: doesn't have mpu register target
base\n,
+oh-name);
This is the real piece that fixes the issue.
r = _init_clocks(oh, NULL);
if (r 0) {
I've tested this patch on am43x-gp-evm, and it seems to fix the issue
although with some unpleasant warning messages.
Could you paste those in?
I can't reproduce what I saw earlier. Sorry for the noise.
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
