[PATCH] omap: twl-common: Fix musb-hdrc device name.
Without this change when booting omap3 device (gta04) with board file
leads to follwing errors:
[1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy
[1.209075] HS USB OTG: no transceiver configured
[1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with
status -517
and usb isn't working.
This is probably regression caused by commit: 6c27f939
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
---
arch/arm/mach-omap2/twl-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..3640ce0 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void)
#if defined(CONFIG_ARCH_OMAP3)
struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
+ PHY_CONSUMER(musb-hdrc.0.auto, usb),
};
struct phy_init_data init_data = {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Add Display support for AM43xx
This patch series adds DSS support to the AM43x. The DPI LCD panel is supported on both am43x-epos-evm and am437x-gp-evm. The LCD panel is from OSD model: OSD057T0559-34TS Done on top of 3.13-rc1 and below dependent patches Sourav patches adding device nodes for epos [1] and gp [2] evm [1]: https://patchwork.kernel.org/patch/3246701/ [2]: https://patchwork.kernel.org/patch/3246751/ Tomi patch adding DT support to DSS [3] [3]: https://patchwork.kernel.org/patch/2841721/ AM43xx has a dedicated display pll. Hence tomi patch improving func clock handling is needed [4] [4]: https://patchwork.kernel.org/patch/3196221/ Tested on am43x-epos-evm and am437x-gp-evm. Sathya Prakash M R (3): OMAPDSS: Add DSS features for AM43xx ARM: OMAP2+: AM43xx DSS Hwmod ARM: DTS: AM43x: Add DSS node Tomi Valkeinen (1): ARM: AM43xx: fix dpll init in bypass mode arch/arm/boot/dts/am4372.dtsi | 28 arch/arm/boot/dts/am437x-gp-evm.dts| 68 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 64 + arch/arm/boot/dts/am43xx-clocks.dtsi |2 + arch/arm/mach-omap2/clkt_dpll.c|4 +- arch/arm/mach-omap2/display.c |2 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104 arch/arm/mach-omap2/prcm43xx.h |1 + drivers/video/omap2/dss/dispc.c|1 + drivers/video/omap2/dss/dpi.c |2 + drivers/video/omap2/dss/dsi.c |1 + drivers/video/omap2/dss/dss.c | 11 +++ drivers/video/omap2/dss/dss_features.c | 67 ++ include/video/omapdss.h|1 + 14 files changed, 354 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP2+: AM43xx DSS Hwmod
Add DSS hwmod structs for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104
arch/arm/mach-omap2/prcm43xx.h |1 +
2 files changed, 105 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 9002fca..6a121db 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include omap_hwmod_common_data.h
+
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,76 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/* Display sub system - DSS */
+
+static struct omap_hwmod_dma_info am43xx_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+ { .dma_req = -1 },
+};
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+ .manager_count = 1,
+ .has_framedonetv_irq= 0
+};
+
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = am43xx_dispc_sysc,
+};
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+ .name = dss_core,
+ .class = omap2_dss_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .sdma_reqs = am43xx_dss_sdma_chs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* display controller -dispc*/
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+ .name = dss_dispc,
+ .class = am43xx_dispc_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+ .dev_attr = am43xx_dss_dispc_dev_attr,
+};
+
+/*RFBI*/
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+ .name = dss_rfbi,
+ .class = omap2_rfbi_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -654,6 +726,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+ .master = am43xx_dss_core_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= disp_clk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_core_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_dispc_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_rfbi_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -747,6 +847,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__ocp2scp1,
am43xx_l3_s__usbotgss0,
am43xx_l3_s__usbotgss1,
+ am43xx_dss__l3_main,
+ am43xx_l4_ls__dss,
+ am43xx_l4_ls__dss_dispc,
+ am43xx_l4_ls__dss_rfbi,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 7785be9..ad7b3e9 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -142,5 +142,6 @@
#define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET0x05B8
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define
[PATCH 1/4] OMAPDSS: Add DSS features for AM43xx
Add DSS features for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/mach-omap2/display.c |2 +
drivers/video/omap2/dss/dispc.c|1 +
drivers/video/omap2/dss/dpi.c |2 +
drivers/video/omap2/dss/dsi.c |1 +
drivers/video/omap2/dss/dss.c | 11 ++
drivers/video/omap2/dss/dss_features.c | 67
include/video/omapdss.h|1 +
7 files changed, 85 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a4e536b..d1cac1c 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -316,6 +316,8 @@ static enum omapdss_version __init
omap_display_get_version(void)
return OMAPDSS_VER_OMAP4;
else if (soc_is_omap54xx())
return OMAPDSS_VER_OMAP5;
+ else if (soc_is_am43xx())
+ return OMAPDSS_VER_AM43xx;
else
return OMAPDSS_VER_UNKNOWN;
}
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4ec59ca..1b4aed5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3622,6 +3622,7 @@ static int __init dispc_init_features(struct
platform_device *pdev)
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
+ case OMAPDSS_VER_AM43xx:
src = omap34xx_rev3_0_dispc_feats;
break;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bd48cde..7ee7f86 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -64,6 +64,7 @@ static struct platform_device *dpi_get_dsidev(enum
omap_channel channel)
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
+ case OMAPDSS_VER_AM43xx:
return NULL;
case OMAPDSS_VER_OMAP4430_ES1:
@@ -593,6 +594,7 @@ static enum omap_channel dpi_get_channel(void)
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
+ case OMAPDSS_VER_AM43xx:
return OMAP_DSS_CHANNEL_LCD;
case OMAPDSS_VER_OMAP4430_ES1:
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6056b27..d68b49b 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5082,6 +5082,7 @@ static enum omap_channel dsi_get_channel(int module_id)
{
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_AM43xx:
DSSWARN(DSI not supported\n);
return OMAP_DSS_CHANNEL_LCD;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index bd01608..0b60746 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -795,6 +795,13 @@ static const struct dss_features omap54xx_dss_feats
__initconst = {
.dpi_select_source = dss_dpi_select_source_omap5,
};
+static const struct dss_features am43xx_dss_feats __initconst = {
+ .fck_div_max= 0,
+ .dss_fck_multiplier = 0,
+ .parent_clk_name= NULL,
+ .dpi_select_source = dss_dpi_select_source_omap2_omap3,
+};
+
static int __init dss_init_features(struct platform_device *pdev)
{
const struct dss_features *src;
@@ -831,6 +838,10 @@ static int __init dss_init_features(struct platform_device
*pdev)
src = omap54xx_dss_feats;
break;
+ case OMAPDSS_VER_AM43xx:
+ src = am43xx_dss_feats;
+ break;
+
default:
return -ENODEV;
}
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index f8fd6db..79df1a2 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -93,6 +93,17 @@ static const struct dss_reg_field omap3_dss_reg_fields[] = {
[FEAT_REG_DSIPLL_REGM_DSI] = { 26, 23 },
};
+static const struct dss_reg_field am43xx_dss_reg_fields[] = {
+ [FEAT_REG_FIRHINC] = { 12, 0 },
+ [FEAT_REG_FIRVINC] = { 28, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 11, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD]= { 27, 16 },
+ [FEAT_REG_FIFOSIZE] = { 10, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
+ [FEAT_REG_VERTICALACCU] = { 25, 16 },
+ [FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
+};
+
static const struct dss_reg_field omap4_dss_reg_fields[] = {
[FEAT_REG_FIRHINC] = { 12, 0 },
[FEAT_REG_FIRVINC] = { 28, 16 },
@@ -149,6 +160,11 @@ static const enum omap_display_type
omap3630_dss_supported_displays[] = {
[PATCH 2/4] ARM: AM43xx: fix dpll init in bypass mode
From: Tomi Valkeinen tomi.valkei...@ti.com
On AM43xx, if a PLL is in bypass at kernel init, the code in
omap2_get_dpll_rate() will not realize this and will try to calculate
the clock rate using the multiplier and the divider, resulting in
errors.
omap2_init_dpll_parent() has similar issue.
Add the missing soc_is_am43xx() check to make the code work on AM43xx.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 924c230..14e9e45 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -209,7 +209,7 @@ u8 omap2_init_dpll_parent(struct clk_hw *hw)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return 1;
- } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx() || soc_is_am43xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
@@ -255,7 +255,7 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return __clk_get_rate(dd-clk_bypass);
- } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx() || soc_is_am43xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: DTS: AM43x: Add DSS node
Add device node for DSS module for AM4372. Both the
AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Also set the right parent clock to the DSS clock.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 28 ++
arch/arm/boot/dts/am437x-gp-evm.dts | 68 ++
arch/arm/boot/dts/am43x-epos-evm.dts | 64
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
4 files changed, 162 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..b72a7df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,34 @@
num-cs = 4;
status = disabled;
};
+
+ dss: dss@4832A000 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4832A000 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@4832A400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x4832A400 0x400;
+ interrupts = GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ rfbi: rfbi@4832A800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x4832A800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ };
+
};
clocks {
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 2e79bda..e58652c6 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -24,6 +24,31 @@
brightness-levels = 0 51 53 56 62 75 101 152 255;
default-brightness-level = 8;
};
+
+ aliases {
+ display0 = lcd0;
+ };
+
+ lcd0: display@0 {
+ compatible = osddisplays,osd057T0559-34ts, panel-dpi;
+ video-source = dpi;
+ data-lines = 24;
+ panel-timing {
+ clock-frequency = 3300;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 210;
+ hback-porch = 16;
+ hsync-len = 30;
+ vback-porch = 10;
+ vfront-porch = 22;
+ vsync-len = 13;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
+ };
};
am43xx_pinmux {
@@ -46,6 +71,40 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ dss_pinctrl: dss_pinctrl {
+ pinctrl-single,pins =
+ 0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 8 -
DSS DATA 23 */
+ 0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x02C (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x03C (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 15 -
DSS DATA 16 */
+ 0x0A0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 0 */
+ 0x0A4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0A8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0AC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0BC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0CC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0DC (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 15 */
+
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
Hi,
On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote:
Without this change when booting omap3 device (gta04) with board file
leads to follwing errors:
[1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy
[1.209075] HS USB OTG: no transceiver configured
[1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with
status -517
and usb isn't working.
This is probably regression caused by commit: 6c27f939
I think a better fix would be to have this merged..
https://lkml.org/lkml/2013/7/26/91
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
---
arch/arm/mach-omap2/twl-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..3640ce0 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void)
#if defined(CONFIG_ARCH_OMAP3)
struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
+ PHY_CONSUMER(musb-hdrc.0.auto, usb),
the index '0' might vary for some boards leading it to again break musb.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
Hi,
On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi,
On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote:
Without this change when booting omap3 device (gta04) with board file
leads to follwing errors:
[1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy
[1.209075] HS USB OTG: no transceiver configured
[1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with
status -517
and usb isn't working.
This is probably regression caused by commit: 6c27f939
I think a better fix would be to have this merged..
https://lkml.org/lkml/2013/7/26/91
Yes I see but how this could help with current situation? Ho you then
specify device number?
This patch is fixing 3.13-rcx regression.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
---
arch/arm/mach-omap2/twl-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..3640ce0 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void)
#if defined(CONFIG_ARCH_OMAP3)
struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
+ PHY_CONSUMER(musb-hdrc.0.auto, usb),
the index '0' might vary for some boards leading it to again break musb.
If you run grep for musb-hdrc :
arch/arm/mach-omap2/board-3430sdp.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-devkit8000.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-overo.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-omap3beagle.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-omap3touchbook.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-cm-t35.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-omap3stalker.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-omap3logic.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-2430sdp.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-ldp.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-rx51.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-omap3pandora.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
Until mentioned patch isn't merged and PHY_CONSUMER isn't updated I
think this is correct solution.
Thanks
Kishon
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek marek.beli...@gmail.com wrote:
Hi,
On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi,
On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote:
Without this change when booting omap3 device (gta04) with board file
leads to follwing errors:
[1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy
[1.209075] HS USB OTG: no transceiver configured
[1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with
status -517
and usb isn't working.
This is probably regression caused by commit: 6c27f939
I think a better fix would be to have this merged..
https://lkml.org/lkml/2013/7/26/91
Yes I see but how this could help with current situation? Ho you then
specify device number?
I was too fast with reply sorry. I can see whole series and it is of
course correct solution. But as I said
can we except to be merged to 3.13. If not Tony can you pick my patch.
This patch is fixing 3.13-rcx regression.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
---
arch/arm/mach-omap2/twl-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..3640ce0 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void)
#if defined(CONFIG_ARCH_OMAP3)
struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
+ PHY_CONSUMER(musb-hdrc.0.auto, usb),
the index '0' might vary for some boards leading it to again break musb.
If you run grep for musb-hdrc :
arch/arm/mach-omap2/board-3430sdp.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-devkit8000.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-overo.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-omap3beagle.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-omap3touchbook.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-cm-t35.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-omap3stalker.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-omap3logic.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-2430sdp.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-ldp.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-rx51.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-omap3pandora.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
Until mentioned patch isn't merged and PHY_CONSUMER isn't updated I
think this is correct solution.
Thanks
Kishon
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
Hi,
On Tuesday 03 December 2013 02:38 PM, Belisko Marek wrote:
Hi,
On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi,
On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote:
Without this change when booting omap3 device (gta04) with board file
leads to follwing errors:
[1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy
[1.209075] HS USB OTG: no transceiver configured
[1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with
status -517
and usb isn't working.
This is probably regression caused by commit: 6c27f939
I think a better fix would be to have this merged..
https://lkml.org/lkml/2013/7/26/91
Yes I see but how this could help with current situation? Ho you then
specify device number?
With this we can for sure know the device numbering (of MUSB) starts from '0'.
If we use PLATFORM_DEVID_AUTO, we won't know what dev number has been assigned
to us. In your case you get musb-hdrc.0.auto because no one else is creating
a device using PLATFORM_DEVID_AUTO (before your device is created).
This patch is fixing 3.13-rcx regression.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
---
arch/arm/mach-omap2/twl-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..3640ce0 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void)
#if defined(CONFIG_ARCH_OMAP3)
struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
+ PHY_CONSUMER(musb-hdrc.0.auto, usb),
the index '0' might vary for some boards leading it to again break musb.
If you run grep for musb-hdrc :
arch/arm/mach-omap2/board-3430sdp.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-devkit8000.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-overo.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-omap3beagle.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-omap3touchbook.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-cm-t35.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-omap3stalker.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-omap3logic.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
arch/arm/mach-omap2/board-2430sdp.c: usb_bind_phy(musb-hdrc.0.auto,
0, twl4030_usb);
arch/arm/mach-omap2/board-ldp.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-rx51.c: usb_bind_phy(musb-hdrc.0.auto, 0,
twl4030_usb);
arch/arm/mach-omap2/board-omap3pandora.c:
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
hmm.. that patch was in a series that fixes this too
https://lkml.org/lkml/2013/7/26/88
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
The TPS65218 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- Over Temperature warning and Shut down.
This patch adds support for tps65218 mfd device. At this time only
the regulator functionality is made available.
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile |1 +
drivers/mfd/tps65218.c | 281 +
include/linux/mfd/tps65218.h | 288
++
snip
+config MFD_TPS65218
+ tristate TI TPS65218 Power Management chips
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the TPS65218 series of
+ Power Management chips.
+ These include voltage regulators, gpio and other features
+ that are often used in portable devices.
Perhaps you should add a note that only the regulator component is
currently supported.
snip
new file mode 100644
index 000..8c61640
--- /dev/null
+++ b/drivers/mfd/tps65218.c
@@ -0,0 +1,281 @@
+/*
+ * TPS65218 chip family multi-function driver
Instead of calling it an MFD driver (is there such a thing?) I think
you should mention its true purpose, as per the datasheet.
snip
+static const struct of_device_id of_tps65218_match_table[] = {
+ { .compatible = ti,tps65218, },
+ { /* end */ }
I think the end comment is superfluous.
However, if you _really_ want to put something in there, I dislike
/* Sentinel */ the least.
+static int tps65218_probe(struct i2c_client *client,
+ const struct i2c_device_id *ids)
+{
snip
+ ret = of_platform_populate(client-dev.of_node, NULL, NULL,
+client-dev);
What are you trying to do here?
Register each regulator as a platform device?
snip
+static const struct i2c_device_id tps65218_id_table[] = {
+ {tps65218, TPS65218},
+};
This has a different structure to of_tps65218_match_table, please
ensure they're the same. I prefer spaces after '{' and before '}'.
snip
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: DT bindings for TPS65218 PMIC
Add DT bindings for TPS65218 PMIC.
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 27
.../devicetree/bindings/regulator/tps65218.txt | 22
2 files changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..87cb7a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,27 @@
+The TPS65218 Integrated Power Management Chips.
+These chips are connected to an i2c bus.
I2C
+Required properties:
+- compatible : Must be ti,tps65218;
+- interrupts : This i2c device has an IRQ line connected to the main SoC
I2C
+- interrupt-controller : Since the tps65218 support several interrupts
support(s) (hosts?)
+ internally, it is considered as an interrupt controller cascaded to the
SoC.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller.
Phandle to ...
+Optional node:
node(s):
+- Child nodes contain in the tps65218.
+ It supports a number of features.
Please re-phase the above two sentences to something decipherable.
+ The children nodes will thus depend of the capability of the variant.
Please, go on ...
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps@24 {
+compatible = ti,tps65218;
+reg = 0x24;
+interrupt-controller;
+#interrupt-cells = 2;
+interrupt-parent = gic;
+};
Perhaps it would be better to centralise the documentation inclusive
of the regulator contingent. Or at least provide a _full_ example in
each document.
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..1ccf170
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,22 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-dcdc5 for DCDC5
+ - ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1 LDO
Why aren't you using 'regulator-compatible'?
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+ xyz: regulator@0 {
Genuine question: Is the @0 meaningful?
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)
Hi Laurent, On 12/03/2013 05:54 AM, Laurent Pinchart wrote: Hi Roger, On Monday 25 November 2013 15:55:45 Roger Quadros wrote: Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply for the USB PHY. As the generic PHY driver can't handle more than one supply at the moment, we configure this supply to be always on. This will cause a very small power impact if the USB host subsystem is not in use, about 76.86 micro-W + LDO power. Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere, so there won't be any functional impact on those boards other than some additional LDO power consumption. Do I need any patch other than this one (on top of v3.13-rc1) to enable the ethernet port on a Beagleboard-xM rev B ? Here's what the kernel reports at boot (with ignore_loglevel set on the command line). It seems on Rev A/B, the power enable line for the USB hub has reversed polarity than Rev C. Does the below patch work for you? If yes, how do we account for it? Do we add a new file omap3-beagle-xm-ab.dts for rev A/B boards? cheers, -roger diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts index b39918e..434d903 100644 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts @@ -78,6 +78,7 @@ regulator-max-microvolt = 330; gpio = twl_gpio 18 0;/* GPIO LEDA */ startup-delay-us = 7; + enable-active-high; }; /* HS USB Host PHY on PORT 2 */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 06:28 PM, David Laight wrote:
From: Roger Quadros [mailto:rog...@ti.com]
On 11/29/2013 03:17 PM, David Laight wrote:
...
+ timeout = jiffies + msecs_to_jiffies(100);
+ while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
+ OMAP_UHH_SYSSTATUS_RESETDONE)) {
+ cpu_relax();
You mean use msleep(1) here instead of cpu_relax()?
Shouldn't be a problem IMO, but can you please tell me why that is better
as the reset seems to complete usually in the first iteration.
If it doesn't finish in the first iteration you don't want to
spin the cpu for 100ms.
If it hasn't finished in the first millisecond, you probably expect
it to actually time out - so you might as well look (say) every 10ms.
Understood now. Thanks.
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 01/15] mfd: menelaus: Drop __exit section annotation
The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
Hi,
On Tuesday 26 November 2013 03:02 AM, Felipe Balbi wrote:
Hi,
On Mon, Nov 11, 2013 at 08:06:12PM +0530, Kishon Vijay Abraham I wrote:
diff --git a/drivers/usb/dwc3/platform_data.h
b/drivers/usb/dwc3/platform_data.h
index 7db34f0..49ffa6d 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+ bool usb2_phy;
+ bool usb3_phy;
This would look better as a quirks flag, then we could:
unsigned long quirks;
#define DWC3_QUIRK_NO_USB3_PHY BIT(0)
#define DWC3_QUIRK_NO_USB2_PHY BIT(1)
Should this quirk be used for dt also? Currently we find if it has usb3 phy
or
usb2 phy from the dt data only. But if we add a quirk, we'll have to add a
property to populate the quirk no?
either we use the quirk, or use the fact that no usb2_phy phandle is
defined, would work both ways, no ?
In my v3, I've made both to use quirks since we don't want to have separate
mechanism for dt and non-dt stuff to know the presence of a particular PHY.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. Also use the full length of the provided buffer, which I believe is 72 chars, but happy to be correct on that one. It's certainly not 40 chars however. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
On Tuesday 03 December 2013 02:54 PM, Lee Jones wrote:
The TPS65218 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- Over Temperature warning and Shut down.
This patch adds support for tps65218 mfd device. At this time only
the regulator functionality is made available.
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile |1 +
drivers/mfd/tps65218.c | 281 +
include/linux/mfd/tps65218.h | 288 ++
snip
+config MFD_TPS65218
+ tristate TI TPS65218 Power Management chips
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the TPS65218 series of
+ Power Management chips.
+ These include voltage regulators, gpio and other features
+ that are often used in portable devices.
Perhaps you should add a note that only the regulator component is
currently supported.
Ok. I will add it.
snip
new file mode 100644
index 000..8c61640
--- /dev/null
+++ b/drivers/mfd/tps65218.c
@@ -0,0 +1,281 @@
+/*
+ * TPS65218 chip family multi-function driver
Instead of calling it an MFD driver (is there such a thing?) I think
you should mention its true purpose, as per the datasheet.
Ok.
snip
+static const struct of_device_id of_tps65218_match_table[] = {
+ { .compatible = ti,tps65218, },
+ { /* end */ }
I think the end comment is superfluous.
However, if you _really_ want to put something in there, I dislike
/* Sentinel */ the least.
I will remove it.
+static int tps65218_probe(struct i2c_client *client,
+ const struct i2c_device_id *ids)
+{
snip
+ ret = of_platform_populate(client-dev.of_node, NULL, NULL,
+ client-dev);
What are you trying to do here?
Register each regulator as a platform device?
Yeah. The probe will be called for every regulator separately.
snip
+static const struct i2c_device_id tps65218_id_table[] = {
+ {tps65218, TPS65218},
+};
This has a different structure to of_tps65218_match_table, please
ensure they're the same. I prefer spaces after '{' and before '}'.
Ok. I will add a space after '{' and before '}'. Sorry I did not
follow tps65218_id_table being different than of_tps65218_match_table.
One is of the type of_device_id and the other i2c_device_id.
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] experimental: arm: dts: dra7xx: Add a DT node for VPE
Hi Laurent,
On Friday 09 August 2013 03:41 AM, Laurent Pinchart wrote:
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:43 Archit Taneja wrote:
Add a DT node for VPE in dra7.dtsi. This is experimental because we might
need to split the VPE address space a bit more, and also because the IRQ
line described is accessible the IRQ crossbar driver is added for DRA7XX.
Cc: Rajendra Nayak rna...@ti.com
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
Documentation is missing :-) As this is an experimental patch you can probably
document the bindings later.
Sorry for the late reply, I missed out on reading this message somehow.
I'm blocked on adding the DT nodes because of some dependencies on dra7x
clocks, and the crossbar framework. I'll make sure to add documentation :)
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..3237972 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -484,6 +484,17 @@
dmas = sdma 70, sdma 71;
dma-names = tx0, rx0;
};
+
+ vpe {
+ compatible = ti,vpe;
+ ti,hwmods = vpe;
+ reg = 0x489d 0xd000, 0x489dd000 0x400;
+ reg-names = vpe, vpdma;
+ interrupts = 0 159 0x4;
+ #address-cells = 1;
+ #size-cells = 0;
Are #address-cells and #size-cells really needed ?
They aren't needed. The vpe node inherits these params from the parent
ocp node.
Thanks,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.
This driver takes care a allocating a free irq and then configuring the
crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
be called right before the irqchip_init, so that it is setup to handle the
irqchip callbacks.
Cc: Thomas Gleixner t...@linutronix.de
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Kumar Gala ga...@codeaurora.org (for DT binding portion)
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
[v5] Used the function of_property_read_u32_index instead of raw reading
from DT as per comments from Mark Rutland mark.rutl...@arm.com
.../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
drivers/irqchip/Kconfig|8 +
drivers/irqchip/Makefile |1 +
drivers/irqchip/irq-crossbar.c | 208
include/linux/irqchip/irq-crossbar.h | 11 ++
5 files changed, 255 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/irqchip/irq-crossbar.c
create mode 100644 include/linux/irqchip/irq-crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..fb88585
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,27 @@
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be ti,irq-crossbar
+- reg: Base address and the size of the crossbar registers.
+- ti,max-irqs: Total number of irqs available at the interrupt controller.
+- ti,reg-size: Size of a individual register in bytes. Every individual
+ register is assumed to be of same size. Valid sizes are 1, 2, 4.
+- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
+crossbar. These interrupt lines are reserved in the soc,
+so crossbar bar driver should not consider them as free
+lines.
+
+Examples:
+ crossbar_mpu: @4a02 {
+ compatible = ti,irq-crossbar;
+ reg = 0x4a002a48 0x130;
+ ti,max-irqs = 160;
+ ti,reg-size = 2;
+ ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3792a1a..2efcde6 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -61,3 +61,11 @@ config VERSATILE_FPGA_IRQ_NR
int
default 4
depends on VERSATILE_FPGA_IRQ
+
+config IRQ_CROSSBAR
+ bool
+ help
+ Support for a CROSSBAR ip that preceeds the main interrupt controller.
+ The primary irqchip invokes the crossbar's callback which inturn
allocates
+ a free irq and configures the IP. Thus the peripheral interrupts are
+ routed to one of the free irqchip interrupt lines.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c60b901..2edead9 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_RENESAS_IRQC)+= irq-renesas-irqc.o
obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
+obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
new file mode 100644
index 000..ae605a3
--- /dev/null
+++ b/drivers/irqchip/irq-crossbar.c
@@ -0,0 +1,208 @@
+/*
+ * drivers/irqchip/irq-crossbar.c
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Sricharan R r.sricha...@ti.com
+ *
+ * This program is
[PATCH V5 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
In some socs the gic can be preceded by a crossbar IP which
routes the peripheral interrupts to the gic inputs. The peripheral
interrupts are associated with a fixed crossbar input line and the
crossbar routes that to one of the free gic input line.
The DT entries for peripherals provides the fixed crossbar input line
as its interrupt number and the mapping code should associate this with
a free gic input line. This patch adds the support inside the gic irqchip
to handle such routable irqs. The routable irqs are registered in a linear
domain. The registered routable domain's callback should be implemented
to get a free irq and to configure the IP to route it.
Cc: Thomas Gleixner t...@linutronix.de
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
Documentation/devicetree/bindings/arm/gic.txt |6 ++
drivers/irqchip/irq-gic.c | 82 ++---
include/linux/irqchip/arm-gic.h |7 ++-
3 files changed, 84 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt
b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0..5357745 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -49,6 +49,11 @@ Optional
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
+- arm,routable-irqs : Total number of gic irq inputs which are not directly
+ connected from the peripherals, but are routed dynamically
+ by a crossbar/multiplexer preceding the GIC. The GIC irq
+ input line is assigned dynamically when the corresponding
+ peripheral's crossbar line is mapped.
Example:
intc: interrupt-controller@fff11000 {
@@ -56,6 +61,7 @@ Example:
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
+ arm,routable-irqs = 160;
reg = 0xfff11000 0x1000,
0xfff10100 0x100;
};
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 9031171..5cfb602 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -824,16 +824,25 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
irq_set_chip_and_handler(irq, gic_chip,
handle_fasteoi_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+
+ gic_routable_irq_domain_ops-map(d, irq, hw);
}
irq_set_chip_data(irq, d-host_data);
return 0;
}
+static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+ gic_routable_irq_domain_ops-unmap(d, irq);
+}
+
static int gic_irq_domain_xlate(struct irq_domain *d,
struct device_node *controller,
const u32 *intspec, unsigned int intsize,
unsigned long *out_hwirq, unsigned int
*out_type)
{
+ unsigned long ret = 0;
+
if (d-of_node != controller)
return -EINVAL;
if (intsize 3)
@@ -843,11 +852,20 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
*out_hwirq = intspec[1] + 16;
/* For SPIs, we need to add 16 more to get the GIC irq ID number */
- if (!intspec[0])
- *out_hwirq += 16;
+ if (!intspec[0]) {
+ ret = gic_routable_irq_domain_ops-xlate(d, controller,
+intspec,
+intsize,
+out_hwirq,
+out_type);
+
+ if (IS_ERR_VALUE(ret))
+ return ret;
+ }
*out_type = intspec[2] IRQ_TYPE_SENSE_MASK;
- return 0;
+
+ return ret;
}
#ifdef CONFIG_SMP
@@ -871,9 +889,41 @@ static struct notifier_block gic_cpu_notifier = {
const struct irq_domain_ops gic_irq_domain_ops = {
.map = gic_irq_domain_map,
+ .unmap = gic_irq_domain_unmap,
.xlate = gic_irq_domain_xlate,
};
+/* Default functions for routable irq domain */
+static int gic_routable_irq_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ return 0;
+}
+
+static void gic_routable_irq_domain_unmap(struct irq_domain *d,
+
[PATCH V5 3/4] ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
The wakeup gen mask/unmask callback uses the irq element of the irq_data to setup. The irq is the linux virtual irq number and is same as the hardware irq number only when the parent irqchip is setup as a legacy domain. When it is used as a linear domain, the virtual irqs are allocated dynamically and wakeup gen code cannot rely on these numbers to access the irq registers. Instead use the hwirq element of the irq_data which represent the physical irq number. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org --- arch/arm/mach-omap2/omap-wakeupgen.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index 3664562..693fe48 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -138,7 +138,7 @@ static void wakeupgen_mask(struct irq_data *d) unsigned long flags; raw_spin_lock_irqsave(wakeupgen_lock, flags); - _wakeupgen_clear(d-irq, irq_target_cpu[d-irq]); + _wakeupgen_clear(d-hwirq, irq_target_cpu[d-hwirq]); raw_spin_unlock_irqrestore(wakeupgen_lock, flags); } @@ -150,7 +150,7 @@ static void wakeupgen_unmask(struct irq_data *d) unsigned long flags; raw_spin_lock_irqsave(wakeupgen_lock, flags); - _wakeupgen_set(d-irq, irq_target_cpu[d-irq]); + _wakeupgen_set(d-hwirq, irq_target_cpu[d-hwirq]); raw_spin_unlock_irqrestore(wakeupgen_lock, flags); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 4/4] ARM: DRA: Enable Crossbar IP support for DRA7XX
Enable the crossbar IP support for DRA7xx soc. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org --- arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/omap4-common.c |2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index dc21df1..d538df6 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -135,6 +135,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_SMP select COMMON_CLK + select IRQ_CROSSBAR comment OMAP Core Type depends on ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index b39efd4..9880a16 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -22,6 +22,7 @@ #include linux/of_platform.h #include linux/export.h #include linux/irqchip/arm-gic.h +#include linux/irqchip/irq-crossbar.h #include linux/of_address.h #include linux/reboot.h @@ -281,5 +282,6 @@ void __init omap_gic_of_init(void) skip_errata_init: omap_wakeupgen_init(); + irqcrossbar_init(); irqchip_init(); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 0/4] DRIVERS: IRQCHIP: Add support for crossbar IP
Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. This series models the peripheral interrupts that can be routed through the crossbar to the GIC as 'routable-irqs'. The routable irqs are added in a separate linear domain inside the GIC. The registered routable domain's callback are invoked as a part of the GIC's callback, which in turn should allocate a free irq line and configure the IP accordingly. So every peripheral in the dts files mentions the fixed crossbar number as its interrupt. A free gic line for that gets allocated and configured when the peripheral interrupts are mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. V5: Addressed a comment from Mark Rutland mark.rutl...@arm.com, updated tags and rebased on 3.13-rc2 V4: Addressed a couple of comments and split the DTS file updates in to a separate series. V3: Addressed few more comments from Thomas Gleixner t...@linutronix.de Rebased patches 3,4,5,7 which updates the DTS file on top of below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.13/dts Rebased patches 1,2,6 on top of 3.12 mainline Updated Commit tags V2: Addressed Thomas Gleixner t...@linutronix.de comments and Kumar Gala ga...@codeaurora.org Split updating the DRA7.dtsi file for adding the routable-irqs Previous discussions that led to this is at https://lkml.org/lkml/2013/9/18/540 The V1,V2,V3,V4 post of these patches is at [V1] https://lkml.org/lkml/2013/9/30/283 [V2] http://www.spinics.net/lists/linux-omap/msg99540.html [V3] http://www.kernelhub.org/?msg=356470p=2 [V4] http://www.spinics.net/lists/linux-doc/msg16726.html Sricharan R (4): DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number ARM: DRA: Enable Crossbar IP support for DRA7XX Documentation/devicetree/bindings/arm/gic.txt |6 + .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++ arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/omap-wakeupgen.c |4 +- arch/arm/mach-omap2/omap4-common.c |2 + drivers/irqchip/Kconfig|8 + drivers/irqchip/Makefile |1 + drivers/irqchip/irq-crossbar.c | 208 drivers/irqchip/irq-gic.c | 81 +++- include/linux/irqchip/arm-gic.h|7 +- include/linux/irqchip/irq-crossbar.h | 11 ++ 11 files changed, 343 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt create mode 100644 drivers/irqchip/irq-crossbar.c create mode 100644 include/linux/irqchip/irq-crossbar.h -- 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 v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
Hi, On Thu, Oct 17, 2013 at 09:54:26AM -0500, Felipe Balbi wrote: On Wed, Oct 16, 2013 at 04:27:26PM +0300, Roger Quadros wrote: On 10/16/2013 04:10 PM, Kishon Vijay Abraham I wrote: Do you know if there are users of dwc3 other than exynos5250 and omap5? If not, we should get rid of the old USB PHY altogether. Intel's Baytrail, at least. But they don't use DT. I don't see any use for the generic-phy when the device is enumerated from PCI. If dwc3 can live without phys, there should not be any problem dropping the old USB PHY support. Br, -- heikki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: DT bindings for TPS65218 PMIC
On Tuesday 03 December 2013 03:06 PM, Lee Jones wrote:
Add DT bindings for TPS65218 PMIC.
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 27
.../devicetree/bindings/regulator/tps65218.txt | 22
2 files changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..87cb7a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,27 @@
+The TPS65218 Integrated Power Management Chips.
+These chips are connected to an i2c bus.
I2C
Ok.
+Required properties:
+- compatible : Must be ti,tps65218;
+- interrupts : This i2c device has an IRQ line connected to the main SoC
I2C
Ok.
+- interrupt-controller : Since the tps65218 support several interrupts
support(s) (hosts?)
Yes Supports multiple interrupts from the sub-modules.
+ internally, it is considered as an interrupt controller cascaded to the SoC.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller.
Phandle to ...
+Optional node:
node(s):
Ok.
+- Child nodes contain in the tps65218.
+ It supports a number of features.
Please re-phase the above two sentences to something decipherable.
Ok.
+ The children nodes will thus depend of the capability of the variant.
Please, go on ...
Ok.
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps@24 {
+compatible = ti,tps65218;
+reg = 0x24;
+interrupt-controller;
+#interrupt-cells = 2;
+interrupt-parent = gic;
+};
Perhaps it would be better to centralise the documentation inclusive
of the regulator contingent. Or at least provide a _full_ example in
each document.
Ok.
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..1ccf170
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,22 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-dcdc5 for DCDC5
+ - ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1 LDO
Why aren't you using 'regulator-compatible'?
I referred tps65217.txt the predecessors and used the compatible.
I also referred twl-regulator.txt.
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+ xyz: regulator@0 {
Genuine question: Is the @0 meaningful?
@0 is not the best example. @24 is what i use on the am43x.
I will change it to @24.
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
Thanks for reviewing.
Kind Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: DT bindings for TPS65218 PMIC
+- interrupt-controller : Since the tps65218 support several interrupts support(s) (hosts?) Yes Supports multiple interrupts from the sub-modules. I think 'support' should be the plural 'supports'. snip Why aren't you using 'regulator-compatible'? I referred tps65217.txt the predecessors and used the compatible. I also referred twl-regulator.txt. That doesn't mean that they are correct/better. ;) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)
Hi Roger, On Tuesday 03 December 2013 11:36:57 Roger Quadros wrote: On 12/03/2013 05:54 AM, Laurent Pinchart wrote: Hi Roger, On Monday 25 November 2013 15:55:45 Roger Quadros wrote: Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply for the USB PHY. As the generic PHY driver can't handle more than one supply at the moment, we configure this supply to be always on. This will cause a very small power impact if the USB host subsystem is not in use, about 76.86 micro-W + LDO power. Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere, so there won't be any functional impact on those boards other than some additional LDO power consumption. Do I need any patch other than this one (on top of v3.13-rc1) to enable the ethernet port on a Beagleboard-xM rev B ? Here's what the kernel reports at boot (with ignore_loglevel set on the command line). It seems on Rev A/B, the power enable line for the USB hub has reversed polarity than Rev C. Does the below patch work for you? It does, thank you. If yes, how do we account for it? Do we add a new file omap3-beagle-xm-ab.dts for rev A/B boards? Unless we want to add board code back with a runtime check, which I doubt would be regarded as a good idea, I don't see any other easy solution. diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts index b39918e..434d903 100644 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts @@ -78,6 +78,7 @@ regulator-max-microvolt = 330; gpio = twl_gpio 18 0;/* GPIO LEDA */ startup-delay-us = 7; + enable-active-high; }; /* HS USB Host PHY on PORT 2 */ -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
+ ret = of_platform_populate(client-dev.of_node, NULL, NULL,
+ client-dev);
What are you trying to do here?
Register each regulator as a platform device?
Yeah. The probe will be called for every regulator separately.
So there are two schools of thought on this. One is that if you want
to do it that way you should use the MFD framework to do this for you.
There is no need to recreate functionality that already exists. The
other is that you shouldn't be doing this at all with regulators. Mark
likes the idea of having a single regulator controller node which
contains all of these individual regulator sub-nodes and you initiate
a single call to for_each_child_of_node() within the driver in order
to register them all.
snip
This has a different structure to of_tps65218_match_table, please
ensure they're the same. I prefer spaces after '{' and before '}'.
Ok. I will add a space after '{' and before '}'. Sorry I did not
follow tps65218_id_table being different than of_tps65218_match_table.
One is of the type of_device_id and the other i2c_device_id.
Shouldn't matter, it's just a formatting thing.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] v4l: ti-vpe: Some VPE fixes
This series fixes 2 issues in the VPE driver. The first fix allows us to use UYVY color format for source and destination buffers. The second fix makes sure we don't set pixel format widths which the VPDMA HW can't support. None of these fixes are fatal, so they don't necessarily need to go in for the 3.13-rc fixes. Archit Taneja (2): v4l: ti-vpe: Fix the data_type value for UYVY VPDMA format v4l: ti-vpe: make sure VPDMA line stride constraints are met drivers/media/platform/ti-vpe/vpdma.c | 4 +-- drivers/media/platform/ti-vpe/vpdma.h | 5 ++- drivers/media/platform/ti-vpe/vpdma_priv.h | 2 +- drivers/media/platform/ti-vpe/vpe.c| 53 ++ 4 files changed, 47 insertions(+), 17 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] v4l: ti-vpe: Fix the data_type value for UYVY VPDMA format
The data_type value to be programmed in the data descriptors to fetch/write a UYVY buffer was not mentioned correctly in the older DRA7x documentation. This caused VPE to fail with UYVY color formats. Update the data_type value to fix functionality when UYVY format is used. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpdma_priv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/ti-vpe/vpdma_priv.h b/drivers/media/platform/ti-vpe/vpdma_priv.h index f0e9a80..c1a6ce1 100644 --- a/drivers/media/platform/ti-vpe/vpdma_priv.h +++ b/drivers/media/platform/ti-vpe/vpdma_priv.h @@ -78,7 +78,7 @@ #define DATA_TYPE_C420 0x6 #define DATA_TYPE_YC4220x7 #define DATA_TYPE_YC4440x8 -#define DATA_TYPE_CY4220x23 +#define DATA_TYPE_CY4220x27 #define DATA_TYPE_RGB16_5650x0 #define DATA_TYPE_ARGB_15550x1 -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] v4l: ti-vpe: make sure VPDMA line stride constraints are met
When VPDMA fetches or writes to an image buffer, the line stride must be a
multiple of 16 bytes. If it isn't, VPDMA HW will write/fetch until the next
16 byte boundry. This causes VPE to work incorrectly for source or destination
widths which don't satisfy the above alignment requirement.
In order to prevent this, we now make sure that when we set pix format for the
input and output buffers, the VPE source and destination image line strides are
16 byte aligned. Also, the motion vector buffers for the de-interlacer are
allocated in such a way that it ensures the same alignment.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 4 +--
drivers/media/platform/ti-vpe/vpdma.h | 5 +++-
drivers/media/platform/ti-vpe/vpe.c | 53 ++-
3 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index af0a5ff..f97253f 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -602,7 +602,7 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct
v4l2_rect *c_rect,
if (fmt-data_type == DATA_TYPE_C420)
depth = 8;
- stride = (depth * c_rect-width) 3;
+ stride = ALIGN((depth * c_rect-width) 3, VPDMA_STRIDE_ALIGN);
dma_addr += (c_rect-left * depth) 3;
dtd = list-next;
@@ -655,7 +655,7 @@ void vpdma_add_in_dtd(struct vpdma_desc_list *list, int
frame_width,
depth = 8;
}
- stride = (depth * c_rect-width) 3;
+ stride = ALIGN((depth * c_rect-width) 3, VPDMA_STRIDE_ALIGN);
dma_addr += (c_rect-left * depth) 3;
dtd = list-next;
diff --git a/drivers/media/platform/ti-vpe/vpdma.h
b/drivers/media/platform/ti-vpe/vpdma.h
index eaa2a71..62dd143 100644
--- a/drivers/media/platform/ti-vpe/vpdma.h
+++ b/drivers/media/platform/ti-vpe/vpdma.h
@@ -45,7 +45,10 @@ struct vpdma_data_format {
};
#define VPDMA_DESC_ALIGN 16 /* 16-byte descriptor alignment
*/
-
+#define VPDMA_STRIDE_ALIGN 16 /*
+* line stride of source and
dest
+* buffers should be 16 byte
aligned
+*/
#define VPDMA_DTD_DESC_SIZE32 /* 8 words */
#define VPDMA_CFD_CTD_DESC_SIZE16 /* 4 words */
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 4e58069..a5f7a35 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -30,6 +30,7 @@
#include linux/sched.h
#include linux/slab.h
#include linux/videodev2.h
+#include linux/log2.h
#include media/v4l2-common.h
#include media/v4l2-ctrls.h
@@ -54,10 +55,6 @@
/* required alignments */
#define S_ALIGN0 /* multiple of 1 */
#define H_ALIGN1 /* multiple of 2 */
-#define W_ALIGN1 /* multiple of 2 */
-
-/* multiple of 128 bits, line stride, 16 bytes */
-#define L_ALIGN4
/* flags that indicate a format can be used for capture/output */
#define VPE_FMT_TYPE_CAPTURE (1 0)
@@ -780,12 +777,21 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
if ((s_q_data-flags Q_DATA_INTERLACED)
!(d_q_data-flags Q_DATA_INTERLACED)) {
+ int bytes_per_line;
const struct vpdma_data_format *mv =
vpdma_misc_fmts[VPDMA_DATA_FMT_MV];
ctx-deinterlacing = 1;
- mv_buf_size =
- (s_q_data-width * s_q_data-height * mv-depth) 3;
+ /*
+* we make sure that the source image has a 16 byte aligned
+* stride, we need to do the same for the motion vector buffer
+* by aligning it's stride to the next 16 byte boundry. this
+* extra space will not be used by the de-interlacer, but will
+* ensure that vpdma operates correctly
+*/
+ bytes_per_line = ALIGN((s_q_data-width * mv-depth) 3,
+ VPDMA_STRIDE_ALIGN);
+ mv_buf_size = bytes_per_line * s_q_data-height;
} else {
ctx-deinterlacing = 0;
mv_buf_size = 0;
@@ -1352,7 +1358,8 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct
v4l2_format *f,
{
struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
struct v4l2_plane_pix_format *plane_fmt;
- int i;
+ unsigned int w_align;
+ int i, depth, depth_bytes;
if (!fmt || !(fmt-types type)) {
vpe_err(ctx-dev, Fourcc format (0x%08x) invalid.\n,
@@ -1363,7 +1370,31 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct
v4l2_format *f,
if (pix-field !=
Re: [PATCH v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi Kishon,
On Wed, Oct 16, 2013 at 01:24:12AM +0530, Kishon Vijay Abraham I wrote:
+ count = of_property_match_string(node, phy-names, usb2-phy);
+ if (count = 0 || (pdata pdata-usb2_generic_phy)) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+ dwc-usb2_phy = NULL;
+ }
+
+ count = of_property_match_string(node, phy-names, usb3-phy);
+ if (count = 0 || (pdata pdata-usb3_generic_phy)) {
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
+ dwc-usb3_phy = NULL;
+ }
Is there some specific reason for these checks? The driver should not
need to care about the platform (DT, ACPI, platform based).
Just get the phys and check the return value. In case ERR_PTR(-ENODEV)
leave the phy as NULL and let the driver continue normally. With other
errors you make the dwc3 probe fail.
Thanks,
--
heikki
--
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
kernel mode splash screen
Hello,
We are working on an embedded system where we need immediate feedback
on the screen in response to power button events, etc. We also need
to be able to display the splash screen whenever kernel is running.
User space splash screens get killed too early on shutdown, etc.
Does anyone know of a kernel mode splash screen that will:
1) display an image
2) display status messages
3) display progress bar (nice to have, but not required)
4) can be accessed from kernel and user space
5) when enabled, will disable writes from user space
6) FB based
I'm currently porting
http://git.yoctoproject.org/cgit/cgit.cgi/psplash/ to the linux
kernel. So far, its going fairly well. Psplash is fairly clean and
minimal. Two questions:
1) is there kernel function to write pixels to the framebuffer? I've
been looking at fb_fillrect()
2) what is the format of the color parameter in the following data
structure (gets passed to fb_fillrect():
struct fb_fillrect {
__u32 dx; /* screen-relative */
__u32 dy;
__u32 width;
__u32 height;
__u32 color;
__u32 rop;
};
3) We are using the omap2 frame buffer driver. By default its
configured to provide 3 frame-buffers. I'm not sure what this means,
but I thinking that perhaps we can use one for the splash screen, and
one for the normal frame buffer used by userspace? The issue is I
want to disable user space from drawing to the framebuffer instantly,
and switch to the splash screen when the user presses the power switch
(instant feedback). What is the purpose of multiple frame buffers,
and is this a reasonable use of them?
Thanks,
Cliff
--
=
http://bec-systems.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
On Tue, Dec 03, 2013 at 11:21:07AM +, Lee Jones wrote: other is that you shouldn't be doing this at all with regulators. Mark likes the idea of having a single regulator controller node which contains all of these individual regulator sub-nodes and you initiate a single call to for_each_child_of_node() within the driver in order to register them all. That's not really the case, it depends on how the hardware is structured. If the regulators are not laid out in a regular fashion or otherwise reusable then the above big bag of regulators makes sense. If the hardware is reusable then things are different. signature.asc Description: Digital signature
Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output
Hi Tony,
On 11/14/2013 04:35 AM, Tony Lindgren wrote:
Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
states in private data) improved things in general, but caused a
regression for setting the GPIO output direction.
The change reorganized twl_direction_out() and twl_set() and swapped
the function names around in the process. While doing that, a bug got
introduced that's not obvious while reading the patch as it appears
as no change to the code.
The bug is we now call function twl4030_set_gpio_dataout() twice in
both twl_direction_out() and twl_set(). Instead, we should first
call twl_direction_out() in twl_direction_out() followed by
twl4030_set_gpio_dataout() in twl_set().
This regression probably has gone unnoticed for a long time as the
bootloader may have set the GPIO direction properly in many cases.
This fixes at least the LCD panel not turning on omap3 LDP for
example.
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: linux-g...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
As one of the LED GPO is used for USB host on beagleboard, it will cause failure
of USB host probe.
I'll explain why below.
---
drivers/gpio/gpio-twl4030.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 0c7e891..5738d5a 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ int ret = -EINVAL;
mutex_lock(priv-mutex);
if (offset TWL4030_GPIO_MAX)
- twl4030_set_gpio_dataout(offset, value);
+ ret = twl4030_set_gpio_direction(offset, 0);
twl_direction_out() is supposed to return 0 on success and non-zero only on
failure.
for (offset = TWL4030_GPIO_MAX) i.e. LED output case we now return -EINVAL,
which
causes the LED GPO set_direction_out to fail. LED outputs are always outputs so
this function shouldn't fail.
priv-direction |= BIT(offset);
mutex_unlock(priv-mutex);
twl_set(chip, offset, value);
- return 0;
+ return ret;
}
static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
Below is a proposed fix for this.
From 7c36c8952ee3c7220ea21396cd3f84a1f9e9ea73 Mon Sep 17 00:00:00 2001
From: Roger Quadros rog...@ti.com
Date: Tue, 3 Dec 2013 15:24:05 +0200
Subject: [PATCH] gpio: twl4030: Fix regression for twl gpio LED output
Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.
This causes USB host probe failures for Beagleboard C4.
[2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests
probe deferral
[2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
[2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register
regulator: -22
[2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with
error -22
direction_out/direction_in must return 0 if the operation succeeded.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/gpio/gpio-twl4030.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..0999ed1 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -294,13 +294,13 @@ out:
static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
- int ret;
+ int ret = 0;
mutex_lock(priv-mutex);
if (offset TWL4030_GPIO_MAX)
- ret = twl4030_set_gpio_direction(offset, 1);
+ twl4030_set_gpio_direction(offset, 1);
else
- ret = -EINVAL;
+ ret = -EINVAL; /* LED outputs can't be set as input */
if (!ret)
priv-direction = ~BIT(offset);
@@ -354,18 +354,21 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
- int ret = -EINVAL;
mutex_lock(priv-mutex);
if (offset TWL4030_GPIO_MAX)
- ret = twl4030_set_gpio_direction(offset, 0);
+ twl4030_set_gpio_direction(offset, 0);
+
+ /*
+* LED gpio's i.e. offset = TWL4030_GPIO_MAX are always output
+*/
Re: [PATCH v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On Tuesday 03 December 2013 05:29 PM, Heikki Krogerus wrote:
Hi Kishon,
On Wed, Oct 16, 2013 at 01:24:12AM +0530, Kishon Vijay Abraham I wrote:
+count = of_property_match_string(node, phy-names, usb2-phy);
+if (count = 0 || (pdata pdata-usb2_generic_phy)) {
+dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+if (IS_ERR(dwc-usb2_generic_phy)) {
+dev_err(dev, no usb2 phy configured yet);
+return PTR_ERR(dwc-usb2_generic_phy);
+}
+dwc-usb2_phy = NULL;
+}
+
+count = of_property_match_string(node, phy-names, usb3-phy);
+if (count = 0 || (pdata pdata-usb3_generic_phy)) {
+dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+if (IS_ERR(dwc-usb3_generic_phy)) {
+dev_err(dev, no usb3 phy configured yet);
+return PTR_ERR(dwc-usb3_generic_phy);
+}
+dwc-usb3_phy = NULL;
+}
Is there some specific reason for these checks? The driver should not
need to care about the platform (DT, ACPI, platform based).
yeah just wanted to throw an error if a platform needs PHY but wasn't able to
get it. Btw this has changed after my v3 of this patch series which I sent
sometime back [1] where we use quirks to know if a PHY is needed for that
platform or not.
http://www.spinics.net/lists/linux-usb/msg98077.html
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP2+: hwmod: Fix RESET logic
In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.
This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.
To fix this we clear the SOFTRESET bit and update the sysconfig
register + sysc_cache using write_sysconfig().
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 43 +++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e3f0eca..615acec 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -399,7 +399,7 @@ static int _set_clockactivity(struct omap_hwmod *oh, u8
clockact, u32 *v)
}
/**
- * _set_softreset: set OCP_SYSCONFIG.CLOCKACTIVITY bits in @v
+ * _set_softreset: set OCP_SYSCONFIG.SOFTRESET bit in @v
* @oh: struct omap_hwmod *
* @v: pointer to register contents to modify
*
@@ -427,6 +427,36 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
}
/**
+ * _clr_softreset: clear OCP_SYSCONFIG.SOFTRESET bit in @v
+ * @oh: struct omap_hwmod *
+ * @v: pointer to register contents to modify
+ *
+ * Clear the SOFTRESET bit in @v for hwmod @oh. Returns -EINVAL upon
+ * error or 0 upon success.
+ */
+static int _clr_softreset(struct omap_hwmod *oh, u32 *v)
+{
+ u32 softrst_mask;
+
+ if (!oh-class-sysc ||
+ !(oh-class-sysc-sysc_flags SYSC_HAS_SOFTRESET))
+ return -EINVAL;
+
+ if (!oh-class-sysc-sysc_fields) {
+ WARN(1,
+omap_hwmod: %s: sysc_fields absent for sysconfig class\n,
+oh-name);
+ return -EINVAL;
+ }
+
+ softrst_mask = (0x1 oh-class-sysc-sysc_fields-srst_shift);
+
+ *v = ~softrst_mask;
+
+ return 0;
+}
+
+/**
* _wait_softreset_complete - wait for an OCP softreset to complete
* @oh: struct omap_hwmod * to wait on
*
@@ -1911,6 +1941,12 @@ static int _ocp_softreset(struct omap_hwmod *oh)
ret = _set_softreset(oh, v);
if (ret)
goto dis_opt_clks;
+
+ _write_sysconfig(v, oh);
+ ret = _clr_softreset(oh, v);
+ if (ret)
+ goto dis_opt_clks;
+
_write_sysconfig(v, oh);
if (oh-class-sysc-srst_udelay)
@@ -3169,6 +3205,11 @@ int omap_hwmod_softreset(struct omap_hwmod *oh)
goto error;
_write_sysconfig(v, oh);
+ ret = _clr_softreset(oh, v);
+ if (ret)
+ goto error;
+ _write_sysconfig(v, oh);
+
error:
return ret;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
Without this, the USB devices are sometimes not detected on OMAP4 Panda
with u-boot v2013.10.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 +++--
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..3318cae9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2937,7 +2937,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_usb_host_hs_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -3001,15 +3001,7 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 9e08d69..e297d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1544,7 +1544,8 @@ static struct omap_hwmod_class_sysconfig
omap54xx_usb_host_hs_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -1598,15 +1599,7 @@ static struct omap_hwmod omap54xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = l3init_60m_fclk,
.prcm = {
.omap4 = {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] ARM: OMAP2+: USB Host bug fixes for 3.13 rc
Hi, This is a follow up solution to the original series in [1] The first patch fixes the OMAP4 Panda USB detection problems on 3.13-rc1 with u-boot v2013.10. The remaining 2 patches are required if SOFTRESET needs to be done for the USB Host module on OMAP3 platforms. Patch 2 fixes the hwmod RESET logic to prevent multiple SOFTRESETs being issued to the modules. This multiple SOFTRESET was causing problems with OMAP3 USB Host module. On Beagleboard C4 this is seen as failure to mount NFS root over external USB to Ethernet device. This might be the reason why HWMOD_INIT_NO_RESET was used for the OMAP USB host module in OMAP3 hwmod data and just carried forward in OMAP4 and OMAP5 hwmod data as well. cheers, -roger [1] - http://thread.gmane.org/gmane.linux.kernel/1603931 Roger Quadros (3): ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module ARM: OMAP2+: hwmod: Fix RESET logic ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module arch/arm/mach-omap2/omap_hwmod.c | 43 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 +++-- 4 files changed, 50 insertions(+), 31 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9e56fab..d337429 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1943,7 +1943,8 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_usb_host_hs_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
@@ -2021,15 +2022,7 @@ static struct omap_hwmod omap3xxx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
On Tue, Dec 03, 2013 at 12:13:24PM +0530, Keerthy wrote:
+static int tps65218_ldo1_dcdc3_vsel_to_uv(unsigned int vsel)
+{
+ int uV = 0;
+
+ if (vsel = 26)
+ uV = vsel * 25000 + 90;
+ else
+ uV = (vsel - 26) * 5 + 155;
+
+ return uV;
+}
Use regulator_map_voltage_linear_range() (and similarly for most of the
other functions).
+static const struct of_device_id tps65218_of_match[] = {
+ TPS65218_OF_MATCH(ti,tps65218-dcdc1, tps65218_pmic_regs[0]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc2, tps65218_pmic_regs[1]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc3, tps65218_pmic_regs[2]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc4, tps65218_pmic_regs[3]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc5, tps65218_pmic_regs[4]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc6, tps65218_pmic_regs[5]),
+ TPS65218_OF_MATCH(ti,tps65218-ldo1, tps65218_pmic_regs[6]),
+};
+MODULE_DEVICE_TABLE(of, tps65218_of_match);
Indexing into another array by magic number like this is both error
prone and hard to read. Either use defined constants or individual
variables for the things being referenced.
signature.asc
Description: Digital signature
Re: [PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
On Tue, Dec 03, 2013 at 12:13:23PM +0530, Keerthy wrote:
+static struct regmap_config tps65218_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
You should consider using a register cache for at least the interrupt
mask registers, it'll improve performance.
signature.asc
Description: Digital signature
Re: [RFC PATCH v3 3/8] regulator: add pbias regulator support
On Thursday 21 November 2013 08:16 PM, Mark Brown wrote:
On Thu, Nov 21, 2013 at 07:50:22PM +0530, Balaji T K wrote:
+static int pbias_regulator_set_voltage(struct regulator_dev *dev,
+ int min_uV, int max_uV, unsigned *selector)
+{
+ struct pbias_regulator_data *data = rdev_get_drvdata(dev);
+ const struct pbias_bit_map *bmap = data-bmap;
+ int ret, vmode;
+
+ if (min_uV = 180)
+ vmode = 0;
+ else if (min_uV 180)
+ vmode = bmap-vmode;
+
+ ret = regmap_update_bits(data-syscon, data-pbias_reg,
+ bmap-vmode, vmode);
+ data-voltage = min_uV;
+static int pbias_regulator_get_voltage(struct regulator_dev *rdev)
+{
+ struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
+
+ return data-voltage;
+}
These don't match up with each other - the get and set voltage calls
should reflect what the hardware state is, not what was requested by the
caller. You should be able to use the regmap helpers I think.
Hi,
get_voltage returns the min_uV, saved in set_voltage since pbias
only need to programmed if the voltage supply in for pbias cell is less than
or greater than 1.8V, so vmode bit will be set for 3V and also for 3.3V too.
+static int pbias_regulator_enable(struct regulator_dev *rdev)
+{
+ struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
+ const struct pbias_bit_map *bmap = data-bmap;
+ int ret;
+
+ ret = regmap_update_bits(data-syscon, data-pbias_reg,
+ bmap-enable_mask, bmap-enable);
regulator_enable_regmap() and similarly for disable() and is_enabled().
I don't think regmap helper can be used here, to enable pbias cells
I need reset a bit field (to bring pbias out of high impedence mode)
and also set a bit (to bring it out of power down mode)
+ supply_name = initdata-constraints.name;
+
+ of_property_read_u32(np, startup-delay-us, startup_delay);
+ ret = of_property_read_u32(np, pbias-reg-offset,
+ drvdata-pbias_reg);
+ if (ret) {
+ dev_err(pdev-dev, no pbias-reg-offset property set\n);
+ return ret;
+ }
This looks like it should be added as a standard property for overridig
the regulator delay if it can't be set based on the compatible string
alone due to board dependencies. Do something like what's done for
regulator-ramp-delay.
+err_regulator:
+ kfree(drvdata-desc.name);
+ return ret;
devm_kzalloc().
Will assign desc name statically
+static int __init pbias_regulator_init(void)
+{
+ return platform_driver_register(pbias_regulator_driver);
+}
+subsys_initcall(pbias_regulator_init);
module_platform_driver().
OK
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 3/8] regulator: add pbias regulator support
On Tue, Dec 03, 2013 at 09:24:15PM +0530, Balaji T K wrote: On Thursday 21 November 2013 08:16 PM, Mark Brown wrote: These don't match up with each other - the get and set voltage calls should reflect what the hardware state is, not what was requested by the caller. You should be able to use the regmap helpers I think. get_voltage returns the min_uV, saved in set_voltage since pbias only need to programmed if the voltage supply in for pbias cell is less than or greater than 1.8V, so vmode bit will be set for 3V and also for 3.3V too. That's the problem... signature.asc Description: Digital signature
Re: [PATCH] mmc: omap: Fix error introduced by fix to release_mem_region() path
On 12/02/2013 07:34 PM, Tony Lindgren wrote: Commit 31ee9181eb92: (mmc: omap: Fix DMA configuration to not rely on device id) fixed getting of the DMA resources when booted with device tree. This patch however changed the handling of the free_mem_region() error path by reusing the struct resource *res for the DMA resources. Fix the error the same way omap_hsmmc.c driver handles it, which is to restore the resource before using the values to call release_mem_region(). Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Tony Lindgren t...@atomide.com I guess my devm_ioremap conversion would have fixed this? http://www.spinics.net/lists/linux-mmc/msg23317.html Does not help now but I'm thinking if queuing some of those my patches (3-5) on top of yours as a fix? Especially fix to NULL pointer dereference: http://www.spinics.net/lists/linux-mmc/msg23320.html -- Jarkko -- 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 v6] ARM: omap: edma: add suspend suspend/resume hooks
Daniel Mack zon...@gmail.com writes: On 11/27/2013 02:22 PM, Sekhar Nori wrote: + Kevin On Monday 25 November 2013 11:04 PM, Joel Fernandes wrote: On 11/17/2013 04:19 PM, Daniel Mack wrote: This patch makes the edma driver resume correctly after suspend. Tested on an AM33xx platform with cyclic audio streams and omap_hsmmc. All information can be reconstructed by already known runtime information. As we now use some functions that were previously only used from __init context, annotations had to be dropped. [n...@ti.com: added error handling for runtime + suspend_late/early_resume] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Daniel Mack zon...@gmail.com Tested-by: Joel Fernandes jo...@ti.com Acked-by: Joel Fernandes jo...@ti.com Hi Sekhar, Can you consider pulling this patch? It has been tested and Acked. Thanks. Kevin had some inputs on previous version of this patch. Were you able to make sure he is okay with this version being merged? I had concerns about the feedback I got, and haven't got answers yet. In particular, I'm not convinced that using runtime PM to suspend channels would actually save any power during runtime, or have any other benefit. /me returning from a week off The amount of power to be saved depends on the activity in the system. If DMA is unused, at least the clocks could be gated allowing the possibility of the enclosing power domain to be gated if other devices are also clock gated, etc. etc. However, my comments were not really about power saving, they were about designing things in a way that are scalable and match the longer term goals of converting drivers to be runtime PM centric. For example, if someone did want to add real runtime PM to this driver later, they would need to rework much of this. So my suggestion was to do runtime PM the right way from the beginning. That being said, I'm not the maintainer of this driver so don't get to make the final call. I will just say that from what I've seen here, I don't think this is the right approach. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[pandaboard] omap-aes L3 standard error
Hello, here a newly introduced one: https://bugzilla.kernel.org/show_bug.cgi?id=66441 Greets, Tobias -- 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.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Hi, current 3.13-rcX break usb support on gta04 board (similar to beagleboard) when booting via board file. In console we can see messages: [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5232.936096] omap_musb_mailbox: musb core is not yet ready [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock Any pointer what could cause that? (in 3.12 usb works fine) BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[pandaboard] audio initialization fails due to TWL6040
And another one! https://bugzilla.kernel.org/show_bug.cgi?id=66451 - Tobias -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: davinci_emac: Fix platform data handling and make usable for am3517
When booted with device tree, we may still have platform data passed
as auxdata. For am3517 this is needed for passing the interrupt_enable
and interrupt_disable callbacks that access the omap system control module
registers. These callback functions will eventually go away when we have
a separate system control module driver.
Some of the things that are currently passed as platform data we don't need
to set up as device tree properties as they are always the same on am3517.
So let's use a new compatible flag for those so we can get those from
the device tree match data.
Also note that we need to fix setting of phy_dev to NULL instead of an empty
string as the code later on uses that to find the first phy on the mdio bus.
This seems to have been caused by 5d69e0076a72 (net: davinci_emac: switch to
new mdio).
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ b/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -4,7 +4,7 @@ This file provides information, what the device node
for the davinci_emac interface contains.
Required properties:
-- compatible: ti,davinci-dm6467-emac;
+- compatible: ti,davinci-dm6467-emac or ti,am3517-emac
- reg: Offset and length of the register set for the device
- ti,davinci-ctrl-reg-offset: offset to control register
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -61,6 +61,7 @@
#include linux/davinci_emac.h
#include linux/of.h
#include linux/of_address.h
+#include linux/of_device.h
#include linux/of_irq.h
#include linux/of_net.h
@@ -1752,10 +1753,14 @@ static const struct net_device_ops emac_netdev_ops = {
#endif
};
+static const struct of_device_id davinci_emac_of_match[];
+
static struct emac_platform_data *
davinci_emac_of_get_pdata(struct platform_device *pdev, struct emac_priv *priv)
{
struct device_node *np;
+ const struct of_device_id *match;
+ const struct emac_platform_data *auxdata;
struct emac_platform_data *pdata = NULL;
const u8 *mac_addr;
@@ -1793,7 +1798,20 @@ davinci_emac_of_get_pdata(struct platform_device *pdev,
struct emac_priv *priv)
priv-phy_node = of_parse_phandle(np, phy-handle, 0);
if (!priv-phy_node)
- pdata-phy_id = ;
+ pdata-phy_id = NULL;
+
+ auxdata = pdev-dev.platform_data;
+ if (auxdata) {
+ pdata-interrupt_enable = auxdata-interrupt_enable;
+ pdata-interrupt_disable = auxdata-interrupt_disable;
+ }
+
+ match = of_match_device(davinci_emac_of_match, pdev-dev);
+ if (match match-data) {
+ auxdata = match-data;
+ pdata-version = auxdata-version;
+ pdata-hw_ram_addr = auxdata-hw_ram_addr;
+ }
pdev-dev.platform_data = pdata;
@@ -2020,8 +2038,14 @@ static const struct dev_pm_ops davinci_emac_pm_ops = {
};
#if IS_ENABLED(CONFIG_OF)
+static const struct emac_platform_data am3517_emac_data = {
+ .version= EMAC_VERSION_2,
+ .hw_ram_addr= 0x01e2,
+};
+
static const struct of_device_id davinci_emac_of_match[] = {
{.compatible = ti,davinci-dm6467-emac, },
+ {.compatible = ti,am3517-emac, .data = am3517_emac_data, },
{},
};
MODULE_DEVICE_TABLE(of, davinci_emac_of_match);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: OMAP2+: Remove legacy emac code
This is no longer needed when booted with device tree.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 3 -
arch/arm/mach-omap2/am35xx-emac.c | 115 --
arch/arm/mach-omap2/am35xx-emac.h | 15 -
3 files changed, 133 deletions(-)
delete mode 100644 arch/arm/mach-omap2/am35xx-emac.c
delete mode 100644 arch/arm/mach-omap2/am35xx-emac.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8e6b0a4..dea93e2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -258,7 +258,4 @@ ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
obj-y += hwspinlock.o
endif
-emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
-obj-y += $(emac-m) $(emac-y)
-
obj-y += common-board-devices.o dss-common.o
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
deleted file mode 100644
index 25b79a2..000
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ /dev/null
@@ -1,115 +0,0 @@
-/*
- * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
- *
- * Based on mach-omap2/board-am3517evm.c
- * Copyright (C) 2009 Texas Instruments Incorporated
- * Author: Ranjith Lohithakshan ranji...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2
- * published by the Free Software Foundation.
- *
- * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
- * whether express or implied; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include linux/err.h
-#include linux/davinci_emac.h
-#include asm/system.h
-#include omap_device.h
-#include am35xx.h
-#include control.h
-#include am35xx-emac.h
-
-static void am35xx_enable_emac_int(void)
-{
- u32 v;
-
- v = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- v |= (AM35XX_CPGMAC_C0_RX_PULSE_CLR | AM35XX_CPGMAC_C0_TX_PULSE_CLR |
- AM35XX_CPGMAC_C0_MISC_PULSE_CLR | AM35XX_CPGMAC_C0_RX_THRESH_CLR);
- omap_ctrl_writel(v, AM35XX_CONTROL_LVL_INTR_CLEAR);
- omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); /* OCP barrier */
-}
-
-static void am35xx_disable_emac_int(void)
-{
- u32 v;
-
- v = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- v |= (AM35XX_CPGMAC_C0_RX_PULSE_CLR | AM35XX_CPGMAC_C0_TX_PULSE_CLR);
- omap_ctrl_writel(v, AM35XX_CONTROL_LVL_INTR_CLEAR);
- omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); /* OCP barrier */
-}
-
-static struct emac_platform_data am35xx_emac_pdata = {
- .ctrl_reg_offset= AM35XX_EMAC_CNTRL_OFFSET,
- .ctrl_mod_reg_offset= AM35XX_EMAC_CNTRL_MOD_OFFSET,
- .ctrl_ram_offset= AM35XX_EMAC_CNTRL_RAM_OFFSET,
- .ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE,
- .hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
- .version= EMAC_VERSION_2,
- .interrupt_enable = am35xx_enable_emac_int,
- .interrupt_disable = am35xx_disable_emac_int,
-};
-
-static struct mdio_platform_data am35xx_mdio_pdata;
-
-static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
-{
- struct platform_device *pdev;
-
- pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len);
- if (IS_ERR(pdev)) {
- WARN(1, Can't build omap_device for %s:%s.\n,
-oh-class-name, oh-name);
- return PTR_ERR(pdev);
- }
-
- return 0;
-}
-
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
-{
- struct omap_hwmod *oh;
- u32 v;
- int ret;
-
- oh = omap_hwmod_lookup(davinci_mdio);
- if (!oh) {
- pr_err(Could not find davinci_mdio hwmod\n);
- return;
- }
-
- am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
-
- ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
-sizeof(am35xx_mdio_pdata));
- if (ret) {
- pr_err(Could not build davinci_mdio hwmod device\n);
- return;
- }
-
- oh = omap_hwmod_lookup(davinci_emac);
- if (!oh) {
- pr_err(Could not find davinci_emac hwmod\n);
- return;
- }
-
- am35xx_emac_pdata.rmii_en = rmii_en;
-
- ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
-sizeof(am35xx_emac_pdata));
- if (ret) {
- pr_err(Could not build davinci_emac hwmod device\n);
- return;
- }
-
- v = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
- v = ~AM35XX_CPGMACSS_SW_RST;
- omap_ctrl_writel(v, AM35XX_CONTROL_IP_SW_RESET);
-
[PATCH 4/5] ARM/dts: Add basic devices on am3517-evm
Let's add the Ethernet so NFSroot works and the first MMC card
so people can patch in more support easily.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am3517-evm.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/am3517-evm.dts b/arch/arm/boot/dts/am3517-evm.dts
index 03fcbf0..b4127c6 100644
--- a/arch/arm/boot/dts/am3517-evm.dts
+++ b/arch/arm/boot/dts/am3517-evm.dts
@@ -17,6 +17,21 @@
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
};
+
+vmmc_fixed: vmmc {
+compatible = regulator-fixed;
+regulator-name = vmmc_fixed;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+};
+};
+
+davinci_emac {
+status = okay;
+};
+
+davinci_mdio {
+status = okay;
};
i2c1 {
@@ -30,3 +45,17 @@
i2c3 {
clock-frequency = 40;
};
+
+mmc1 {
+ vmmc-supply = vmmc_fixed;
+ bus-width = 4;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: OMAP2+: Use pdata quirks for emac on am3517
As the emac uses the system control module registers for
reset and interrupts, we need to pass those in the platform
data until we have a separate system control module driver.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/pdata-quirks.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index ecdba9f..ec83c20 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
#include linux/clk.h
+#include linux/davinci_emac.h
#include linux/gpio.h
#include linux/init.h
#include linux/kernel.h
@@ -16,6 +17,7 @@
#include linux/platform_data/pinctrl-single.h
+#include am35xx.h
#include common.h
#include common-board-devices.h
#include dss-common.h
@@ -118,6 +120,42 @@ static void __init omap3_zoom_legacy_init(void)
{
legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
}
+
+static void am35xx_enable_emac_int(void)
+{
+ u32 v;
+
+ v = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ v |= (AM35XX_CPGMAC_C0_RX_PULSE_CLR | AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_MISC_PULSE_CLR | AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+ omap_ctrl_writel(v, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); /* OCP barrier */
+}
+
+static void am35xx_disable_emac_int(void)
+{
+ u32 v;
+
+ v = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ v |= (AM35XX_CPGMAC_C0_RX_PULSE_CLR | AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+ omap_ctrl_writel(v, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); /* OCP barrier */
+}
+
+static struct emac_platform_data am35xx_emac_pdata = {
+ .interrupt_enable = am35xx_enable_emac_int,
+ .interrupt_disable = am35xx_disable_emac_int,
+};
+
+static void __init am3517_evm_legacy_init(void)
+{
+ u32 v;
+
+ v = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+ v = ~AM35XX_CPGMACSS_SW_RST;
+ omap_ctrl_writel(v, AM35XX_CONTROL_IP_SW_RESET);
+ omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); /* OCP barrier */
+}
#endif /* CONFIG_ARCH_OMAP3 */
#ifdef CONFIG_ARCH_OMAP4
@@ -186,6 +224,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002a00, 48002a00.pinmux,
pcs_pdata),
+ /* Only on am3517 */
+ OF_DEV_AUXDATA(ti,davinci_mdio, 0x5c03, davinci_mdio.0, NULL),
+ OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
+ am35xx_emac_pdata),
#endif
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
@@ -207,6 +249,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ ti,omap3-evm-37xx, omap3_evm_legacy_init, },
{ ti,omap3-ldp, omap3_ldp_legacy_init, },
{ ti,omap3-zoom3, omap3_zoom_legacy_init, },
+ { ti,am3517-evm, am3517_evm_legacy_init, },
#endif
#ifdef CONFIG_ARCH_OMAP4
{ ti,omap4-sdp, omap4_sdp_legacy_init, },
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: OMAP2+: Fix the machine entry for am3517
From: Nishanth Menon n...@ti.com
The am3517 is wrongly booting as omap3 which means that the am3517
specific devices like Ethernet won't work when booted with device
tree. Now with the new devices defined in am3517.dtsi, let's use
that instead of the omap3.dtsi, and add a separate machine entry
for am3517 so am3517-evm can use it.
Signed-off-by: Nishanth Menon n...@ti.com
[t...@atomide.com: updated comments]
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am3517-evm.dts| 6 +++---
arch/arm/mach-omap2/board-generic.c | 18 ++
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am3517-evm.dts b/arch/arm/boot/dts/am3517-evm.dts
index e99dfaf..03fcbf0 100644
--- a/arch/arm/boot/dts/am3517-evm.dts
+++ b/arch/arm/boot/dts/am3517-evm.dts
@@ -7,11 +7,11 @@
*/
/dts-v1/;
-#include omap34xx.dtsi
+#include am3517.dtsi
/ {
- model = TI AM3517 EVM (AM3517/05);
- compatible = ti,am3517-evm, ti,omap3;
+ model = TI AM3517 EVM (AM3517/05 TMDSEVM3517);
+ compatible = ti,am3517-evm, ti,am3517, ti,omap3;
memory {
device_type = memory;
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 19f1652..e94a215 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -139,6 +139,24 @@ static const char *am33xx_boards_compat[] __initdata = {
NULL,
};
+static const char *am3517_boards_compat[] __initdata = {
+ ti,am3517,
+ NULL,
+};
+
+DT_MACHINE_START(AM3517_DT, Generic AM3517 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = am35xx_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = am3517_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree))
.reserve= omap_reserve,
.map_io = am33xx_map_io,
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] arm/dts: Fix missing entries for am3517
On am3517 there are some extra devices compared to omap3.dtsi that
we currently have not defined. Let's fix that by adding am3517.dtsi
file.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am3517.dtsi | 63 +++
1 file changed, 63 insertions(+)
create mode 100644 arch/arm/boot/dts/am3517.dtsi
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
new file mode 100644
index 000..2fbe02f
--- /dev/null
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -0,0 +1,63 @@
+/*
+ * Device Tree Source for am3517 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include omap3.dtsi
+
+/ {
+ aliases {
+ serial3 = uart4;
+ };
+
+ ocp {
+ am35x_otg_hs: am35x_otg_hs@5c04 {
+ compatible = ti,omap3-musb;
+ ti,hwmods = am35x_otg_hs;
+ status = disabled;
+ reg = 0x5c04 0x1000;
+ interrupts = 71;
+ interrupt-names = mc;
+ };
+
+ davinci_emac: ethernet@0x5c00 {
+ compatible = ti,am3517-emac;
+ ti,hwmods = davinci_emac;
+ status = disabled;
+ reg = 0x5c00 0x3;
+ interrupts = 67 68 69 70;
+ ti,davinci-ctrl-reg-offset = 0x1;
+ ti,davinci-ctrl-mod-reg-offset = 0;
+ ti,davinci-ctrl-ram-offset = 0x2;
+ ti,davinci-ctrl-ram-size = 0x2000;
+ ti,davinci-rmii-en = /bits/ 8 1;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: ethernet@0x5c03 {
+ compatible = ti,davinci_mdio;
+ ti,hwmods = davinci_mdio;
+ status = disabled;
+ reg = 0x5c03 0x1000;
+ bus_freq = 100;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+
+ uart4: serial@4809e000 {
+ compatible = ti,omap3-uart;
+ ti,hwmods = uart4;
+ status = disabled;
+ reg = 0x4809e000 0x400;
+ interrupts = 84;
+ dmas = sdma 55 sdma 54;
+ dma-names = tx, rx;
+ clock-frequency = 4800;
+ };
+ };
+};
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Get am3517 working with device tree
Hi all, Looks like I missed am3517 earlier when making mach-omap2 boot in device tree only mode. Here are patches to make am3517-evm bootable with NFSroot and MMC with device tree. This should make it easy to add further support and also to add support for the missing am3517 craneboard and cm-t3517 boards. These should apply against v3.12 except for the pdata-quirks.c patch that depends on the earlier mach-omap2 device tree conversion patches. Regards, Tony Nishanth Menon (1): ARM: OMAP2+: Fix the machine entry for am3517 Tony Lindgren (4): arm/dts: Fix missing entries for am3517 ARM: OMAP2+: Use pdata quirks for emac on am3517 ARM/dts: Add basic devices on am3517-evm ARM: OMAP2+: Remove legacy emac code arch/arm/boot/dts/am3517-evm.dts| 35 ++- arch/arm/boot/dts/am3517.dtsi | 63 arch/arm/mach-omap2/Makefile| 3 - arch/arm/mach-omap2/am35xx-emac.c | 115 arch/arm/mach-omap2/am35xx-emac.h | 15 - arch/arm/mach-omap2/board-generic.c | 18 ++ arch/arm/mach-omap2/pdata-quirks.c | 43 ++ 7 files changed, 156 insertions(+), 136 deletions(-) create mode 100644 arch/arm/boot/dts/am3517.dtsi delete mode 100644 arch/arm/mach-omap2/am35xx-emac.c delete mode 100644 arch/arm/mach-omap2/am35xx-emac.h -- 1.8.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected
Due to the cross dependencies between hwmod for automanaged device
information for OMAP and dts node definitions, we can run into scenarios
where the dts node is defined, however it's hwmod entry is yet to be
added. In these cases:
a) omap_device does not register a pm_domain (since it cannot find
hwmod entry).
b) driver does not know about (a), does a pm_runtime_get_sync which
never fails
c) It then tries to do some operation on the device (such as read the
revision register (as part of probe) without clock or adequate OMAP
generic PM operation performed for enabling the module.
This causes a crash such as that reported in:
https://bugzilla.kernel.org/show_bug.cgi?id=66441
When 'ti,hwmod' is provided in dt node, it is expected that the device
will not function without the OMAP's power automanagement. Hence, when
we hit a fail condition (due to hwmod entries not present or other
similar scenario), fail at pm_domain level due to lack of data, provide
enough information for it to be fixed, however, it allows for the driver
to take appropriate measures to prevent crash.
Reported-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap_device.c | 24
arch/arm/mach-omap2/omap_device.h |1 +
2 files changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 53f0735..e0a398c 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -183,6 +183,10 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
odbfd_exit1:
kfree(hwmods);
odbfd_exit:
+ /* if data/we are at fault.. load up a fail handler */
+ if (ret)
+ pdev-dev.pm_domain = omap_device_fail_pm_domain;
+
return ret;
}
@@ -604,6 +608,19 @@ static int _od_runtime_resume(struct device *dev)
return pm_generic_runtime_resume(dev);
}
+
+static int _od_fail_runtime_suspend(struct device *dev)
+{
+ dev_warn(dev, %s: FIXME: missing hwmod/omap_dev info\n, __func__);
+ return -ENODEV;
+}
+
+static int _od_fail_runtime_resume(struct device *dev)
+{
+ dev_warn(dev, %s: FIXME: missing hwmod/omap_dev info\n, __func__);
+ return -ENODEV;
+}
+
#endif
#ifdef CONFIG_SUSPEND
@@ -657,6 +674,13 @@ static int _od_resume_noirq(struct device *dev)
#define _od_resume_noirq NULL
#endif
+struct dev_pm_domain omap_device_fail_pm_domain = {
+ .ops = {
+ SET_RUNTIME_PM_OPS(_od_fail_runtime_suspend,
+ _od_fail_runtime_resume, NULL)
+ }
+};
+
struct dev_pm_domain omap_device_pm_domain = {
.ops = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
diff --git a/arch/arm/mach-omap2/omap_device.h
b/arch/arm/mach-omap2/omap_device.h
index 17ca1ae..78c02b3 100644
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -29,6 +29,7 @@
#include omap_hwmod.h
extern struct dev_pm_domain omap_device_pm_domain;
+extern struct dev_pm_domain omap_device_fail_pm_domain;
/* omap_device._state values */
#define OMAP_DEVICE_STATE_UNKNOWN 0
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: omap-aes: add error check for pm_runtime_get_sync
The AES driver currently assumes that pm_runtime_get_sync will always
succeed, which may not always be true, so add error handling for the
same.
This scenario was reported in the following bug:
place. https://bugzilla.kernel.org/show_bug.cgi?id=66441
Reported-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Signed-off-by: Nishanth Menon n...@ti.com
---
Note: the bug in OMAP pm_domain layer is addressed here:
https://patchwork.kernel.org/patch/3280531/
Proper fixes required to make this work is part of the series:
http://marc.info/?l=linux-kernelm=138541594910233w=2
drivers/crypto/omap-aes.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index a9ccbf1..dde41f1d 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -784,6 +784,7 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request
*req)
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
struct omap_aes_dev *dd = NULL;
+ int err;
/* Find AES device, currently picks the first device */
spin_lock_bh(list_lock);
@@ -792,7 +793,13 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
}
spin_unlock_bh(list_lock);
- pm_runtime_get_sync(dd-dev);
+ err = pm_runtime_get_sync(dd-dev);
+ if (err 0) {
+ dev_err(dd-dev, %s: failed to get_sync(%d)\n,
+ __func__, err);
+ return err;
+ }
+
tfm-crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -1182,7 +1189,12 @@ static int omap_aes_probe(struct platform_device *pdev)
dd-phys_base = res.start;
pm_runtime_enable(dev);
- pm_runtime_get_sync(dev);
+ err = pm_runtime_get_sync(dev);
+ if (err 0) {
+ dev_err(dev, %s: failed to get_sync(%d)\n,
+ __func__, err);
+ goto err_res;
+ }
omap_aes_dma_stop(dd);
--
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: [pandaboard] omap-aes L3 standard error
On 12/03/2013 03:05 PM, Tobias Jakobi wrote: Hello, here a newly introduced one: https://bugzilla.kernel.org/show_bug.cgi?id=66441 [1] solves the issue However, digging further, the root of the crash starts here: platform 4b501000.aes: Cannot lookup hwmod 'aes' with this, the following happens: a) omap_device does not register a pm_domain (since it cannot find hwmod entry). b) driver does not know about (a), does a pm_runtime_get_sync which never fails c) tries to read the revision register (as part of probe) without clock. generates the issue mentioned above. Now, there are three issues here: a) hwmod entries are not present - this is addressed in [1] b) omap_device pm_domain is not handled - fixed in [2] c) aes driver needs to handle error case when pm_runtime_get_sync fails. addressed in [3]. [1] http://marc.info/?l=linux-kernelm=138541593010221w=2 + http://marc.info/?l=linux-kernelm=138541603810300w=2 [2] https://patchwork.kernel.org/patch/3280531/ [3] https://patchwork.kernel.org/patch/3280571/ -- 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 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
Thanks for the review Mark.
On Tuesday 03 December 2013 08:46 PM, Mark Brown wrote:
On Tue, Dec 03, 2013 at 12:13:24PM +0530, Keerthy wrote:
+static int tps65218_ldo1_dcdc3_vsel_to_uv(unsigned int vsel)
+{
+ int uV = 0;
+
+ if (vsel = 26)
+ uV = vsel * 25000 + 90;
+ else
+ uV = (vsel - 26) * 5 + 155;
+
+ return uV;
+}
Use regulator_map_voltage_linear_range() (and similarly for most of the
other functions).
Ok.
+static const struct of_device_id tps65218_of_match[] = {
+ TPS65218_OF_MATCH(ti,tps65218-dcdc1, tps65218_pmic_regs[0]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc2, tps65218_pmic_regs[1]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc3, tps65218_pmic_regs[2]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc4, tps65218_pmic_regs[3]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc5, tps65218_pmic_regs[4]),
+ TPS65218_OF_MATCH(ti,tps65218-dcdc6, tps65218_pmic_regs[5]),
+ TPS65218_OF_MATCH(ti,tps65218-ldo1, tps65218_pmic_regs[6]),
+};
+MODULE_DEVICE_TABLE(of, tps65218_of_match);
Indexing into another array by magic number like this is both error
prone and hard to read. Either use defined constants or individual
variables for the things being referenced.
Okay.
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
Hi Keerthy,
+ rdev = regulator_register(regulators[id], config);
Can you make use of devm_regulator_register instead?
+ if (IS_ERR(rdev)) {
+ dev_err(tps-dev, failed to register %s regulator\n,
+ pdev-name);
+ return PTR_ERR(rdev);
+ }
+
+ /* Save regulator */
+ tps-rdev[id] = rdev;
+
+ return 0;
+}
Best Regards
Manish Badarkhe
--
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
