Re: [PATCH v2 02/12] ARM: dts: DRA7: Add DCAN nodes
On 09/09/2014 06:06 PM, Marc Kleine-Budde wrote:
On 09/09/2014 05:04 PM, Marc Kleine-Budde wrote:
On 09/09/2014 04:55 PM, Roger Quadros wrote:
The SoC supports 2 DCAN nodes. Add them.
I think you should put the device-tree ml for DT related patches on Cc.
OK.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..09d5739 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ d_can0 = dcan1;
+ d_can1 = dcan2;
};
timer {
@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ dcan1: can@481cc000 {
+ compatible = bosch,d_can;
+ ti,hwmods = dcan1;
+ reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within
syscon */
Putting the offset within the syscon here doesn't look good.
+ ti,raminit-syscon = dra7_ctrl_core;
Why not add it as a second parameter to the ti,raminit-syscon instead?
Yes, that would be better.
./drivers/power/reset/keystone-reset.c does this.
Thanks for the hint. I'll fix this in v3.
cheers,
-rogre
--
To unsubscribe from this list: send the line unsubscribe 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 05/12] arm: dts: am4372: Add dcan nodes
On 09/09/2014 06:09 PM, Marc Kleine-Budde wrote:
On 09/09/2014 04:55 PM, Roger Quadros wrote:
From: Afzal Mohammed af...@ti.com
Add dcan nodes.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 8689949..3514d0a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -885,6 +885,28 @@
clock-names = fck;
};
};
+
+dcan0: can@481cc000 {
+compatible = bosch,d_can;
+ti,hwmods = d_can0;
+clocks = dcan0_fck;
+clock-names = fck;
+reg = 0x481cc000 0x2000
+0x44e10644 0x4;
+interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
Where are the syscon phandles?
They are added in patch 10. As that doesn't look nice, I'll squash it to this
patch.
+status = disabled;
+};
+
+dcan1: can@481d {
+compatible = bosch,d_can;
+ti,hwmods = d_can1;
+clocks = dcan1_fck;
+clock-names = fck;
+reg = 0x481d 0x2000
+0x44e10644 0x4;
+interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+status = disabled;
+};
};
};
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/12] ARM: dts: AM43xx: Add aliases to d_can nodes
On 09/09/2014 06:08 PM, Marc Kleine-Budde wrote: On 09/09/2014 04:55 PM, Roger Quadros wrote: The d_can driver expects appropriately named aliases for the d_can nodes for the RAMINIT control register access. Provide those, otherwise RAMINIT register won't be configured. Get's rid of the following messages during boot. With your patch set this is not true anymore, is it? Right. I'll drop this patch. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2+: make of_device_ids const
of_device_ids (i.e. compatible strings and the respective data) are not
supposed to change at runtime. All functions working with of_device_ids
provided by linux/of.h work with const of_device_ids. So mark the
non-const function parameters and structs for OMAP2+ as const, too.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-omap2/common.h| 2 +-
arch/arm/mach-omap2/gpmc.c | 2 +-
arch/arm/mach-omap2/irq.c | 2 +-
arch/arm/mach-omap2/pdata-quirks.c | 2 +-
arch/arm/mach-omap2/prm_common.c| 2 +-
arch/arm/mach-omap2/timer.c | 6 +++---
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 9480997ba616..5827abb080e4 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -27,7 +27,7 @@
#define gic_of_initNULL
#endif
-static struct of_device_id omap_dt_match_table[] __initdata = {
+static const struct of_device_id omap_dt_match_table[] __initconst = {
{ .compatible = simple-bus, },
{ .compatible = ti,omap-infra, },
{ }
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dc571f1d3b8a..79664411e794 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -307,7 +307,7 @@ static inline void omap4_cpu_resume(void)
#endif
-void pdata_quirks_init(struct of_device_id *);
+void pdata_quirks_init(const struct of_device_id *);
void omap_auxdata_legacy_init(struct device *dev);
void omap_pcs_legacy_init(int irq, void (*rearm)(void));
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2f97228f188a..a4d52c42a438 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1243,7 +1243,7 @@ int gpmc_cs_program_settings(int cs, struct gpmc_settings
*p)
}
#ifdef CONFIG_OF
-static struct of_device_id gpmc_dt_ids[] = {
+static const struct of_device_id gpmc_dt_ids[] = {
{ .compatible = ti,omap2420-gpmc },
{ .compatible = ti,omap2430-gpmc },
{ .compatible = ti,omap3430-gpmc }, /* omap3430 omap3630 */
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 35b8590c322e..604a976abf14 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -289,7 +289,7 @@ int __init intc_of_init(struct device_node *node,
return 0;
}
-static struct of_device_id irq_match[] __initdata = {
+static const struct of_device_id irq_match[] __initconst = {
{ .compatible = ti,omap2-intc, .data = intc_of_init, },
{ }
};
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 90c88d498485..05a8c8b07449 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -405,7 +405,7 @@ static void pdata_quirks_check(struct pdata_init *quirks)
}
}
-void __init pdata_quirks_init(struct of_device_id *omap_dt_match_table)
+void __init pdata_quirks_init(const struct of_device_id *omap_dt_match_table)
{
omap_sdrc_init(NULL, NULL);
pdata_quirks_check(auxdata_quirks);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 76ca320f007c..74054b813600 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -467,7 +467,7 @@ int prm_unregister(struct prm_ll_data *pld)
return 0;
}
-static struct of_device_id omap_prcm_dt_match_table[] = {
+static const struct of_device_id omap_prcm_dt_match_table[] = {
{ .compatible = ti,am3-prcm },
{ .compatible = ti,am3-scrm },
{ .compatible = ti,am4-prcm },
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 43d03fbf4c0b..4f61148ec168 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -141,7 +141,7 @@ static struct property device_disabled = {
.value = disabled,
};
-static struct of_device_id omap_timer_match[] __initdata = {
+static const struct of_device_id omap_timer_match[] __initconst = {
{ .compatible = ti,omap2420-timer, },
{ .compatible = ti,omap3430-timer, },
{ .compatible = ti,omap4430-timer, },
@@ -162,7 +162,7 @@ static struct of_device_id omap_timer_match[] __initdata = {
* the timer node in device-tree as disabled, to prevent the kernel from
* registering this timer as a platform device and so no one else can use it.
*/
-static struct device_node * __init omap_get_timer_dt(struct of_device_id
*match,
+static struct device_node * __init omap_get_timer_dt(const struct of_device_id
*match,
const char *property)
{
struct device_node *np;
@@ -388,7 +388,7 @@ static u64 notrace dmtimer_read_sched_clock(void)
return 0;
}
-static struct of_device_id omap_counter_match[] __initdata = {
+static const struct
[PATCH] bus: omap_l3_noc: Fix connID for OMAP4
Commit d4d8819e205854c (bus: omap_l3_noc: fix masterid detection)
did the right thing in dropping the LSB 2 bits which is not part
of the ConnID for NTTP master address. However, as part of that
change, we should also have ensured that existing list of OMAP4 connID
codes are also shifted by 2 bits to ensure that connIDs map to Table
13-18. ConnID Values as provided in Technical Reference Manuals for
OMAP4430(Rev AP, April 2014, SWPU220AP) and OMAP4460(Rev AB, April
2014, SWPU234AB)
Fixes: d4d8819e205854c (bus: omap_l3_noc: fix masterid detection)
Reported-by: Kristian Otnes kot...@cisco.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on v3.17-rc1 - but might be 3.17 rc material
Quick links (seems to work on firefox):
4430:
http://www.ti.com/lit/ug/swpu231ap/swpu231ap.pdf#page=3030zoom=auto,0,699.5
4460:
http://www.ti.com/lit/ug/swpu235ab/swpu235ab.pdf#page=3073zoom=auto,0,699.5
NOTE: there are a few more cleanup patches that can follow these..
will leave those out for now.
drivers/bus/omap_l3_noc.h | 50 ++---
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 551e010..9525458 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -188,31 +188,31 @@ static struct l3_flagmux_data omap_l3_flagmux_clk3 = {
};
static struct l3_masters_data omap_l3_masters[] = {
- { 0x0 , MPU},
- { 0x10, CS_ADP},
- { 0x14, xxx},
- { 0x20, DSP},
- { 0x30, IVAHD},
- { 0x40, ISS},
- { 0x44, DucatiM3},
- { 0x48, FaceDetect},
- { 0x50, SDMA_Rd},
- { 0x54, SDMA_Wr},
- { 0x58, xxx},
- { 0x5C, xxx},
- { 0x60, SGX},
- { 0x70, DSS},
- { 0x80, C2C},
- { 0x88, xxx},
- { 0x8C, xxx},
- { 0x90, HSI},
- { 0xA0, MMC1},
- { 0xA4, MMC2},
- { 0xA8, MMC6},
- { 0xB0, UNIPRO1},
- { 0xC0, USBHOSTHS},
- { 0xC4, USBOTGHS},
- { 0xC8, USBHOSTFS}
+ { 0x00, MPU},
+ { 0x04, CS_ADP},
+ { 0x05, xxx},
+ { 0x08, DSP},
+ { 0x0C, IVAHD},
+ { 0x10, ISS},
+ { 0x11, DucatiM3},
+ { 0x12, FaceDetect},
+ { 0x14, SDMA_Rd},
+ { 0x15, SDMA_Wr},
+ { 0x16, xxx},
+ { 0x17, xxx},
+ { 0x18, SGX},
+ { 0x1C, DSS},
+ { 0x20, C2C},
+ { 0x22, xxx},
+ { 0x23, xxx},
+ { 0x24, HSI},
+ { 0x28, MMC1},
+ { 0x29, MMC2},
+ { 0x2A, MMC6},
+ { 0x2C, UNIPRO1},
+ { 0x30, USBHOSTHS},
+ { 0x31, USBOTGHS},
+ { 0x32, USBHOSTFS}
};
static struct l3_flagmux_data *omap_l3_flagmux[] = {
--
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 2/2] ARM: dts: omap5: Add dr_mode for dwc3
Hi, On 09/08/2014 04:24 PM, Felipe Balbi wrote: Hi, On Mon, Sep 08, 2014 at 02:34:33PM +0300, Dmitry Lifshitz wrote: Hi Felipe, Roger On 04/16/2014 07:16 PM, Felipe Balbi wrote: On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote: Hi, On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote: From: George Cherian george.cher...@ti.com Added dr_mode property in dwc3 and set its default mode to device. If there is a specific reason why this is not set to otg, we need to explain it here. AFAIK the port is meant to be used as OTG port. we still don't have the workaround for dual role ports, I've been working on it but still need to retest and make sure it's working fine before merging upstream. Does the OTG port suppose to work with OMAP5? I mean role switching mechanism? I'm testing kernel v3.16 with OMAP5 based board (CM-T54). If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon events works fine). Dual role does not work. We allow the driver to the built with both Host and Peripheral support because some platforms have more than one port and building the driver with dual role allows us to make one port host and one peripheral. Please, can you provide some detail about platforms with several ports. How do that ports are connected to DWC3? Thanks, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Add DRA7xx CPSW Ethernet support in Device Tree
Adding device tree entry for CPSW to make it work in Dual EMAC mode. These patches were tested with DRA7 hwmod patches on top of linux-next. Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed my tree to [2]. Did a boot test with CPSW and ping test with suspend/resume, the boot logs on DRA7xx EVM are posted at [3] [1] git://github.com/nmenon/linux-2.6-playground.git testing/v3.17/cpu-idle-suspend-dra7-omap5-framework [2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git v3.17/dra7-evm-cpsw [3] http://pastebin.ubuntu.com/8309289/ Changes from initial version: * Dropped patch for pinoff states * Changed pinoff state to mode15 Mugunthan V N (2): ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7 ARM: dts: dra7-evm: Enable CPSW and MDIO for dra7xx EVM arch/arm/boot/dts/dra7-evm.dts | 107 + arch/arm/boot/dts/dra7.dtsi| 59 +++ 2 files changed, 166 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: dra7-evm: 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 | 107 +
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..e5c4e33 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,6 +151,87 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
;
};
+
+ 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 (MUX_MODE15)
+ 0x254 (MUX_MODE15)
+ 0x258 (MUX_MODE15)
+ 0x25c (MUX_MODE15)
+ 0x260 (MUX_MODE15)
+ 0x264 (MUX_MODE15)
+ 0x268 (MUX_MODE15)
+ 0x26c (MUX_MODE15)
+ 0x270 (MUX_MODE15)
+ 0x274 (MUX_MODE15)
+ 0x278 (MUX_MODE15)
+ 0x27c (MUX_MODE15)
+
+ /* Slave 1 */
+ 0x198 (MUX_MODE15)
+ 0x19c (MUX_MODE15)
+ 0x1a0 (MUX_MODE15)
+ 0x1a4 (MUX_MODE15)
+ 0x1a8 (MUX_MODE15)
+ 0x1ac (MUX_MODE15)
+ 0x1b0 (MUX_MODE15)
+ 0x1b4 (MUX_MODE15)
+ 0x1b8 (MUX_MODE15)
+ 0x1bc (MUX_MODE15)
+ 0x1c0 (MUX_MODE15)
+ 0x1c4 (MUX_MODE15)
+ ;
+ };
+
+ 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 (MUX_MODE15)
+ 0x240 (MUX_MODE15)
+ ;
+ };
+
};
i2c1 {
@@ -504,3 +585,29 @@
usb2_phy2 {
phy-supply = ldousb_reg;
};
+
+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;
+ dual_emac_res_vlan = 1;
+};
+
+cpsw_emac1 {
+ phy_id = davinci_mdio, 3;
+ phy-mode = rgmii;
+ dual_emac_res_vlan = 2;
+};
+
+davinci_mdio {
+ pinctrl-names = default, sleep;
+ pinctrl-0 = davinci_mdio_default;
+ pinctrl-1 = davinci_mdio_sleep;
+};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
[PATCH v2 1/2] ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7
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 d678152..8d79321 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ ethernet0 = cpsw_emac0;
+ ethernet1 = cpsw_emac1;
};
timer {
@@ -1262,6 +1264,63 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ 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 0x1000
+ 0x48485200 0x2E00;
+ #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;
+ };
+ };
+
};
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7
On 09/10/2014 08:37 AM, Mugunthan V N wrote:
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 d678152..8d79321 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ ethernet0 = cpsw_emac0;
+ ethernet1 = cpsw_emac1;
should this rather be in board dts?
};
timer {
@@ -1262,6 +1264,63 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ 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 0x1000
+0x48485200 0x2E00;
+ #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 ];
should be disabled? what about platforms that do not have both emac ports?
+ };
+
+ cpsw_emac1: slave@48480300 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
should be disabled? what about platforms that do not have both emac ports?
+ };
+
+ phy_sel: cpsw-phy-sel@4a002554 {
+ compatible = ti,dra7xx-cpsw-phy-sel;
+ reg= 0x4a002554 0x4;
+ reg-names = gmii-sel;
+ };
+ };
+
};
};
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: dts: dra7-evm: Enable CPSW and MDIO for dra7xx EVM
On 09/10/2014 08:37 AM, Mugunthan V N wrote:
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 | 107
+
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..e5c4e33 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,6 +151,87 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
;
};
+
+ 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 */
Cant we do this based on emac0 and emac1?
+
+ /* Slave 2 */
+ 0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
NAK. reason comment style - we use the style:
/* mode0_name.mode3_name */
+ 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 (MUX_MODE15)
+ 0x254 (MUX_MODE15)
+ 0x258 (MUX_MODE15)
+ 0x25c (MUX_MODE15)
+ 0x260 (MUX_MODE15)
+ 0x264 (MUX_MODE15)
+ 0x268 (MUX_MODE15)
+ 0x26c (MUX_MODE15)
+ 0x270 (MUX_MODE15)
+ 0x274 (MUX_MODE15)
+ 0x278 (MUX_MODE15)
+ 0x27c (MUX_MODE15)
+
+ /* Slave 1 */
^^ Slave 1?
+ 0x198 (MUX_MODE15)
+ 0x19c (MUX_MODE15)
+ 0x1a0 (MUX_MODE15)
+ 0x1a4 (MUX_MODE15)
+ 0x1a8 (MUX_MODE15)
+ 0x1ac (MUX_MODE15)
+ 0x1b0 (MUX_MODE15)
+ 0x1b4 (MUX_MODE15)
+ 0x1b8 (MUX_MODE15)
+ 0x1bc (MUX_MODE15)
+ 0x1c0 (MUX_MODE15)
+ 0x1c4 (MUX_MODE15)
+ ;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins =
+ /* MDIO */
^^ you can drop the comment. it is redundant.
+ 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 (MUX_MODE15)
+ 0x240 (MUX_MODE15)
+ ;
+ };
+
};
i2c1 {
@@ -504,3 +585,29 @@
usb2_phy2 {
phy-supply = ldousb_reg;
};
+
+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;
+ dual_emac_res_vlan = 1;
+};
+
+cpsw_emac1 {
+ phy_id = davinci_mdio, 3;
+ phy-mode = rgmii;
+ dual_emac_res_vlan = 2;
+};
+
+davinci_mdio {
+ pinctrl-names = default, sleep;
+
Re: [PATCH v2 0/2] Add DRA7xx CPSW Ethernet support in Device Tree
On 09/10/2014 08:37 AM, Mugunthan V N wrote: Adding device tree entry for CPSW to make it work in Dual EMAC mode. These patches were tested with DRA7 hwmod patches on top of linux-next. Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed my tree to [2]. Did a boot test with CPSW and ping test with suspend/resume, the boot logs on DRA7xx EVM are posted at [3] [1] git://github.com/nmenon/linux-2.6-playground.git testing/v3.17/cpu-idle-suspend-dra7-omap5-framework [2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git v3.17/dra7-evm-cpsw [3] http://pastebin.ubuntu.com/8309289/ Changes from initial version: * Dropped patch for pinoff states * Changed pinoff state to mode15 Mugunthan V N (2): ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7 ARM: dts: dra7-evm: Enable CPSW and MDIO for dra7xx EVM arch/arm/boot/dts/dra7-evm.dts | 107 + arch/arm/boot/dts/dra7.dtsi| 59 +++ 2 files changed, 166 insertions(+) I did apply these on Tony's omap-for-v3.18/dt 6e55426 Merge branch .. they do apply. However: why are we not sending dra72-evm.dts changes in the same series since we claim it to be dra7xx support? Also, in your tests (http://pastebin.ubuntu.com/8309289/) echo -n 20/sys/kernel/debug/pm_debug/wakeup_timer_seconds ping 172.24.188.1 (or even better do a transfer of large file in background) echo mem /sys/power/state transfer/ping should resume seamlessly. (only thing you should be careful is that the server should not timeout for 20 second inactivity).. It is a valid test to verify peripheral activity after resume, BUT, equally important is to verify suspend-resume in the middle of activity. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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 v8 00/18] 8250-core based serial driver for OMAP + DMA
On Tue, Sep 09, 2014 at 09:41:20PM +0200, Sebastian Andrzej Siewior wrote: On 09/08/2014 08:33 PM, Frans Klaver wrote: Thanks. I'll give it a spin on Wednesday. Could you please pull the upcoming v9 first? git://git.breakpoint.cc/bigeasy/linux.git uart_v9_pre1 This solves a few of my am335x related issues. Using v9_pre1, I get a kernel panic in edma_dma_pause() on echan-edesc being NULL. I do get data before this happens. This is at high speed, high rate. No mention of the irq having too much to do, though. The more data I transmit, the more likely this is to occur. I don't currently have the setup to lower the baudrate. I would probably need to reproduce this on a beaglebone, instead of our custom board. I'll see if I can do that. If you need more info, just let me know. Thanks, Frans -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.15+: omap4: mmc: multi_v7: can't boot off mmc
I'm having an hard time making the vanilla v7_defconfig boot off the mmc on my pandaboard: [1.698272] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517 [1.705139] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral [1.712890] omap_hsmmc 480d5000.mmc: unable to get vmmc regulator -517 [1.719787] platform 480d5000.mmc: Driver omap_hsmmc requests probe deferral [1.727691] sdhci-pltfm: SDHCI platform and OF driver helper [1.734619] usbcore: registered new interface driver usbhid [1.740478] usbhid: USB HID core driver [1.749359] TCP: cubic registered [1.752838] NET: Registered protocol family 17 [1.757690] Key type dns_resolver registered [1.762756] Power Management for TI OMAP4+ devices. [1.767883] Power Management for TI OMAP4. [1.772186] OMAP4 PM: u-boot = v2012.07 is required for full PM support [1.779296] ThumbEE CPU extension supported. [1.779296] Registering SWP/SWPB emulation handler [1.790008] vwl1271: 1800 mV [1.794952] Skipping twl internal clock init and using bootloader value (unknown osc rate) [1.805358] twl 0-0048: PIH (irq 39) nested IRQs [1.811340] twl_rtc rtc.14: Power up reset detected. [1.817260] twl_rtc rtc.14: Enabling TWL-RTC [1.824249] twl_rtc rtc.14: rtc core: registered rtc.14 as rtc0 [1.831451] VAUX1_6030: 1000 -- 3000 mV at 1800 mV [1.837677] VAUX2_6030: 1200 -- 2800 mV at 1800 mV [1.844024] VAUX3_6030: 1000 -- 3000 mV at 1200 mV [1.850311] VMMC: 1200 -- 3000 mV at 3000 mV [1.855957] VPP: 1800 -- 2500 mV at 1900 mV [1.861572] VUSIM: 1200 -- 2900 mV at 1800 mV [1.866577] VDAC: 1800 mV [1.869964] VANA: 2100 mV [1.874114] VCXIO: 1800 mV [1.877624] VUSB: 3300 mV [1.881317] V1V8: 1800 mV [1.884979] V2V1: 2100 mV [1.967407] usb 1-1: new high-speed USB device number 2 using ehci-omap [2.094512] omap_i2c 4807.i2c: bus 0 rev0.10 at 400 kHz [2.104583] omap_i2c 48072000.i2c: bus 1 rev0.10 at 400 kHz [2.114044] omap_i2c 4806.i2c: bus 2 rev0.10 at 100 kHz [2.121582] hub 1-1:1.0: USB hub found [2.125854] hub 1-1:1.0: 5 ports detected [2.131744] omap_i2c 4835.i2c: bus 3 rev0.10 at 400 kHz [2.140686] omap_hsmmc 4809c000.mmc: pins are not configured from the driver [2.321166] twl_rtc rtc.14: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [2.336578] ALSA device list: [2.339782] No soundcards found. [2.339782] VFS: Cannot open root device mmcblk0p2 or unknown-block(0,0): error -6 [2.352478] Please append a correct root= boot option; here are the available partitions: [2.361297] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [2.367980] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-12143-g552e691 #70 [2.377716] [c02155f4] (unwind_backtrace) from [c0211234] (show_stack+0x10/0x14) [2.385864] [c0211234] (show_stack) from [c080b2c8] (dump_stack+0x88/0x98) [2.390289] [c080b2c8] (dump_stack) from [c0808d10] (panic+0xa0/0x208) [2.400695] [c0808d10] (panic) from [c0ade00c] (mount_block_root+0x1a0/0x230) [2.408569] [c0ade00c] (mount_block_root) from [c0ade1a4] (mount_root+0x108/0x110) [2.408569] [c0ade1a4] (mount_root) from [c0ade304] (prepare_namespace+0x158/0x1a0) [2.425292] [c0ade304] (prepare_namespace) from [c0addcc8] (kernel_init_freeable+0x1cc/0x1dc) [2.430084] [c0addcc8] (kernel_init_freeable) from [c0806184] (kernel_init+0x8/0xf0) [2.443145] [c0806184] (kernel_init) from [c020e338] (ret_from_fork+0x14/0x3c) [2.447967] CPU0: stopping [2.451110] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-12143-g552e691 #70 [2.451110] [c02155f4] (unwind_backtrace) from [c0211234] (show_stack+0x10/0x14) [2.451110] [c0211234] (show_stack) from [c080b2c8] (dump_stack+0x88/0x98) [2.451110] [c080b2c8] (dump_stack) from [c0213e1c] (handle_IPI+0x148/0x174) [2.477386] [c0213e1c] (handle_IPI) from [c0208818] (gic_handle_irq+0x58/0x5c) [2.477386] [c0208818] (gic_handle_irq) from [c0211dc0] (__irq_svc+0x40/0x50) [2.477386] Exception stack(0xc0b6def0 to 0xc0b6df38) [2.506256] dee0: c0b7bf54 c0b7bf54 004c [2.506256] df00: 91be7a33 92080d44 eaf94de8 c0c8f2bc ea4bdd94 [2.523437] df20: 0010 c0b6df38 c06bcbf8 c06bcc04 6153 [2.523437] [c0211dc0] (__irq_svc) from [c06bcc04] (cpuidle_enter_state+0x68/0xf8) [2.523437] [c06bcc04] (cpuidle_enter_state) from [c06be65c] (cpuidle_enter_state_coupled+0x130/0x378) [2.523437] [c06be65c] (cpuidle_enter_state_coupled) from [c0277ed4] (cpu_startup_entry+0x200/0x230) [2.558868] [c0277ed4] (cpu_startup_entry) from [c0addaf0] (start_kernel+0x348/0x354) [2.567474] [c0addaf0] (start_kernel) from [80208074] (0x80208074) [2.567474] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on
[PATCH v3 3/3] ARM: OMAP4+: Remove static iotable mappings for SRAM
From: Rajendra Nayak rna...@ti.com
In order to handle errata I688, a page of sram was reserved by doing a
static iotable map. Now that we use gen_pool to manage sram, we can
completely remove all of these static mappings and use gen_pool_alloc()
to get the one page of sram space needed to implement errata I688.
omap_bus_sync will be NOP until SRAM initialization happens.
Suggested-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v2-v3: add check for null sram_pool
Documentation/devicetree/bindings/arm/omap/mpu.txt | 3 +++
arch/arm/boot/dts/omap4.dtsi | 1 +
arch/arm/boot/dts/omap5.dtsi | 3 ++-
arch/arm/mach-omap2/io.c | 17 -
arch/arm/mach-omap2/omap4-common.c | 22 +-
arch/arm/mach-omap2/sram.c | 6 --
arch/arm/mach-omap2/sram.h | 6 --
7 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/mpu.txt
b/Documentation/devicetree/bindings/arm/omap/mpu.txt
index 83f405b..763695d 100644
--- a/Documentation/devicetree/bindings/arm/omap/mpu.txt
+++ b/Documentation/devicetree/bindings/arm/omap/mpu.txt
@@ -10,6 +10,9 @@ Required properties:
Should be ti,omap5-mpu for OMAP5
- ti,hwmods: mpu
+Optional properties:
+- sram:Phandle to the ocmcram node
+
Examples:
- For an OMAP5 SMP system:
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index f584611..42a2d12 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -81,6 +81,7 @@
mpu {
compatible = ti,omap4-mpu;
ti,hwmods = mpu;
+ sram = ocmcram;
};
dsp {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index d4e6976..dff19bd 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,8 +104,9 @@
soc {
compatible = ti,omap-infra;
mpu {
- compatible = ti,omap5-mpu;
+ compatible = ti,omap4-mpu;
ti,hwmods = mpu;
+ sram = ocmcram;
};
};
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5d0667c..a80ee95 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -231,15 +231,6 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.length = L4_PER_44XX_SIZE,
.type = MT_DEVICE,
},
-#ifdef CONFIG_OMAP4_ERRATA_I688
- {
- .virtual= OMAP4_SRAM_VA,
- .pfn= __phys_to_pfn(OMAP4_SRAM_PA),
- .length = PAGE_SIZE,
- .type = MT_MEMORY_RW_SO,
- },
-#endif
-
};
#endif
@@ -269,14 +260,6 @@ static struct map_desc omap54xx_io_desc[] __initdata = {
.length = L4_PER_54XX_SIZE,
.type = MT_DEVICE,
},
-#ifdef CONFIG_OMAP4_ERRATA_I688
- {
- .virtual= OMAP4_SRAM_VA,
- .pfn= __phys_to_pfn(OMAP4_SRAM_PA),
- .length = PAGE_SIZE,
- .type = MT_MEMORY_RW_SO,
- },
-#endif
};
#endif
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index a0fe747..16b20ce 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -25,6 +25,7 @@
#include linux/irqchip/irq-crossbar.h
#include linux/of_address.h
#include linux/reboot.h
+#include linux/genalloc.h
#include asm/hardware/cache-l2x0.h
#include asm/mach/map.h
@@ -71,6 +72,26 @@ void omap_bus_sync(void)
}
EXPORT_SYMBOL(omap_bus_sync);
+static int __init omap4_sram_init(void)
+{
+ struct device_node *np;
+ struct gen_pool *sram_pool;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-mpu);
+ if (!np)
+ pr_warn(%s:Unable to allocate sram needed to handle errata
I688\n,
+ __func__);
+ sram_pool = of_get_named_gen_pool(np, sram, 0);
+ if (!sram_pool)
+ pr_warn(%s:Unable to get sram pool needed to handle errata
I688\n,
+ __func__);
+ else
+ sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE);
+
+ return 0;
+}
+omap_arch_initcall(omap4_sram_init);
+
/* Steal one page physical memory for barrier implementation */
int __init omap_barrier_reserve_memblock(void)
{
@@ -91,7 +112,6 @@ void __init omap_barriers_init(void)
dram_io_desc[0].type = MT_MEMORY_RW_SO;
iotable_init(dram_io_desc, ARRAY_SIZE(dram_io_desc));
dram_sync = (void __iomem *)
[PATCH v3 2/3] ARM: OMAP4+: Move SRAM data to DT
From: Rajendra Nayak rna...@ti.com
Use drivers/misc/sram.c driver to manage SRAM on all DT only
OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
the existing private plat-omap/sram.c
Address and size related data is removed from mach-omap2/sram.c
and now passed to drivers/misc/sram.c from DT.
Users can hence use general purpose allocator apis instead of
OMAP private ones to manage and use SRAM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi| 5 ++---
arch/arm/boot/dts/am4372.dtsi| 5 +
arch/arm/boot/dts/omap4.dtsi | 5 +
arch/arm/boot/dts/omap5.dtsi | 5 +
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/mach-omap2/sram.c | 26 +-
arch/arm/mach-omap2/sram.h | 1 -
7 files changed, 19 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161..c8238c4 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -726,9 +726,8 @@
};
ocmcram: ocmcram@4030 {
- compatible = ti,am3352-ocmcram;
- reg = 0x4030 0x1;
- ti,hwmods = ocmcram;
+ compatible = mmio-sram;
+ reg = 0x4030 0x1; /* 64k */
};
wkup_m3: wkup_m3@44d0 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 8689949..24531de 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -885,6 +885,11 @@
clock-names = fck;
};
};
+
+ ocmcram: ocmcram@4030 {
+ compatible = mmio-sram;
+ reg = 0x4030 0x4; /* 256k */
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 69408b5..f584611 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -208,6 +208,11 @@
};
};
+ ocmcram: ocmcram@40304000 {
+ compatible = mmio-sram;
+ reg = 0x40304000 0xa000; /* 40k */
+ };
+
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc8df17..d4e6976 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -219,6 +219,11 @@
};
};
+ ocmcram: ocmcram@4030 {
+ compatible = mmio-sram;
+ reg = 0x4030 0x2; /* 128k */
+ };
+
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index f650f00..5dd120f 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -101,6 +101,7 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_SENSORS_TSL2550=m
CONFIG_BMP085_I2C=m
CONFIG_SENSORS_LIS3_I2C=m
+CONFIG_SRAM=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_MULTI_LUN=y
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 5e45df0..e5ac29d 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -32,12 +32,6 @@
#define OMAP2_SRAM_PUB_PA (OMAP2_SRAM_PA + 0xf800)
#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
-#ifdef CONFIG_OMAP4_ERRATA_I688
-#define OMAP4_SRAM_PUB_PA OMAP4_SRAM_PA
-#else
-#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
-#endif
-#define OMAP5_SRAM_PA 0x4030
#define SRAM_BOOTLOADER_SZ 0x00
@@ -105,32 +99,14 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
- } else if (cpu_is_omap44xx()) {
- omap_sram_start = OMAP4_SRAM_PUB_PA;
- omap_sram_size = 0xa000; /* 40K */
- } else if (soc_is_omap54xx()) {
- omap_sram_start = OMAP5_SRAM_PA;
- omap_sram_size = SZ_128K; /* 128KB */
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
}
} else {
- if (soc_is_am33xx()) {
- omap_sram_start = AM33XX_SRAM_PA;
- omap_sram_size = 0x1; /* 64K */
- } else if (soc_is_am43xx()) {
-
[PATCH v3 1/3] ARM: AM335x: Get rid of unused sram init function
From: Rajendra Nayak rna...@ti.com
Remove the empty am33xx_sram_init() function.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/sram.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index ddf1818..5e45df0 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -285,11 +285,6 @@ static inline int omap34xx_sram_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
-static inline int am33xx_sram_init(void)
-{
- return 0;
-}
-
int __init omap_sram_init(void)
{
omap_detect_sram();
@@ -299,8 +294,6 @@ int __init omap_sram_init(void)
omap242x_sram_init();
else if (cpu_is_omap2430())
omap243x_sram_init();
- else if (soc_is_am33xx())
- am33xx_sram_init();
else if (cpu_is_omap34xx())
omap34xx_sram_init();
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] OMAP4+: Get rid of internal SRAM handling
v3: Fix minor issue in last patch to check for null sram_pool if no sram phandle is given in DT. Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) use drivers/misc/sram.c driver instead of the omap internal implementation for SRAM handling. Previous discussion can be found at [1]. Regards, Dave [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/195588.html Rajendra Nayak (3): ARM: AM335x: Get rid of unused sram init function ARM: OMAP4+: Move SRAM data to DT ARM: OMAP4+: Remove static iotable mappings for SRAM Documentation/devicetree/bindings/arm/omap/mpu.txt | 3 ++ arch/arm/boot/dts/am33xx.dtsi | 5 ++- arch/arm/boot/dts/am4372.dtsi | 5 +++ arch/arm/boot/dts/omap4.dtsi | 6 arch/arm/boot/dts/omap5.dtsi | 8 - arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-omap2/io.c | 17 -- arch/arm/mach-omap2/omap4-common.c | 22 +++- arch/arm/mach-omap2/sram.c | 39 +- arch/arm/mach-omap2/sram.h | 7 10 files changed, 46 insertions(+), 67 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
* Mauro Carvalho Chehab mche...@infradead.org [140909 17:52]: Em Tue, 09 Sep 2014 12:36:54 -0300 Mauro Carvalho Chehab m.che...@samsung.com escreveu: Em Tue, 9 Sep 2014 15:41:58 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote: We want to be able to COMPILE_TEST the omap1_camera driver. It compiles fine, but it fails linkediting: ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_dma_link_lch [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_burst_mode [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_src_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_transfer_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! So, add some stub functions to avoid it. The real answer to this is to find someone who still uses it, and convert it to the DMA engine API. If there's no users, the driver might as well be killed off. Hmm... it seems that there are still several drivers still relying on the functions declared at: omap-dma.h: $ grep extern include/linux/omap-dma.h |perl -ne 'print $1\n if (m/extern\s\S+\s(.*)\(/)' funcs git grep -f funcs -l arch/arm/mach-omap1/pm.c arch/arm/mach-omap2/pm24xx.c arch/arm/plat-omap/dma.c drivers/dma/omap-dma.c drivers/media/platform/omap/omap_vout_vrfb.c drivers/media/platform/omap3isp/isphist.c drivers/media/platform/soc_camera/omap1_camera.c drivers/mtd/onenand/omap2.c drivers/usb/gadget/udc/omap_udc.c drivers/usb/musb/tusb6010_omap.c drivers/video/fbdev/omap/omapfb_main.c include/linux/omap-dma.h Perhaps we can remove the header and mark all the above as BROKEN. No, not quite yet. That would currently cause major issues for omap2 and omap3. If nobody fixes, we can strip all of them from the Kernel. Are all the functions declared at omap-dma.h part of the old DMA API that should be deprecated? For the drivers yes. For the platform code, there are few functions needed, that's at least omap_dma_global_context_save() and omap_dma_global_context_restore(). But those can be in a local header file in arch/arm/plat-omap/include/plat. If so, it seems that the OMAP2 and OMAP3 also depends on this thing, as all the PM code for OMAP depends on the functions declared inside omap-dma.h, and marking them as BROKEN causes compilation to failure: arch/arm/mach-omap2/built-in.o: In function `omap3_save_scratchpad_contents': :(.text+0x798): undefined reference to `omap3_restore_3630' :(.text+0x7a8): undefined reference to `omap3_restore' :(.text+0x7ac): undefined reference to `omap3_restore_es3' arch/arm/mach-omap2/built-in.o: In function `omap3_sram_restore_context': :(.text+0x925c): undefined reference to `omap_push_sram_idle' arch/arm/mach-omap2/built-in.o: In function `option_set': :(.text+0xc15c): undefined reference to `omap3_pm_off_mode_enable' arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_set': :(.text+0xc1a0): undefined reference to `omap3_pm_set_suspend_state' arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_get': :(.text+0xc1e4): undefined reference to `omap3_pm_get_suspend_state' arch/arm/mach-omap2/built-in.o: In function `omap3_enter_idle_bm': :(.text+0xc7ec): undefined reference to `omap_sram_idle' :(.text+0xc848): undefined reference to `pm34xx_errata' arch/arm/mach-omap2/built-in.o: In function `omap2420_init_late': :(.init.text+0xf64): undefined reference to `omap2_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap2430_init_late': :(.init.text+0x1024): undefined reference to `omap2_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3_init_late': :(.init.text+0x1248): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3430_init_late': :(.init.text+0x1264): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap35xx_init_late': :(.init.text+0x1280): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3630_init_late': :(.init.text+0x129c): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `am35xx_init_late': :(.init.text+0x12b8): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o::(.init.text+0x12d4): more undefined references to `omap3_pm_init' follow This was
Re: 3.15+: omap4: mmc: multi_v7: can't boot off mmc
On 17:33-20140910, Paolo Pisati wrote: I'm having an hard time making the vanilla v7_defconfig boot off the mmc on my pandaboard: V3.15: https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-vanilla.txt https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-es.txt v3.16: https://github.com/nmenon/kernel-test-logs/blob/v3.16/multi_v7_defconfig/pandaboard-es.txt https://github.com/nmenon/kernel-test-logs/blob/v3.16/multi_v7_defconfig/pandaboard-vanilla.txt Latest tag: v3.17-rc4 https://github.com/nmenon/kernel-test-logs/blob/v3.17-rc4/multi_v7_defconfig/pandaboard-es.txt https://github.com/nmenon/kernel-test-logs/blob/v3.17-rc4/multi_v7_defconfig/pandaboard-vanilla.txt You might be interested in using partuuid to be careful about the probe order deltas that may take place. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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 v8 00/18] 8250-core based serial driver for OMAP + DMA
On 09/10/2014 04:15 PM, Frans Klaver wrote: On Tue, Sep 09, 2014 at 09:41:20PM +0200, Sebastian Andrzej Siewior wrote: On 09/08/2014 08:33 PM, Frans Klaver wrote: Thanks. I'll give it a spin on Wednesday. Could you please pull the upcoming v9 first? git://git.breakpoint.cc/bigeasy/linux.git uart_v9_pre1 This solves a few of my am335x related issues. Using v9_pre1, I get a kernel panic in edma_dma_pause() on echan-edesc being NULL. I do get data before this happens. This is at high speed, high rate. No mention of the irq having too much to do, though. The more data I transmit, the more likely this is to occur. Hmm. This shouldn't happen because if dma-rx_running is set, then there should be a descriptor to pause. Could check how this could happen? (and which event tries to do so) In the meantime, the lower part of [0] should fix the NULL bug. [0] https://lkml.org/lkml/2014/7/29/506 I don't currently have the setup to lower the baudrate. I would probably need to reproduce this on a beaglebone, instead of our custom board. I'll see if I can do that. If you need more info, just let me know. I just pushed uart_v9_pre2 and I will post it once I rebased it on top Greg's latest. There was a bug where THRE could be active longer than needed caused a few not needed interrupts until the FIFO was empty again. My less on file test case did not fail anymore with this. Thanks, Frans Sebastian -- To unsubscribe from this list: send the line unsubscribe 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/3] OMAP4+: Get rid of internal SRAM handling
On 11:04-20140910, Dave Gerlach wrote: v3: Fix minor issue in last patch to check for null sram_pool if no sram phandle is given in DT. Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) use drivers/misc/sram.c driver instead of the omap internal implementation for SRAM handling. Previous discussion can be found at [1]. Regards, Dave [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/195588.html Rajendra Nayak (3): ARM: AM335x: Get rid of unused sram init function ARM: OMAP4+: Move SRAM data to DT ARM: OMAP4+: Remove static iotable mappings for SRAM Documentation/devicetree/bindings/arm/omap/mpu.txt | 3 ++ arch/arm/boot/dts/am33xx.dtsi | 5 ++- arch/arm/boot/dts/am4372.dtsi | 5 +++ arch/arm/boot/dts/omap4.dtsi | 6 arch/arm/boot/dts/omap5.dtsi | 8 - arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-omap2/io.c | 17 -- arch/arm/mach-omap2/omap4-common.c | 22 +++- arch/arm/mach-omap2/sram.c | 39 +- arch/arm/mach-omap2/sram.h | 7 10 files changed, 46 insertions(+), 67 deletions(-) Could you please provide logs for the following: a) Low power transition tests for OMAP3,4 on all available platforms as well? b) provide bootlogs on all omap2plus platforms to ensure we have no regressions. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCHv3 2/2] mailbox/omap: add support for parsing dt devices
Logic has been added to the OMAP2+ mailbox code to parse the
mailbox dt nodes and construct the different sub-mailboxes
associated with the instance. The DT representation of the
sub-mailbox devices is different from legacy platform data
representation to allow flexibility of interrupt configuration
between Tx and Rx fifos (to also possibly allow simplex devices
in the future). The DT representation gathers similar information
that was being passed previously through the platform data, except
for the interrupt type information, which is gathered through driver
compatible match data.
The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Pavel Machek pa...@ucw.cz
---
drivers/mailbox/omap-mailbox.c | 156 ++---
1 file changed, 132 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a27e00e..bcc7ee1 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -31,6 +31,7 @@
#include linux/err.h
#include linux/notifier.h
#include linux/module.h
+#include linux/of_device.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/platform_data/mailbox-omap.h
@@ -94,6 +95,18 @@ struct omap_mbox_device {
struct list_head elem;
};
+struct omap_mbox_fifo_info {
+ int tx_id;
+ int tx_usr;
+ int tx_irq;
+
+ int rx_id;
+ int rx_usr;
+ int rx_irq;
+
+ const char *name;
+};
+
struct omap_mbox {
const char *name;
int irq;
@@ -587,24 +600,118 @@ static int omap_mbox_unregister(struct omap_mbox_device
*mdev)
return 0;
}
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = ti,omap2-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = ti,omap3-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = ti,omap4-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE2,
+ },
+ {
+ /* end */
+ },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev-dev.platform_data;
- struct omap_mbox_dev_info *info;
+ struct omap_mbox_dev_info *info = NULL;
+ struct omap_mbox_fifo_info *finfo, *finfoblk;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
- u32 intr_type;
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *child;
+ const struct of_device_id *match;
+ u32 intr_type, info_count;
+ u32 num_users, num_fifos;
+ u32 tmp[3];
u32 l;
int i;
- if (!pdata || !pdata-info_cnt || !pdata-info) {
+ if (!node (!pdata || !pdata-info_cnt || !pdata-info)) {
pr_err(%s: platform not supported\n, __func__);
return -ENODEV;
}
+ if (node) {
+ match = of_match_device(omap_mailbox_of_match, pdev-dev);
+ if (!match)
+ return -ENODEV;
+ intr_type = (u32)match-data;
+
+ if (of_property_read_u32(node, ti,mbox-num-users,
+num_users))
+ return -ENODEV;
+
+ if (of_property_read_u32(node, ti,mbox-num-fifos,
+num_fifos))
+ return -ENODEV;
+
+ info_count = of_get_available_child_count(node);
+ if (!info_count) {
+ dev_err(pdev-dev, no available mbox devices
found\n);
+ return -ENODEV;
+ }
+ } else { /* non-DT device creation */
+ info_count = pdata-info_cnt;
+ info = pdata-info;
+ intr_type = pdata-intr_type;
+ num_users = pdata-num_users;
+ num_fifos = pdata-num_fifos;
+ }
+
+ finfoblk = devm_kzalloc(pdev-dev, info_count * sizeof(*finfoblk),
+ GFP_KERNEL);
+ if (!finfoblk)
+ return -ENOMEM;
+
+ finfo = finfoblk;
+ child = NULL;
+ for (i = 0; i info_count; i++, finfo++) {
+ if (node) {
+ child = of_get_next_available_child(node, child);
+ ret = of_property_read_u32_array(child, ti,mbox-tx,
+
[REPOST PATCHv3 1/2] Documentation: dt: add omap mailbox bindings
Add the device tree bindings document for OMAP2+ mailbox.
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 108 +
1 file changed, 108 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 000..48edc4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,108 @@
+OMAP2+ Mailbox Driver
+=
+
+The OMAP mailbox hardware facilitates communication between different
processors
+using a queued mailbox interrupt mechanism. The IP block is external to the
+various processor subsystems and is connected on an interconnect bus. The
+communication is achieved through a set of registers for message storage and
+interrupt configuration registers.
+
+Each mailbox IP block has a certain number of h/w fifo queues and output
+interrupt lines. An output interrupt line is routed to an interrupt controller
+within a processor subsystem, and there can be more than one line going to a
+specific processor's interrupt controller. The interrupt line connections are
+fixed for an instance and are dictated by the IP integration into the SoC
+(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is
+programmable through a set of interrupt configuration registers, and have a rx
+and tx interrupt source per h/w fifo. Communication between different
processors
+is achieved through the appropriate programming of the rx and tx interrupt
+sources on the appropriate interrupt lines.
+
+The number of h/w fifo queues and interrupt lines dictate the usable registers.
+All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP
+instance. DRA7xx has multiple instances with different number of h/w fifo
queues
+and interrupt lines between different instances. The interrupt lines can also
be
+routed to different processor sub-systems on DRA7xx as they are routed through
+the Crossbar, a kind of interrupt router/multiplexer.
+
+Mailbox Device Node:
+
+A Mailbox device node is used to represent a Mailbox IP instance within a SoC.
+The sub-mailboxes are represented as child nodes of this parent node.
+
+Required properties:
+
+- compatible: Should be one of the following,
+ ti,omap2-mailbox for OMAP2420, OMAP2430 SoCs
+ ti,omap3-mailbox for OMAP3430, OMAP3630 SoCs
+ ti,omap4-mailbox for OMAP44xx, OMAP54xx, AM33xx,
+ AM43xx and DRA7xx SoCs
+- reg: Contains the mailbox register address range (base
+ address and length)
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the OMAP device uses
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
+ device can interrupt
+- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
+
+Child Nodes:
+
+A child node is used for representing the actual sub-mailbox device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name across all the different
+mailbox device nodes.
+
+Required properties:
+
+- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo
+- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo
+
+Sub-mailbox Descriptor Data
+---
+Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of
+data that represent the following:
+Cell #1 (fifo_id) - mailbox fifo id used either for transmitting
+(ti,mbox-tx) or for receiving (ti,mbox-rx)
+Cell #2 (irq_id) - irq identifier index number to use from the parent's
+interrupts data. Should be 0 for most of the cases, a
+positive index value is seen only on mailboxes that
have
+multiple interrupt lines connected to the MPU
processor.
+Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
+associated with generating a tx/rx fifo interrupt.
+
+Example:
+
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ interrupts = GIC_SPI 26
[REPOST PATCHv3 0/2] OMAP Mailbox DT support for 3.18
Hi Tony, This is a repost of just the DT support patches (first 2 patches out of 5) from the OMAP Mailbox framework adoption and DT support series [1], so that they can be picked up for 3.18. The only change is an Acked-by picked up on the second patch. I will repost the third patch separately, and the last 2 patches once a framework branch is published (no changes on those as well). The patches are rebased onto 3.17-rc3. The previous dependencies - the OMAP mailbox DT/hwmod cleanup series [2] and the OMAP mailbox cleanup series [3] have already been merged in 3.17-rc1, so there are no more pending dependencies for these patches. The following shows the boot logs on various OMAP platforms with just these patches: OMAP2 (SDP2430) : http://pastebin.ubuntu.com/8311033 OMAP3 (BeagleXM) : http://pastebin.ubuntu.com/8310760 OMAP4 (PandaBoard): http://pastebin.ubuntu.com/8310633 OMAP5 (OMAP5 uEVM): http://pastebin.ubuntu.com/8310650 DRA7 (DRA7 EVM) : http://pastebin.ubuntu.com/8310700 AM33xx (BeagleBone Black) : http://pastebin.ubuntu.com/8310732 AM43xx (AM437x GP EVM): http://pastebin.ubuntu.com/8310824 [1] http://marc.info/?l=linux-omapm=140668054422693w=2 [2] http://marc.info/?l=linux-omapm=140511512208519w=2 [3] http://www.spinics.net/lists/linux-omap/msg108574.html Suman Anna (2): Documentation: dt: add omap mailbox bindings mailbox/omap: add support for parsing dt devices .../devicetree/bindings/mailbox/omap-mailbox.txt | 108 ++ drivers/mailbox/omap-mailbox.c | 156 + 2 files changed, 240 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCHv3] ARM: dts: OMAP2+: Add sub mailboxes device node information
The sub-mailbox devices are added to the Mailbox DT nodes on
OMAP2420, OMAP2430, OMAP3, AM33xx, AM43xx, OMAP4 and OMAP5
family of SoCs. This data represents the same mailboxes that
used to be represented in hwmod attribute data previously.
The node name is chosen based on the .name field of
omap_mbox_dev_info structure used in the hwmod data.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 4
arch/arm/boot/dts/am4372.dtsi | 4
arch/arm/boot/dts/omap2420.dtsi | 8
arch/arm/boot/dts/omap2430.dtsi | 4
arch/arm/boot/dts/omap3.dtsi| 4
arch/arm/boot/dts/omap4.dtsi| 8
arch/arm/boot/dts/omap5.dtsi| 8
7 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161..e4f165a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -354,6 +354,10 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 0 0 3;
+ };
};
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 9b3d2ba..a0503be 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -168,6 +168,10 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 0 0 3;
+ };
};
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 9be3c12..ae89aad 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -159,6 +159,14 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 6;
+ mbox_dsp: dsp {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
+ mbox_iva: iva {
+ ti,mbox-tx = 2 1 3;
+ ti,mbox-rx = 3 1 3;
+ };
};
timer1: timer@48028000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 1a00f15..b56d7161 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -249,6 +249,10 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 6;
+ mbox_dsp: dsp {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
};
timer1: timer@49018000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 575a49b..b2ae8b8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -334,6 +334,10 @@
interrupts = 26;
ti,mbox-num-users = 2;
ti,mbox-num-fifos = 2;
+ mbox_dsp: dsp {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
};
mcspi1: spi@48098000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 69408b5..bc54d66 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -656,6 +656,14 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = 3 0 0;
+ ti,mbox-rx = 2 0 0;
+ };
};
timer1: timer@4a318000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc8df17..43336c2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -642,6 +642,14 @@
ti,hwmods = mailbox;
[REPOST PATCHv3] OMAP Mailbox DTS patch for 3.18
Hi Tony, This is a repost of just the DTS patch (third patch) from the OMAP Mailbox framework adoption and DT support series [1], for it to be picked up in your dts branch for 3.18. There are no changes, just rebased onto 3.17-rc3. This is the DTS counterpart for the mailbox DT support series for 3.18 [2]. The following shows the boot logs on various OMAP platforms with just this patch: OMAP2 (SDP2430) : http://pastebin.ubuntu.com/8311699 OMAP3 (BeagleXM) : http://pastebin.ubuntu.com/8311804 OMAP4 (PandaBoard): http://pastebin.ubuntu.com/8311837 OMAP5 (OMAP5 uEVM): http://pastebin.ubuntu.com/8311834 DRA7 (DRA7 EVM) : http://pastebin.ubuntu.com/8311859 AM33xx (BeagleBone Black) : http://pastebin.ubuntu.com/8311774 AM43xx (AM437x GP EVM): http://pastebin.ubuntu.com/8311754 [1] http://marc.info/?l=linux-omapm=140668054422693w=2 [2] http://marc.info/?l=linux-omapm=141037688814464w=2 Suman Anna (1): ARM: dts: OMAP2+: Add sub mailboxes device node information arch/arm/boot/dts/am33xx.dtsi | 4 arch/arm/boot/dts/am4372.dtsi | 4 arch/arm/boot/dts/omap2420.dtsi | 8 arch/arm/boot/dts/omap2430.dtsi | 4 arch/arm/boot/dts/omap3.dtsi| 4 arch/arm/boot/dts/omap4.dtsi| 8 arch/arm/boot/dts/omap5.dtsi| 8 7 files changed, 40 insertions(+) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/16] tty: serial: Add 8250-core based omap driver
This patch provides a 8250-core based UART driver for the internal OMAP UART. The long term goal is to provide the same functionality as the current OMAP uart driver and DMA support. I tried to merge omap-serial code together with the 8250-core code. There should should be hardly a noticable difference. The trigger levels are different compared to omap-serial: - omap serial TX: Interrupt comes after TX FIFO has room for 16 bytes. TX of 4096 bytes in one go results in 256 interrupts RX: Interrupt comes after there is on byte in the FIFO. RX of 4096 bytes results in 4096 interrupts. - this driver TX: Interrupt comes once the TX FIFO is empty. TX of 4096 bytes results in 65 interrupts. That means there will be gaps on the line while the driver reloads the FIFO. RX: Interrupt comes once there are 48 bytes in the FIFO or less over longer time frame. We have 1 / 11520 * 10^3 * 16 = 1.38… ms 1.38ms to react and purge the FIFO on 115200,8N1. Since the other driver fired after each byte it had ~5.47ms time to react. This _may_ cause problems if one relies on no missing bytes and has no flow control. On the other hand we get only 85 interrupts for the same amount of data. It has been only tested as console UART on am335x-evm, dra7-evm and beagle bone. I also did some longer raw-transfers to meassure the load. The device name is ttyS based instead of ttyO. If a ttyO based node name is required please ask udev for it. If both driver are activated (this and omap-serial) then this serial driver will take control over the device due to the link order v8…v9: - less on a file seems to hang the am335x after a while. I believe I introduce this bug a while ago since I can reproduce this prior to v8. Fixed by redoing the omap8250_restore_regs() v7…v8: - redo the register write. There is now one function for that which is used from set_termios() and runtime-resume. - drop PORT_OMAP_16750 and move the setup to the omap file. We have our own set termios function anyway (Heikki Krogerus) - use MEM instead of MEM32. TRM of AM/DM37x says that 32bit access on THR might result in data abort. We only need 32bit access in the errata function which is before we use 8250's read function so it doesn't matter. v4…v7: - change trigger levels after some tests with raw transfers. v3…v4: - drop RS485 support - wire up -throttle / -unthrottle v2…v3: - wire up startup shutdown for wakeup-irq handling. - RS485 handling (well the core does). v1…v2: - added runtime PM. Could somebody could please double check this? - added omap_8250_set_termios() Reviewed-by: Tony Lindgren t...@atomide.com Tested-by: Tony Lindgren t...@atomide.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_omap.c | 911 drivers/tty/serial/8250/Kconfig | 9 + drivers/tty/serial/8250/Makefile| 1 + 3 files changed, 921 insertions(+) create mode 100644 drivers/tty/serial/8250/8250_omap.c diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c new file mode 100644 index ..2a187b00ed0a --- /dev/null +++ b/drivers/tty/serial/8250/8250_omap.c @@ -0,0 +1,911 @@ +/* + * 8250-core based driver for the OMAP internal UART + * + * Copyright (C) 2014 Sebastian Andrzej Siewior + * + */ + +#include linux/device.h +#include linux/io.h +#include linux/module.h +#include linux/serial_8250.h +#include linux/serial_core.h +#include linux/serial_reg.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/of.h +#include linux/of_gpio.h +#include linux/of_irq.h +#include linux/delay.h +#include linux/pm_runtime.h +#include linux/console.h +#include linux/pm_qos.h + +#include 8250.h + +#define DEFAULT_CLK_SPEED 4800 + +#define UART_ERRATA_i202_MDR1_ACCESS (1 0) +#define OMAP_UART_WER_HAS_TX_WAKEUP(1 1) + +#define OMAP_UART_FCR_RX_TRIG 6 +#define OMAP_UART_FCR_TX_TRIG 4 + +/* SCR register bitmasks */ +#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7) +#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6) +#define OMAP_UART_SCR_TX_EMPTY (1 3) +#define OMAP_UART_SCR_DMAMODE_MASK (3 1) +#define OMAP_UART_SCR_DMAMODE_1(1 1) +#define OMAP_UART_SCR_DMAMODE_CTL (1 0) + +/* MVR register bitmasks */ +#define OMAP_UART_MVR_SCHEME_SHIFT 30 +#define OMAP_UART_LEGACY_MVR_MAJ_MASK 0xf0 +#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4 +#define OMAP_UART_LEGACY_MVR_MIN_MASK 0x0f +#define OMAP_UART_MVR_MAJ_MASK 0x700 +#define OMAP_UART_MVR_MAJ_SHIFT8 +#define OMAP_UART_MVR_MIN_MASK 0x3f + +#define UART_TI752_TLR_TX 0 +#define UART_TI752_TLR_RX 4 + +#define
[PATCH 00/16 v9] omap 8250 based uart + DMA
the diff of v8…v9 is small: - rebased on top's of Greg's tty-next branch - fixed #10 where we might have THRE interrupt enabled for longer than needed - re-did register setup in #10. Before this less file could freeze the am335x-evm. Sebastian -- To unsubscribe from this list: send the line unsubscribe 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that now there is enough
room in the FIFO and so the transfer begins.
This problem has not been seen on DRA7 or beagle board xm (OMAP3). I am not
sure if this is UART-IP core specific or DMA engine.
The workaround is to use a threshold of one byte, program the DMA
transfer minus one byte and then to put the first byte into the FIFO to
kick start the transfer.
v7…v8:
- fix the problem when get invoked and the FIFO is full.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 3 +++
drivers/tty/serial/8250/8250_dma.c | 39 +++---
include/uapi/linux/serial_reg.h| 1 +
3 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index fbed1636e9c4..09489b391568 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -82,6 +82,9 @@ struct serial8250_config {
#define UART_BUG_PARITY(1 4)/* UART mishandles parity if
FIFO enabled */
#define UART_BUG_DMA_RX(1 5)/* UART needs DMA RX req before
there is
data in FIFO */
+#define UART_BUG_DMA_TX(1 6)/* UART needs one byte in FIFO
for
+ kickstart */
+
#define PROBE_RSA (1 0)
#define PROBE_ANY (~0)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 3674900a1f14..48dc57aad0dd 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -83,6 +83,7 @@ int serial8250_tx_dma(struct uart_8250_port *p)
struct uart_8250_dma*dma = p-dma;
struct circ_buf *xmit = p-port.state-xmit;
struct dma_async_tx_descriptor *desc;
+ unsigned intskip_byte = 0;
int ret;
if (uart_tx_stopped(p-port) || dma-tx_running ||
@@ -91,10 +92,40 @@ int serial8250_tx_dma(struct uart_8250_port *p)
dma-tx_size = CIRC_CNT_TO_END(xmit-head, xmit-tail, UART_XMIT_SIZE);
+ if (p-bugs UART_BUG_DMA_TX) {
+ u8 tx_lvl;
+
+ /*
+* We need to put the first byte into the FIFO in order to start
+* the DMA transfer. For transfers smaller than four bytes we
+* don't bother doing DMA at all. It seem not matter if there
+* are still bytes in the FIFO from the last transfer (in case
+* we got here directly from __dma_tx_complete()). Bytes leaving
+* the FIFO seem not to trigger the DMA transfer. It is really
+* the byte that we put into the FIFO.
+* If the FIFO is already full then we most likely got here from
+* __dma_tx_complete(). And this means the DMA engine just
+* completed its work. We don't have to wait the complete 86us
+* at 115200,8n1 but around 60us (not to mention lower
+* baudrates). So in that case we take the interrupt and try
+* again with an empty FIFO.
+*/
+ tx_lvl = serial_in(p, UART_OMAP_TX_LVL);
+ if (tx_lvl == p-tx_loadsz) {
+ ret = -EBUSY;
+ goto err;
+ }
+ if (dma-tx_size 4) {
+ ret = -EINVAL;
+ goto err;
+ }
+ skip_byte = 1;
+ }
+
desc = dmaengine_prep_slave_single(dma-txchan,
- dma-tx_addr + xmit-tail,
- dma-tx_size, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ dma-tx_addr + xmit-tail + skip_byte,
+ dma-tx_size - skip_byte, DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc) {
ret = -EBUSY;
goto err;
@@ -118,6 +149,8 @@ int serial8250_tx_dma(struct uart_8250_port *p)
serial_out(p, UART_IER, p-ier);
}
}
+ if (skip_byte)
+ serial_out(p, UART_TX, xmit-buf[xmit-tail]);
return 0;
err:
dma-tx_err = 1;
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index df6c9ab6b0cd..53af3b790129 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -359,6 +359,7 @@
#define UART_OMAP_SYSC
[PATCH 07/16] tty: serial: 8250_dma: handle error on TX submit
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up-dma is set
and so serial8250_tx_chars() won't be invoked. We end up with plenty of
interrupts and some too much work for irq output.
This patch introduces dma_tx_err in struct uart_8250_port to signal that
the last invocation of serial8250_tx_dma() failed so we can fill the TX
FIFO manually. Should the next invocation of serial8250_start_tx()
succeed then the dma_tx_err flag along with the THRI bit is removed and
DMA only usage may continue.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 4 +++-
drivers/tty/serial/8250/8250_dma.c | 30 +-
3 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 1bcb4b2141a6..a63d198f8d03 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -41,6 +41,7 @@ struct uart_8250_dma {
size_t tx_size;
unsigned char tx_running:1;
+ unsigned char tx_err: 1;
};
struct old_serial_port {
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 139f3d2b8aa9..9f961ea82564 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1594,8 +1594,10 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
status = serial8250_rx_chars(up, status);
}
serial8250_modem_status(up);
- if (!up-dma (status UART_LSR_THRE))
+ if ((!up-dma || (up-dma up-dma-tx_err))
+ (status UART_LSR_THRE)) {
serial8250_tx_chars(up);
+ }
spin_unlock_irqrestore(port-lock, flags);
return 1;
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 148ffe4c232f..69e54abb6e71 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -36,8 +36,16 @@ static void __dma_tx_complete(void *param)
if (uart_circ_chars_pending(xmit) WAKEUP_CHARS)
uart_write_wakeup(p-port);
- if (!uart_circ_empty(xmit) !uart_tx_stopped(p-port))
- serial8250_tx_dma(p);
+ if (!uart_circ_empty(xmit) !uart_tx_stopped(p-port)) {
+ int ret;
+
+ ret = serial8250_tx_dma(p);
+ if (ret) {
+ dma-tx_err = 1;
+ p-ier |= UART_IER_THRI;
+ serial_port_out(p-port, UART_IER, p-ier);
+ }
+ }
spin_unlock_irqrestore(p-port.lock, flags);
}
@@ -69,6 +77,7 @@ int serial8250_tx_dma(struct uart_8250_port *p)
struct uart_8250_dma*dma = p-dma;
struct circ_buf *xmit = p-port.state-xmit;
struct dma_async_tx_descriptor *desc;
+ int ret;
if (uart_tx_stopped(p-port) || dma-tx_running ||
uart_circ_empty(xmit))
@@ -80,8 +89,10 @@ int serial8250_tx_dma(struct uart_8250_port *p)
dma-tx_addr + xmit-tail,
dma-tx_size, DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!desc)
- return -EBUSY;
+ if (!desc) {
+ ret = -EBUSY;
+ goto err;
+ }
dma-tx_running = 1;
@@ -94,8 +105,17 @@ int serial8250_tx_dma(struct uart_8250_port *p)
UART_XMIT_SIZE, DMA_TO_DEVICE);
dma_async_issue_pending(dma-txchan);
-
+ if (dma-tx_err) {
+ dma-tx_err = 0;
+ if (p-ier UART_IER_THRI) {
+ p-ier = ~UART_IER_THRI;
+ serial_out(p, UART_IER, p-ier);
+ }
+ }
return 0;
+err:
+ dma-tx_err = 1;
+ return ret;
}
EXPORT_SYMBOL_GPL(serial8250_tx_dma);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/16] tty: serial: 8250_core: remove UART_IER_RDI in serial8250_stop_rx()
serial8250_do_startup() adds UART_IER_RDI and UART_IER_RLSI to ier. serial8250_stop_rx() should remove both. This is what the serial-omap driver has been doing and is now moved to the 8250-core since it does no look to be *that* omap specific. Cc: heikki.kroge...@linux.intel.com Reviewed-by: Tony Lindgren t...@atomide.com Tested-by: Tony Lindgren t...@atomide.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index ac88e66df65d..139f3d2b8aa9 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -1390,7 +1390,7 @@ static void serial8250_stop_rx(struct uart_port *port) serial8250_rpm_get(up); - up-ier = ~UART_IER_RLSI; + up-ier = ~(UART_IER_RLSI | UART_IER_RDI); up-port.read_status_mask = ~UART_LSR_DR; serial_port_out(port, UART_IER, up-ier); -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/16] tty: serial: 8250_dma: enqueue RX dma again on completion.
The omap needs a DMA request pending right away. If it is enqueued once
the bytes are in the FIFO then nothing will happen and the FIFO will be
later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it was
aborted on error. The first enqueue will happen in the driver in
startup.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 3 ++-
drivers/tty/serial/8250/8250_core.c | 3 +++
drivers/tty/serial/8250/8250_dma.c | 12 +---
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index a63d198f8d03..fbed1636e9c4 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -80,7 +80,8 @@ struct serial8250_config {
#define UART_BUG_NOMSR (1 2)/* UART has buggy MSR status bits
(Au1x00) */
#define UART_BUG_THRE (1 3)/* UART has buggy THRE reassertion */
#define UART_BUG_PARITY(1 4)/* UART mishandles parity if
FIFO enabled */
-
+#define UART_BUG_DMA_RX(1 5)/* UART needs DMA RX req before
there is
+ data in FIFO */
#define PROBE_RSA (1 0)
#define PROBE_ANY (~0)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 9f961ea82564..39b1c7318f17 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1592,6 +1592,9 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
if (!up-dma || dma_err)
status = serial8250_rx_chars(up, status);
+
+ if (dma_err up-bugs UART_BUG_DMA_RX)
+ serial8250_rx_dma(up, 0);
}
serial8250_modem_status(up);
if ((!up-dma || (up-dma up-dma-tx_err))
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 69e54abb6e71..3674900a1f14 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -50,9 +50,8 @@ static void __dma_tx_complete(void *param)
spin_unlock_irqrestore(p-port.lock, flags);
}
-static void __dma_rx_complete(void *param)
+static void __dma_rx_do_complete(struct uart_8250_port *p, bool error)
{
- struct uart_8250_port *p = param;
struct uart_8250_dma*dma = p-dma;
struct tty_port *tty_port = p-port.state-port;
struct dma_tx_state state;
@@ -68,10 +67,17 @@ static void __dma_rx_complete(void *param)
tty_insert_flip_string(tty_port, dma-rx_buf, count);
p-port.icount.rx += count;
+ if (!error p-bugs UART_BUG_DMA_RX)
+ serial8250_rx_dma(p, 0);
tty_flip_buffer_push(tty_port);
}
+static void __dma_rx_complete(void *param)
+{
+ __dma_rx_do_complete(param, false);
+}
+
int serial8250_tx_dma(struct uart_8250_port *p)
{
struct uart_8250_dma*dma = p-dma;
@@ -139,7 +145,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
*/
if (dma_status == DMA_IN_PROGRESS) {
dmaengine_pause(dma-rxchan);
- __dma_rx_complete(p);
+ __dma_rx_do_complete(p, true);
}
return -ETIMEDOUT;
default:
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/16] tty: serial: 8250_core: add run time pm
While comparing the OMAP-serial and the 8250 part of this I noticed that
the latter does not use run time-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access. This has to be enabled from userland _and_ UART_CAP_RPM is
required for this.
The runtime PM can usually work transparently in the background however
there is one exception to this: After serial8250_tx_chars() completes
there still may be unsent bytes in the FIFO (depending on CPU speed vs
baud rate + flow control). Even if the TTY-buffer is empty we do not
want RPM to disable the device because it won't send the remaining
bytes. Instead we leave serial8250_tx_chars() with RPM enabled and wait
for the FIFO empty interrupt. Once we enter serial8250_tx_chars() with
an empty buffer we know that the FIFO is empty and since we are not going
to send anything, we can disable the device.
That xchg() is to ensure that serial8250_tx_chars() can be called
multiple times and only the first invocation will actually invoke the
runtime PM function. So that the last invocation of __stop_tx() will
disable runtime pm.
NOTE: do not enable RPM on the device unless you know what you do! If
the device goes idle, it won't be woken up by incomming RX data _unless_
there is a wakeup irq configured which is usually the RX pin configure
for wakeup via the reset module. The RX activity will then wake up the
device from idle. However the first character is garbage and lost. The
following bytes will be received once the device is up in time. On the
beagle board xm (omap3) it takes approx 13ms from the first wakeup byte
until the first byte that is received properly if the device was in
core-off.
v5…v8:
- drop RPM from serial8250_set_mctrl() it will be used in
restore path which already has RPM active and holds
dev-power.lock
v4…v5:
- add a wrapper around rpm function and introduce UART_CAP_RPM
to ensure RPM put is invoked after the TX FIFO is empty.
v3…v4:
- added runtime to the console code
- removed device_may_wakeup() from serial8250_set_sleep()
Cc: mika.westerb...@linux.intel.com
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 133
include/linux/serial_8250.h | 1 +
3 files changed, 122 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 85bfec58d77c..1bcb4b2141a6 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -72,6 +72,7 @@ struct serial8250_config {
#define UART_CAP_UUE (1 12) /* UART needs IER bit 6 set (Xscale) */
#define UART_CAP_RTOIE (1 13) /* UART needs IER bit 4 set (Xscale,
Tegra) */
#define UART_CAP_HFIFO (1 14) /* UART has a hidden FIFO */
+#define UART_CAP_RPM (1 15) /* Runtime PM is active while idle */
#define UART_BUG_QUOT (1 0)/* UART has buggy quot LSB */
#define UART_BUG_TXEN (1 1)/* UART has buggy TX IIR status */
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 68c44d97091b..3cf5c98013e4 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -38,6 +38,7 @@
#include linux/mutex.h
#include linux/slab.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#ifdef CONFIG_SPARC
#include linux/sunserialcore.h
#endif
@@ -540,6 +541,53 @@ void serial8250_clear_and_reinit_fifos(struct
uart_8250_port *p)
}
EXPORT_SYMBOL_GPL(serial8250_clear_and_reinit_fifos);
+static void serial8250_rpm_get(struct uart_8250_port *p)
+{
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+ pm_runtime_get_sync(p-port.dev);
+}
+
+static void serial8250_rpm_put(struct uart_8250_port *p)
+{
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+ pm_runtime_mark_last_busy(p-port.dev);
+ pm_runtime_put_autosuspend(p-port.dev);
+}
+
+/*
+ * This two wrapper ensure, that enable_runtime_pm_tx() can be called more than
+ * once and disable_runtime_pm_tx() will still disable RPM because the fifo is
+ * empty and the HW can idle again.
+ */
+static void serial8250_rpm_get_tx(struct uart_8250_port *p)
+{
+ unsigned char rpm_active;
+
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+
+ rpm_active = xchg(p-rpm_tx_active, 1);
+ if (rpm_active)
+ return;
+ pm_runtime_get_sync(p-port.dev);
+}
+
+static void serial8250_rpm_put_tx(struct uart_8250_port *p)
+{
+ unsigned char rpm_active;
+
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+
+ rpm_active = xchg(p-rpm_tx_active, 0);
+ if (!rpm_active)
+ return;
+
[PATCH 01/16] tty: serial: 8250_core: allow to set -throttle / -unthrottle callbacks
The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core (uart_throttle()) if the feature
flags are set.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 14 ++
include/linux/serial_core.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index a0c1d64f34c5..68c44d97091b 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1319,6 +1319,16 @@ static void serial8250_start_tx(struct uart_port *port)
}
}
+static void serial8250_throttle(struct uart_port *port)
+{
+ port-throttle(port);
+}
+
+static void serial8250_unthrottle(struct uart_port *port)
+{
+ port-unthrottle(port);
+}
+
static void serial8250_stop_rx(struct uart_port *port)
{
struct uart_8250_port *up = up_to_u8250p(port);
@@ -2912,6 +2922,8 @@ static struct uart_ops serial8250_pops = {
.get_mctrl = serial8250_get_mctrl,
.stop_tx= serial8250_stop_tx,
.start_tx = serial8250_start_tx,
+ .throttle = serial8250_throttle,
+ .unthrottle = serial8250_unthrottle,
.stop_rx= serial8250_stop_rx,
.enable_ms = serial8250_enable_ms,
.break_ctl = serial8250_break_ctl,
@@ -3462,6 +3474,8 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
uart-capabilities = up-capabilities;
uart-rs485_config = up-rs485_config;
uart-rs485 = up-rs485;
+ uart-port.throttle = up-port.throttle;
+ uart-port.unthrottle = up-port.unthrottle;
/* Take tx_loadsz from fifosize if it wasn't set separately */
if (uart-port.fifosize !uart-tx_loadsz)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 3bd7d55eebce..80936c68a7d3 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -124,6 +124,8 @@ struct uart_port {
struct ktermios *old);
int (*startup)(struct uart_port *port);
void(*shutdown)(struct uart_port *port);
+ void(*throttle)(struct uart_port *port);
+ void(*unthrottle)(struct uart_port *port);
int (*handle_irq)(struct uart_port *);
void(*pm)(struct uart_port *, unsigned int state,
unsigned int old);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/16] tty: serial: 8250_core: use the -line argument as a hint in serial8250_find_match_or_unused()
Tony noticed that the old omap-serial driver picked the uart number based on the hint given from device tree or platform device's id. The 8250 based omap driver doesn't do this because the core code does not honour the -line argument which is passed by the driver. This patch aims to keep the same behaviour as with omap-serial. The function will first try to use the line suggested -line argument and then fallback to the old strategy in case the port is taken. That means the the third uart will always be ttyS2 even if the previous two have not been enabled in DT. Reviewed-by: Tony Lindgren t...@atomide.com Tested-by: Tony Lindgren t...@atomide.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 547afde9fdda..ac88e66df65d 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -3516,6 +3516,11 @@ static struct uart_8250_port *serial8250_find_match_or_unused(struct uart_port * if (uart_match_port(serial8250_ports[i].port, port)) return serial8250_ports[i]; + /* try line number first if still available */ + i = port-line; + if (i nr_uarts serial8250_ports[i].port.type == PORT_UNKNOWN + serial8250_ports[i].port.iobase == 0) + return serial8250_ports[i]; /* * We didn't find a matching entry, so look for the first * free entry. We look for one which hasn't been previously -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/16] tty: serial: 8250_core: read only RX if there is something in the FIFO
The serial8250_do_startup() function unconditionally clears the interrupts and for that it reads from the RX-FIFO without checking if there is a byte in the FIFO or not. This works fine on OMAP4+ HW like AM335x or DRA7. OMAP3630 ES1.1 (which means probably all OMAP3 and earlier) does not like this: |Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 |Internal error: : 1028 [#1] ARM |Modules linked in: |CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-00022-g7edcb57-dirty #1213 |task: de0572c0 ti: de058000 task.ti: de058000 |PC is at mem32_serial_in+0xc/0x1c |LR is at serial8250_do_startup+0x220/0x85c |Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel |Control: 10c5387d Table: 80004019 DAC: 0015 |[c03051d4] (mem32_serial_in) from [c0307fe8] (serial8250_do_startup+0x220/0x85c) |[c0307fe8] (serial8250_do_startup) from [c0309e00] (omap_8250_startup+0x5c/0xe0) |[c0309e00] (omap_8250_startup) from [c030863c] (serial8250_startup+0x18/0x2c) |[c030863c] (serial8250_startup) from [c030394c] (uart_startup+0x78/0x1d8) |[c030394c] (uart_startup) from [c0304678] (uart_open+0xe8/0x114) |[c0304678] (uart_open) from [c02e9e10] (tty_open+0x1a8/0x5a4) Reviewed-by: Tony Lindgren t...@atomide.com Tested-by: Tony Lindgren t...@atomide.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_core.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 3cf5c98013e4..547afde9fdda 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -2088,8 +2088,8 @@ int serial8250_do_startup(struct uart_port *port) /* * Clear the interrupt registers. */ - serial_port_in(port, UART_LSR); - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) UART_LSR_DR) + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); @@ -2250,8 +2250,8 @@ int serial8250_do_startup(struct uart_port *port) * saved flags to avoid getting false values from polling * routines or the previous session. */ - serial_port_in(port, UART_LSR); - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) UART_LSR_DR) + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); up-lsr_saved_flags = 0; @@ -2344,7 +2344,8 @@ void serial8250_do_shutdown(struct uart_port *port) * Read data port to reset things, and then unlink from * the IRQ chain. */ - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) UART_LSR_DR) + serial_port_in(port, UART_RX); serial8250_rpm_put(up); del_timer_sync(up-timer); -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ARM: edma: unconditionally ack the error interrupt
With 8250-dma, 8250-omap and am335x I observe the following:
- start a RX transfer which will finish once the FIFO has enough data
- The TX side starts a large TX transfer, say 1244 bytes. It takes approx
102ms for the transfer to complete
- cancel the RX transfer start the RX transfer a few times
- the TX transfer completes. dma_irq_handler() notices this and
schedules the completion callback
- dma_ccerr_handler() is invoked. It returns IRQ_NONE because all four
checked registers return 0.
- the last irq handler is repeated a few times until the irq core shuts it
down.
I see the above describes pattern also without dma_ccerr_handler()
beeing invoked. But if it is invoked, it always _after_ the dma interrupt
handler for the TX handler was handled. If I disable TX-DMA for the UART
then I don't see this dma_ccerr_handler() at all.
Testing longer I see two addition scenarios of dma_ccerr_handler():
- EDMA_EMR0 reports 0x0400 (the channel used by TX-UART).
edma_callback() reports looks like slot is null. Looks harmless.
- EDMA_EMR0 reports the same values but later in the loop where a match
search again EDMA_EMR0 reports 0 and so thing is done.
Since it looks like the EDMA_EMR0 is loosing its content before the
dma_ccerr_handler() is invoked, I suggest to unconditionally ack the
interrupt so the irq core does not shut it down.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/common/edma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 88099175fc56..b31f3b7b3851 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -432,8 +432,10 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0)
(edma_read_array(ctlr, EDMA_EMR, 1) == 0)
(edma_read(ctlr, EDMA_QEMR) == 0)
- (edma_read(ctlr, EDMA_CCERR) == 0))
+ (edma_read(ctlr, EDMA_CCERR) == 0)) {
+ edma_write(ctlr, EDMA_EEVAL, 1);
return IRQ_NONE;
+ }
while (1) {
int j = -1;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/16] tty: serial: 8250: omap: add dma support
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the RX-FIFO mean that no DMA transfer will happen and the UART will send a
RX-timeout _or_ RDI event at which point the FIFO will be manually purged.
There is a workaround for TX-DMA on AM33xx where we put the first byte
into the FIFO to kick start the DMA process. Haven't seen this problem on
OMAP36xx (beagle board xm) or DRA7xx.
On AM375x there is Usage Note 2.7: UART: Cannot Acknowledge Idle
Requests in Smartidle Mode When Configured for DMA Operations in the
errata document. This problem persists even after disabling DMA in the
UART and will be addressed in the HWMOD.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 2a187b00ed0a..5312c9e7ab15 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -366,6 +366,10 @@ static void omap_8250_set_termios(struct uart_port *port,
priv-scr = OMAP_UART_SCR_RX_TRIG_GRANU1_MASK | OMAP_UART_SCR_TX_EMPTY |
OMAP_UART_SCR_TX_TRIG_GRANU1_MASK;
+ if (up-dma)
+ priv-scr |= OMAP_UART_SCR_DMAMODE_1 |
+ OMAP_UART_SCR_DMAMODE_CTL;
+
priv-xon = termios-c_cc[VSTART];
priv-xoff = termios-c_cc[VSTOP];
@@ -548,6 +552,11 @@ static int omap_8250_startup(struct uart_port *port)
priv-wer |= OMAP_UART_TX_WAKEUP_EN;
serial_out(up, UART_OMAP_WER, priv-wer);
+ if (up-dma) {
+ serial8250_rx_dma(up, 0);
+ priv-dma_active = true;
+ }
+
pm_runtime_mark_last_busy(port-dev);
pm_runtime_put_autosuspend(port-dev);
return 0;
@@ -566,6 +575,10 @@ static void omap_8250_shutdown(struct uart_port *port)
struct omap8250_priv *priv = port-private_data;
flush_work(priv-qos_work);
+ if (up-dma) {
+ serial8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
+ priv-dma_active = false;
+ }
pm_runtime_get_sync(port-dev);
@@ -613,6 +626,13 @@ static void omap_8250_unthrottle(struct uart_port *port)
pm_runtime_put_autosuspend(port-dev);
}
+#ifdef CONFIG_SERIAL_8250_DMA
+static bool the_no_dma_filter_fn(struct dma_chan *chan, void *param)
+{
+ return false;
+}
+#endif
+
static int omap8250_probe(struct platform_device *pdev)
{
struct resource *regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -712,6 +732,30 @@ static int omap8250_probe(struct platform_device *pdev)
pm_runtime_get_sync(pdev-dev);
omap_serial_fill_features_erratas(up, priv);
+#ifdef CONFIG_SERIAL_8250_DMA
+ if (pdev-dev.of_node) {
+ /*
+* Oh DMA support. If there are no DMA properties in the DT then
+* we will fall back to a generic DMA channel which does not
+* really work here. To ensure that we do not get a generic DMA
+* channel assigned, we have the the_no_dma_filter_fn() here.
+* To avoid failed to request DMA messages we check for DMA
+* properties in DT.
+*/
+ ret = of_property_count_strings(pdev-dev.of_node, dma-names);
+ if (ret == 2) {
+ up.dma = priv-omap8250_dma;
+ priv-omap8250_dma.fn = the_no_dma_filter_fn;
+ priv-omap8250_dma.rx_size = RX_TRIGGER;
+ priv-omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
+ priv-omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
+
+ if (of_machine_is_compatible(ti,am33xx))
+ up.bugs |= UART_BUG_DMA_TX;
+ up.bugs |= UART_BUG_DMA_RX;
+ }
+ }
+#endif
ret = serial8250_register_8250_port(up);
if (ret 0) {
dev_err(pdev-dev, unable to register 8250 port\n);
@@ -848,6 +892,8 @@ static int omap8250_runtime_suspend(struct device *dev)
}
omap8250_enable_wakeup(priv, true);
+ if (priv-dma_active)
+ serial8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
priv-latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
schedule_work(priv-qos_work);
@@ -872,6 +918,9 @@ static int omap8250_runtime_resume(struct device *dev)
if (loss_cntx)
omap8250_restore_regs(up);
+ if (priv-dma_active)
+ serial8250_rx_dma(up, 0);
+
priv-latency =
[PATCH 10/16] tty: serial: 8250_dma: optimize the xmit path due to UART_BUG_DMA_TX
Due to UART_BUG_DMA_TX the am335x has to put the first one byte into the
TX FIFO to get things going. If we get to serial8250_tx_dma() via
__dma_tx_complete() then the DMA engine just finished and the FIFO is
full and we can't put the first byte into the TX FIFO as kick start so
we leave with THRI enabled.
The result is that we end up manually filling the FIFO. We could be a
little better at this and try DMA once again. If it works, it works and
if not we do it manually.
v8…v9:
- fix receiving THRI interrupts after DMA operation completed and
the next one would fail (length 4 bytes).
- while at it makes sure we fail with an error for zero lenght
transfers with the TX bug or runtime PM
- make sure THRI is always cleared after DMA is fired.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 17 +++--
drivers/tty/serial/8250/8250_dma.c | 27 +++
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 39b1c7318f17..660d19771bbe 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1599,9 +1599,22 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
serial8250_modem_status(up);
if ((!up-dma || (up-dma up-dma-tx_err))
(status UART_LSR_THRE)) {
- serial8250_tx_chars(up);
- }
+ if (!up-dma) {
+ serial8250_tx_chars(up);
+ } else {
+ if (uart_tx_stopped(up-port) ||
+ uart_circ_empty(up-port.state-xmit)) {
+ up-dma-tx_err = 0;
+ serial8250_tx_chars(up);
+ } else {
+ /* try again due to UART_BUG_DMA_TX+full fifo */
+ dma_err = serial8250_tx_dma(up);
+ if (dma_err)
+ serial8250_tx_chars(up);
+ }
+ }
+ }
spin_unlock_irqrestore(port-lock, flags);
return 1;
}
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 48dc57aad0dd..e836d128e63a 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -86,12 +86,23 @@ int serial8250_tx_dma(struct uart_8250_port *p)
unsigned intskip_byte = 0;
int ret;
- if (uart_tx_stopped(p-port) || dma-tx_running ||
- uart_circ_empty(xmit))
+ if (dma-tx_running)
return 0;
+ if (uart_tx_stopped(p-port) || uart_circ_empty(xmit)) {
- dma-tx_size = CIRC_CNT_TO_END(xmit-head, xmit-tail, UART_XMIT_SIZE);
+ /*
+* Even if no data, we need to return an error for the two cases
+* below so serial8250_tx_chars() is invoked and properly clears
+* THRI and/or runtime suspend.
+*/
+ if (dma-tx_err || p-capabilities UART_CAP_RPM) {
+ ret = -EBUSY;
+ goto err;
+ }
+ return 0;
+ }
+ dma-tx_size = CIRC_CNT_TO_END(xmit-head, xmit-tail, UART_XMIT_SIZE);
if (p-bugs UART_BUG_DMA_TX) {
u8 tx_lvl;
@@ -142,12 +153,12 @@ int serial8250_tx_dma(struct uart_8250_port *p)
UART_XMIT_SIZE, DMA_TO_DEVICE);
dma_async_issue_pending(dma-txchan);
- if (dma-tx_err) {
+ if (dma-tx_err)
dma-tx_err = 0;
- if (p-ier UART_IER_THRI) {
- p-ier = ~UART_IER_THRI;
- serial_out(p, UART_IER, p-ier);
- }
+
+ if (p-ier UART_IER_THRI) {
+ p-ier = ~UART_IER_THRI;
+ serial_out(p, UART_IER, p-ier);
}
if (skip_byte)
serial_out(p, UART_TX, xmit-buf[xmit-tail]);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/16] arm: dts: dra7: add DMA properties for UART
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152db4cb..f273e3811f75 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -332,6 +332,8 @@
ti,hwmods = uart1;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 49, sdma 50;
+ dma-names = tx, rx;
};
uart2: serial@4806c000 {
@@ -341,6 +343,8 @@
ti,hwmods = uart2;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 51, sdma 52;
+ dma-names = tx, rx;
};
uart3: serial@4802 {
@@ -350,6 +354,8 @@
ti,hwmods = uart3;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 53, sdma 54;
+ dma-names = tx, rx;
};
uart4: serial@4806e000 {
@@ -359,6 +365,8 @@
ti,hwmods = uart4;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 55, sdma 56;
+ dma-names = tx, rx;
};
uart5: serial@48066000 {
@@ -368,6 +376,8 @@
ti,hwmods = uart5;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 63, sdma 64;
+ dma-names = tx, rx;
};
uart6: serial@48068000 {
@@ -377,6 +387,8 @@
ti,hwmods = uart6;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 79, sdma 80;
+ dma-names = tx, rx;
};
uart7: serial@4842 {
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] tty: serial: 8250_dma: add pm runtime
There is nothing to do for RPM in the RX path. If the HW goes off then it
won't assert the DMA line and the transfer won't happen. So we hope that
the HW does not go off for RX to work (DMA or PIO makes no difference
here).
For TX the situation is slightly different. RPM is enabled on
start_tx(). We can't disable RPM on DMA complete callback because there
is still data in the FIFO which is being sent. We have to wait until
the FIFO is empty before we disable it.
For this to happen we fake a TX sent error and enable THRI. Once the
FIFO is empty we receive an interrupt and since the TTY-buffer is still
empty we put RPM via __stop_tx(). Should it been filed then in the
start_tx() path we should program the DMA transfer and remove the error
flag and the THRI bit.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_dma.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 898a6781d0b3..e8850219b150 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -21,6 +21,7 @@ static void __dma_tx_complete(void *param)
struct uart_8250_dma*dma = p-dma;
struct circ_buf *xmit = p-port.state-xmit;
unsigned long flags;
+ bool en_thri = false;
dma_sync_single_for_cpu(dma-txchan-device-dev, dma-tx_addr,
UART_XMIT_SIZE, DMA_TO_DEVICE);
@@ -40,11 +41,16 @@ static void __dma_tx_complete(void *param)
int ret;
ret = serial8250_tx_dma(p);
- if (ret) {
- dma-tx_err = 1;
- p-ier |= UART_IER_THRI;
- serial_port_out(p-port, UART_IER, p-ier);
- }
+ if (ret)
+ en_thri = true;
+
+ } else if (p-capabilities UART_CAP_RPM)
+ en_thri = true;
+
+ if (en_thri) {
+ dma-tx_err = 1;
+ p-ier |= UART_IER_THRI;
+ serial_port_out(p-port, UART_IER, p-ier);
}
spin_unlock_irqrestore(p-port.lock, flags);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/16] arm: dts: am33xx: add DMA properties for UART
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..078a760a4a21 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -200,6 +200,8 @@
reg = 0x44e09000 0x2000;
interrupts = 72;
status = disabled;
+ dmas = edma 26, edma 27;
+ dma-names = tx, rx;
};
uart1: serial@48022000 {
@@ -209,6 +211,8 @@
reg = 0x48022000 0x2000;
interrupts = 73;
status = disabled;
+ dmas = edma 28, edma 29;
+ dma-names = tx, rx;
};
uart2: serial@48024000 {
@@ -218,6 +222,8 @@
reg = 0x48024000 0x2000;
interrupts = 74;
status = disabled;
+ dmas = edma 30, edma 31;
+ dma-names = tx, rx;
};
uart3: serial@481a6000 {
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/16] tty: serial: 8250_dma: handle the UART RDI event while DMA remains idle
Sometimes the OMAP UART does not signal the DMA engine to unload the FIFO.
Usually this happens when we have threshold bytes in the FIFO
and start the DMA transfer. It seems that in those cases the UART won't
trigger the transfer once the requested threshold is reached. In some
rare cases the UART does not trigger the DMA transfer even if programmed
while the FIFO was empty.
In those cases the UART drops an RDI event and we have to empty the FIFO
manually. If we ignore it because the DMA transfer is programmed then we
will enter the function a few times until we receive the RX_TIMEOUT
event. At that point the FIFO is usually full and we risk to overflow
the FIFO.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_dma.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index fa1dc966f394..898a6781d0b3 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -193,6 +193,24 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
__dma_rx_do_complete(p, true);
}
return -ETIMEDOUT;
+ case UART_IIR_RDI:
+ if (p-bugs UART_BUG_DMA_RX)
+ break;
+ /*
+* The OMAP UART is a special BEAST. If we receive RDI we _have_
+* a DMA transfer programmed but it didn't worked. One reason is
+* that we were too slow and there were too many bytes in the
+* FIFO, the UART counted wrong and never kicked the DMA engine
+* to do anything. That means once we receive RDI on OMAP than
+* the DMA won't do anything soon so we have to cancel the DMA
+* transfer and purge the FIFO manually.
+*/
+ if (dma-rx_running) {
+ dmaengine_pause(dma-rxchan);
+ __dma_rx_do_complete(p, true);
+ }
+ return -ETIMEDOUT;
+
default:
break;
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/16] tty: serial: 8250_dma: keep own book keeping about RX transfers
After dmaengine_terminate_all() has been invoked then both DMA drivers
(edma and omap-dma) do not invoke dma_cookie_complete() to mark the
transfer as complete. This dma_cookie_complete() is performed by the
Synopsys DesignWare driver which is probably the only one that is used
by omap8250-dma and hence don't see following problem…
…which is that once a RX transfer has been terminated then following
query of channel status reports DMA_IN_PROGRESS (again: the actual
transfer has been canceled, there is nothing going on anymore).
This means that serial8250_rx_dma() never enqueues another DMA transfer
because it (wrongly) assumes that there is a transer already pending.
Vinod Koul refuses to accept a patch which adds this
dma_cookie_complete() to both drivers and so dmaengine_tx_status() would
report DMA_COMPLETE instead (and behave like the Synopsys DesignWare
driver already does). He argues that I am not allowed to use the cookie
to query the status and that the driver already cleaned everything up after
the invokation of dmaengine_terminate_all().
To end this I add a bookkeeping whether or not a RX-transfer has been
started to the 8250-dma code. It has already been done for the TX side.
*Now* we learn about the RX status based on our bookkeeping and don't
need dmaengine_tx_status() for this anymore.
Cc: vinod.k...@intel.com
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_dma.c | 14 --
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 09489b391568..a7581b37f264 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -42,6 +42,7 @@ struct uart_8250_dma {
unsigned char tx_running:1;
unsigned char tx_err: 1;
+ unsigned char rx_running:1;
};
struct old_serial_port {
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index e836d128e63a..fa1dc966f394 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -60,6 +60,7 @@ static void __dma_rx_do_complete(struct uart_8250_port *p,
bool error)
dma_sync_single_for_cpu(dma-rxchan-device-dev, dma-rx_addr,
dma-rx_size, DMA_FROM_DEVICE);
+ dma-rx_running = 0;
dmaengine_tx_status(dma-rxchan, dma-rx_cookie, state);
dmaengine_terminate_all(dma-rxchan);
@@ -173,21 +174,21 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
{
struct uart_8250_dma*dma = p-dma;
struct dma_async_tx_descriptor *desc;
- struct dma_tx_state state;
- int dma_status;
-
- dma_status = dmaengine_tx_status(dma-rxchan, dma-rx_cookie, state);
switch (iir 0x3f) {
case UART_IIR_RLSI:
/* 8250_core handles errors and break interrupts */
+ if (dma-rx_running) {
+ dmaengine_pause(dma-rxchan);
+ __dma_rx_do_complete(p, true);
+ }
return -EIO;
case UART_IIR_RX_TIMEOUT:
/*
* If RCVR FIFO trigger level was not reached, complete the
* transfer and let 8250_core copy the remaining data.
*/
- if (dma_status == DMA_IN_PROGRESS) {
+ if (dma-rx_running) {
dmaengine_pause(dma-rxchan);
__dma_rx_do_complete(p, true);
}
@@ -196,7 +197,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
break;
}
- if (dma_status)
+ if (dma-rx_running)
return 0;
desc = dmaengine_prep_slave_single(dma-rxchan, dma-rx_addr,
@@ -205,6 +206,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
if (!desc)
return -EBUSY;
+ dma-rx_running = 1;
desc-callback = __dma_rx_complete;
desc-callback_param = p;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] Input: misc: introduce palmas-pwrbutton
Hi Nishanth,
On Thu, Aug 21, 2014 at 02:01:43PM -0500, Nishanth Menon wrote:
On 08/21/2014 01:03 PM, Dmitry Torokhov wrote:
I believe I have taken care of other concerns on v2, but..Arrgh.. I
did not reply to this comment..
BTW, I do not think you need to use of_node_get/put here, it's not going
anywhere.
It has been mentioned as a good practice to ensure we use get_put in
to ensure reference count is appropriately maintained. So, I have'nt
changed that in v3.
You only need to maintain reference count if you pass the handle on.
Otherwise you'd have to do get/put every time you dereference something.
Anyway, I did a few changes to the driver (no need to store current
state, do not fre einput device after unregister, etc.), could you
please tell me if the version below still works for you?
Thanks.
--
Dmitry
Input: introduce palmas-pwrbutton
From: Nishanth Menon n...@ti.com
Many palmas family of PMICs have support for interrupt based power button.
This allows the device to notify the processor of external push button
events over the shared palmas interrupt. However, this event is generated
only during a press operation. Software is supposed to poll(sigh!) for
detecting a release event.
The PMIC also supports ability to power off independent of the software
decisions when the button is pressed for a long duration if the PMIC is
appropriately configured on the platform.
Even though the function is similar to twl4030_pwrbutton, it is
substantially different in operation to belong to a new driver of it's own.
Based on original work done by Girish S Ghongdemath giris...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
.../bindings/input/ti,palmas-pwrbutton.txt | 36 ++
drivers/input/misc/Kconfig | 10 +
drivers/input/misc/Makefile|1
drivers/input/misc/palmas-pwrbutton.c | 330
4 files changed, 377 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
create mode 100644 drivers/input/misc/palmas-pwrbutton.c
diff --git a/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
new file mode 100644
index 000..a3dde8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
@@ -0,0 +1,36 @@
+Texas Instruments Palmas family power button module
+
+This module is part of the Palmas family of PMICs. For more details
+about the whole chip see:
+Documentation/devicetree/bindings/mfd/palmas.txt.
+
+This module provides a simple power button event via an Interrupt.
+
+Required properties:
+- compatible: should be one of the following
+ - ti,palmas-pwrbutton: For Palmas compatible power on button
+- interrupt-parent: Parent interrupt device, must be handle of palmas node.
+- interrupts: Interrupt number of power button submodule on device.
+
+Optional Properties:
+
+- ti,palmas-long-press-seconds: Duration in seconds which the power
+ button should be kept pressed for Palmas to power off automatically.
+ NOTE: This depends on OTP support and POWERHOLD signal configuration
+ on platform. Valid values are 6, 8, 10 and 12.
+- ti,palmas-pwron-debounce-milli-seconds: Duration in milliseconds
+ which the power button should be kept pressed for Palmas to register
+ a press for debouncing purposes. NOTE: This depends on specific
+ Palmas variation capability. Valid values are 15, 100, 500 and 1000.
+
+Example:
+
+palmas {
+ palmas_pwr_button: pwrbutton {
+ compatible = ti,palmas-pwrbutton;
+ interrupt-parent = tps659038;
+ interrupts = 1 IRQ_TYPE_EDGE_FALLING;
+ ti,palmas-long-press-seconds = 12;
+ ti,palmas-pwron-debounce-milli-seconds = 15;
+ };
+};
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 51891f6..36382e5 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -451,6 +451,16 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config INPUT_PALMAS_PWRBUTTON
+ tristate Palmas Power button Driver
+ depends on MFD_PALMAS
+ help
+ Say Y here if you want to enable power key reporting via the
+ Palmas family of PMICs.
+
+ To compile this driver as a module, choose M here. The module will
+ be called palmas_pwrbutton.
+
config INPUT_PCF50633_PMU
tristate PCF50633 PMU events
depends on MFD_PCF50633
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index e0cee17..e8b84d2 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_INPUT_MAX8997_HAPTIC)+= max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
Kevin, On 09/09/2014 04:10 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: Kevin/Ohad, On 09/09/2014 02:59 PM, Suman Anna wrote: Hi Ohad, On 09/09/2014 05:31 AM, Ohad Ben-Cohen wrote: On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman khil...@linaro.org wrote: To me, it's not terribly clear how you made the split between this PM core code an the remoteproc code. In the changelog for the remoteproc patch, it states it's to load the firmware for and boot the wkup_m3. But, while parts of the IPC are here in pm33xx.c, parts of the IPC are also inside the remoteproc driver, so I'm quite curious if that's OK with the remoteproc maintainers. Either way, please make it clearer how and why you made the split, and please isolate the wkup_m3 IPC/protocol from this code. Think of people wanting to rework/extend the wkup_m3 firmware. They shouldn't be messing around in here, but rather inside a driver specificaly for the wkup_m3. I haven't looked at the code very thoroughly yet, but generally a remoteproc driver should only implement the three start/stop/kick rproc_ops, and then register them via the remoteproc framework. Exposing additional API directly from that driver isn't something we immediately want to accept. If relevant, we would generally prefer to extend remoteproc instead, so other platform-specific drivers could utilize that functionality as well. Or rpmsg - if we're missing some IPC functionality. The WkupM3 cannot access DDR, and so we don't intend to use rpmsg. The IPC with wkup_m3 is usually one of the last steps for putting the SoC into a desired low-power state either during suspend or cpuidle, and the communication uses a bank of fixed registers. The .kick is specific to virtio-based communication, and so this is not gonna be used. If you can take a closer look at the wkup_m3 remoteproc driver and give your comments, then we can plan on the next steps. Especially as there are also pieces pertaining to the PM layer knowing the WkupM3 has been loaded and booted. There are already some pending comments on code fragments from Santosh and myself, but let us know your inputs on the integration aspects on PM, remoteproc and IPC with WkupM3. The split was defined by putting all the application specific (to the firmware in use) code in the platform pm code while trying to keep all the IPC code within the wkup_m3_rproc driver. I don't even see that split. I see the platform PM code directly setting IPC register values, but then rproc driver actually sends the mailbox command. Well, really the pm code is setting a structure which gets passed to the wkup_m3_rproc API and that's what does the write. I suppose the naming of the structure is misleading though. However, the wkup_m3 driver isn't aware of the protocol or what is going into these registers for the writes, the PM code defines the usage. The exposed API is definitely heavily biased towards the intended use-case, Maybe if the API was actually documented, it would be easier for us to review it. but the CM3 was designed with this exact purpose in mind and not much else, and due to the limited IPC registers we have to work with there isn't a whole lot of flexibility. Only IPC reg 0 is always used as the resume address, the usage of the other registers is defined by the firmware and pm code. Just as a refresher for those not familiar with it, the IPC mechanism works like this: we load the ipc registers (8 for am33xx, 16 for am43xx) with any information we want to communicate to the CM3, OK, and this happens currently in the platform PM code, right? then we make a dummy write to the Mailbox which triggers an interrupt on the CM3, the CM3 does what it needs to with the info passed in the IPC regs and writes anything it wants to communicate back to these registers, and then triggers a different interrupt (not related to mailbox) to let the MPU know it is done. And this part happens in the rproc driver, right? It's kind of a mess so I figured one driver was the best way to encapsulate it all, So where is this one driver that encapsulates it all? Sp my thinking was that I put the IPC writing in the wkup_m3_rproc driver, but the actual configuration of what gets written in the PM platform code, to at least try to keep things generic. Still, I do agree now that the split is not that clear. and I still had to introduce callbacks within the wkup_m3_rproc driver so it could let the pm code know when the FW loaded (to actually enable pm) and when an interrupt was received from the wkup_m3 (so the pm code can process the response). As Suman stated, this sequence is part of the suspend path and also will be part of the lower c-states for cpuidle, so we need something fast and lightweight. RPMsg is way more than we need and it doesn't really fit the use case, so I'm not sure what makes the most sense, extending remoteproc in some way to
[REPOST PATCHv3 2/2] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
The '#mbox-cells' property is added to all the OMAP mailbox
nodes. This property is mandatory with the new mailbox framework.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 1 +
arch/arm/boot/dts/am4372.dtsi | 1 +
arch/arm/boot/dts/dra7.dtsi | 13 +
arch/arm/boot/dts/omap2420.dtsi | 1 +
arch/arm/boot/dts/omap2430.dtsi | 1 +
arch/arm/boot/dts/omap3.dtsi| 1 +
arch/arm/boot/dts/omap4.dtsi| 1 +
arch/arm/boot/dts/omap5.dtsi| 1 +
8 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e4f165a..5663ff5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,7 @@
reg = 0x480C8000 0x200;
interrupts = 77;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index a0503be..77eb92f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,7 @@
reg = 0x480C8000 0x200;
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152..fa97040 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -419,6 +419,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4a0f4000 0x200;
ti,hwmods = mailbox1;
+ #mbox-cells = 1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
status = disabled;
@@ -428,6 +429,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883a000 0x200;
ti,hwmods = mailbox2;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -437,6 +439,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883c000 0x200;
ti,hwmods = mailbox3;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -446,6 +449,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883e000 0x200;
ti,hwmods = mailbox4;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -455,6 +459,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4884 0x200;
ti,hwmods = mailbox5;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -464,6 +469,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48842000 0x200;
ti,hwmods = mailbox6;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -473,6 +479,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48844000 0x200;
ti,hwmods = mailbox7;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -482,6 +489,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48846000 0x200;
ti,hwmods = mailbox8;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -491,6 +499,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4885e000 0x200;
ti,hwmods = mailbox9;
+ #mbox-cells = 1;
[REPOST PATCHv3 0/2] OMAP Mailbox framework adaptation
Hi, This is a repost of the Mailbox Framework adaptation support patches for the OMAP mailbox driver (last 2 patches out of 5) from the OMAP Mailbox framework adoption and DT support series [1]. The previous series is split into 3 different series to resolve merge and build dependencies. The patches are based on 3.17-rc3, with the baseline dependencies having already been merged in the 3.17 window. The testing is done against the latest version v10 [2] of the mailbox framework compared to v9 in the previous post, and there are no code changes required to any patches. Please see [1] for the history of these patches. The following are the remaining dependencies for these 2 patches: - OMAP Mailbox DT support in driver [3] - OMAP Mailbox DTS patch adding the sub-mailboxes [4] - Mailbox Framework v10 [2] The reference branch with all the patches is hosted (not for merging) at https://github.com/sumananna/mailbox/commits/submit/3.17-rc3-omap-mbox-v10-fwk-v3 The following shows the boot logs on various OMAP platforms: OMAP2 (SDP2430) : http://pastebin.ubuntu.com/8312682 OMAP3 (BeagleXM) : http://pastebin.ubuntu.com/8312348 OMAP4 (PandaBoard): http://pastebin.ubuntu.com/8312364 OMAP5 (OMAP5 uEVM): http://pastebin.ubuntu.com/8312378 DRA7 (DRA7 EVM) : http://pastebin.ubuntu.com/8312482 AM33xx (BeagleBone Black) : http://pastebin.ubuntu.com/8312420 AM43xx (AM437x GP EVM): http://pastebin.ubuntu.com/8312457 [1] http://marc.info/?l=linux-omapm=140668054422693w=2 [2] https://lkml.org/lkml/2014/8/1/200 [3] http://marc.info/?l=linux-omapm=141037688814464w=2 [4] http://marc.info/?l=linux-omapm=141037727114587w=2 Suman Anna (2): mailbox/omap: adapt to the new mailbox framework ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes .../devicetree/bindings/mailbox/omap-mailbox.txt | 24 ++ arch/arm/boot/dts/am33xx.dtsi | 1 + arch/arm/boot/dts/am4372.dtsi | 1 + arch/arm/boot/dts/dra7.dtsi| 13 + arch/arm/boot/dts/omap2420.dtsi| 1 + arch/arm/boot/dts/omap2430.dtsi| 1 + arch/arm/boot/dts/omap3.dtsi | 1 + arch/arm/boot/dts/omap4.dtsi | 1 + arch/arm/boot/dts/omap5.dtsi | 1 + drivers/mailbox/omap-mailbox.c | 346 - drivers/remoteproc/omap_remoteproc.c | 51 +-- include/linux/omap-mailbox.h | 16 +- 12 files changed, 277 insertions(+), 180 deletions(-) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCHv3 1/2] mailbox/omap: adapt to the new mailbox framework
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+) are adapted to use the generic mailbox framework.
No changes are done to OMAP3 TI DSP/Bridge driver as it was
deleted.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
- The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes.
- The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
- The OMAP mailbox driver uses a custom of_xlate controller ops that
allows phandles for the pargs specifier instead of indexing to avoid
any channel registration order dependencies.
- The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
- The remoteproc driver (current client) is adapted to use the new API.
The notifier callbacks used within this client is replaced with the
regular callbacks from the newer framework.
- The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel will be removed once OMAP3 becomes DT-boot
only.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 24 ++
drivers/mailbox/omap-mailbox.c | 346 -
drivers/remoteproc/omap_remoteproc.c | 51 +--
include/linux/omap-mailbox.h | 16 +-
4 files changed, 257 insertions(+), 180 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
index 48edc4b..1c6aa0d 100644
--- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -43,6 +43,9 @@ Required properties:
device. The format is dependent on which interrupt
controller the OMAP device uses
- ti,hwmods: Name of the hwmod associated with the mailbox
+- #mbox-cells: Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be
+ 1
- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
device can interrupt
- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
@@ -72,6 +75,18 @@ data that represent the following:
Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
associated with generating a tx/rx fifo interrupt.
+Mailbox Users:
+==
+A device needing to communicate with a target processor device should specify
+them using the common mailbox binding properties, mboxes and the optional
+mbox-names (please see Documentation/devicetree/bindings/mailbox/mailbox.txt
+for details). Each value of the mboxes property should contain a phandle to the
+mailbox controller device node and an args specifier that will be the phandle
to
+the intended sub-mailbox child node to be used for communication. The
equivalent
+mbox-names property value can be used to give a name to the communication
channel
+to be used by the client user.
+
+
Example:
@@ -81,6 +96,7 @@ mailbox: mailbox@4a0f4000 {
reg = 0x4a0f4000 0x200;
interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
mbox_ipu: mbox_ipu {
@@ -99,6 +115,7 @@ mailbox: mailbox@480C8000 {
reg = 0x480C8000 0x200;
interrupts = 77;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
@@ -106,3 +123,10 @@ mailbox: mailbox@480C8000 {
ti,mbox-rx = 0 0 3;
};
};
+
+wkup_m3: wkup_m3@44d0 {
+ ...
+ mbox-names = wkup_m3;
+ mboxes = mailbox mbox_wkupm3;
+ ...
+};
diff --git
Re: [PATCH v2 1/2] ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7
On Wed, Sep 10, 2014 at 07:07:26PM +0530, Mugunthan V N wrote:
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 d678152..8d79321 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ ethernet0 = cpsw_emac0;
+ ethernet1 = cpsw_emac1;
};
timer {
@@ -1262,6 +1264,63 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ 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;
How am I supposed to override this in the board dtb when my board only
uses 1 slave?
+ active_slave = 0;
+ cpts_clock_mult = 0x8000;
+ cpts_clock_shift = 29;
+ reg = 0x48484000 0x1000
+0x48485200 0x2E00;
+ #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 ];
+ };
Should I then be setting this to disabled from my board file? Or does
the disabled for the ethernet overall take care of that?
+ phy_sel: cpsw-phy-sel@4a002554 {
+ compatible = ti,dra7xx-cpsw-phy-sel;
+ reg= 0x4a002554 0x4;
+ reg-names = gmii-sel;
+ };
I guess the board file would have to disable that too (we won't have a
phy given we are connecting to a switch chip).
+ };
+
};
};
--
Len Sorensen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
