Re: RCU stall on panda
On 05/13/2014 05:21 AM, Tony Lindgren wrote: * Paul E. McKenney paul...@linux.vnet.ibm.com [140505 11:11]: On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: I keep seeing the RCU stall problem on panda board from 3.10 kernel to latest upstream kernel and google find some one report it before: https://lkml.org/lkml/2012/9/20/519 Is it the hardware issue or a real software problem? I cannot distinguish between hardware and software from the trace below, but given that you are also seeing a soft lockup, either way you do appear to have a real problem as opposed to an RCU CPU stall warning false positive. Looks like you have CPU_IDLE enabled on panda. Hangs with current linux next with CPU_IDLE are currently being discussed on the linux-omap list in thread omap4-panda-es boot issues with v3.15-rc4 I've seen occasional system hangs, and I've also noticed that doing ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system producing similar errors to the below. Thanks a lot for the info. In fact, the oops keeps in upstream kernel from 3.10 to latest. Regards, Tony 95.519653] INFO: rcu_sched self-detected stall on CPU^M [ 95.519866] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M [ 95.526489] INFO: rcu_sched detected stalls on CPUs/tasks:^M [ 95.526489] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M [ 95.526489] (detected by 0, t=4229 jiffies, g=800, c=799, q=440)^M [ 95.526519] Task dump for CPU 1:^M [ 95.526519] swapper/1 R running 0 0 1 0x^M [ 95.559844] (t=4229 jiffies g=800 c=799 q=440)^M [ 95.564727] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc4 #93^M [ 95.571502] [c00133fd] (unwind_backtrace) from [c001076d] (show_stack+0x11/0x14)^M [ 95.579711] [c001076d] (show_stack) from [c0570465] (dump_stack+0x75/0x88)^M [ 95.587371] [c0570465] (dump_stack) from [c0084383] (rcu_check_callbacks+0x353/0x79c)^M [ 95.596038] [c0084383] (rcu_check_callbacks) from [c003e99f] (update_process_times+0x33/0x4c)^M [ 95.605438] [c003e99f] (update_process_times) from [c008e5a3] (tick_sched_handle.isra.18+0x1f/0x48)^M [ 95.615386] [c008e5a3] (tick_sched_handle.isra.18) from [c008e609] (tick_sched_timer+0x3d/0x5c)^M [ 95.624969] [c008e609] (tick_sched_timer) from [c0051a23] (__run_hrtimer+0x67/0x310)^M [ 95.633544] [c0051a23] (__run_hrtimer) from [c00525fd] (hrtimer_interrupt+0xe1/0x214)^M [ 95.642211] [c00525fd] (hrtimer_interrupt) from [c008cecb] (tick_receive_broadcast+0x1f/0x30)^M [ 95.651611] [c008cecb] (tick_receive_broadcast) from [c0011e4f] (handle_IPI+0xb3/0x120)^M [ 95.660461] [c0011e4f] (handle_IPI) from [c00085e5] (gic_handle_irq+0x51/0x54)^M [ 95.668487] [c00085e5] (gic_handle_irq) from [c057603f] (__irq_svc+0x3f/0x64)^M [ 95.676391] Exception stack(0xee0dbf10 to 0xee0dbf58)^M [ 95.681762] bf00: 0001 0001 ee0d8c40^M [ 95.690429] bf20: 3c6bd296 0016 3c6f8c43 0016 eefab540 c08e0c84 c0fc7114^M [ 95.699066] bf40: 0010 ee0dbf58 c006ef4d c0443890 4033 ^M [ 95.706085] [c057603f] (__irq_svc) from [c0443890] (cpuidle_enter_state+0xc0/0xc4)^M [ 95.714477] [c0443890] (cpuidle_enter_state) from [c0444d11] (cpuidle_enter_state_coupled+0xe1/0x290)^M [ 95.724639] [c0444d11] (cpuidle_enter_state_coupled) from [c0067cd1] (cpu_startup_entry+0x1a5/0x494)^M [ 95.734680] [c0067cd1] (cpu_startup_entry) from [80008685] (0x80008685)^M [ 95.742095] BUG: soft lockup - CPU#1 stuck for 40s! [swapper/1:0]^M [ 95.748535] Modules linked in:^M [ 95.751770] irq event stamp: 128730^M [ 95.755462] hardirqs last enabled at (128727): [c044388f] cpuidle_enter_state+0xbf/0xc4^M [ 95.764221] hardirqs last disabled at (128728): [c0576033] __irq_svc+0x33/0x64^M [ 95.772064] softirqs last enabled at (128730): [c00386cd] irq_enter+0x59/0x60^M [ 95.779907] softirqs last disabled at (128729): [c00386ba] irq_enter+0x46/0x60^M [ 95.787750] ^M my RCU and IDLE related kernel config as blow: CONFIG_TREE_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_TREE_RCU_TRACE=y CONFIG_PROVE_RCU=y CONFIG_PROVE_RCU_REPEATEDLY=y CONFIG_SPARSE_RCU_POINTER=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RCU_CPU_STALL_INFO=y CONFIG_RCU_TRACE=y alexs@alex-panda:~$ cat /proc/config.gz | gunzip | grep IDLE CONFIG_NO_HZ_IDLE=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y -- Thanks Alex ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in
[PATCH] ARM: edma: Clean up and simplify the code around irq request
Get the two interrupt line number at the same time by merging the two
instance of if(node){}else{} places.
replace the pdev-dev with the already existing dev which makes it possible
to collapse lines with devm_request_irq()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index db2d9dc62d33..fade9ada81f8 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1596,7 +1596,6 @@ static int edma_probe(struct platform_device *pdev)
struct resource *r[EDMA_MAX_CC] = {NULL};
struct resource res[EDMA_MAX_CC];
charres_name[10];
- charirq_name[10];
struct device_node *node = pdev-dev.of_node;
struct device *dev = pdev-dev;
int ret;
@@ -1718,14 +1717,21 @@ static int edma_probe(struct platform_device *pdev)
if (node) {
irq[j] = irq_of_parse_and_map(node, 0);
+ err_irq[j] = irq_of_parse_and_map(node, 2);
} else {
+ char irq_name[10];
+
sprintf(irq_name, edma%d, j);
irq[j] = platform_get_irq_byname(pdev, irq_name);
+
+ sprintf(irq_name, edma%d_err, j);
+ err_irq[j] = platform_get_irq_byname(pdev, irq_name);
}
edma_cc[j]-irq_res_start = irq[j];
- status = devm_request_irq(pdev-dev, irq[j],
- dma_irq_handler, 0, edma,
- pdev-dev);
+ edma_cc[j]-irq_res_end = err_irq[j];
+
+ status = devm_request_irq(dev, irq[j], dma_irq_handler, 0,
+ edma, dev);
if (status 0) {
dev_dbg(pdev-dev,
devm_request_irq %d failed -- %d\n,
@@ -1733,16 +1739,8 @@ static int edma_probe(struct platform_device *pdev)
return status;
}
- if (node) {
- err_irq[j] = irq_of_parse_and_map(node, 2);
- } else {
- sprintf(irq_name, edma%d_err, j);
- err_irq[j] = platform_get_irq_byname(pdev, irq_name);
- }
- edma_cc[j]-irq_res_end = err_irq[j];
- status = devm_request_irq(pdev-dev, err_irq[j],
- dma_ccerr_handler, 0,
- edma_error, pdev-dev);
+ status = devm_request_irq(dev, err_irq[j], dma_ccerr_handler, 0,
+ edma_error, dev);
if (status 0) {
dev_dbg(pdev-dev,
devm_request_irq %d failed -- %d\n,
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM/DT: edma: Get IP configuration from hardware
Hi, We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Regards, Peter --- Peter Ujfalusi (4): ARM: edma: Get IP information from HW when booting with DT dt/bindings: ti,edma: Remove redundant properties from documentation ARM: dts: am33xx: Remove obsolete properties from edma node ARM: dts: am4372: Remove obsolete properties from edma node Documentation/devicetree/bindings/dma/ti-edma.txt | 6 - arch/arm/boot/dts/am33xx.dtsi | 3 - arch/arm/boot/dts/am4372.dtsi | 3 - arch/arm/common/edma.c| 128 +- 4 files changed, 79 insertions(+), 61 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: am33xx: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index baf56cc92040..5e8f647ee4ec 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -147,9 +147,6 @@
0x44e10f90 0x10;
interrupts = 12 13 14;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
gpio0: gpio@44e07000 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: edma: Get IP information from HW when booting with DT
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 128 ++---
1 file changed, 79 insertions(+), 49 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index fade9ada81f8..1a98f3cd4cd9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,16 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5))
#define EDMA_DCHMAP0x0100 /* 64 registers */
-#define CHMAP_EXISTBIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x) ((x 0x70) 4) /* bits 4-6 */
+#define GET_NUM_INTCH(x) ((x 0x700) 8) /* bits 8-10 */
+#define GET_NUM_PAENTRY(x) ((x 0x7000) 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x 0x7) 16) /* bits 16-18 */
+#define GET_NUM_REGN(x)((x 0x30) 20) /* bits 20-21 */
+#define CHMAP_EXISTBIT(24)
+#define MP_EXIST BIT(25)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1415,6 +1424,68 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_info_from_hw(struct device *dev,
+ struct edma_soc_info *pdata)
+{
+ int i;
+ u32 value, cccfg, n_tc;
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
+
+ value = GET_NUM_DMACH(cccfg);
+ pdata-n_channel = BIT(value + 1);
+
+ value = GET_NUM_REGN(cccfg);
+ pdata-n_region = BIT(value);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ pdata-n_slot = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ n_tc = value + 1;
+
+ dev_dbg(dev, eDMA3 HW configuration (cccfg: 0x%08x):\n, cccfg);
+ dev_dbg(dev, n_channel: %u\n, pdata-n_channel);
+ dev_dbg(dev, n_region: %u\n, pdata-n_region);
+ dev_dbg(dev, n_slot: %u\n, pdata-n_slot);
+ dev_dbg(dev, n_tc: %u\n, n_tc);
+
+ pdata-n_cc = 1;
+
+ queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata-queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+
+ pdata-default_queue = 0;
+
+ return 0;
+}
+
#if IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_DMADEVICES)
static int edma_of_read_u32_to_s16_array(const struct device_node *np,
@@ -1483,63 +1554,16 @@ static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
{
- int ret = 0, i;
- u32 value;
+ int ret = 0;
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
-
- ret = of_property_read_u32(node, dma-channels, value);
- if (ret 0)
- return ret;
- pdata-n_channel = value;
-
- ret = of_property_read_u32(node, ti,edma-regions, value);
- if (ret 0)
- return ret;
- pdata-n_region = value;
-
- ret = of_property_read_u32(node, ti,edma-slots, value);
- if (ret 0)
- return ret;
- pdata-n_slot = value;
-
- pdata-n_cc = 1;
rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
if (!rsv_info)
return -ENOMEM;
pdata-rsv = rsv_info;
- queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_tc_map)
- return -ENOMEM;
-
- for (i = 0; i 3; i++) {
- queue_tc_map[i][0] = i;
- queue_tc_map[i][1] = i;
- }
- queue_tc_map[i][0] = -1;
- queue_tc_map[i][1] = -1;
-
- pdata-queue_tc_mapping = queue_tc_map;
-
- queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_priority_map)
- return -ENOMEM;
-
- for (i = 0; i 3; i++) {
-
[PATCH 4/4] ARM: dts: am4372: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 03a225505126..b9f83b705f4b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -108,9 +108,6 @@
GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
uart0: serial@44e09000 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] dt/bindings: ti,edma: Remove redundant properties from documentation
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
The ti,edma-regions; ti,edma-slots and dma-channels in DT are
redundant since the very same information can be obtained from the HW.
The mentioned properties can be removed from the binding document.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 9fbbdb783a72..cf8d0a2d5b33 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -2,11 +2,8 @@ TI EDMA
Required properties:
- compatible : ti,edma3
-- ti,edma-regions: Number of regions
-- ti,edma-slots: Number of slots
- #dma-cells: Should be set to 1
Clients should use a single channel number per DMA request.
-- dma-channels: Specify total DMA channels per CC
- reg: Memory map for accessing module
- interrupt-parent: Interrupt controller the interrupt is routed through
- interrupts: Exactly 3 interrupts need to be specified in the order:
@@ -26,9 +23,6 @@ edma: edma@4900 {
compatible = ti,edma3;
ti,hwmods = tpcc, tptc0, tptc1, tptc2;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
ti,edma-xbar-event-map = 1 12
2 13;
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 810c205..02ea08f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -273,6 +273,56 @@ static struct omap_hwmod dra7xx_ctrl_module_wkup_hwmod = {
};
/*
+ * 'gmac' class
+ * cpsw/gmac sub system
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_gmac_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x8,
+ .syss_offs = 0x4,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
+ MSTANDBY_NO),
+ .sysc_fields= omap_hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_gmac_hwmod_class = {
+ .name = gmac,
+ .sysc = dra7xx_gmac_sysc,
+};
+
+static struct omap_hwmod dra7xx_gmac_hwmod = {
+ .name = gmac,
+ .class = dra7xx_gmac_hwmod_class,
+ .clkdm_name = gmac_clkdm,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+ .main_clk = dpll_gmac_ck,
+ .mpu_rt_idx = 1,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_GMAC_GMAC_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_GMAC_GMAC_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
+ * 'mdio' class
+ */
+static struct omap_hwmod_class dra7xx_mdio_hwmod_class = {
+ .name = davinci_mdio,
+};
+
+static struct omap_hwmod dra7xx_mdio_hwmod = {
+ .name = davinci_mdio,
+ .class = dra7xx_mdio_hwmod_class,
+ .clkdm_name = gmac_clkdm,
+ .main_clk = dpll_gmac_ck,
+};
+
+/*
* 'dcan' class
*
*/
@@ -1999,6 +2049,19 @@ static struct omap_hwmod_ocp_if
dra7xx_l4_wkup__ctrl_module_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__cpgmac0 = {
+ .master = dra7xx_l4_per2_hwmod,
+ .slave = dra7xx_gmac_hwmod,
+ .clk= dpll_gmac_ck,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if dra7xx_gmac__mdio = {
+ .master = dra7xx_gmac_hwmod,
+ .slave = dra7xx_mdio_hwmod,
+ .user = OCP_USER_MPU,
+};
+
/* l4_wkup - dcan1 */
static struct omap_hwmod_ocp_if dra7xx_l4_wkup__dcan1 = {
.master = dra7xx_l4_wkup_hwmod,
@@ -2652,6 +2715,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_wkup__ctrl_module_wkup,
dra7xx_l4_wkup__dcan1,
dra7xx_l4_per2__dcan2,
+ dra7xx_l4_per2__cpgmac0,
+ dra7xx_gmac__mdio,
dra7xx_l4_cfg__dma_system,
dra7xx_l3_main_1__dss,
dra7xx_l3_main_1__dispc,
--
1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
Adding device tree entry for CPSW to make it work in Dual EMAC mode. DRA7 cpsw phy sel driver patch has been pulled in net-next git with the following commit id *d415fa1b88748d664b7b6a310dd8e699d2686cf7* Mugunthan V N (3): pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM arch/arm/boot/dts/dra7-evm.dts| 103 ++ arch/arm/boot/dts/dra7.dtsi | 59 ++ include/dt-bindings/pinctrl/dra.h | 8 +++ 3 files changed, 170 insertions(+) -- 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx
Add CPSW and MDIO related device tree data for DRA7XX and made as status
disabled. Phy-id, pinmux for active and sleep state needs to be added in
board dts files and enable the CPSW device.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 59 +
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e550f06..61a5b68 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -31,6 +31,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ ethernet0 = cpsw_emac0;
+ ethernet1 = cpsw_emac1;
};
timer {
@@ -785,6 +787,63 @@
interrupts = 0 343 0x4;
status = disabled;
};
+
+ mac: ethernet@4a10 {
+ compatible = ti,cpsw;
+ ti,hwmods = gmac;
+ cpdma_channels = 8;
+ ale_entries = 1024;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
+ slaves = 2;
+ active_slave = 0;
+ cpts_clock_mult = 0x8000;
+ cpts_clock_shift = 29;
+ reg = 0x48484000 0x800
+ 0x48485200 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ /*
+* rx_thresh_pend
+* rx_pend
+* tx_pend
+* misc_pend
+*/
+ interrupts = GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH;
+ ranges;
+ status = disabled;
+
+ davinci_mdio: mdio@48485000 {
+ compatible = ti,davinci_mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = davinci_mdio;
+ bus_freq = 100;
+ reg = 0x48485000 0x100;
+ };
+
+ cpsw_emac0: slave@48480200 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ cpsw_emac1: slave@48480300 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ phy_sel: cpsw-phy-sel@4a002554 {
+ compatible = ti,dra7xx-cpsw-phy-sel;
+ reg= 0x4a002554 0x4;
+ reg-names = gmii-sel;
+ };
+ };
+
};
crossbar_mpu: crossbar@4a02 {
--
1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC
Add pin off modes for dra7 SoC so that during module disable or suspend state it can help saving power Signed-off-by: Mugunthan V N mugunthan...@ti.com --- include/dt-bindings/pinctrl/dra.h | 8 1 file changed, 8 insertions(+) diff --git a/include/dt-bindings/pinctrl/dra.h b/include/dt-bindings/pinctrl/dra.h index 002a285..a0ff2d0 100644 --- a/include/dt-bindings/pinctrl/dra.h +++ b/include/dt-bindings/pinctrl/dra.h @@ -46,5 +46,13 @@ #define PIN_INPUT_PULLUP (PULL_ENA | INPUT_EN | PULL_UP) #define PIN_INPUT_PULLDOWN (PULL_ENA | INPUT_EN) +/* Off mode states */ +#define PIN_OFF_NONE 0 +#define PIN_OFF_OUTPUT_HIGH(OFF_EN | OFFOUT_EN | OFFOUT_VAL) +#define PIN_OFF_OUTPUT_LOW (OFF_EN | OFFOUT_EN) +#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFF_PULL_EN | OFF_PULL_UP) +#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN) +#define PIN_OFF_WAKEUPENABLE WAKEUP_EN + #endif -- 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM
Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active and
sleep states and enable them in board evm dts file.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 103 +
1 file changed, 103 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5f1f6da..91d5dd8 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -108,6 +108,85 @@
0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs3.qspi1_cs1 */
;
};
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x250 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tclk */
+ 0x254 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tctl */
+ 0x258 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td3 */
+ 0x25c (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td2 */
+ 0x260 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td1 */
+ 0x264 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td0 */
+ 0x268 (PIN_INPUT | MUX_MODE0) /* rgmii1_rclk */
+ 0x26c (PIN_INPUT | MUX_MODE0) /* rgmii1_rctl */
+ 0x270 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd3 */
+ 0x274 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd2 */
+ 0x278 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd1 */
+ 0x27c (PIN_INPUT | MUX_MODE0) /* rgmii1_rd0 */
+
+ /* Slave 2 */
+ 0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
+ 0x19c (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tctl */
+ 0x1a0 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td3 */
+ 0x1a4 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td2 */
+ 0x1a8 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td1 */
+ 0x1ac (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td0 */
+ 0x1b0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rclk */
+ 0x1b4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rctl */
+ 0x1b8 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd3 */
+ 0x1bc (PIN_INPUT | MUX_MODE3) /* rgmii2_rd2 */
+ 0x1c0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd1 */
+ 0x1c4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd0 */
+ ;
+
+ };
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x250 (PIN_OFF_NONE)
+ 0x254 (PIN_OFF_NONE)
+ 0x258 (PIN_OFF_NONE)
+ 0x25c (PIN_OFF_NONE)
+ 0x260 (PIN_OFF_NONE)
+ 0x264 (PIN_OFF_NONE)
+ 0x268 (PIN_OFF_NONE)
+ 0x26c (PIN_OFF_NONE)
+ 0x270 (PIN_OFF_NONE)
+ 0x274 (PIN_OFF_NONE)
+ 0x278 (PIN_OFF_NONE)
+ 0x27c (PIN_OFF_NONE)
+
+ /* Slave 1 */
+ 0x198 (PIN_OFF_NONE)
+ 0x19c (PIN_OFF_NONE)
+ 0x1a0 (PIN_OFF_NONE)
+ 0x1a4 (PIN_OFF_NONE)
+ 0x1a8 (PIN_OFF_NONE)
+ 0x1ac (PIN_OFF_NONE)
+ 0x1b0 (PIN_OFF_NONE)
+ 0x1b4 (PIN_OFF_NONE)
+ 0x1b8 (PIN_OFF_NONE)
+ 0x1bc (PIN_OFF_NONE)
+ 0x1c0 (PIN_OFF_NONE)
+ 0x1c4 (PIN_OFF_NONE)
+ ;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_data */
+ 0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* mdio_clk */
+ ;
+ };
+
+ davinci_mdio_sleep: davinci_mdio_sleep {
+ pinctrl-single,pins =
+ 0x23c (PIN_OFF_NONE)
+ 0x240 (PIN_OFF_NONE)
+ ;
+ };
};
i2c1 {
@@ -353,3 +432,27 @@
};
};
};
+
+mac {
+ status = okay;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = cpsw_default;
+ pinctrl-1 = cpsw_sleep;
+ dual_emac;
+};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 2;
+ phy-mode = rgmii;
+};
+
+cpsw_emac1 {
+ phy_id = davinci_mdio, 3;
+ phy-mode = rgmii;
+};
+
+davinci_mdio {
+ pinctrl-names = default, sleep;
+ pinctrl-0 = davinci_mdio_default;
+ pinctrl-1 = davinci_mdio_sleep;
+};
--
1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: omap4-panda-es boot issues with v3.15-rc4
On 05/13/2014 01:07 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [140512 14:41]:
On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote:
* Kevin Hilman khil...@linaro.org [140509 16:46]:
Roger Quadros rog...@ti.com writes:
Kevin,
On 05/09/2014 01:15 AM, Kevin Hilman wrote:
Tony Lindgren t...@atomide.com writes:
[...]
..but I think I found the cause for recent hangs on panda, just a wild
guess based on looking at the recent cpuidle patches after v3.14.
Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
until all coupled CPUs leave idle) makes booting work reliably again
on panda.
Can you guys confirm, so far no issues here after few boot tests,
but it might be too early to tell.
Reverting that makes things a bit more stable, but it still eventually
fails in the same way. For me it took 8 boots for it to eventually
fail.
However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
(20+ boots in a row and still going.)
Can you please test with CPU_IDLE enabled but C3 disabled as in below
patch?
It worked for me 10/10 boots.
Yup, it worked for me too for 10/10 boots in a row.
But what has caused this regression, does it work reliably with let's
say v3.13 or v3.12?
IIRC things were stable till some CPUIDLE code consolidation happened.
I don't recall exactly but some one did discuss about it a while back.
OK that's good to hear.
Can you re-run your test-cases with patch at end of the email. This
is just a hunch so don't blame me if I waste your time testing the
patch.
Seems to work after adding #include linux/clockchips.h. I did about 10
reboots and they all succeeded for me. Without your revert, I'm getting
a hang (with sysrq not working) about 1/3 of the boots.
Kevin, Roger, does the revert from Santosh work for you too?
next-20140508 worked for me 10/10 times with Santosh's patch.
The heartbeat LED behaves normally as well. So I like it :).
cheers,
-roger
BTW, I think the the RCU stall was/is a separate issue. That's different
where the system actually recovers after about a minute, or after sysrq
ctrl-a f h or l. Sorry, I no longer know if the RCU stall is only with the
older kernels around v3.10 time, or if it's still also happening.
Regards,
Tony
From bdd30d68f8fa659aa0e3ce436f94029a7719036b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] Revert cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag
This reverts commit cb7094e848f7bcaa0a4cda3db4b232f08dbf5b78.
Conflicts:
arch/arm/mach-omap2/cpuidle44xx.c
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..aae3606 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -83,6 +83,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
{
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+int cpu_id = smp_processor_id();
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +111,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET)
(cx-mpu_logic_state == PWRDM_POWER_OFF);
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +168,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -189,8 +194,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
-.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
|
- CPUIDLE_FLAG_TIMER_STOP,
+.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
@@ -199,8 +203,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
.exit_latency = 460 + 518,
.target_residency = 1100,
-.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
|
- CPUIDLE_FLAG_TIMER_STOP,
+
Re: [PATCH 0/4] ARM/DT: edma: Get IP configuration from hardware
On Tuesday 13 May 2014 01:13 PM, Peter Ujfalusi wrote: Hi, We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Peter, to which baseline do these patches apply? I tried applying them to v3.15-rc5 but 1/4 doesn't apply cleanly. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/5] usb: musb: dsps: Enable sw babble control for newer silicon
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index eb1985a..1ae6681 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -136,6 +136,7 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+ bool sw_babble_enabled;
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -469,6 +470,16 @@ static int dsps_musb_init(struct musb *musb)
val = ~(1 wrp-otg_disable);
dsps_writel(musb-ctrl_base, wrp-phy_utmi, val);
+ /*
+* Check whether the dsps version has babble control enabled.
+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+ val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ if (val == MUSB_BABBLE_RCV_DISABLE)
+ glue-sw_babble_enabled = true;
+
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
return ret;
@@ -591,14 +602,25 @@ static int dsps_musb_reset(struct musb *musb)
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
const struct dsps_musb_wrapper *wrp = glue-wrp;
+ int session_restart = 0;
- dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
- usleep_range(100, 200);
- usb_phy_shutdown(musb-xceiv);
- usleep_range(100, 200);
- usb_phy_init(musb-xceiv);
+ if (glue-sw_babble_enabled)
+ session_restart = sw_babble_control(musb);
+ /*
+* In case of new silicon version babble condition can be recovered
+* without resetting the MUSB. But for older silicon versions, MUSB
+* reset is needed
+*/
+ if (session_restart || !glue-sw_babble_enabled) {
+ dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
+ usleep_range(100, 200);
+ usb_phy_shutdown(musb-xceiv);
+ usleep_range(100, 200);
+ usb_phy_init(musb-xceiv);
+ session_restart = 1;
+ }
- return 0;
+ return !session_restart;
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.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 v3 2/5] usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset()
For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 51beb13..74c4193 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -543,7 +543,11 @@ static void dsps_musb_reset(struct musb *musb)
const struct dsps_musb_wrapper *wrp = glue-wrp;
dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
- udelay(100);
+ usleep_range(100, 200);
+ usb_phy_shutdown(musb-xceiv);
+ usleep_range(100, 200);
+ usb_phy_init(musb-xceiv);
+
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.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 v3 0/5] Add support for SW babble Control
Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. Patch 1 - Convert recover work to delayed work. Patch 2 - usb_phy_vbus_(off/_on) are NOPs for am335x PHY so use usb_phy(_shutdown/_init) in musb_platform_reset() Patch 3 - Add return value for musb_platform_reset() in prepration to support SW babble_ctrl Patch 4 - Add the sw_babble_control() Patch 5 - Enable sw babble control for newer silicon v2 - v3 : Modify musb_platform_reset() to return zero on success. v1 - v2 : Fixed the issue with Patch 5. In v1 it was not calling sw_babble_control(). George Cherian (5): usb: musb: core: Convert babble recover work to delayed work usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset() usb: musb: core: Convert the musb_platform_reset to have a return value. usb: musb: dsps: Add the sw_babble_control() usb: musb: dsps: Enable sw babble control for newer silicon drivers/usb/musb/musb_core.c | 49 ++ drivers/usb/musb/musb_core.h | 12 --- drivers/usb/musb/musb_dsps.c | 83 ++-- drivers/usb/musb/musb_regs.h | 7 4 files changed, 121 insertions(+), 30 deletions(-) -- 1.8.3.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 v3 3/5] usb: musb: core: Convert the musb_platform_reset to have a return value.
Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetting the IP block. In preperation to add that support
its better to have a rest_done return for musb_platform_reset().
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 38 +-
drivers/usb/musb/musb_core.h | 10 ++
drivers/usb/musb/musb_dsps.c | 3 ++-
3 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index dcadc62..1f8b175 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1755,28 +1755,32 @@ static void musb_irq_work(struct work_struct *data)
static void musb_recover_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, recover_work.work);
- int status;
+ int status, ret;
- musb_platform_reset(musb);
+ ret = musb_platform_reset(musb);
+ if (ret 0)
+ return;
- usb_phy_vbus_off(musb-xceiv);
- usleep_range(100, 200);
+ if (!ret) {
+ usb_phy_vbus_off(musb-xceiv);
+ usleep_range(100, 200);
- usb_phy_vbus_on(musb-xceiv);
- usleep_range(100, 200);
+ usb_phy_vbus_on(musb-xceiv);
+ usleep_range(100, 200);
- /*
-* When a babble condition occurs, the musb controller removes the
-* session bit and the endpoint config is lost.
-*/
- if (musb-dyn_fifo)
- status = ep_config_from_table(musb);
- else
- status = ep_config_from_hw(musb);
+ /*
+* When a babble condition occurs, the musb controller removes
the
+* session bit and the endpoint config is lost.
+*/
+ if (musb-dyn_fifo)
+ status = ep_config_from_table(musb);
+ else
+ status = ep_config_from_hw(musb);
- /* start the session again */
- if (status == 0)
- musb_start(musb);
+ /* start the session again */
+ if (status == 0)
+ musb_start(musb);
+ }
}
/* --
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 423cd00..3ccb428 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,7 +192,7 @@ struct musb_platform_ops {
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
- void(*reset)(struct musb *musb);
+ int (*reset)(struct musb *musb);
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -554,10 +554,12 @@ static inline void musb_platform_try_idle(struct musb
*musb,
musb-ops-try_idle(musb, timeout);
}
-static inline void musb_platform_reset(struct musb *musb)
+static inline int musb_platform_reset(struct musb *musb)
{
- if (musb-ops-reset)
- musb-ops-reset(musb);
+ if (!musb-ops-reset)
+ return -EINVAL;
+
+ return musb-ops-reset(musb);
}
static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..f6f3087 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
{
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+ return 0;
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.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 v3 1/5] usb: musb: core: Convert babble recover work to delayed work
During babble condition both first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.
To acheive this schedule a delayed work for babble rrecovery.
While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 15 ---
drivers/usb/musb/musb_core.h | 2 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61da471..dcadc62 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -850,7 +850,8 @@ b_host:
/* handle babble condition */
if (int_usb MUSB_INTR_BABBLE)
- schedule_work(musb-recover_work);
+ schedule_delayed_work(musb-recover_work,
+ msecs_to_jiffies(100));
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
@@ -1753,16 +1754,16 @@ static void musb_irq_work(struct work_struct *data)
/* Recover from babble interrupt conditions */
static void musb_recover_work(struct work_struct *data)
{
- struct musb *musb = container_of(data, struct musb, recover_work);
+ struct musb *musb = container_of(data, struct musb, recover_work.work);
int status;
musb_platform_reset(musb);
usb_phy_vbus_off(musb-xceiv);
- udelay(100);
+ usleep_range(100, 200);
usb_phy_vbus_on(musb-xceiv);
- udelay(100);
+ usleep_range(100, 200);
/*
* When a babble condition occurs, the musb controller removes the
@@ -1945,7 +1946,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
- INIT_WORK(musb-recover_work, musb_recover_work);
+ INIT_DELAYED_WORK(musb-recover_work, musb_recover_work);
INIT_DELAYED_WORK(musb-deassert_reset_work, musb_deassert_reset);
INIT_DELAYED_WORK(musb-finish_resume_work, musb_host_finish_resume);
@@ -2041,7 +2042,7 @@ fail4:
fail3:
cancel_work_sync(musb-irq_work);
- cancel_work_sync(musb-recover_work);
+ cancel_delayed_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
if (musb-dma_controller)
@@ -2107,7 +2108,7 @@ static int musb_remove(struct platform_device *pdev)
dma_controller_destroy(musb-dma_controller);
cancel_work_sync(musb-irq_work);
- cancel_work_sync(musb-recover_work);
+ cancel_delayed_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
musb_free(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 47e8874..423cd00 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -297,7 +297,7 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
- struct work_struct recover_work;
+ struct delayed_work recover_work;
struct delayed_work deassert_reset_work;
struct delayed_work finish_resume_work;
u16 hwvers;
--
1.8.3.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 0/2] Add AM437x GP EVM cpsw DT node
Add AM437x GP EVM cpsw device tree node Mugunthan V N (2): ARM: dts: am4372: Add cpsw phy sel dt node ARM: dts: am437x-gp-evm: Add ethernet support for GP EVM arch/arm/boot/dts/am4372.dtsi | 6 arch/arm/boot/dts/am437x-gp-evm.dts | 72 + 2 files changed, 78 insertions(+) -- 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: am4372: Add cpsw phy sel dt node
Add cpsw phy sel device tree node for selecting phy mode in control module
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ac37ac9..0ff84cf 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -521,6 +521,12 @@
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
+
+ phy_sel: cpsw-phy-sel@44e10650 {
+ compatible = ti,am43xx-cpsw-phy-sel;
+ reg= 0x44e10650 0x4;
+ reg-names = gmii-sel;
+ };
};
epwmss0: epwmss@4830 {
--
1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: am437x-gp-evm: Add ethernet support for GP EVM
Add CPSW ethernet support for AM437x GP EVM which has one slave pinned out
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 72 +
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 4e92d9e..8dc1c6e 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,6 +98,58 @@
0x264 (PIN_INPUT_PULLUP | MUX_MODE7) /*
spi2_d0.gpio3_22 */
;
};
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txen.rgmii1_txen */
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxdv.rgmii1_rxctl */
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_txd3 */
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_txd2 */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_txd1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_txd0 */
+ 0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txclk.rmii1_tclk */
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxclk.rmii1_rclk */
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rxd3 */
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rxd2 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rxd0 */
+ ;
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 reset value */
+ 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ ;
+ };
+
+ davinci_mdio_sleep: davinci_mdio_sleep {
+ pinctrl-single,pins =
+ /* MDIO reset value */
+ 0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
};
i2c0 {
@@ -179,3 +231,23 @@
dr_mode = host;
status = okay;
};
+
+mac {
+ slaves = 1;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = cpsw_default;
+ pinctrl-1 = cpsw_sleep;
+ status = okay;
+};
+
+davinci_mdio {
+ pinctrl-names = default, sleep;
+ pinctrl-0 = davinci_mdio_default;
+ pinctrl-1 = davinci_mdio_sleep;
+ status = okay;
+};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 0;
+ phy-mode = rgmii;
+};
--
1.9.2.459.g68773ac
--
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] Add DRA7xx CPSW Ethernet support in Device Tree
Tony/Benoit On Tuesday 13 May 2014 01:34 PM, Mugunthan V N wrote: Adding device tree entry for CPSW to make it work in Dual EMAC mode. DRA7 cpsw phy sel driver patch has been pulled in net-next git with the following commit id *d415fa1b88748d664b7b6a310dd8e699d2686cf7* Mugunthan V N (3): pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM arch/arm/boot/dts/dra7-evm.dts| 103 ++ arch/arm/boot/dts/dra7.dtsi | 59 ++ include/dt-bindings/pinctrl/dra.h | 8 +++ 3 files changed, 170 insertions(+) This patch series depends on Cross bar dt patch set http://comments.gmane.org/gmane.linux.drivers.devicetree/73025 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: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock
On Thu, May 8, 2014 at 9:06 AM, Rajendra Nayak rna...@ti.com wrote: Do you mind picking this fix up via the GPIO tree? Yes, it's merged to my devel branch now with the ACKs. Alternatively you could Ack this if you are fine and we can take both Patch 1/2 and Patch 2/2 from this series via the OMAP tree. This probably will not work as I have a set of other changes to this driver in my tree. Patch 2/2 has a dependency on Patch 1/2 and they need to go in in that order else gpio would break. More discussions are here [1]. Tell me if I should prepare an immutable tag on my branch that you can pull in. I want an explicit handshake with the platform maintainer for this kind of stuff. 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 v3 0/5] Add support for SW babble Control
Hi George, On 05/13/2014 10:31 AM, George Cherian wrote: Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. I tested this on a AM33xx platform and don't see any regression at least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE. Anything particular you want me to test as well? Thanks, Daniel -- 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/4] ARM/DT: edma: Get IP configuration from hardware
On 05/13/2014 11:33 AM, Sekhar Nori wrote: On Tuesday 13 May 2014 01:13 PM, Peter Ujfalusi wrote: Hi, We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Peter, to which baseline do these patches apply? I tried applying them to v3.15-rc5 but 1/4 doesn't apply cleanly. It is on top of next-20140509. Now that I looked at my branch, I missed one small patch from the series which could cause the issue (removing the memset from edma_of_parse_dt). I'll resend ASAP with that patch included. Thanks, Sekhar -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] ARM: dts: am4372: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 03a225505126..b9f83b705f4b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -108,9 +108,6 @@
GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
uart0: serial@44e09000 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
The ti,edma-regions; ti,edma-slots and dma-channels in DT are
redundant since the very same information can be obtained from the HW.
The mentioned properties can be removed from the binding document.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 9fbbdb783a72..cf8d0a2d5b33 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -2,11 +2,8 @@ TI EDMA
Required properties:
- compatible : ti,edma3
-- ti,edma-regions: Number of regions
-- ti,edma-slots: Number of slots
- #dma-cells: Should be set to 1
Clients should use a single channel number per DMA request.
-- dma-channels: Specify total DMA channels per CC
- reg: Memory map for accessing module
- interrupt-parent: Interrupt controller the interrupt is routed through
- interrupts: Exactly 3 interrupts need to be specified in the order:
@@ -26,9 +23,6 @@ edma: edma@4900 {
compatible = ti,edma3;
ti,hwmods = tpcc, tptc0, tptc1, tptc2;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
ti,edma-xbar-event-map = 1 12
2 13;
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] ARM: edma: Get IP information from HW when booting with DT
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 128 ++---
1 file changed, 79 insertions(+), 49 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index fade9ada81f8..1a98f3cd4cd9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,16 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5))
#define EDMA_DCHMAP0x0100 /* 64 registers */
-#define CHMAP_EXISTBIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x) ((x 0x70) 4) /* bits 4-6 */
+#define GET_NUM_INTCH(x) ((x 0x700) 8) /* bits 8-10 */
+#define GET_NUM_PAENTRY(x) ((x 0x7000) 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x 0x7) 16) /* bits 16-18 */
+#define GET_NUM_REGN(x)((x 0x30) 20) /* bits 20-21 */
+#define CHMAP_EXISTBIT(24)
+#define MP_EXIST BIT(25)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1415,6 +1424,68 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_info_from_hw(struct device *dev,
+ struct edma_soc_info *pdata)
+{
+ int i;
+ u32 value, cccfg, n_tc;
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
+
+ value = GET_NUM_DMACH(cccfg);
+ pdata-n_channel = BIT(value + 1);
+
+ value = GET_NUM_REGN(cccfg);
+ pdata-n_region = BIT(value);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ pdata-n_slot = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ n_tc = value + 1;
+
+ dev_dbg(dev, eDMA3 HW configuration (cccfg: 0x%08x):\n, cccfg);
+ dev_dbg(dev, n_channel: %u\n, pdata-n_channel);
+ dev_dbg(dev, n_region: %u\n, pdata-n_region);
+ dev_dbg(dev, n_slot: %u\n, pdata-n_slot);
+ dev_dbg(dev, n_tc: %u\n, n_tc);
+
+ pdata-n_cc = 1;
+
+ queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata-queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+
+ pdata-default_queue = 0;
+
+ return 0;
+}
+
#if IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_DMADEVICES)
static int edma_of_read_u32_to_s16_array(const struct device_node *np,
@@ -1483,63 +1554,16 @@ static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
{
- int ret = 0, i;
- u32 value;
+ int ret = 0;
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
-
- ret = of_property_read_u32(node, dma-channels, value);
- if (ret 0)
- return ret;
- pdata-n_channel = value;
-
- ret = of_property_read_u32(node, ti,edma-regions, value);
- if (ret 0)
- return ret;
- pdata-n_region = value;
-
- ret = of_property_read_u32(node, ti,edma-slots, value);
- if (ret 0)
- return ret;
- pdata-n_slot = value;
-
- pdata-n_cc = 1;
rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
if (!rsv_info)
return -ENOMEM;
pdata-rsv = rsv_info;
- queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_tc_map)
- return -ENOMEM;
-
- for (i = 0; i 3; i++) {
- queue_tc_map[i][0] = i;
- queue_tc_map[i][1] = i;
- }
- queue_tc_map[i][0] = -1;
- queue_tc_map[i][1] = -1;
-
- pdata-queue_tc_mapping = queue_tc_map;
-
- queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_priority_map)
- return -ENOMEM;
-
- for (i = 0; i 3; i++) {
-
[PATCH v2 4/5] ARM: dts: am33xx: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index baf56cc92040..5e8f647ee4ec 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -147,9 +147,6 @@
0x44e10f90 0x10;
interrupts = 12 13 14;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
gpio0: gpio@44e07000 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] ARM: edma: No need to clean the pdata in edma_of_parse_dt()
The pdata has been just allocated with devm_kzalloc() in edma_setup_info_from_dt() and passed to this function. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index b9bd42ad2d6e..fade9ada81f8 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1490,8 +1490,6 @@ static int edma_of_parse_dt(struct device *dev, struct edma_rsv_info *rsv_info; s8 (*queue_tc_map)[2], (*queue_priority_map)[2]; - memset(pdata, 0, sizeof(struct edma_soc_info)); - ret = of_property_read_u32(node, dma-channels, value); if (ret 0) return ret; -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] ARM/DT: edma: Get IP configuration from hardware
Hi, Changes sicne v1: - added missing patch to remove the memset from edma_of_parse_dt() We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Regards, Peter --- Peter Ujfalusi (5): ARM: edma: No need to clean the pdata in edma_of_parse_dt() ARM: edma: Get IP information from HW when booting with DT dt/bindings: ti,edma: Remove redundant properties from documentation ARM: dts: am33xx: Remove obsolete properties from edma node ARM: dts: am4372: Remove obsolete properties from edma node Documentation/devicetree/bindings/dma/ti-edma.txt | 6 - arch/arm/boot/dts/am33xx.dtsi | 3 - arch/arm/boot/dts/am4372.dtsi | 3 - arch/arm/common/edma.c| 130 +- 4 files changed, 79 insertions(+), 63 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On 12/05/14 18:51, Tony Lindgren wrote: It's already in v3.15. Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow even acked it :( Looks like there's also the custom mux hacks. And custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev, omap_display_init stuff can be removed when the DT conversion has been done. For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently discussed) I still have no solution, but I haven't spent time on it. I have dropped the omap5 dsi muxing from the latest series for that reason. dispc_disable_outputs and omap_dss_reset are needed because omap_device doesn't handle resetting DSS properly, as special steps need to be done for that. omap_dss_reset is called from the hwmod/omap_device code, so I don't think this code can be anywhere else. For the omap_display_get_version() I have no good solution. Making separate .dts versions for all the needed OMAP ES versions seems like a huge hassle to me, but that is one solution. I think that would mean having separate .dtsi files for omapdss for omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then having separate omap.dtsi files for all of those, and then separate board .dts files for the ES versions used on each board. Or is there some sane way to define such things in dts? _any_ new crap into arch/arm/mach-omap2/display.c. So please consider this a huge eternal NAK to add any more crap to arch/arm/mach-omap2/display.c from me. No more new soc_is beyond the soc_is_am43xx() you have in linux next. No more adding of_find_compatible_node() beyond ti,omap5-dss you have in linux next. And no more new panel remapping in this file as soon as you have found a better solution. Preferrably by v3.17 merge window. This file just needs to disappear. Yuk. Do you object to the compatible string remapping as such, or just that it's in arch/arm/mach-omap2? I guess nothing prevents me from moving it to drivers/, and having some early-ish initcall doing the job. If the remapping as such is horrible, I'm all ears for better ideas. I spent quite a lot of time on it, and that's the best I could come up with. It's rather simple prefixing of the compatible strings for selected devices. The purpose of that is to have proper data in the .dts files (which I think is very important) with the cost of having some rather simple internal hacks in the kernel, which can be removed immediately when we have a common display driver framework. I'm not sure what it would give us to try to be compatible with simple-panel.txt. The simple-panel bindings won't probably be compatible with the future common display drivers in any case, as the simple-panel binding is just too limited and doesn't describe the hardware fully. Hmm what else does a panel need where the existing binding cannot be extended? The existing simple-panel binding doesn't describe the connections of the panel, i.e. its video input. I guess it can be extended, but I don't see what the benefit is of trying to create new panel bindings compatible with the simple-panel bindings. As I see, the simple-panel bindings work only with very limited use cases, where the drivers make assumptions. Simple panel bindings cannot be used with omapdss, nor can it be used with the future common display framework. But I'm not really familiar with using extending current bindings, and making new bindings compatible with old ones. Can you explain why it'd be good to have the sharp panel bindings compatible with simple-panel? In what kind of scenario would it be used? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On Tue, May 13, 2014 at 12:51 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 12/05/14 18:51, Tony Lindgren wrote: It's already in v3.15. Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow even acked it :( Looks like there's also the custom mux hacks. And custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev, omap_display_init stuff can be removed when the DT conversion has been done. For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently discussed) I still have no solution, but I haven't spent time on it. I have dropped the omap5 dsi muxing from the latest series for that reason. dispc_disable_outputs and omap_dss_reset are needed because omap_device doesn't handle resetting DSS properly, as special steps need to be done for that. omap_dss_reset is called from the hwmod/omap_device code, so I don't think this code can be anywhere else. For the omap_display_get_version() I have no good solution. Making separate .dts versions for all the needed OMAP ES versions seems like a huge hassle to me, but that is one solution. I think that would mean having separate .dtsi files for omapdss for omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then having separate omap.dtsi files for all of those, and then separate board .dts files for the ES versions used on each board. Or is there some sane way to define such things in dts? Unfortunately there isn't. I have a similar problem with the IGEP boards since there are just too many variations of them (e.g: DM3730 SoC vs OMAP3530 SoC, NAND vs OneNAND, 256MB vs 512MB flash memory sizes, with and without wifi chip, etc). Since dts are supposed to describe the hardware, each revision with a slighter variation forces to have a different dts. My solution was to not try to have a dts for every single variation in mainline but only one for the most common revision and that could be used as a reference to modify and ship on each device. Unfortunately that is not possible to you since each DSS IP block is used by many boards. _any_ new crap into arch/arm/mach-omap2/display.c. So please consider this a huge eternal NAK to add any more crap to arch/arm/mach-omap2/display.c from me. No more new soc_is beyond the soc_is_am43xx() you have in linux next. No more adding of_find_compatible_node() beyond ti,omap5-dss you have in linux next. And no more new panel remapping in this file as soon as you have found a better solution. Preferrably by v3.17 merge window. This file just needs to disappear. Yuk. Do you object to the compatible string remapping as such, or just that it's in arch/arm/mach-omap2? I guess nothing prevents me from moving it to drivers/, and having some early-ish initcall doing the job. If the remapping as such is horrible, I'm all ears for better ideas. I spent quite a lot of time on it, and that's the best I could come up with. It's rather simple prefixing of the compatible strings for selected devices. The purpose of that is to have proper data in the .dts files (which I think is very important) with the cost of having some rather simple internal hacks in the kernel, which can be removed immediately when we have a common display driver framework. Even though the compatible trick that I said before could be an alternative, it has the problem that does not describes the hardware as you said. The restriction of the DT being a stable API and get it right from the beginning forces us to make these kind of technical decisions. So, since we can change the kernel later but not the DTS, I agree with you that the remapping is the least bad of our options. I'm not sure what it would give us to try to be compatible with simple-panel.txt. The simple-panel bindings won't probably be compatible with the future common display drivers in any case, as the simple-panel binding is just too limited and doesn't describe the hardware fully. Hmm what else does a panel need where the existing binding cannot be extended? The existing simple-panel binding doesn't describe the connections of the panel, i.e. its video input. I guess it can be extended, but I don't see what the benefit is of trying to create new panel bindings compatible with the simple-panel bindings. As I see, the simple-panel bindings work only with very limited use cases, where the drivers make assumptions. Simple panel bindings cannot be used with omapdss, nor can it be used with the future common display framework. But I'm not really familiar with using extending current bindings, and making new bindings compatible with old ones. Can you explain why it'd be good to have the sharp panel bindings compatible with simple-panel? In what kind of scenario would it be used? Tomi Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to
Re: [PATCH v3 0/5] Add support for SW babble Control
On 5/13/2014 3:16 PM, Daniel Mack wrote: Hi George, On 05/13/2014 10:31 AM, George Cherian wrote: Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. I tested this on a AM33xx platform and don't see any regression at least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE. Anything particular you want me to test as well? Are you seeing a wrapper restart done always or does it continue with a restart after the babble condition? You can check for musb_hdrc: setup fifo_mode 4 prints . Thanks, Daniel -- -George -- 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 0/5] Add support for SW babble Control
On 05/13/2014 01:57 PM, George Cherian wrote: On 5/13/2014 3:16 PM, Daniel Mack wrote: On 05/13/2014 10:31 AM, George Cherian wrote: Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. I tested this on a AM33xx platform and don't see any regression at least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE. Anything particular you want me to test as well? Are you seeing a wrapper restart done always or does it continue with a restart after the babble condition? MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns 0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means (babble_ctl MUSB_BABBLE_STUCK_J) is false, and hence sw_babble_control() returns 1. Consequently, the glue is fully reset in this case. Does this help? FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled: [ 54.066124] CAUTION: musb: Babble Interrupt Occurred [ 54.071856] usb 1-1: USB disconnect, device number 8 [ 54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4 [ 54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset I only have one exact USB device to reproduce the babble condition, so I guess this is all I can do for now. Thanks, Daniel -- 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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
Hi Arnd, On Thursday 08 May 2014 02:48 PM, Arnd Bergmann wrote: On Thursday 08 May 2014 18:05:11 Jingoo Han wrote: On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html That is the patch Santosh did for platform devices, which is related but not what I meant here. For the PCI inbound window setup, please have a look at https://lkml.org/lkml/2014/3/19/607 Do you think it can be used for *outbound* window setup too? The problem is the *ranges* property defines both the pci address and cpu address which should have been enough to program the ob translation window, but the hw is designed so that the controller sees only the 28 bits. (The most significant 4 bits is for the l3 to address the controller). Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Tuesday 13 May 2014 18:01:59 Kishon Vijay Abraham I wrote: On Thursday 08 May 2014 02:48 PM, Arnd Bergmann wrote: On Thursday 08 May 2014 18:05:11 Jingoo Han wrote: On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html That is the patch Santosh did for platform devices, which is related but not what I meant here. For the PCI inbound window setup, please have a look at https://lkml.org/lkml/2014/3/19/607 Do you think it can be used for *outbound* window setup too? The problem is the *ranges* property defines both the pci address and cpu address which should have been enough to program the ob translation window, but the hw is designed so that the controller sees only the 28 bits. (The most significant 4 bits is for the l3 to address the controller). I'm not following what the problem is. You should always be able to describe in the inbound window (that is from the CPU perspective) using dma-ranges and the outbound window using ranges. If you have a case where the outbound translation is a 256MB (i.e. 28bit) section of the CPU address space, that could be represented as ranges = 0x8200 0 0 0xb000 0 0x1000; or ranges = 0x8200 0 0xb000 0xb000 0 0x1000; depending on whether you want the BARs to be programmed using a low address 0x0-0x0fff or an address matching the window 0xb000-0xbfff. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 05/12/2014 04:57 PM, Robert Nelson wrote: Either case if fine with me. As who knows when the dtc overlay will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information. Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes. Anybody working on enabling/disabling cape dtb configurations in u-boot? Well, Would Tom even approve of that in mainline u-boot? He didn't want my invert the gpio to enable the usb hub on the older beagle xm A/B.. http://lists.denx.de/pipermail/u-boot/2014-January/172154.html http://lists.denx.de/pipermail/u-boot/2014-January/172274.html I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, etc) sounds like a step in the wrong direction. -- Tom -- 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 0/5] Add support for SW babble Control
On 5/13/2014 5:50 PM, Daniel Mack wrote:
On 05/13/2014 01:57 PM, George Cherian wrote:
On 5/13/2014 3:16 PM, Daniel Mack wrote:
On 05/13/2014 10:31 AM, George Cherian wrote:
Series add support for SW babble control logic found in
new silicon versions of AM335x. Runtime differentiation of
silicon version is done by checking the BABBLE_CTL register.
For newer silicon the register default value read is 0x4 and
for older versions its 0x0.
I tested this on a AM33xx platform and don't see any regression at
least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
Anything particular you want me to test as well?
Are you seeing a wrapper restart done always or does it continue with a
restart
after the babble condition?
MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is
called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns
0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means
(babble_ctl MUSB_BABBLE_STUCK_J) is false, and hence
sw_babble_control() returns 1.
Ah Missed a critical portion
My bad...
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
-- 1.8.3.1
I will resend the series, if this works fine.
Thanks for all your help.
Consequently, the glue is fully reset in
this case. Does this help?
FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled:
[ 54.066124] CAUTION: musb: Babble Interrupt Occurred
[ 54.071856] usb 1-1: USB disconnect, device number 8
[ 54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4
[ 54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I only have one exact USB device to reproduce the babble condition, so I
guess this is all I can do for now.
Same with me also . I also have only one device with which i get the issue.
Thanks,
Daniel
--
-George
--
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 0/5] Add support for SW babble Control
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
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 0/5] Add support for SW babble Control
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an
IP reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of
now to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
Hi Arnd, On Tuesday 13 May 2014 06:17 PM, Arnd Bergmann wrote: On Tuesday 13 May 2014 18:01:59 Kishon Vijay Abraham I wrote: On Thursday 08 May 2014 02:48 PM, Arnd Bergmann wrote: On Thursday 08 May 2014 18:05:11 Jingoo Han wrote: On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html That is the patch Santosh did for platform devices, which is related but not what I meant here. For the PCI inbound window setup, please have a look at https://lkml.org/lkml/2014/3/19/607 Do you think it can be used for *outbound* window setup too? The problem is the *ranges* property defines both the pci address and cpu address which should have been enough to program the ob translation window, but the hw is designed so that the controller sees only the 28 bits. (The most significant 4 bits is for the l3 to address the controller). I'm not following what the problem is. You should always be able to describe in the inbound window (that is from the CPU perspective) using dma-ranges and the outbound window using ranges. If you have a case where the outbound translation is a 256MB (i.e. 28bit) section of the CPU address space, that could be represented as ranges = 0x8200 0 0 0xb000 0 0x1000; or ranges = 0x8200 0 0xb000 0xb000 0 0x1000; depending on whether you want the BARs to be programmed using a low address 0x0-0x0fff or an address matching the window 0xb000-0xbfff. The problem is, for configuring the window starting at 0xb000, the ATU should be programmed 0x000 (the cpu address for it will be 0xb000 though). Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Tuesday 13 May 2014 18:56:23 Kishon Vijay Abraham I wrote: If you have a case where the outbound translation is a 256MB (i.e. 28bit) section of the CPU address space, that could be represented as ranges = 0x8200 0 0 0xb000 0 0x1000; or ranges = 0x8200 0 0xb000 0xb000 0 0x1000; depending on whether you want the BARs to be programmed using a low address 0x0-0x0fff or an address matching the window 0xb000-0xbfff. The problem is, for configuring the window starting at 0xb000, the ATU should be programmed 0x000 (the cpu address for it will be 0xb000 though). Then use the first of the two? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
On 05/13/2014 03:24 PM, George Cherian wrote: Basically, there are 2 types of babble conditions. 1) Transient babble condition - which could be recovered from without an IP reset . 2) Babble condition - which could be recovered from only by doing an IP reset. Ok, thanks for the explanation. Looks like you are always hitting case 2 (Most times am also hitting the same). Seems like, yes. There is no 100% reliable method to force it to happen. Following is my setup , I have a HUB with 4 devices connected , which gives me a Babble interrupt on both connects and disconnects ( Not always though). I also get them at disconnects, but only with one specific USB device. But as I don't ever see case 1) above, I can't say if your approach works. What I can say, though, is that your patches don't break the recovery from babble conditions that I experienced :) Daniel -- 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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Tuesday 13 May 2014 15:27:46 Arnd Bergmann wrote: On Tuesday 13 May 2014 18:56:23 Kishon Vijay Abraham I wrote: If you have a case where the outbound translation is a 256MB (i.e. 28bit) section of the CPU address space, that could be represented as ranges = 0x8200 0 0 0xb000 0 0x1000; or ranges = 0x8200 0 0xb000 0xb000 0 0x1000; depending on whether you want the BARs to be programmed using a low address 0x0-0x0fff or an address matching the window 0xb000-0xbfff. The problem is, for configuring the window starting at 0xb000, the ATU should be programmed 0x000 (the cpu address for it will be 0xb000 though). Then use the first of the two? To clarify: using 0x8200 0 0 0xb000 0 0x1000 will give you a mem_offset of 0xb000, which should work just fine for this case. What I don't understand is why the ATU cares about whether the outbound address is 0x000 or 0xb000 if it just decodes the lower 28 bit anyway. Did you mean that we have to program the BARs using low addresses regardless of what is programmed in the ATU? That would make more sense, and it also matches what I suggested. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
Hi Balbi,
Do you have any comment for this patch?
Thanks
Jincan
On Wed, May 07, 2014 at 05:53:44PM -0400, Zhuang Jin Can wrote:
A delayed status request may be queued before composite framework returns
USB_GADGET_DELAYED_STATUS, because the thread queueing the request can run
on a different core in parallel with the control request irq.
SETUP XferComplete IRQfsg_main_thread
-----
| |
spin_lock_irqsave(dwc-lock) sleeping
| |
... ...
dwc3_ep0_inspect_setup() |
| |
dwc3_ep0_delegate_req() |
| |
... |
spin_unlock(dwc-lock); |
| |
fsg_set_alt() == Signal Wakeup |
| |
other gadgets-set_alt() handle exception
| |
| usb_composite_setup_continue()
| |
| spin_lock_irqsave(dwc-lock)
|__dwc3_gadget_ep0_queue()
|delay_status is false
| spin_unlock_irqrestore(dwc-lock)
| |
|sleeping
spin_lock(dwc-lock);|
| |
delayed_status=true |
| |
STATUS XferNotReady IRQ
|
dwc3_ep0_xfernotready()
|
delayed_status is true, return;
The result is the status packet will never be transferred, and
delayed_status is not cleared.
Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
Reported-by: Zhou Liping liping.z...@intel.com
---
drivers/usb/dwc3/ep0.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 21a3520..07292c0 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -1020,7 +1020,11 @@ static void dwc3_ep0_xfernotready(struct dwc3 *dwc,
if (dwc-delayed_status) {
WARN_ON_ONCE(event-endpoint_number != 1);
dev_vdbg(dwc-dev, Mass Storage delayed status\n);
- return;
+
+ if (list_empty(dwc-eps[0]-request_list))
+ return;
+ else
+ dwc-delayed_status = false;
}
dwc3_ep0_do_control_status(dwc, event);
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
--
Tom
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 05/13/2014 10:06 AM, Javier Martinez Canillas wrote:
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
Sometimes nothing exposes just how big a problem something is (and how
much we need the solution to it) like actually showing the output.
Someone could also start posting the profileN device trees for the
am335x GP EVMs too.
--
Tom
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4-panda-es boot issues with v3.15-rc4
On Tuesday 13 May 2014 04:10 AM, Roger Quadros wrote: On 05/13/2014 01:07 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [140512 14:41]: On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote: * Kevin Hilman khil...@linaro.org [140509 16:46]: Roger Quadros rog...@ti.com writes: Kevin, On 05/09/2014 01:15 AM, Kevin Hilman wrote: Tony Lindgren t...@atomide.com writes: [...] ..but I think I found the cause for recent hangs on panda, just a wild guess based on looking at the recent cpuidle patches after v3.14. Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) makes booting work reliably again on panda. Can you guys confirm, so far no issues here after few boot tests, but it might be too early to tell. Reverting that makes things a bit more stable, but it still eventually fails in the same way. For me it took 8 boots for it to eventually fail. However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable (20+ boots in a row and still going.) Can you please test with CPU_IDLE enabled but C3 disabled as in below patch? It worked for me 10/10 boots. Yup, it worked for me too for 10/10 boots in a row. But what has caused this regression, does it work reliably with let's say v3.13 or v3.12? IIRC things were stable till some CPUIDLE code consolidation happened. I don't recall exactly but some one did discuss about it a while back. OK that's good to hear. Can you re-run your test-cases with patch at end of the email. This is just a hunch so don't blame me if I waste your time testing the patch. Seems to work after adding #include linux/clockchips.h. I did about 10 reboots and they all succeeded for me. Without your revert, I'm getting a hang (with sysrq not working) about 1/3 of the boots. Kevin, Roger, does the revert from Santosh work for you too? next-20140508 worked for me 10/10 times with Santosh's patch. The heartbeat LED behaves normally as well. So I like it :). Great. Will post the patch with change log updated and cc you guys. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
-Matt
Best regards,
Javier
--
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: OMAP4: Fix the boot regression with CPU_IDLE enabled
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.
Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..3e169d9 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
#include linux/cpuidle.h
#include linux/cpu_pm.h
#include linux/export.h
+#include linux/clockchips.h
#include asm/cpuidle.h
#include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
{
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+ int cpu_id = smp_processor_id();
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET)
(cx-mpu_logic_state == PWRDM_POWER_OFF);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -189,8 +195,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
- .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
|
-CPUIDLE_FLAG_TIMER_STOP,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
@@ -199,8 +204,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
.exit_latency = 460 + 518,
.target_residency = 1100,
- .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
|
-CPUIDLE_FLAG_TIMER_STOP,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C3,
.desc = CPUx OFF, MPUSS OSWR,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
Hi, On Tue, May 13, 2014 at 09:45:51PM -0400, Zhuang Jin Can wrote: Hi Balbi, Do you have any comment for this patch? do you have an easy test-case which I can use to validate on my end ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Javier Martinez Canillas jav...@dowhile0.org [140513 04:40]: On Tue, May 13, 2014 at 12:51 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 12/05/14 18:51, Tony Lindgren wrote: It's already in v3.15. Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow even acked it :( Looks like there's also the custom mux hacks. And custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev, omap_display_init stuff can be removed when the DT conversion has been done. Yes great that helps :) For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently discussed) I still have no solution, but I haven't spent time on it. I have dropped the omap5 dsi muxing from the latest series for that reason. OK dispc_disable_outputs and omap_dss_reset are needed because omap_device doesn't handle resetting DSS properly, as special steps need to be done for that. omap_dss_reset is called from the hwmod/omap_device code, so I don't think this code can be anywhere else. OK that we should be able to do with drivers/reset eventually. The reset and idle of drivers is also needed for unused devices too, so we can't have drivers do it in those cases. For the omap_display_get_version() I have no good solution. Making separate .dts versions for all the needed OMAP ES versions seems like a huge hassle to me, but that is one solution. I think that would mean having separate .dtsi files for omapdss for omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then having separate omap.dtsi files for all of those, and then separate board .dts files for the ES versions used on each board. Or is there some sane way to define such things in dts? Unfortunately there isn't. I have a similar problem with the IGEP boards since there are just too many variations of them (e.g: DM3730 SoC vs OMAP3530 SoC, NAND vs OneNAND, 256MB vs 512MB flash memory sizes, with and without wifi chip, etc). Since dts are supposed to describe the hardware, each revision with a slighter variation forces to have a different dts. My solution was to not try to have a dts for every single variation in mainline but only one for the most common revision and that could be used as a reference to modify and ship on each device. Unfortunately that is not possible to you since each DSS IP block is used by many boards. Well ideally the revision info for a device would come from device revision registers rather using the SoC revision. In the DSS case when the SoC revision is needed by a device it maybe it can be deciphered from a combination of compatible flag and the clock rate for example? But yeah I agree we still need revision detection in the kernel rather than try to create separate .dtsi files for sub-revisions. _any_ new crap into arch/arm/mach-omap2/display.c. So please consider this a huge eternal NAK to add any more crap to arch/arm/mach-omap2/display.c from me. No more new soc_is beyond the soc_is_am43xx() you have in linux next. No more adding of_find_compatible_node() beyond ti,omap5-dss you have in linux next. And no more new panel remapping in this file as soon as you have found a better solution. Preferrably by v3.17 merge window. This file just needs to disappear. Yuk. Do you object to the compatible string remapping as such, or just that it's in arch/arm/mach-omap2? It's something I'd rather not have under mach-omap2 as that means that I may need to deal with it too to some extent. And I don't think we need to do such remapping, we should be able to use the panel compatible strings as they are just fine. It should be possible to figure out from the device tree properties what controller the panel belongs to. Or for now, use the panel registration to figure out what display controller it belongs to. I guess nothing prevents me from moving it to drivers/, and having some early-ish initcall doing the job. /me likes this idea if you need it at all. Stuff like this tends to stay and spread, so I'd rather not do the remapping of compatible strings at all. If the remapping as such is horrible, I'm all ears for better ideas. I spent quite a lot of time on it, and that's the best I could come up with. It's rather simple prefixing of the compatible strings for selected devices. The purpose of that is to have proper data in the .dts files (which I think is very important) with the cost of having some rather simple internal hacks in the kernel, which can be removed immediately when we have a common display driver framework. Even though the compatible trick that I said before could be an alternative, it has the problem that does not describes the hardware as you said. The restriction of the DT being a stable API and get it right from the beginning forces us to make these kind of technical decisions. So, since we can
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Tomi Valkeinen tomi.valkei...@ti.com [140512 07:45]: On 12/05/14 17:39, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140512 04:36]: On 09/05/14 17:37, Tony Lindgren wrote: This is just the 3730-evm with the Sharp VGA panel mentioned in this series. Hmm, well, those both look fine. The fck is well below the maximum, which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher with this patch, but that should affect the GFX overlay. So you're just booting, and there are no applications that use the framebuffer? And there is no rotation or such configured? Right. The rotation is set to 3 though. Hmm, that's probably the issue then. VRFB rotation is very heavy on the memory bandwidth, and is generally a very easy way to get sync lost errors. I found another case without rotation where the error always triggers. By forcing 3730-evm LCD panel to QVGA mode it always seems to happen even without rotation. Without this patch with errors and no image: # cat /sys/kernel/debug/omapdss/clk [ 55.185729] DSS: dss_runtime_get [ 55.189422] DSS: dss_runtime_put [ 55.192810] DISPC: dispc_runtime_get [ 55.196685] DISPC: dispc_runtime_put - DSS - DSS_FCK (DSS1_ALWON_FCLK) = 2700 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck 2700 - LCD - LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) lck 2700lck div 1 pck 540 pck div 5 With this patch without errors and penguin showing: # cat /sys/kernel/debug/omapdss/clk [ 19.905792] DSS: dss_runtime_get [ 19.909545] DSS: dss_runtime_put [ 19.912933] DISPC: dispc_runtime_get [ 19.916778] DISPC: dispc_runtime_put - DSS - DSS_FCK (DSS1_ALWON_FCLK) = 10800 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck 10800 - LCD - LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) lck 10800 lck div 1 pck 540 pck div 20 In this case the errors are different too: DISPC: channel 0 xres 240 yres 320 DISPC: pck 540 DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7 DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge 0 DISPC: hsync 18947Hz, vsync 57Hz DISPC: lck = 2700 (1) DISPC: pck = 540 (5) APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST DISPC: dispc_runtime_get omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay Regarding rotation, it does look like that with VGA mode enabling rotation makes the error trigger quite often on 3730. will handle it fine with the clock rates and bandwidth usage you have for your use cases. I don't think it's all because of rotation. And rotating my head makes my neck hurt! 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 4/8] usb: phy: fix isp1301-omap dependency on tps65010
On Thu, May 08, 2014 at 03:52:17PM +0200, Arnd Bergmann wrote:
The isp1301-omap driver cannot be built-in if the tps65010 driver
is a module, otherwise we get a link error from the reference to
the tps65010_set_vbus_draw function.
There is already a hack in the driver to work around the problem
of tps65010 being not available at all. This patch extends that
hack to ensure that the real tps65010_set_vbus_draw() function
is only called when it's avaiable.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-omap@vger.kernel.org
---
drivers/usb/phy/phy-isp1301-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 6e146d7..35a0dd2 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -94,7 +94,7 @@ struct isp1301 {
#if defined(CONFIG_MACH_OMAP_H2) || defined(CONFIG_MACH_OMAP_H3)
-#if defined(CONFIG_TPS65010) || defined(CONFIG_TPS65010_MODULE)
+#if defined(CONFIG_TPS65010) || (defined(CONFIG_TPS65010_MODULE)
defined(MODULE))
nack, I would rather see a real fix, possibly also fixing the original
hack.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
On Tue, May 13, 2014 at 10:05:34AM -0500, Felipe Balbi wrote: Hi, On Tue, May 13, 2014 at 09:45:51PM -0400, Zhuang Jin Can wrote: Hi Balbi, Do you have any comment for this patch? do you have an easy test-case which I can use to validate on my end ? The issue was reproduced on a multi-core platform with f_mass_storage and adb (f_fs gadget) enabled. The enumeration will fail when it's connected to PC via USB2 cable. You may not be able to use adb (I think), but do replacing it with some other gadgets (e.g.f_rndis). And f_mass_storage gadget should be the first interface in the composite device (this is important to larger the chance to reproduce the issue, the delayed status request will be queued while irq is still enabling other endpoints of other gadgets). Best Regards Jincan -- 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: RCU stall on panda
* Alex Shi alex@linaro.org [140512 23:37]: On 05/13/2014 05:21 AM, Tony Lindgren wrote: * Paul E. McKenney paul...@linux.vnet.ibm.com [140505 11:11]: On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: I keep seeing the RCU stall problem on panda board from 3.10 kernel to latest upstream kernel and google find some one report it before: https://lkml.org/lkml/2012/9/20/519 Is it the hardware issue or a real software problem? I cannot distinguish between hardware and software from the trace below, but given that you are also seeing a soft lockup, either way you do appear to have a real problem as opposed to an RCU CPU stall warning false positive. Looks like you have CPU_IDLE enabled on panda. Hangs with current linux next with CPU_IDLE are currently being discussed on the linux-omap list in thread omap4-panda-es boot issues with v3.15-rc4 I've seen occasional system hangs, and I've also noticed that doing ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system producing similar errors to the below. Thanks a lot for the info. In fact, the oops keeps in upstream kernel from 3.10 to latest. Care to test if the revert of commit cb7094 Santosh posted as [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled solves the problem for you? 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 5/5] usb: dwc3: dwc3-omap: Disable/Enable core interrupts in Suspend/Resume
Hi, On Thu, May 08, 2014 at 03:03:07PM +0530, George Cherian wrote: Enabling the core interrupts in complete is too late for XHCI, and stops xhci from proper operation. So remove prepare and complete and disable/enable isn't this a bug in xhci ? I mean the driver should make no assumption as to when IRQs are enabled, why do we need to enable IRQs earlier when the device is only considered ready for use after -complete() finishes executing ? From documentation we have: 107 * @complete: Undo the changes made by @prepare(). This method is executed for 108 * all kinds of resume transitions, following one of the resume callbacks: 109 * @resume(), @thaw(), @restore(). Also called if the state transition 110 * fails before the driver's suspend callback: @suspend(), @freeze() or 111 * @poweroff(), can be executed (e.g. if the suspend callback fails for one 112 * of the other devices that the PM core has unsuccessfully attempted to 113 * suspend earlier). 114 * The PM core executes subsystem-level @complete() after it has executed 115 * the appropriate resume callbacks for all devices. which tells me that using -complete() to reenable IRQs is ok here. Specially when you consider that the role of -prepare() is to prevent new children from being created and, for a USB host, that means we should prevent hub port changes. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset function
Hi,
On Thu, May 08, 2014 at 03:03:03PM +0530, George Cherian wrote:
Calculate the wrapper register offsets in a seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 80
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 1160ff4..872f065 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -383,6 +383,49 @@ static int dwc3_omap_vbus_notifier(struct notifier_block
*nb,
return NOTIFY_DONE;
}
+static void dwc3_omap_map_offset(struct dwc3_omap *omap)
+{
+ u32 reg;
+ struct device_node *node = omap-dev-of_node;
+ int x_major;
+
+ reg = dwc3_omap_readl(omap-base, USBOTGSS_REVISION);
+ omap-revision = reg;
+ x_major = USBOTGSS_REVISION_XMAJOR(reg);
+
+ /* Differentiate between OMAP5 and AM437x */
+ switch (x_major) {
+ case USBOTGSS_REVISION_XMAJOR1:
+ case USBOTGSS_REVISION_XMAJOR2:
+ omap-irq_eoi_offset = 0;
+ omap-irq0_offset = 0;
+ omap-irqmisc_offset = 0;
+ omap-utmi_otg_offset = 0;
+ omap-debug_offset = 0;
+ break;
+ default:
+ /* Default to the latest revision */
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ break;
+ }
+
+ /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+ * changes in wrapper registers, Using dt compatible for aegis
+ */
+
+ if (of_device_is_compatible(node, ti,am437x-dwc3)) {
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ }
can you add a patch before $subject which gets rid of the switch
statement above since it's pretty much useless now that we use
compatible strings to differentiate omap5 and am437x ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: am335x-evm: fix comments for lcd pins
* Uwe Kleine-König u.kleine-koe...@pengutronix.de [140511 23:04]: Hi Wolfram, On Fri, May 09, 2014 at 05:15:50PM +0200, Wolfram Sang wrote: From: Wolfram Sang w...@sang-engineering.com In the comments, LCD pins 16-23 were numbered in the wrong order. Fix this and use proper pinmux constants for all entries while we are Your sentence misses a word at the I'll fix and apply it into Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works absolutely
fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.
Let me explain, the point is for people to easily design capes, open-source
their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate his own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.
The notion of hardware as something static that never changes is obsolete IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
-Matt
Best regards,
Javier
Regards
-- Pantelis
--
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+: Add support for RNG on DT booted N900
* Sebastian Reichel s...@kernel.org [140508 12:55]: Hi, On Mon, Apr 07, 2014 at 02:28:46PM +0200, Sebastian Reichel wrote: Add support for OMAP3 ROM Random Number Generator via pdata-quirks. ping Thanks applying into omap-for-v3.16/board. 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 7/7] dts: dra7-evm: add USB support
* Roger Quadros rog...@ti.com [140505 02:55]:
Add USB pinmux information and USB modes
for the USB controllers.
CC: Benoît Cousson bcous...@baylibre.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..1d77815 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,18 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ usb1_pins: pinmux_usb1_pins {
+pinctrl-single,pins =
+ 0x280 0xc /* usb1_drvvbus, SLOW_SLEW | PULLUPEN |
MODE0 */
+;
+};
+
+ usb2_pins: pinmux_usb2_pins {
+pinctrl-single,pins =
+ 0x284 0xc /* usb2_drvvbus, SLOW_SLEW | PULLUPEN |
MODE0 */
+;
+};
};
Looks like these should use the existing defins PIN_INPUT_SLEW etc?
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 1/1] ARM: dts: am437x-gp-evm: Add ethernet support for GP EVM
* Mugunthan V N mugunthan...@ti.com [140507 02:31]:
Add CPSW ethernet support for AM437x GP EVM which has one slave pinned out
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 72
+
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 2e0c636..30ace1b 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,6 +98,58 @@
0x264 (PIN_INPUT_PULLUP | MUX_MODE7) /*
spi2_d0.gpio3_22 */
;
};
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txen.rgmii1_txen */
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxdv.rgmii1_rxctl */
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_txd3 */
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_txd2 */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_txd1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_txd0 */
+ 0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txclk.rmii1_tclk */
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxclk.rmii1_rclk */
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rxd3 */
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rxd2 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rxd0 */
+ ;
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 reset value */
+ 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
Just a nitpick comment to make things more readable. Can you please add
the comments for these pins too so people can cross check them against
the documentation easier?
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ ;
+ };
+
+ davinci_mdio_sleep: davinci_mdio_sleep {
+ pinctrl-single,pins =
+ /* MDIO reset value */
+ 0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
};
And here too please.
Thanks,
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 v4 1/6] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Pekon Gupta pe...@ti.com [140509 13:41]:
+gpmc {
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0 0x0100;/* CS0: NAND */
+ nand@0,0 {
+ reg = 0 0 0x380; /* CS0, offset=0x0, reg-map size=0x380 */
Just noticed this, can you please use the comments I suggested
here too?
That way we know which ones we've fixed up and can also
grep easier eventually to unify the GPMC mappings a bit.
Thanks,
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 v4 5/6] ARM: dts: am43x-epos-evm: fix reg and range property of GPMC NAND node
* Pekon Gupta pe...@ti.com [140509 13:48]:
1) NAND device memory is not directly accessible to CPU, its indirectly
accessed
via registers. So the 'reg' property for GPMC NAND nodes should be limited
to
address range of internal GPMC registers only.
2) Also, minimum granularity of address space under a GPMC chip-select is 16MB
so 'range' property for GPMC NAND node should specify 16MB as its
memory-size
3) On AM437x, address map of external memory accessible via GPMC starts from
0x0
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index fd29930..63a6a59 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -287,9 +287,9 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = nand_flash_x8;
- ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ ranges = 0 0 0 0x100; /* CS0: NAND */
nand@0,0 {
- reg = 0 0 0; /* CS0, offset 0 */
+ reg = 0 0 0x380; /* CS0, offset=0, re-map size=0x380 */
ti,nand-ecc-opt = bch8;
ti,elm-id = elm;
nand-bus-width = 8;
Here too let's use the standard comments while fixing up the GPMC
ranges.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works absolutely
fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.
Let me explain, the point is for people to easily design capes, open-source
their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate his own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.
The notion of hardware as something static that never changes is obsolete
IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not something that a newbie could do
it neither.
Also, doing these FDT changes in the bootloader has several
disadvantages, besides having to implement on each bootloaders like
Tom said, you need to upgrade your
Re: [PATCH v3 0/5] Add support for SW babble Control
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] PM / OPP: move cpufreq specific helpers out of OPP layer
On Mon, May 5, 2014 at 7:03 PM, Nishanth Menon n...@ti.com wrote: CPUFreq usage of OPP should be independent of the ordering of type of data storage inside OPP layer. The current operations can equally be performed by generic operations. [RFC]: https://patchwork.kernel.org/patch/4100811/ Series based on: v3.15-rc1 Nishanth Menon (2): PM / OPP: Remove cpufreq wrapper dependency on internal data organization PM / OPP: Move cpufreq specific OPP functions out of generic OPP library Documentation/cpu-freq/core.txt | 29 +++ Documentation/power/opp.txt | 40 ++ drivers/base/power/opp.c| 91 drivers/cpufreq/Makefile|2 + drivers/cpufreq/cpufreq_opp.c | 110 +++ include/linux/cpufreq.h | 21 include/linux/pm_opp.h | 20 --- 7 files changed, 167 insertions(+), 146 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_opp.c Works fine on Exynos. Tested-by: Thomas Abraham thomas...@samsung.com -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] usb: phy: fix isp1301-omap dependency on tps65010
On Tuesday 13 May 2014 10:26:31 Felipe Balbi wrote:
On Thu, May 08, 2014 at 03:52:17PM +0200, Arnd Bergmann wrote:
The isp1301-omap driver cannot be built-in if the tps65010 driver
is a module, otherwise we get a link error from the reference to
the tps65010_set_vbus_draw function.
There is already a hack in the driver to work around the problem
of tps65010 being not available at all. This patch extends that
hack to ensure that the real tps65010_set_vbus_draw() function
is only called when it's avaiable.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-omap@vger.kernel.org
---
drivers/usb/phy/phy-isp1301-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 6e146d7..35a0dd2 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -94,7 +94,7 @@ struct isp1301 {
#if defined(CONFIG_MACH_OMAP_H2) || defined(CONFIG_MACH_OMAP_H3)
-#if defined(CONFIG_TPS65010) || defined(CONFIG_TPS65010_MODULE)
+#if defined(CONFIG_TPS65010) || (defined(CONFIG_TPS65010_MODULE)
defined(MODULE))
nack, I would rather see a real fix, possibly also fixing the original
hack.
Any suggestion how?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] usb: phy: fix isp1301-omap dependency on tps65010
Hi,
On Tue, May 13, 2014 at 09:48:27PM +0200, Arnd Bergmann wrote:
On Tuesday 13 May 2014 10:26:31 Felipe Balbi wrote:
On Thu, May 08, 2014 at 03:52:17PM +0200, Arnd Bergmann wrote:
The isp1301-omap driver cannot be built-in if the tps65010 driver
is a module, otherwise we get a link error from the reference to
the tps65010_set_vbus_draw function.
There is already a hack in the driver to work around the problem
of tps65010 being not available at all. This patch extends that
hack to ensure that the real tps65010_set_vbus_draw() function
is only called when it's avaiable.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-omap@vger.kernel.org
---
drivers/usb/phy/phy-isp1301-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 6e146d7..35a0dd2 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -94,7 +94,7 @@ struct isp1301 {
#if defined(CONFIG_MACH_OMAP_H2) || defined(CONFIG_MACH_OMAP_H3)
-#if defined(CONFIG_TPS65010) || defined(CONFIG_TPS65010_MODULE)
+#if defined(CONFIG_TPS65010) || (defined(CONFIG_TPS65010_MODULE)
defined(MODULE))
nack, I would rather see a real fix, possibly also fixing the original
hack.
Any suggestion how?
well, that driver shouldn't depend on a particular PMIC. It should use
regulator framework to enable and disable vbus regulator, to start with.
In fact, isp1301-omap.c shouldn't even exist. isp1301 is a generic
device and not OMAP-specific.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org
wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas
wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc
overlay will
every truly make it mainline, as the capemgr was the only real
kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be
used
to toggle it while waiting for the capemgr. That's because the
board
has a header for pins, so it's not exactly limited to just the
capes.
Anybody working on enabling/disabling cape dtb configurations in
u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want
my
invert the gpio to enable the usb hub on the older beagle xm
A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying
to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different,
then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive
someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox,
UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works
absolutely fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS
for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.
Let me explain, the point is for people to easily design capes,
open-source their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate his
own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about
dynamic
hardware configuration. There are a number of FPGA people that seem
interested
as well.
The notion of hardware as something static that never changes is
obsolete IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not something that a newbie could do
it neither.
Also, doing these FDT changes in the bootloader has several
disadvantages, besides having to
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tony Lindgren t...@atomide.com [140509 08:31]:
* Tomi Valkeinen tomi.valkei...@ti.com [140509 01:31]:
On 09/05/14 02:33, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140507 11:00]:
* Tomi Valkeinen tomi.valkei...@ti.com [140507 09:03]:
On 07/05/14 18:03, Tony Lindgren wrote:
BTW, I'm also personally fine with all five gpios showing in a single
gpios property, I'm not too exited about naming anything in DT..
I don't have a strong opinion here. I don't have much experience with
DT, especially with making bindings compatible with other ones.
I'd just forget the simple-panel, and have single gpio array.
Well if it's a don't care flag for both of us, let's try to use
the existing standard for simple-panel.txt and add mode-gpios
property. I'll post a patch for that.
Here's an updated version using enable-gpios, reset-gpios and
mode-gpios. So it follows simple-panel.txt and adds mode-gpios
that's currently specific to this panel only.
Also updated for -EPROBE_DEFER handling, tested that by changing
one of the GPIOs to be a twl4030 GPIO.
To speed things up a bit, I made the changes I suggested. Compile tested
only.
OK thanks did not get the penguin with it so need to look at it a bit
more.
Here's this patch updated again for QVGA and VGA support and to use
your panel remapping. I've also made sure the blanking works properly
on evm-37xx and ldp.
Regards,
Tony
8
From: Tony Lindgren t...@atomide.com
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
Add device tree support for sharp-ls037v7dw01 panel.
Note that this patch is using the remapping of the compatible
flag as implemented by Tomi (that I do not like), but seems
like that's currently needed to avoid redoing the panel
bindings later on. And for the record, that has been agreed
to be a temporary measure until the generic display bindings
can be used by DSS.
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,44 @@
+SHARP LS037V7DW01 TFT-LCD panel
+===
+
+Required properties:
+- compatible: sharp,ls037v7dw01
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin
+ this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+ this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example
+---
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+ compatible = sharp,ls037v7dw01;
+ power-supply = lcd_3v3;
+ enable-gpios = gpio5 24 GPIO_ACTIVE_HIGH;/* gpio152, lcd INI */
+ reset-gpios = gpio5 27 GPIO_ACTIVE_HIGH; /* gpio155, lcd RESB */
+ mode-gpios = gpio5 26 GPIO_ACTIVE_HIGH/* gpio154, lcd MO */
+ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+};
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -562,6 +562,7 @@ static const char * const dss_compat_conv_list[]
__initconst = {
hdmi-connector,
panel-dpi,
panel-dsi-cm,
+ sharp,ls037v7dw01,
sony,acx565akm,
svideo-connector,
ti,tfp410,
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
#include linux/delay.h
#include linux/gpio.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/slab.h
-
+#include linux/regulator/consumer.h
#include video/omapdss.h
#include video/omap-panel-data.h
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
+ struct regulator *vcc;
int data_lines;
@@ -31,9 +34,33 @@ struct panel_drv_data {
struct gpio_desc *mo_gpio; /* low = 480x640, high = 240x320 */
struct gpio_desc *lr_gpio; /* high = conventional horizontal
scanning */
struct gpio_desc *ud_gpio; /* high = conventional vertical
scanning */
+
+#define SHARP_LS_QVGA (1 0)
+ u32 flags;
+};
+
Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
* Tony Lindgren t...@atomide.com [140509 08:38]:
* Tomi Valkeinen tomi.valkei...@ti.com [140509 00:08]:
On 09/05/14 02:36, Tony Lindgren wrote:
Why always-on?
Oops, yeah that should not be there. The GPIO is board specific.
Oops, on ldp the regulator is always on tps61130rsa enabled by
twl4030 regen. Here's the updated patch with ldp support fixed
for the GPIOs tested with blank and bl_power.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Thu, 8 May 2014 17:55:32 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for
omap3-evm and ldp
Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = vdds_dsi
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = vpll2.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+dss {
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins1
+ dss_dpi_pins2
+ ;
+};
+
omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /*
dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /*
dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /*
dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /*
dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /*
dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /*
dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /*
dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /*
dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /*
dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /*
dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /*
dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /*
dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /*
dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /*
dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /*
dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /*
dss_data17.dss_data17 */
+
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3) /*
dss_data18.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3) /*
dss_data19.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3) /*
dss_data20.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3) /*
dss_data21.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3) /*
dss_data22.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /*
dss_data23.dss_data5 */
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
};
};
+omap3_pmx_wkup {
+ dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+ pinctrl-single,pins =
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18
*/
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19
*/
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20
*/
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21
*/
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22
*/
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23
*/
+ ;
+ };
+};
+
mmc1 {
pinctrl-names = default;
[PATCH v2 0/7] mfd: twl4030-power: Enable off-idle configuration when booted with device tree
Hi, Here's an updated set of patches to enable low-power idle modes for some omap3 boards when booted with device tree. This series when applied on top of the patches in tread [PATCH 00/11] Fixes for omap PM for making omap3 DT only, or omap-for-v3.16/pm branch. Lee, if these patches look OK to you, please feel free to pick them, preferrably to the immutable branch you already have set up so I can also merge them in to be able to have things working in my branch properly for PM. Regards, Tony Tony Lindgren (7): mfd: twl4030-power: Fix hang on reboot if sleep configuration was loaded earlier mfd: twl4030-power: Fix some defines for SW_EVENTS mfd: twl4030-power: Add generic reset configuration mfd: twl4030-power: Add recommended idle configuration mfd: twl4030-power: Add support for board specific configuration mfd: twl4030power: Add a configuration to turn off oscillator during off-idle ARM: dts: Enable twl4030 off-idle configuration for selected omaps .../devicetree/bindings/mfd/twl4030-power.txt | 17 +- arch/arm/boot/dts/omap3-beagle-xm.dts | 6 + arch/arm/boot/dts/omap3-evm-common.dtsi| 7 + arch/arm/boot/dts/omap3-n900.dts | 5 + drivers/mfd/twl4030-power.c| 269 +++-- include/linux/i2c/twl.h| 4 + 6 files changed, 284 insertions(+), 24 deletions(-) -- 1.8.1.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 4/7] mfd: twl4030-power: Add recommended idle configuration
These settings are based on the Recommended Sleep Sequences for
the Zoom Platform pdf at:
http://omappedia.com/wiki/File:Recommended_Sleep_Sequences_Zoom.pdf
These settings assume most of the regulators are under control of
Linux, and twl4030 only cuts off VDD1 and VDD2 during off-idle as
Linux cannot do it.
For any board specific changes to these, let's patch them in as
changes to the generic data in the follow-up patches. This keeps
the board specific changes small.
Note that this does not consider the twl5030 errata 27 and 28.
That can be added later on after it has been tested. For more
information about errata 27 and 28, please see:
https://github.com/openembedded/openembedded/blob/master/recipes/linux/linux-omap-2.6.39/mfd/0012-MFD-TWL4030-workaround-changes-for-Erratum-27.patch
Cc: Peter De Schrijver pdeschrij...@nvidia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/mfd/twl4030-power.txt | 4 +
drivers/mfd/twl4030-power.c| 103 +
2 files changed, 107 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b906116..bbd6603 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -8,10 +8,14 @@ Required properties:
- compatible : must be one of the following
ti,twl4030-power
ti,twl4030-power-reset
+ ti,twl4030-power-idle
The use of ti,twl4030-power-reset is recommended at least on
3530 that needs a special configuration for warm reset to work.
+When using ti,twl4030-power-idle, the TI recommended configuration
+for idle modes is loaded to the tlw4030 PMIC.
+
Optional properties:
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
SLEEP-to-OFF transition when the system poweroffs.
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index b61b725..392 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -139,19 +139,32 @@ enum {
TWL_REMAP_ACTIVE = 9,
};
+#define TWL_DEV_GRP_P123 (DEV_GRP_P1 | DEV_GRP_P2 | DEV_GRP_P3)
#define TWL_RESOURCE_ON(res) \
{ MSG_SINGULAR(DEV_GRP_NULL, (res), RES_STATE_ACTIVE), 0x02 }
#define TWL_RESOURCE_OFF(res) \
{ MSG_SINGULAR(DEV_GRP_NULL, (res), RES_STATE_OFF), 0x02 }
#define TWL_RESOURCE_RESET(res)
\
{ MSG_SINGULAR(DEV_GRP_NULL, (res), RES_STATE_WRST), 0x02 }
+#define TWL_RESOURCE_SET_ACTIVE(res, state)\
+ { MSG_SINGULAR(DEV_GRP_NULL, (res), RES_STATE_ACTIVE), (state) }
#define TWL_RESOURCE_GROUP_RESET(group, type1, type2) \
{ MSG_BROADCAST(DEV_GRP_NULL, (group), (type1), (type2),\
RES_STATE_WRST), 0x02 }
+#define TWL_RESOURCE_GROUP_SLEEP(group, type, type2) \
+ { MSG_BROADCAST(DEV_GRP_NULL, (group), (type), (type2), \
+ RES_STATE_SLEEP), 0x02 }
+#define TWL_RESOURCE_GROUP_ACTIVE(group, type, type2) \
+ { MSG_BROADCAST(DEV_GRP_NULL, (group), (type), (type2), \
+ RES_STATE_ACTIVE), 0x02 }
#define TWL_REMAP_SLEEP(res, devgrp, typ, typ2)
\
{ .resource = (res), .devgroup = (devgrp), \
.type = (typ), .type2 = (typ2), \
.remap_off = TWL_REMAP_OFF, .remap_sleep = TWL_REMAP_SLEEP, }
+#define TWL_REMAP_OFF(res, devgrp, typ, typ2) \
+ { .resource = (res), .devgroup = (devgrp), \
+ .type = (typ), .type2 = (typ2), \
+ .remap_off = TWL_REMAP_OFF, .remap_sleep = TWL_REMAP_OFF, }
static int twl4030_write_script_byte(u8 address, u8 byte)
{
@@ -628,11 +641,101 @@ static struct twl4030_power_data omap3_reset = {
.resource_config= omap3_rconfig,
};
+/* Recommended generic default idle configuration for off-idle */
+
+/* Broadcast message to put res to sleep */
+static struct twl4030_ins omap3_idle_sleep_on_seq[] = {
+ TWL_RESOURCE_GROUP_SLEEP(RES_GRP_ALL, RES_TYPE_ALL, 0),
+};
+
+static struct twl4030_script omap3_idle_sleep_on_script = {
+ .script = omap3_idle_sleep_on_seq,
+ .size = ARRAY_SIZE(omap3_idle_sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/* Broadcast message to put res to active */
+static struct twl4030_ins omap3_idle_wakeup_p12_seq[] = {
+ TWL_RESOURCE_GROUP_ACTIVE(RES_GRP_ALL, RES_TYPE_ALL, 0),
+};
+
+static struct twl4030_script omap3_idle_wakeup_p12_script = {
+ .script = omap3_idle_wakeup_p12_seq,
[PATCH 3/7] mfd: twl4030-power: Add generic reset configuration
The twl4030 PMIC needs to be configured properly for things like
warm reset and deeper idle states so the PMIC manages the regulators
properly based on the hardware triggers from the SoC.
For example, when rebooting an OMAP3530 at 125 MHz, it hangs.
With this patch, TWL4030 will be reset when a warm reset occures.
This way the OMAP3530 does not hang on reboot.
Let's use this as the default when compatible = ti,twl4030-power.
Other more complicated configurations can be added to the driver
based on other compatible flags.
Based on earlier patch by Matthias Brugger matthias@gmail.com:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/144165.html
And Lesly A M lesl...@ti.com:
https://github.com/openembedded/openembedded/blob/master/recipes/linux/linux-omap-2.6.39/mfd/0010-MFD-TWL4030-power-scripts-for-OMAP3-boards.patch
For more information about twl4030 configuration for the
power scripts see:
http://www.omappedia.com/wiki/TWL4030_power_scripts
Cc: Matthias Brugger matthias@gmail.com
Cc: Robert Nelson robertcnel...@gmail.com
Cc: Peter De Schrijver pdeschrij...@nvidia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/mfd/twl4030-power.txt | 7 +-
drivers/mfd/twl4030-power.c| 99 +++---
include/linux/i2c/twl.h| 3 +
3 files changed, 95 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index 8e15ec3..b906116 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -5,7 +5,12 @@ to control the power resources, including power scripts. For
now, the
binding only supports the complete shutdown of the system after poweroff.
Required properties:
-- compatible : must be ti,twl4030-power
+- compatible : must be one of the following
+ ti,twl4030-power
+ ti,twl4030-power-reset
+
+The use of ti,twl4030-power-reset is recommended at least on
+3530 that needs a special configuration for warm reset to work.
Optional properties:
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index c0e4fc3..b61b725 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -29,6 +29,7 @@
#include linux/i2c/twl.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_device.h
#include asm/mach-types.h
@@ -128,6 +129,30 @@ static u8 res_config_addrs[] = {
[RES_MAIN_REF] = 0x94,
};
+/*
+ * Usable values for .remap_sleep and .remap_off
+ * Based on table 5.3.3 Resource Operating modes
+ */
+enum {
+ TWL_REMAP_OFF = 0,
+ TWL_REMAP_SLEEP = 8,
+ TWL_REMAP_ACTIVE = 9,
+};
+
+#define TWL_RESOURCE_ON(res) \
+ { MSG_SINGULAR(DEV_GRP_NULL, (res), RES_STATE_ACTIVE), 0x02 }
+#define TWL_RESOURCE_OFF(res) \
+ { MSG_SINGULAR(DEV_GRP_NULL, (res), RES_STATE_OFF), 0x02 }
+#define TWL_RESOURCE_RESET(res)
\
+ { MSG_SINGULAR(DEV_GRP_NULL, (res), RES_STATE_WRST), 0x02 }
+#define TWL_RESOURCE_GROUP_RESET(group, type1, type2) \
+ { MSG_BROADCAST(DEV_GRP_NULL, (group), (type1), (type2),\
+ RES_STATE_WRST), 0x02 }
+#define TWL_REMAP_SLEEP(res, devgrp, typ, typ2)
\
+ { .resource = (res), .devgroup = (devgrp), \
+ .type = (typ), .type2 = (typ2), \
+ .remap_off = TWL_REMAP_OFF, .remap_sleep = TWL_REMAP_SLEEP, }
+
static int twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -502,7 +527,8 @@ int twl4030_remove_script(u8 flags)
return err;
}
-static int twl4030_power_configure_scripts(struct twl4030_power_data *pdata)
+static int
+twl4030_power_configure_scripts(const struct twl4030_power_data *pdata)
{
int err;
int i;
@@ -518,7 +544,8 @@ static int twl4030_power_configure_scripts(struct
twl4030_power_data *pdata)
return 0;
}
-static int twl4030_power_configure_resources(struct twl4030_power_data *pdata)
+static int
+twl4030_power_configure_resources(const struct twl4030_power_data *pdata)
{
struct twl4030_resconfig *resconfig = pdata-resource_config;
int err;
@@ -550,7 +577,7 @@ void twl4030_power_off(void)
pr_err(TWL4030 Unable to power off\n);
}
-static bool twl4030_power_use_poweroff(struct twl4030_power_data *pdata,
+static bool twl4030_power_use_poweroff(const struct twl4030_power_data *pdata,
struct device_node *node)
{
if (pdata
[PATCH 2/7] mfd: twl4030-power: Fix some defines for SW_EVENTS
We have these bits partially defined in two different places, so let's fix them up and add defines for the missing bits. These bits are the same for P1_SW_EVENTS, P2_SW_EVENTS and P3_SW_EVENTS. Cc: Peter Ujfalusi peter.ujfal...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/mfd/twl4030-power.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c index 1b30d8a..c0e4fc3 100644 --- a/drivers/mfd/twl4030-power.c +++ b/drivers/mfd/twl4030-power.c @@ -35,7 +35,14 @@ static u8 twl4030_start_script_address = 0x2b; #define PWR_P1_SW_EVENTS 0x10 +#define PWR_STOPON_PRWON (1 6) +#define PWR_STOPON_SYSEN (1 5) +#define PWR_ENABLE_WARMRESET (1 4) +#define PWR_LVL_WAKEUP (1 3) +#define PWR_DEVACT (1 2) +#define PWR_DEVSLP (1 1) #define PWR_DEVOFF (1 0) + #define SEQ_OFFSYNC(1 0) #define PHY_TO_OFF_PM_MASTER(p)(p - 0x36) @@ -52,10 +59,6 @@ static u8 twl4030_start_script_address = 0x2b; #define R_CFG_P2_TRANSITIONPHY_TO_OFF_PM_MASTER(0x37) #define R_CFG_P3_TRANSITIONPHY_TO_OFF_PM_MASTER(0x38) -#define LVL_WAKEUP 0x08 - -#define ENABLE_WARMRESET (14) - #define END_OF_SCRIPT 0x3f #define R_SEQ_ADD_A2S PHY_TO_OFF_PM_MASTER(0x55) @@ -196,7 +199,7 @@ static int twl4030_config_wakeup3_sequence(u8 address) err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, data, R_P3_SW_EVENTS); if (err) goto out; - data |= LVL_WAKEUP; + data |= PWR_LVL_WAKEUP; err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, data, R_P3_SW_EVENTS); out: if (err) @@ -219,7 +222,7 @@ static int twl4030_config_wakeup12_sequence(u8 address) if (err) goto out; - data |= LVL_WAKEUP; + data |= PWR_LVL_WAKEUP; err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, data, R_P1_SW_EVENTS); if (err) goto out; @@ -228,7 +231,7 @@ static int twl4030_config_wakeup12_sequence(u8 address) if (err) goto out; - data |= LVL_WAKEUP; + data |= PWR_LVL_WAKEUP; err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, data, R_P2_SW_EVENTS); if (err) goto out; @@ -281,7 +284,7 @@ static int twl4030_config_warmreset_sequence(u8 address) if (err) goto out; - rd_data |= ENABLE_WARMRESET; + rd_data |= PWR_ENABLE_WARMRESET; err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, rd_data, R_P1_SW_EVENTS); if (err) goto out; @@ -290,7 +293,7 @@ static int twl4030_config_warmreset_sequence(u8 address) if (err) goto out; - rd_data |= ENABLE_WARMRESET; + rd_data |= PWR_ENABLE_WARMRESET; err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, rd_data, R_P2_SW_EVENTS); if (err) goto out; @@ -299,7 +302,7 @@ static int twl4030_config_warmreset_sequence(u8 address) if (err) goto out; - rd_data |= ENABLE_WARMRESET; + rd_data |= PWR_ENABLE_WARMRESET; err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, rd_data, R_P3_SW_EVENTS); out: if (err) -- 1.8.1.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 1/7] mfd: twl4030-power: Fix hang on reboot if sleep configuration was loaded earlier
Looks like we can still hit the issue of wrong load order of
twl4030 configuration. If we have a sleep configuration loaded,
and do a warm reset, the device can hang while initializing the
wakeup12 sequence. We do have a warning message about wrong order
of twl4030 configuration, but in this case it does not help as
the sleep configuration was loaded during the previous boot and
the state of twl4030 is maintained throughout the warm reset.
Fix the issue by clearing any existing sleep configuration
before we load the warm reset configuration.
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/mfd/twl4030-power.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 96162b6..1b30d8a 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -421,6 +421,12 @@ static int load_twl4030_script(struct twl4030_script
*tscript,
goto out;
}
if (tscript-flags TWL4030_WAKEUP12_SCRIPT) {
+ /* Reset any existing sleep script to avoid hangs on reboot */
+ err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, END_OF_SCRIPT,
+ R_SEQ_ADD_A2S);
+ if (err)
+ goto out;
+
err = twl4030_config_wakeup12_sequence(address);
if (err)
goto out;
--
1.8.1.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 7/7] ARM: dts: Enable twl4030 off-idle configuration for selected omaps
N900 now seems to shut down the external oscillator when hitting
off-idle.
And Beagle XM seems to have OSC_EN pin connected to allow shutting
down the oscillator looking at the schematics. The oscillator
output is cut off in off-idle and you can monitor it from R56 on
the bottom side of the board near the power jack. Note that for
beagle we need to also enable the UART wake-up event, the others
have that enabled in earlier patches.
OMAP37XX EVM (TMDSEVM3730) does not seem to have twl4030 clken
pin connected, so there is no point trying to enable shutting
down of the oscillator on it for the extra latency it adds.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 6 ++
arch/arm/boot/dts/omap3-evm-common.dtsi | 7 +++
arch/arm/boot/dts/omap3-n900.dts| 5 +
3 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 447e714..b05814b 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -152,6 +152,11 @@
codec {
};
};
+
+ twl_power: power {
+ compatible = ti,twl4030-power-beagleboard-xm,
ti,twl4030-power-idle-osc-off;
+ ti,use_poweroff;
+ };
};
};
@@ -211,6 +216,7 @@
};
uart3 {
+ interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX;
pinctrl-names = default;
pinctrl-0 = uart3_pins;
};
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..7e44e29 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -45,6 +45,13 @@
#include twl4030.dtsi
#include twl4030_omap3.dtsi
+twl {
+ twl_power: power {
+ compatible = ti,twl4030-power-omap3-evm,
ti,twl4030-power-idle;
+ ti,use_poweroff;
+ };
+};
+
i2c2 {
clock-frequency = 40;
};
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 869bdd9..09ae615 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -277,6 +277,11 @@
compatible = ti,twl4030-audio;
ti,enable-vibra = 1;
};
+
+ twl_power: power {
+ compatible = ti,twl4030-power-n900,
ti,twl4030-power-idle-osc-off;
+ ti,use_poweroff;
+ };
};
twl_gpio {
--
1.8.1.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 6/7] mfd: twl4030power: Add a configuration to turn off oscillator during off-idle
Some oscillators can be turned off during off-idle saving few
a little bit power at the cost of the oscillator start up
latency.
If you board can do this, you can now enable it by using the
ti,twl4030-power-idle-osc-off compatible flag.
Cc: Peter De Schrijver pdeschrij...@nvidia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
Documentation/devicetree/bindings/mfd/twl4030-power.txt | 6 ++
drivers/mfd/twl4030-power.c | 17 +
2 files changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index bbd6603..b9ee7b9 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -9,6 +9,7 @@ Required properties:
ti,twl4030-power
ti,twl4030-power-reset
ti,twl4030-power-idle
+ ti,twl4030-power-idle-osc-off
The use of ti,twl4030-power-reset is recommended at least on
3530 that needs a special configuration for warm reset to work.
@@ -16,6 +17,11 @@ The use of ti,twl4030-power-reset is recommended at least on
When using ti,twl4030-power-idle, the TI recommended configuration
for idle modes is loaded to the tlw4030 PMIC.
+When using ti,twl4030-power-idle-osc-off, the TI recommended
+configuration is used with the external oscillator being shut
+down during off-idle. Note that this does not work on all boards
+depending on how the external oscillator is wired.
+
Optional properties:
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
SLEEP-to-OFF transition when the system poweroffs.
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 4b3f192..4341961 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -748,6 +748,19 @@ static struct twl4030_power_data omap3_idle = {
.resource_config= omap3_idle_rconfig,
};
+/* Disable 32 KiHz oscillator during idle */
+static struct twl4030_resconfig osc_off_rconfig[] = {
+ TWL_REMAP_OFF(RES_CLKEN, DEV_GRP_P1 | DEV_GRP_P3, 3, 2),
+ { /* Terminator */ },
+};
+
+static struct twl4030_power_data osc_off_idle = {
+ .scripts= omap3_idle_scripts,
+ .num= ARRAY_SIZE(omap3_idle_scripts),
+ .resource_config= omap3_idle_rconfig,
+ .board_config = osc_off_rconfig,
+};
+
static struct of_device_id twl4030_power_of_match[] = {
{
.compatible = ti,twl4030-power-reset,
@@ -757,6 +770,10 @@ static struct of_device_id twl4030_power_of_match[] = {
.compatible = ti,twl4030-power-idle,
.data = omap3_idle,
},
+ {
+ .compatible = ti,twl4030-power-idle-osc-off,
+ .data = osc_off_idle,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, twl4030_power_of_match);
--
1.8.1.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 5/7] mfd: twl4030-power: Add support for board specific configuration
With the recommended twl4030 configuration added, we can now add
board specific changes as modifications to the recommended
configuration.
Note that the data is private to this driver, and the data must
always have a NULL resource in the sentinel.
Cc: Peter De Schrijver pdeschrij...@nvidia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/mfd/twl4030-power.c | 21 +
include/linux/i2c/twl.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 392..4b3f192 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -557,13 +557,34 @@ twl4030_power_configure_scripts(const struct
twl4030_power_data *pdata)
return 0;
}
+static void twl4030_patch_rconfig(struct twl4030_resconfig *common,
+ struct twl4030_resconfig *board)
+{
+ while (common-resource) {
+ struct twl4030_resconfig *b = board;
+
+ while (b-resource) {
+ if (b-resource == common-resource) {
+ *common = *b;
+ break;
+ }
+ b++;
+ }
+ common++;
+ }
+}
+
static int
twl4030_power_configure_resources(const struct twl4030_power_data *pdata)
{
struct twl4030_resconfig *resconfig = pdata-resource_config;
+ struct twl4030_resconfig *boardconf = pdata-board_config;
int err;
if (resconfig) {
+ if (boardconf)
+ twl4030_patch_rconfig(resconfig, boardconf);
+
while (resconfig-resource) {
err = twl4030_configure_resource(resconfig);
if (err)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 5fe0313..57fe782 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -662,6 +662,7 @@ struct twl4030_power_data {
struct twl4030_script **scripts;
unsigned num;
struct twl4030_resconfig *resource_config;
+ struct twl4030_resconfig *board_config;
#define TWL4030_RESCONFIG_UNDEF((u8)-1)
bool use_poweroff; /* Board is wired for TWL poweroff */
};
--
1.8.1.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 v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hi Javier,
On May 13, 2014, at 10:51 AM, Javier Martinez Canillas wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in
u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works
absolutely fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.
Let me explain, the point is for people to easily design capes, open-source
their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate his own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem
interested
as well.
The notion of hardware as something static that never changes is obsolete
IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not something that a newbie could do
it neither.
Also, doing these FDT changes
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org
wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas
wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc
overlay will
every truly make it mainline, as the capemgr was the only real
kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be
used
to toggle it while waiting for the capemgr. That's because the
board
has a header for pins, so it's not exactly limited to just the
capes.
Anybody working on enabling/disabling cape dtb configurations in
u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want
my
invert the gpio to enable the usb hub on the older beagle xm
A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying
to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different,
then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive
someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox,
UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works
absolutely fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS
for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.
Let me explain, the point is for people to easily design capes,
open-source their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate his
own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about
dynamic
hardware configuration. There are a number of FPGA people that seem
interested
as well.
The notion of hardware as something static that never changes is
obsolete IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not
Re: [PATCH v3 0/5] Add support for SW babble Control
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
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
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset function
On 5/13/2014 9:32 PM, Felipe Balbi wrote:
Hi,
On Thu, May 08, 2014 at 03:03:03PM +0530, George Cherian wrote:
Calculate the wrapper register offsets in a seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 80
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 1160ff4..872f065 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -383,6 +383,49 @@ static int dwc3_omap_vbus_notifier(struct notifier_block
*nb,
return NOTIFY_DONE;
}
+static void dwc3_omap_map_offset(struct dwc3_omap *omap)
+{
+ u32 reg;
+ struct device_node *node = omap-dev-of_node;
+ int x_major;
+
+ reg = dwc3_omap_readl(omap-base, USBOTGSS_REVISION);
+ omap-revision = reg;
+ x_major = USBOTGSS_REVISION_XMAJOR(reg);
+
+ /* Differentiate between OMAP5 and AM437x */
+ switch (x_major) {
+ case USBOTGSS_REVISION_XMAJOR1:
+ case USBOTGSS_REVISION_XMAJOR2:
+ omap-irq_eoi_offset = 0;
+ omap-irq0_offset = 0;
+ omap-irqmisc_offset = 0;
+ omap-utmi_otg_offset = 0;
+ omap-debug_offset = 0;
+ break;
+ default:
+ /* Default to the latest revision */
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ break;
+ }
+
+ /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+* changes in wrapper registers, Using dt compatible for aegis
+*/
+
+ if (of_device_is_compatible(node, ti,am437x-dwc3)) {
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ }
can you add a patch before $subject which gets rid of the switch
statement above since it's pretty much useless now that we use
compatible strings to differentiate omap5 and am437x ?'
okay will do in v2.
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 5/13/14, 8:39 PM, Pantelis Antoniou pantelis.anton...@gmail.com
wrote:
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org
wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas
wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc
overlay will
every truly make it mainline, as the capemgr was the only real
kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be
used
to toggle it while waiting for the capemgr. That's because the
board
has a header for pins, so it's not exactly limited to just the
capes.
Anybody working on enabling/disabling cape dtb configurations in
u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want
my
invert the gpio to enable the usb hub on the older beagle xm
A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying
to
replicate what we used to do from boards files where it was
possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different,
then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive
someone
to madness quite quickly. Moving all of Pantelis' work for
dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox,
UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if
they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an
dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider
that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works
absolutely fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS
for
the base board and the cape in question. Doing that he essentially
cuts
himself off from the community.
Let me explain, the point is for people to easily design capes,
open-source their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate
his
own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about
dynamic
hardware configuration. There are a number of FPGA people that seem
interested
as well.
The notion of hardware as something static that never changes is
obsolete IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is
that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned
Re: [PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
hi Arnd, On Tuesday 13 May 2014 07:04 PM, Arnd Bergmann wrote: On Tuesday 13 May 2014 15:27:46 Arnd Bergmann wrote: On Tuesday 13 May 2014 18:56:23 Kishon Vijay Abraham I wrote: If you have a case where the outbound translation is a 256MB (i.e. 28bit) section of the CPU address space, that could be represented as ranges = 0x8200 0 0 0xb000 0 0x1000; or ranges = 0x8200 0 0xb000 0xb000 0 0x1000; depending on whether you want the BARs to be programmed using a low address 0x0-0x0fff or an address matching the window 0xb000-0xbfff. The problem is, for configuring the window starting at 0xb000, the ATU should be programmed 0x000 (the cpu address for it will be 0xb000 though). Then use the first of the two? To clarify: using 0x8200 0 0 0xb000 0 0x1000 will give you a mem_offset of 0xb000, which should work just fine for this case. What I don't understand is why the ATU cares about whether the outbound address is 0x000 or 0xb000 if it just decodes the lower 28 bit anyway. Did you mean that we have to program the BARs using low addresses regardless of what is programmed in the ATU? That would make more sense, and it also matches what I suggested. No, It's not like it decodes only the lower 28bits. The BARs is programmed with 32 bit value. My pcie dt node has ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /* CONFIG */ 0x8100 0 0 0x20003000 0 0x0001 /* IO */ 0x8200 0 0x20013000 0x20013000 0 0xffed000; /* MEM */ Consider MEM address space.. Here both PCI address and CPU address is 0x20013000. So when there is a write to cpu addr 0x20013000 [writel(virt_addr(0x20013000)], we want it to be translated to PCI addr 0x20013000. So in 'ATU', we would expect *base* to be programmed to *0x20013000* and target to be programmed to *0x20013000*. But that's not the case for DRA7xx. For DRA7xx *base* should be programmed to *0x0013000* and target should be programmed to *0x20013000*. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
