[PATCH v5 00/11] ARM: OMAP2+: AM43x PRCM basic support
Hi Paul, Benoit, Tony, This series adds PRCM support (except clock tree) for AM43x SoC's. Please consider this for inclusion in the coming merge window. Patch 02/11 ARM: OMAP2+: hwmod: AM335x/AM43x: move common data may not reach mailing lists due to bigger size, this series is also present @git://gitorious.org/x0148406-public/linux-kernel.git tags/am43x-prcm-v5 Compared to v4, only change is in fixing the powerdomain data. Major changes compared to rfc v3: 1. All register offsets properly taken care for AM43x (with rfc v3, a couple of issues was detected while testing on pre-silicon) 2. There were two patches for common hwmod data movement (one for interconnect and other for ip block data), both were combined to have a cleaner series that is bisectable. 3. Cleaner seperation of common data Major changes compared to v2 (v3 was only an rfc for current approach): 1. omap_hwmod_33xx_43xx_interconnect_data.c has the common interconnect ocp's structs shared between AM335x and AM43x 2. omap_hwmod_33xx_43xx_ipblock_data.c has the common hwmod structs shared between AM335x and AM43x 3. Instances where clock domain or clock topology has changed in the few cases, have separate structures for AM335x and AM43x 4. To handle scenarios where register offsets are different, they are dynamically init-ed in omap_hwmod_33xx_43xx_ipblock_data.c 5. Register offsets for hwmod's that are present either in AM335x or AM43x are updated statically in omap_hwmod_33xx_data.c or omap_hwmod_43xx_data.c as that was cleaner. 6. Remove the change that re-introduces SW_SLEEP for OMAP4, this will be taken care separately. This series has been boot tested on pre-silicon platform with the help of Tero's DT clock tree conversion series. This series has been tested on AM335x-EVM too. Additional details: AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. As AM43x PRCM register layout differs from AM335x and is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. Currently there is no public TRM available for AM43x. Changes based on: v3.12-rc2 Regards Afzal Afzal Mohammed (7): ARM: OMAP2+: hwmod: AM335x/AM43x: move common data ARM: OMAP2+: hwmod: AM335x: runtime register update ARM: OMAP2+: hwmod: AM335x: remove static register offs ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AM43x support ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 arch/arm/mach-omap2/Makefile |9 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c| 196 ++ arch/arm/mach-omap2/cm33xx.c | 16 +- arch/arm/mach-omap2/cm33xx.h | 12 +- arch/arm/mach-omap2/cminst44xx.c | 29 +- arch/arm/mach-omap2/cminst44xx.h | 26 +- arch/arm/mach-omap2/io.c |6 + arch/arm/mach-omap2/omap_hwmod.c |8 + arch/arm/mach-omap2/omap_hwmod.h |1 + .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 163 ++ .../omap_hwmod_33xx_43xx_interconnect_data.c | 643 +++ .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 1456 +++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1966 +--- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 622 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c| 136 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 18 files changed, 3432 insertions(+), 2003 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 1.8.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/11] ARM: OMAP2+: CM: cm_inst offset s16-u16
From: Ankur Kishore a-kish...@ti.com
Most of the AM43x CM reg address offsets are with MSB bit '1' (on
16-bit value) leading to arithmetic miscalculations while calculating
CLOCK ENABLE register's address because cm_inst field was a type of
const s16, so make it const u16.
Also modify relevant functions so as to take care of the above.
[af...@ti.com: fixup and cleanup]
Signed-off-by: Ankur Kishore a-kish...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clockdomain.h | 2 +-
arch/arm/mach-omap2/cm33xx.c | 16
arch/arm/mach-omap2/cm33xx.h | 10 +-
arch/arm/mach-omap2/cminst44xx.c | 20 ++--
arch/arm/mach-omap2/cminst44xx.h | 26 +-
5 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 4b03394..5431b0c 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -132,7 +132,7 @@ struct clockdomain {
u8 _flags;
const u8 dep_bit;
const u8 prcm_partition;
- const s16 cm_inst;
+ const u16 cm_inst;
const u16 clkdm_offs;
struct clkdm_dep *wkdep_srcs;
struct clkdm_dep *sleepdep_srcs;
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 325a515..40a22e5 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -48,13 +48,13 @@
/* Private functions */
/* Read a register in a CM instance */
-static inline u32 am33xx_cm_read_reg(s16 inst, u16 idx)
+static inline u32 am33xx_cm_read_reg(u16 inst, u16 idx)
{
return __raw_readl(cm_base + inst + idx);
}
/* Write into a register in a CM */
-static inline void am33xx_cm_write_reg(u32 val, s16 inst, u16 idx)
+static inline void am33xx_cm_write_reg(u32 val, u16 inst, u16 idx)
{
__raw_writel(val, cm_base + inst + idx);
}
@@ -138,7 +138,7 @@ static bool _is_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
* @c must be the unshifted value for CLKTRCTRL - i.e., this function
* will handle the shift itself.
*/
-static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
+static void _clktrctrl_write(u8 c, u16 inst, u16 cdoffs)
{
u32 v;
@@ -158,7 +158,7 @@ static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
* Returns true if the clockdomain referred to by (@inst, @cdoffs)
* is in hardware-supervised idle mode, or 0 otherwise.
*/
-bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
+bool am33xx_cm_is_clkdm_in_hwsup(u16 inst, u16 cdoffs)
{
u32 v;
@@ -177,7 +177,7 @@ bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
* Put a clockdomain referred to by (@inst, @cdoffs) into
* hardware-supervised idle mode. No return value.
*/
-void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_enable_hwsup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_ENABLE_AUTO, inst, cdoffs);
}
@@ -191,7 +191,7 @@ void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
* software-supervised idle mode, i.e., controlled manually by the
* Linux OMAP clockdomain code. No return value.
*/
-void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, inst, cdoffs);
}
@@ -204,7 +204,7 @@ void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
* Put a clockdomain referred to by (@inst, @cdoffs) into idle
* No return value.
*/
-void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, inst, cdoffs);
}
@@ -217,7 +217,7 @@ void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
* Take a clockdomain referred to by (@inst, @cdoffs) out of idle,
* waking it up. No return value.
*/
-void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_WAKEUP, inst, cdoffs);
}
diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h
index 9d1f4fc..757320b 100644
--- a/arch/arm/mach-omap2/cm33xx.h
+++ b/arch/arm/mach-omap2/cm33xx.h
@@ -377,11 +377,11 @@
#ifndef __ASSEMBLER__
-extern bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs);
+bool am33xx_cm_is_clkdm_in_hwsup(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_enable_hwsup(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs);
#if defined(CONFIG_SOC_AM33XX) ||
[PATCH v5 03/11] ARM: OMAP2+: hwmod: AM335x: runtime register update
Most of IP's in AM335x is present on AM43x and so in those cases both
will use same hwmod database (except for a few cases where clock related
details differ), but there is difference w.r.t register offset between
these. Update register offsets at runtime based on the SoC detected to
help in sharing otherwise same hwmod.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 +
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 77 ++
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
3 files changed, 80 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index e873e72..a9a7902 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
@@ -157,4 +157,6 @@ extern struct omap_hwmod_class am33xx_spi_hwmod_class;
extern struct omap_gpio_dev_attr gpio_dev_attr;
extern struct omap2_mcspi_dev_attr mcspi_attrib;
+void omap_hwmod_am33xx_reg(void);
+
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 3e70e9c..da40252 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -24,6 +24,10 @@
#include prm33xx.h
#include omap_hwmod_33xx_43xx_common_data.h
+#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
+#define RSTCTRL(oh, rstctrl) ((oh).prcm.omap4.rstctrl_offs = (rstctrl))
+#define RSTST(oh, rstst) ((oh).prcm.omap4.rstst_offs = (rstst))
+
/*
* 'l3' class
* instance(s): l3_main, l3_s, l3_instr
@@ -1360,3 +1364,76 @@ struct omap_hwmod am33xx_wd_timer1_hwmod = {
},
},
};
+
+static void omap_hwmod_am33xx_clkctrl(void)
+{
+ CLKCTRL(am33xx_uart2_hwmod, AM33XX_CM_PER_UART1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart3_hwmod, AM33XX_CM_PER_UART2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart4_hwmod, AM33XX_CM_PER_UART3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart5_hwmod, AM33XX_CM_PER_UART4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart6_hwmod, AM33XX_CM_PER_UART5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan0_hwmod, AM33XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan1_hwmod, AM33XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_elm_hwmod, AM33XX_CM_PER_ELM_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss0_hwmod, AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss1_hwmod, AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss2_hwmod, AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio1_hwmod, AM33XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio2_hwmod, AM33XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio3_hwmod, AM33XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c2_hwmod, AM33XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c3_hwmod, AM33XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mailbox_hwmod, AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp0_hwmod, AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp1_hwmod, AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc0_hwmod, AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc1_hwmod, AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi0_hwmod, AM33XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi1_hwmod, AM33XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spinlock_hwmod, AM33XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer2_hwmod, AM33XX_CM_PER_TIMER2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer3_hwmod, AM33XX_CM_PER_TIMER3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer4_hwmod, AM33XX_CM_PER_TIMER4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer5_hwmod, AM33XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer6_hwmod, AM33XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer7_hwmod, AM33XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex0_hwmod,
+ AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex1_hwmod,
+ AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart1_hwmod, AM33XX_CM_WKUP_UART0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer1_hwmod, AM33XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c1_hwmod, AM33XX_CM_WKUP_I2C0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_wd_timer1_hwmod, AM33XX_CM_WKUP_WDT1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_rtc_hwmod, AM33XX_CM_RTC_RTC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc2_hwmod, AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpmc_hwmod, AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_ls_hwmod, AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_wkup_hwmod, AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
+
[PATCH v5 04/11] ARM: OMAP2+: hwmod: AM335x: remove static register offs
Hwmod common to AM43x and AM335x has register offsets different. It is
now updated based on SoC detection at run time, hence remove statically
initialized ones.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 57 --
1 file changed, 57 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index da40252..598f813 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -44,7 +44,6 @@ struct omap_hwmod am33xx_l3_main_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L3_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -66,7 +65,6 @@ struct omap_hwmod am33xx_l3_instr_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -89,7 +87,6 @@ struct omap_hwmod am33xx_l4_ls_hwmod = {
.main_clk = l4ls_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -103,7 +100,6 @@ struct omap_hwmod am33xx_l4_wkup_hwmod = {
.flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -124,7 +120,6 @@ struct omap_hwmod am33xx_mpu_hwmod = {
.main_clk = dpll_mpu_m2_ck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_MPU_MPU_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -159,8 +154,6 @@ struct omap_hwmod am33xx_pruss_hwmod = {
.main_clk = pruss_ocp_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_PRUSS_CLKCTRL_OFFSET,
- .rstctrl_offs = AM33XX_RM_PER_RSTCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -185,9 +178,6 @@ struct omap_hwmod am33xx_gfx_hwmod = {
.main_clk = gfx_fck_div_ck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
- .rstctrl_offs = AM33XX_RM_GFX_RSTCTRL_OFFSET,
- .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -232,7 +222,6 @@ struct omap_hwmod am33xx_aes0_hwmod = {
.main_clk = aes0_fck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_AES0_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -258,7 +247,6 @@ struct omap_hwmod am33xx_sha0_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_SHA0_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -277,7 +265,6 @@ struct omap_hwmod am33xx_ocmcram_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -296,7 +283,6 @@ struct omap_hwmod am33xx_smartreflex0_hwmod = {
.main_clk = smartreflex0_fck,
.prcm = {
.omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -310,7 +296,6 @@ struct omap_hwmod am33xx_smartreflex1_hwmod = {
.main_clk = smartreflex1_fck,
.prcm = {
.omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -352,7 +337,6 @@ struct omap_hwmod am33xx_cpgmac0_hwmod = {
.mpu_rt_idx = 1,
.prcm = {
.omap4 = {
- .clkctrl_offs =
[PATCH v5 05/11] ARM: OMAP2+: PRCM: AM43x definitions
Add AM43x CMINST, CDOFFS, RM_RSTST RM_RSTCTRL definitions - minimal ones that would be used. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/prcm43xx.h | 141 + 1 file changed, 141 insertions(+) create mode 100644 arch/arm/mach-omap2/prcm43xx.h diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h new file mode 100644 index 000..f0636ec --- /dev/null +++ b/arch/arm/mach-omap2/prcm43xx.h @@ -0,0 +1,141 @@ +/* + * AM43x PRCM defines + * + * 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. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H +#define __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H + +#define AM43XX_PRM_PARTITION 1 +#define AM43XX_CM_PARTITION1 + +/* PRM instances */ +#define AM43XX_PRM_OCP_SOCKET_INST 0x +#define AM43XX_PRM_MPU_INST0x0300 +#define AM43XX_PRM_GFX_INST0x0400 +#define AM43XX_PRM_RTC_INST0x0500 +#define AM43XX_PRM_TAMPER_INST 0x0600 +#define AM43XX_PRM_CEFUSE_INST 0x0700 +#define AM43XX_PRM_PER_INST0x0800 +#define AM43XX_PRM_WKUP_INST 0x2000 +#define AM43XX_PRM_DEVICE_INST 0x4000 + +/* RM RSTCTRL offsets */ +#define AM43XX_RM_PER_RSTCTRL_OFFSET 0x0010 +#define AM43XX_RM_GFX_RSTCTRL_OFFSET 0x0010 +#define AM43XX_RM_WKUP_RSTCTRL_OFFSET 0x0010 + +/* RM RSTST offsets */ +#define AM43XX_RM_GFX_RSTST_OFFSET 0x0014 +#define AM43XX_RM_WKUP_RSTST_OFFSET0x0014 + +/* CM instances */ +#define AM43XX_CM_WKUP_INST0x2800 +#define AM43XX_CM_DEVICE_INST 0x4100 +#define AM43XX_CM_DPLL_INST0x4200 +#define AM43XX_CM_MPU_INST 0x8300 +#define AM43XX_CM_GFX_INST 0x8400 +#define AM43XX_CM_RTC_INST 0x8500 +#define AM43XX_CM_TAMPER_INST 0x8600 +#define AM43XX_CM_CEFUSE_INST 0x8700 +#define AM43XX_CM_PER_INST 0x8800 + +/* CD offsets */ +#define AM43XX_CM_WKUP_L3_AON_CDOFFS 0x +#define AM43XX_CM_WKUP_L3S_TSC_CDOFFS 0x0100 +#define AM43XX_CM_WKUP_L4_WKUP_AON_CDOFFS 0x0200 +#define AM43XX_CM_WKUP_WKUP_CDOFFS 0x0300 +#define AM43XX_CM_MPU_MPU_CDOFFS 0x +#define AM43XX_CM_GFX_GFX_L3_CDOFFS0x +#define AM43XX_CM_RTC_RTC_CDOFFS 0x +#define AM43XX_CM_TAMPER_TAMPER_CDOFFS 0x +#define AM43XX_CM_CEFUSE_CEFUSE_CDOFFS 0x +#define AM43XX_CM_PER_L3_CDOFFS0x +#define AM43XX_CM_PER_L3S_CDOFFS 0x0200 +#define AM43XX_CM_PER_ICSS_CDOFFS 0x0300 +#define AM43XX_CM_PER_L4LS_CDOFFS 0x0400 +#define AM43XX_CM_PER_EMIF_CDOFFS 0x0700 +#define AM43XX_CM_PER_DSS_CDOFFS 0x0a00 +#define AM43XX_CM_PER_CPSW_CDOFFS 0x0b00 +#define AM43XX_CM_PER_OCPWP_L3_CDOFFS 0x0c00 + +/* CLK CTRL offsets */ +#define AM43XX_CM_PER_UART1_CLKCTRL_OFFSET 0x0580 +#define AM43XX_CM_PER_UART2_CLKCTRL_OFFSET 0x0588 +#define AM43XX_CM_PER_UART3_CLKCTRL_OFFSET 0x0590 +#define AM43XX_CM_PER_UART4_CLKCTRL_OFFSET 0x0598 +#define AM43XX_CM_PER_UART5_CLKCTRL_OFFSET 0x05a0 +#define AM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET 0x0428 +#define AM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET 0x0430 +#define AM43XX_CM_PER_ELM_CLKCTRL_OFFSET 0x0468 +#define AM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET 0x0438 +#define AM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET 0x0440 +#define AM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET 0x0448 +#define AM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET 0x0478 +#define AM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET 0x0480 +#define AM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET 0x0488 +#define AM43XX_CM_PER_I2C1_CLKCTRL_OFFSET 0x04a8 +#define AM43XX_CM_PER_I2C2_CLKCTRL_OFFSET 0x04b0 +#define AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET 0x04b8 +#define AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET 0x04c0 +#define AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET 0x04c8 +#define AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET 0x0500 +#define AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET
[PATCH v5 08/11] ARM: OMAP2+: hwmod: AM43x support
Add hwmod support for IP's that are present in AM43x, but not in AM335x.
AM43x additional ones added here are,
1. synctimer
2. timer8-11
3. ehrpwm3-5
4. spi2-4
5. gpio4-5
AM43x pruss interconnect which is different as compared to AM335x, has
been taken care.
And register offsets for same hwmod's shared with AM335x is different,
AM43x register offsets are updated appropriately.
ocp clock of those in l4_wkup is fed from sys_clkin_ck instead of
dpll_core_m4_div2_ck, so ocpif for those in AM43x l4_wkup has been
added seperately.
hwmod's has been added for those that have main clock (wkup_m3, control,
gpio0) and clock domain (l4_hs) different from AM335x. debugss and
adc_tsc that have different clocks and clockdomains repectively has not
been added due to the reasons mentioned below.
AM43x also has IP's like qspi, hdq1w, vpfe, des, rng, usb, dss, debugss,
adc_tsc. These are not handled here due to both/either of following
reasons,
1. To avoid churn; most of them don't have DT bindings, which would
necessitate adding address space in hwmod, which any way would have
to be removed once DT bindings happen with driver support.
2. patches would come in from sources other than the author
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 1 +
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 1 +
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 74 +++
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 622 +
4 files changed, 698 insertions(+)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_43xx_data.c
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index d02acf9..0f97d63 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -752,6 +752,7 @@ extern int omap44xx_hwmod_init(void);
extern int omap54xx_hwmod_init(void);
extern int am33xx_hwmod_init(void);
extern int dra7xx_hwmod_init(void);
+int am43xx_hwmod_init(void);
extern int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois);
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index a9a7902..130332c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
@@ -158,5 +158,6 @@ extern struct omap_gpio_dev_attr gpio_dev_attr;
extern struct omap2_mcspi_dev_attr mcspi_attrib;
void omap_hwmod_am33xx_reg(void);
+void omap_hwmod_am43xx_reg(void);
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 598f813..d080bef 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -23,6 +23,7 @@
#include cm33xx.h
#include prm33xx.h
#include omap_hwmod_33xx_43xx_common_data.h
+#include prcm43xx.h
#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
#define RSTCTRL(oh, rstctrl) ((oh).prcm.omap4.rstctrl_offs = (rstctrl))
@@ -1380,3 +1381,76 @@ void omap_hwmod_am33xx_reg(void)
omap_hwmod_am33xx_clkctrl();
omap_hwmod_am33xx_rst();
}
+
+static void omap_hwmod_am43xx_clkctrl(void)
+{
+ CLKCTRL(am33xx_uart2_hwmod, AM43XX_CM_PER_UART1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart3_hwmod, AM43XX_CM_PER_UART2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart4_hwmod, AM43XX_CM_PER_UART3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart5_hwmod, AM43XX_CM_PER_UART4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart6_hwmod, AM43XX_CM_PER_UART5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan0_hwmod, AM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan1_hwmod, AM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_elm_hwmod, AM43XX_CM_PER_ELM_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss0_hwmod, AM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss1_hwmod, AM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss2_hwmod, AM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio1_hwmod, AM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio2_hwmod, AM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio3_hwmod, AM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c2_hwmod, AM43XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c3_hwmod, AM43XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mailbox_hwmod, AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp0_hwmod, AM43XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp1_hwmod, AM43XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc0_hwmod, AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc1_hwmod, AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi0_hwmod, AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi1_hwmod, AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+
[PATCH v5 07/11] ARM: OMAP2+: CM: AM43x clockdomain data
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
OMAP4 clockdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clockdomain.h | 2 +
arch/arm/mach-omap2/clockdomains43xx_data.c | 196
arch/arm/mach-omap2/cminst44xx.c| 9 ++
3 files changed, 207 insertions(+)
create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 5431b0c..f17f006 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -218,6 +218,7 @@ extern void __init am33xx_clockdomains_init(void);
extern void __init omap44xx_clockdomains_init(void);
extern void __init omap54xx_clockdomains_init(void);
extern void __init dra7xx_clockdomains_init(void);
+void am43xx_clockdomains_init(void);
extern void clkdm_add_autodeps(struct clockdomain *clkdm);
extern void clkdm_del_autodeps(struct clockdomain *clkdm);
@@ -226,6 +227,7 @@ extern struct clkdm_ops omap2_clkdm_operations;
extern struct clkdm_ops omap3_clkdm_operations;
extern struct clkdm_ops omap4_clkdm_operations;
extern struct clkdm_ops am33xx_clkdm_operations;
+extern struct clkdm_ops am43xx_clkdm_operations;
extern struct clkdm_dep gfx_24xx_wkdeps[];
extern struct clkdm_dep dsp_24xx_wkdeps[];
diff --git a/arch/arm/mach-omap2/clockdomains43xx_data.c
b/arch/arm/mach-omap2/clockdomains43xx_data.c
new file mode 100644
index 000..6d71c60
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains43xx_data.c
@@ -0,0 +1,196 @@
+/*
+ * AM43xx Clock domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+
+#include clockdomain.h
+#include prcm44xx.h
+#include prcm43xx.h
+
+static struct clockdomain l4_cefuse_43xx_clkdm = {
+ .name = l4_cefuse_clkdm,
+ .pwrdm= { .name = cefuse_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_CEFUSE_INST,
+ .clkdm_offs = AM43XX_CM_CEFUSE_CEFUSE_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain mpu_43xx_clkdm = {
+ .name = mpu_clkdm,
+ .pwrdm= { .name = mpu_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_MPU_INST,
+ .clkdm_offs = AM43XX_CM_MPU_MPU_CDOFFS,
+ .flags= CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4ls_43xx_clkdm = {
+ .name = l4ls_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_L4LS_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain tamper_43xx_clkdm = {
+ .name = tamper_clkdm,
+ .pwrdm= { .name = tamper_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_TAMPER_INST,
+ .clkdm_offs = AM43XX_CM_TAMPER_TAMPER_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain l4_rtc_43xx_clkdm = {
+ .name = l4_rtc_clkdm,
+ .pwrdm= { .name = rtc_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_RTC_INST,
+ .clkdm_offs = AM43XX_CM_RTC_RTC_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain pruss_ocp_43xx_clkdm = {
+ .name = pruss_ocp_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_ICSS_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain ocpwp_l3_43xx_clkdm = {
+ .name = ocpwp_l3_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_OCPWP_L3_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain l3s_tsc_43xx_clkdm = {
+ .name = l3s_tsc_clkdm,
+ .pwrdm= { .name = wkup_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_WKUP_INST,
+ .clkdm_offs = AM43XX_CM_WKUP_L3S_TSC_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain dss_43xx_clkdm = {
+ .name = dss_clkdm,
+ .pwrdm
[PATCH v5 06/11] ARM: OMAP2+: PM: AM43x powerdomain data
From: Ambresh K ambr...@ti.com
Add the data file to describe all power domains in AM43x SoC.
OMAP4 powerdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/powerdomain.h | 1 +
arch/arm/mach-omap2/powerdomains43xx_data.c | 136
2 files changed, 137 insertions(+)
create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index baf3d8b..da5a59a 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -257,6 +257,7 @@ extern void am33xx_powerdomains_init(void);
extern void omap44xx_powerdomains_init(void);
extern void omap54xx_powerdomains_init(void);
extern void dra7xx_powerdomains_init(void);
+void am43xx_powerdomains_init(void);
extern struct pwrdm_ops omap2_pwrdm_operations;
extern struct pwrdm_ops omap3_pwrdm_operations;
diff --git a/arch/arm/mach-omap2/powerdomains43xx_data.c
b/arch/arm/mach-omap2/powerdomains43xx_data.c
new file mode 100644
index 000..95fee54
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains43xx_data.c
@@ -0,0 +1,136 @@
+/*
+ * AM43xx Power domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include powerdomain.h
+
+#include prcm-common.h
+#include prcm44xx.h
+#include prcm43xx.h
+
+static struct powerdomain gfx_43xx_pwrdm = {
+ .name = gfx_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_GFX_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_ON,
+ .banks= 1,
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* gfx_mem */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain mpu_43xx_pwrdm = {
+ .name = mpu_pwrdm,
+ .voltdm = { .name = mpu },
+ .prcm_offs= AM43XX_PRM_MPU_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .banks= 3,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* mpu_l1 */
+ [1] = PWRSTS_OFF_RET, /* mpu_l2 */
+ [2] = PWRSTS_OFF_RET, /* mpu_ram */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* mpu_l1 */
+ [1] = PWRSTS_ON,/* mpu_l2 */
+ [2] = PWRSTS_ON,/* mpu_ram */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain rtc_43xx_pwrdm = {
+ .name = rtc_pwrdm,
+ .voltdm = { .name = rtc },
+ .prcm_offs= AM43XX_PRM_RTC_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+static struct powerdomain wkup_43xx_pwrdm = {
+ .name = wkup_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_WKUP_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+ .banks= 1,
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* debugss_mem */
+ },
+};
+
+static struct powerdomain tamper_43xx_pwrdm = {
+ .name = tamper_pwrdm,
+ .voltdm = { .name = tamper },
+ .prcm_offs= AM43XX_PRM_TAMPER_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+static struct powerdomain cefuse_43xx_pwrdm = {
+ .name = cefuse_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_CEFUSE_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_ON,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain per_43xx_pwrdm = {
+ .name = per_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_PER_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .banks= 4,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* icss_mem */
+ [1] = PWRSTS_OFF_RET, /* per_mem */
+ [2] = PWRSTS_OFF_RET, /* ram1_mem */
+ [3] = PWRSTS_OFF_RET, /* ram2_mem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* icss_mem */
+ [1] = PWRSTS_ON,/*
[PATCH v5 09/11] ARM: OMAP2+: hwmod: AM43x operations
Reuse OMAP4 operations on AM43x.
Context related ops are not used on AM43x, as this would not add value
when using DT and AM43x is DT only boot. This additionally helps not to
add context register offset for each hwmod.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d9ee0ff..aa593da 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4125,6 +4125,14 @@ void __init omap_hwmod_init(void)
soc_ops.init_clkdm = _init_clkdm;
soc_ops.update_context_lost = _omap4_update_context_lost;
soc_ops.get_context_lost = _omap4_get_context_lost;
+ } else if (soc_is_am43xx()) {
+ soc_ops.enable_module = _omap4_enable_module;
+ soc_ops.disable_module = _omap4_disable_module;
+ soc_ops.wait_target_ready = _omap4_wait_target_ready;
+ soc_ops.assert_hardreset = _omap4_assert_hardreset;
+ soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
+ soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
+ soc_ops.init_clkdm = _init_clkdm;
} else if (soc_is_am33xx()) {
soc_ops.enable_module = _am33xx_enable_module;
soc_ops.disable_module = _am33xx_disable_module;
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 10/11] ARM: OMAP2+: AM43x: PRCM kbuild
Build AM43x power domain, clock domain and hwmod data. Many of AM43x IP's and interconnects are similar as that in AM335x, hence AM335x hwmod data is being reused with necessary changes. Earlier the plan was to reuse AM335x specific PRCM code, but as AM43x PRCM register layout is much similar to OMAP4/5, AM335x PRCM is divorced and instead married with OMAP4/5 PRCM for AM43x. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/Makefile | 7 ++- arch/arm/mach-omap2/cm33xx.h | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 0746494..cb7b527 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -112,13 +112,13 @@ obj-$(CONFIG_ARCH_OMAP2) += prm2xxx_3xxx.o prm2xxx.o cm2xxx.o obj-$(CONFIG_ARCH_OMAP3) += prm2xxx_3xxx.o prm3xxx.o cm3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o obj-$(CONFIG_SOC_AM33XX) += prm33xx.o cm33xx.o -obj-$(CONFIG_SOC_AM43XX) += prm33xx.o cm33xx.o omap-prcm-4-5-common = cminst44xx.o cm44xx.o prm44xx.o \ prcm_mpu44xx.o prminst44xx.o \ vc44xx_data.o vp44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common) +obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -146,6 +146,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= powerdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) obj-$(CONFIG_SOC_AM33XX) += powerdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(powerdomain-common) +obj-$(CONFIG_SOC_AM43XX) += powerdomains43xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= powerdomains54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += $(powerdomain-common) @@ -165,6 +166,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= clockdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common) +obj-$(CONFIG_SOC_AM43XX) += clockdomains43xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += $(clockdomain-common) @@ -212,6 +214,9 @@ obj-$(CONFIG_ARCH_OMAP3)+= omap_hwmod_3xxx_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_43xx_interconnect_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_43xx_ipblock_data.o +obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o +obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_interconnect_data.o +obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 757320b..cfb8891 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -383,7 +383,7 @@ void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs); void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs); void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs); -#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX) +#ifdef CONFIG_SOC_AM33XX extern int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs, u16 clkctrl_offs); extern void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs, -- 1.8.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 11/11] ARM: OMAP2+: AM43x PRCM init
From: Ambresh K ambr...@ti.com Initialise AM43x HWMOD, powerdomains and clockdomains. Signed-off-by: Ambresh K ambr...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/io.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index ff2113c..c90f647 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -594,7 +594,13 @@ void __init am43xx_init_early(void) NULL); omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE)); omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL); + omap_prm_base_init(); + omap_cm_base_init(); omap3xxx_check_revision(); + am43xx_powerdomains_init(); + am43xx_clockdomains_init(); + am43xx_hwmod_init(); + omap_hwmod_init_postsetup(); } #endif -- 1.8.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
On 09/27/2013 08:08 PM, Kevin Hilman wrote: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I'm fine with this appproach. For both patches: Reviewed-by: Kevin Hilman khil...@linaro.org Also, I gave it a spin across a handful of OMAP boards using v3.12-rc2 + these 2 patches. Boot tested successfully with DT boot: omap3530/beagle omap3730/beagle-xm omap3530/overo (Tobi w/GPIO IRQ networking) omap3730/overo STORM (w/GPIO IRQ for networking) am335x/beaglebone am335x/beaglebone black omap4430/panda omap4460/panda-es omap5912/OSK (omap1) I also verified non-DT boot on the OMAP3 platforms that still support legacy boot. So feel free to also add Tested-by: Kevin Hilman khil...@linaro.org Thanks for your persistence in getting a fix for this upstream. Kevin Thanks a lot Kevin for testing on so many boards. Linus, Since this patch-set doesn't cause any regression and fix a long standing issue on OMAP, do you think that it would be possible to include on the -rc series as a bugfix or do you prefer to wait until 3.13? Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
Then for the SDIO with device tree, take a look at the following
patches:
[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#
I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.
+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
If I look at the similar names in the deceased board-omap4panda.c:
board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
and in mux44xx.h:
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a
So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.
If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.
So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.
That was what I was looking for. Thanks!
Hi Roger,
It has been a while, but I would like to pickup this thread. We have a
couple of pandaboards used as test setup. These have an SDIO adapter
hooked up to expansion connector A using MMC2. I have attached the patch
file (just ignore platform_data stuff). Now on one board it works, but
not for the other. I suspect a board issue so listing the two types that
we use:
PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope
Any hints for me.
Regards,
Arend
NOTE: omap4_pmx_wkup starts at a different address. Those are for
wakeup domain
control registers.
Will keep that in mind.
Regards,
Arend
From 4a20162935b27e23ec7ddc818c9fe6b451c1a968 Mon Sep 17 00:00:00 2001
From: Arend van Spriel ar...@broadcom.com
Date: Thu, 22 Aug 2013 12:29:23 +0200
Subject: [PATCH] brcmfmac: add device tree support for panda board
In linux mainline the pandaboard specific code moved to using
the device tree. Changing our internal patches to get platform
specific info from the device tree.
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 20 +++-
arch/arm/mach-omap2/devices.c | 36 -
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..6ebeb8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -226,6 +226,22 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
;
};
+ mmc2_brcmf_en: pinmux_mmc2_brcmf_en {
+ pinctrl-single,pins =
+ 0x92 (PIN_OUTPUT | MUX_MODE3) /* brcmf-power
*/
+ ;
+ };
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x44 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-cmd */
+ 0x42 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-clk */
+ 0x00 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-dat 0-3
*/
+ 0x02 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x04 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x06 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x9a (MUX_MODE3 | PIN_INPUT_PULLDOWN) /* oob-irq */
+ ;
+ };
};
omap4_pmx_wkup {
@@ -302,7 +318,9 @@
};
mmc2 {
- status = disabled;
+ vmmc-supply = vaux1;
+ bus-width = 4;
+ non-removable;
};
mmc3 {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..7a47535 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -21,7 +21,7 @@
#include linux/platform_data/omap4-keypad.h
#include linux/wl12xx.h
#include linux/platform_data/mailbox-omap.h
-
+#include linux/platform_data/brcmfmac-sdio.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -547,6 +547,39 @@ static inline void omap_init_wl12xx_of(void)
}
#endif
+#define GPIO_BRCMF_SDIO_PWR134
+#define GPIO_BRCMF_SDIO_OOB138
+static struct brcmfmac_sdio_platform_data brcmfmac_sdio_pdata;
+
+static struct platform_device brcmf_sdio_device = {
+ .name = BRCMFMAC_SDIO_PDATA_NAME,
+ .id = PLATFORM_DEVID_NONE,
+ .dev.platform_data = brcmfmac_sdio_pdata
+};
+
+static struct
Re: [RFC 00/15] Device Tree schemas and validation
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit of comments about at least the bindings syntax:-(
I'd like to know if this is the right direction and if it worth pursuing
in that direction.
The idea was to have at least some base for further discussion during
ARM KS 2013.
I feel alone :-(
If you have any comment, go ahead!
Thanks,
Benoit
On 24/09/2013 18:52, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
[1] http://www.spinics.net/lists/arm-kernel/msg262224.html
=== What it does? ===
For now device-tree bindings are defined in a not standardized
text-based format and thus any one can write the documentation for a
binding as he wish. In addition to this there is no automated way to
check if a dts is conform to the available bindings.
The goal of this series of patch is to fix this situation by adding a
well defined way to write bindings in a human-readable format. These
bindings will be written through files called schemas.
=== What is a schema? ===
A schema is a file describing the constraints that one or several nodes
of a dts must conform to. Schemas must use the file extension .schema.
A schema can check that:
- A node has a given property
- An array has a valid size
- A node contains the required children.
- A property has the correct type.
- A property has the correct value.
A schema can as well recursively check the constraints for parent nodes.
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
=== How to defined a schema? ===
A binding directory has been added at the root of repository. Users can
add schema files anywhere in it but a nice way would be to keep the same
structure as the binding directory in the documentation.
To demonstrate how to write a schema and its capability I will use the
OMAP DTS schemas when applicable.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the compatible properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
interrupts = 0x0 0x25 0x4;
ti,hwmods = timer1;
ti,timer-alwon;
};
To write a schema which will validate OMAP Timers like the one above,
one may write the following schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
...
};
The schema above will be used to validate every node in a dts which has
a compatible matching the following regular expression:
ti,omap[0-9]+-timer.
It is possible to specify multiple compatible inside a schema using this
syntax:
compatible = ti,omap[0-9]+-timer, ti,am[0-9]+-timer;
This time the schema will be application for both OMAP Timers and AM
Timers.
* Define constraints on properties
To define constraints on a property one has to create a node in a schema
which has as name the name of the property that one want to validate.
To specify constraints on the property ti,hwmods of OMAP Timers one
can write this schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
...
};
};
If one want to use a regular as property name one can write this schema:
/dts-v1/;
/ {
compatible = abc;
def {
name = def[0-9];
...
};
};
Above one can see that the name property override the node name.
* Require the presence of a property
One can require the presence of a property by using the is-required
constraint.
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
is-required;
};
};
The ti,hwmods property above is set as required and its presence will
be checked in every OMAP timer.
* Require the presence of a property inside a node or inside one of its
parents
Sometimes a property required is not directly present inside a node but
is present in one of its parents. To check this, one can use
can-be-inherited in addition to is-required.
twl {
interrupt-controller;
rtc {
compatible = ti,twl4030-rtc;
interrupts = 0xc;
};
}
In the case of the rtc above the interrupt-controller is not present,
Re: [PATCHv2 1/9] hwspinlock/core: add common dt bindings and OF helpers
Hi Suman,
Apologies for replying to a subthread, due to an earlier mistake on my
part I don't have the original to hand.
On Fri, Sep 27, 2013 at 05:04:22PM +0100, Kumar Gala wrote:
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
All the platform-specific hwlock driver implementations need the
number of locks and the associated base id for registering the
locks present within a hwspinlock device with the driver core.
These two variables are represented by 'hwlock-num-locks' and
'hwlock-base-id' properties. The documentation and OF helpers to
retrieve these common properties have been added to the driver core.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 26 +
drivers/hwspinlock/hwspinlock_core.c | 61
+-
include/linux/hwspinlock.h | 11 ++--
3 files changed, 93 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 000..789930e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,26 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one driver
+implementation to another. Look through the individual hwlock driver
+binding documentations for identifying which are mandatory and which are
+optional for that specific driver.
+
+Common properties:
+- hwlock-base-id: Base Id for the locks for a particular hwlock device.
+ This property is used for representing a set of locks
+ present in a hwlock device with a unique base id in
+ the driver core. This property is mandatory ONLY if a
+ SoC has several hwlock devices.
+
+ See documentation on struct hwspinlock_pdata in
+ linux/hwspinlock.h for more details.
I don't like this, as it seems to be encoding a Linux implementation
detail (the ID of the lock, which means that we have to have a numeric
representation of each hwlock) in the device tree.
I don't see why the ID within Linux should be a concern of the device
tree binding. I think that whatever internal identifier we have in Linux
(be it an integer or struct) should be allocated by Linux. If a driver
needs to request specific hwlocks, then we should have a phandle + args
representation for referring to a specific hwlock that bidnings can use,
and some code for parsing that and returning a Linux-internal
identifier/struct as we do with interrupts and clocks.
+
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the number
+ of supported locks within a hwlock device cannot be
+ read from a register.
Hmm... this seems generic, but it doesn't allow for sparse ID spaces on
the hwlock module. It should probably be common for the moment, but if
we encounter a hwlock module with a sparse ID space, we'll need to come
up with a way of handling sparse IDs (that might be device-specific).
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..aec32e7 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -1,7 +1,7 @@
/*
* Hardware spinlock framework
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2013 Texas Instruments Incorporated -
http://www.ti.com
*
* Contact: Ohad Ben-Cohen o...@wizery.com
*
@@ -27,6 +27,7 @@
#include linux/hwspinlock.h
#include linux/pm_runtime.h
#include linux/mutex.h
+#include linux/of.h
#include hwspinlock_internal.h
@@ -308,6 +309,64 @@ out:
}
/**
+ * of_hwspin_lock_get_base_id() - OF helper to retrieve base id
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the base id for the
+ * set of locks present within a hwspinlock device instance.
+ *
+ * Returns the base id value on success, -ENODEV on generic failure or
+ * an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_base_id(struct device_node *dn)
+{
+ unsigned int val;
+ int ret = -ENODEV;
+
+#ifdef CONFIG_OF
+ if (!dn)
+ return -ENODEV;
Checking !dn is done in of_property_read_u32, so you don't need to duplicate
Re: [PATCHv2 2/9] hwspinlock/omap: add support for dt nodes
Hi Suman, On Fri, Sep 27, 2013 at 05:06:38PM +0100, Kumar Gala wrote: On Sep 17, 2013, at 2:30 PM, Suman Anna wrote: HwSpinlock IP is present only on OMAP4 and other newer SoCs, which are all device-tree boot only. This patch adds the base support for parsing the DT nodes, and removes the code dealing with the traditional platform device instantiation. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 31 +++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/omap_hwspinlock.c | 23 +++-- 4 files changed, 50 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt new file mode 100644 index 000..235b7c5 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt @@ -0,0 +1,31 @@ +OMAP4+ HwSpinlock Driver + + +Required properties: +- compatible: Currently supports only ti,omap4-hwspinlock for + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs Currently supports is not something I expect to see in a binding document. That sounds like a description of the driver rather than the binding. How similar are these hardware modules? What are the differences? +- reg: Contains the hwspinlock register address range (base + address and length) Is there only one register bank for the hwlock module? +- ti,hwmods: Name of the hwmod associated with the hwspinlock device + +Common hwlock properties: +The following describes the usage of the common hwlock properties (defined in +Documentation/devicetree/bindings/hwlock/hwlock.txt) on OMAP. + +- hwlock-base-id: There are currently no OMAP SoCs with multiple + hwspinlock devices. The OMAP driver uses a default + base id value of 0 for the locks present within the + single hwspinlock device on all SoCs. Driver details should not leak into bindngs... As mentioned in the other patch, I don't think this is the way to handle this. I think we need a phandle + args representation. +- hwlock-num-locks:This property is not required on OMAP SoCs, since the + number of locks present within a device can be deduced + from the SPINLOCK_SYSSTATUS device register. Huh? Why define this property at all here if we don't need it and don't use it? The common document should state that specific bindings may use it and should explicitly state if they do, rather than stating they don't... Cheers, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? Most likely your Pandaboard (A2) doesn't have the WLAN chip (U3) on board so there is no problem there. 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: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. Most likely your Pandaboard (A2) doesn't have the WLAN chip (U3) on board so there is no problem there. 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: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Regards, Arend [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-wl-27553-g4a20162 (arend@arend-ubuntu-1) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #5 SMP Mon Sep 23 10:42:07 CEST 2013 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [0.00] cma: CMA: reserved 16 MiB at ae80 [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] On node 0 totalpages: 261888 [0.00] free_area_init_node: node 0, pgdat c08835c0, node_mem_map c0ded000 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 67328 pages, LIFO batch:15 [0.00] OMAP4430 ES2.1 [0.00] PERCPU: Embedded 9 pages/cpu @c1607000 s14208 r8192 d14464 u36864 [0.00] pcpu-alloc: s14208 r8192 d14464 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1007680K/1047552K available (5750K kernel code, 614K rwdata, 1952K rodata, 381K init, 5522K bss, 39872K reserved, 269312K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc078d9c8 (7703
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
Hi, On Monday 30 September 2013 08:39 PM, Rob Herring wrote: On 09/30/2013 08:59 AM, Sricharan R wrote: 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's interrupt is mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. Seems like interrupt-map property is what you need here. http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Versatile Express also has an example. OK, but the idea was not to tie up the crossbar-interrupt numbers at the DTS level, but to assign it dynamically during runtime. This was one of the comments that came up with first crossbar support patches, which was assigning a interrupt line to crossbar number in the DTS and setting it up in crossbar probe. https://lkml.org/lkml/2013/7/18/416 Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and that did not go as well. Finally was asked to handle this as a part of GIC driver with a separate domain. http://www.spinics.net/lists/linux-omap/msg97085.html Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
On Tue, Oct 1, 2013 at 9:34 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Linus, Since this patch-set doesn't cause any regression and fix a long standing issue on OMAP, do you think that it would be possible to include on the -rc series as a bugfix or do you prefer to wait until 3.13? I've added it to my fixes branch for v3.12. Since linux-next is not available we need some extensive build testing first to make sure that if something explodes it explodes on OMAP only. So will let this boil a few days and then send a pull request. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. FWIW, my patches were working with PandaBoardES rev B1, which was also OMAP4460 ES1.1. It worked fine for me, *except* that sometimes for some unknown reason the SDIO MMC connected to WiLink didn't get probed (as it appears to be the case on your dmesg-4460.txt). Most weirdly, it seems that booting the board with a non-DT kernel and then booting back to the DT kernel seemed to help and the problem was gone for many reboots, until it happened again. I never figure out why this was happening, though. :( -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] usb: dwc3: msm: Add device tree binding information
Hi, I am sorry for delay answer. On Thu, 2013-09-26 at 10:46 +0100, Mark Rutland wrote: On Mon, Sep 23, 2013 at 08:31:48PM +0100, Felipe Balbi wrote: Hi, On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com Any acks for the DT part ? This patch has been pending forever. Apologies for the delay. I have a couple of comments that would be nice to fix up now. --- .../devicetree/bindings/usb/msm-ssusb.txt | 104 1 file changed, 104 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt new file mode 100644 index 000..cacbd3b --- /dev/null +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt @@ -0,0 +1,104 @@ +MSM SuperSpeed DWC3 USB SoC controller + + +DWC3 Highspeed USB PHY +== +Required properities : +- compatible : sould be qcom,dwc3-hsphy; s/sould/should/ In general, compatible properties are should contain rather than should be, as we might have backwards compatible hardware in future. Ok. +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes Clocks are referred to be phandle + clock-specifier pairs rather than phandles, it would be nice to fix the terminology here Ok. +- clock-names : + xo : External reference clock 19 MHz + sleep_a : Sleep clock, used when USB3 core goes into low + power mode (U3). I think it would be nicer to say: - clocks : A list of phandle + clock-specifier pairs for the clocks listed in clock-names - clock-names: Should contain the following: xo - External reference clock (19MHz) sleep_a - Sleep clock used when USB3 core goes into low power mode (U3). I'm not sure we need to describe the frequency of the xo clock -- either it's a requriement of the IP and thus doesn't need to be a part of the binding, or it's configurable by the driver and thus doesn't need to be documented. Ok. will remove explicit numbers here. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for HSPHY + v3p3 : 3.3v supply for HSPHY + vbus : vbus supply for host mode + vddcx : vdd supply for HS-PHY digital circuit operation Any reason for the HSPHY/HS-PHY difference? No, just lack of attention from my side. I'd list these separately with their full names: - v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY. - v3p3-supply: phandle to the regulator for the 3.3v supply to HSPHY. - vbus-supply: phandle to the regulator for the vbus supply for host mode. - vddcx-supply: phandle to the regulator for the vdd supply for HSPHY digital circuit operation. ok. + +DWC3 Superspeed USB PHY +=== +Required properities : +- compatible : sould be qcom,dwc3-ssphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + ref : Reference clock - used in host mode. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for SS-PHY + vddcx : vdd supply for SS-PHY digital circuit operation The commments on compatible, clocks, clock-names and the regulators apply here. ok + +DWC3 controller wrapper +=== +Required properties : +- compatible : should be qcom,dwc3 +- reg : offset and length of the register set in the memory map + offset and length of the TCSR register for routing USB + signals to either picoPHY0 or picoPHY1. +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + core : Master/Core clock, have to be = 125 MHz for SS + operation and = 60MHz for HS operation + iface : System bus AXI clock + sleep : Sleep clock, used when USB3 core goes into low + power mode (U3). + utmi : Generated by HS-PHY. Used to clock the low power + parts of thr HS Link layer. +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. The commments on compatible, clocks, and clock-names apply here too. I see the regulator is defined individually :) I'm fine with the
Re: [PATCH v4 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Mon, 2013-09-23 at 14:31 -0500, Felipe Balbi wrote: Hi, On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com Any acks for the DT part ? This patch has been pending forever. Thanks you for you patience Felipe. There are also several small fixups in the driver code that I will like to address. Will send updated version with all pending comments shortly. Regards, Ivan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Mon, 2013-09-23 at 16:03 -0600, Stephen Warren wrote: On 09/23/2013 01:32 PM, Felipe Balbi wrote: Hi, On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com and here's a new version from same patch The binding looks pretty simple, so I don't think it's too contentious. diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt +MSM DWC3 controller wrapper +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. If that's a regulator node, why not use xxx-supply properties to interface with it? That was the intention. What about: Optional supply-name : gdsc - supply from globally distributed switch controller Aside from that, the binding, Acked-by: Stephen Warren swar...@nvidia.com Thank you. Regards, Ivan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Mon, 2013-09-23 at 14:32 -0500, Felipe Balbi wrote: Hi, On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com and here's a new version from same patch The only difference is that references to dwc3 are replaced with just dw in USB PHY drivers and file names. This is to indicate that the PHY's are DesignWare, but not necessarily related to DWC3 IP core. If you prefer I could keep old abbreviation. Thanks, Ivan -- 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: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 01:53 PM, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? 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 v3 4/5] dma: cppi41: only allocate descriptor memory once
Hi Sebastian,
sorry for the long delay, I got distracted by other things.
On 26.09.2013 10:26, Sebastian Andrzej Siewior wrote:
* Daniel Mack | 2013-09-22 16:50:03 [+0200]:
cdd-cd and cdd-descs_phys are allocated DESCS_AREAS times from
init_descs() and freed as often from purge_descs(). This leads to both
memory leaks and double-frees.
Fix this by pulling the calls to dma_{alloc,free}_coherent() out of the
loops.
While at it, remove the intermediate variable mem_decs (I guess it was
only there to make the code comply to the 80-chars CodingSytle rule).
Signed-off-by: Daniel Mack zon...@gmail.com
Please don't merge the memory descriptors. The idea was initially to
allocate multiple small descriptors instead one big. The descrriptor
turned out to be enough so it looks like the way it looks.
If you want to clean this up, please either remove the for loop and
allocate only one memory area or please prepare for multiple descripors
(I think two is the upper limit).
Well, I didn't merge the descriptors. Look again at my changes please.
A simplified version of the code as it stands is:
for (i = 0; i DESCS_AREAS; i++)
cdd-cd = dma_alloc_coherent(dev, ..., cdd-descs_phys, GFP_KERNEL);
for (i = 0; i DESCS_AREAS; i++)
dma_free_coherent(dev, mem_decs, cdd-cd, cdd-descs_phys);
So you're effectively allocating and freeing the same pointer
DESCS_AREAS times, which is certainly not what you wanted.
And this just doesn't hit you because DESCS_AREAS is always 1:
BUILD_BUG_ON(DESCS_AREAS != 1);
So, after all, my patch doesn't really change any of the runtime
behaviour. Consider it a cosmetic cleanup if you wish :)
Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/15] Device Tree schemas and validation
On 10/01/2013 03:06 AM, Benoit Cousson wrote:
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit of comments about at least the bindings syntax:-(
I'd like to know if this is the right direction and if it worth pursuing
in that direction.
The idea was to have at least some base for further discussion during
ARM KS 2013.
I feel alone :-(
If you have any comment, go ahead!
Thanks for taking this on!
This is interesting approach using the dts syntax, but I worry that the
validation will only be as good as the schema written and the review of
the schema. I think the schema needs to define the binding rather than
define the checks. Then the schema can feed the validation checks. This
format does not seem to me as easily being able to generate
documentation from the schema which I believe is one of the goals. I for
one don't care to review the documentation and the schema for every binding.
I would like to ensure we can start with the basics and have some
generic rules. Some examples:
- flag compatible strings in dts files that are not documented
- check required properties
- check properties against cell sizes
- a node with reg property must have a unit address
- flag properties with _
- check properties are the correct data type
Rob
Thanks,
Benoit
On 24/09/2013 18:52, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
[1] http://www.spinics.net/lists/arm-kernel/msg262224.html
=== What it does? ===
For now device-tree bindings are defined in a not standardized
text-based format and thus any one can write the documentation for a
binding as he wish. In addition to this there is no automated way to
check if a dts is conform to the available bindings.
The goal of this series of patch is to fix this situation by adding a
well defined way to write bindings in a human-readable format. These
bindings will be written through files called schemas.
=== What is a schema? ===
A schema is a file describing the constraints that one or several nodes
of a dts must conform to. Schemas must use the file extension .schema.
A schema can check that:
- A node has a given property
- An array has a valid size
- A node contains the required children.
- A property has the correct type.
- A property has the correct value.
A schema can as well recursively check the constraints for parent nodes.
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
=== How to defined a schema? ===
A binding directory has been added at the root of repository. Users can
add schema files anywhere in it but a nice way would be to keep the same
structure as the binding directory in the documentation.
To demonstrate how to write a schema and its capability I will use the
OMAP DTS schemas when applicable.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the compatible properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
interrupts = 0x0 0x25 0x4;
ti,hwmods = timer1;
ti,timer-alwon;
};
To write a schema which will validate OMAP Timers like the one above,
one may write the following schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
...
};
The schema above will be used to validate every node in a dts which has
a compatible matching the following regular expression:
ti,omap[0-9]+-timer.
It is possible to specify multiple compatible inside a schema using this
syntax:
compatible = ti,omap[0-9]+-timer, ti,am[0-9]+-timer;
This time the schema will be application for both OMAP Timers and AM
Timers.
* Define constraints on properties
To define constraints on a property one has to create a node in a schema
which has as name the name of the property that one want to validate.
To specify constraints on the property ti,hwmods of OMAP Timers one
can write this schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
...
};
};
If one want to use a regular as property name one can write this schema:
/dts-v1/;
/ {
compatible = abc;
def {
name = def[0-9];
...
};
};
Above one can see that the name property override the node name.
* Require the presence of a property
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? if you are using vaux1, can you check the voltage levels, From dmesg you attached, vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460 4430 [2.425750] VAUX1_6030: 1000 -- 3000 mV at 1800 mV 4460 [2.244262] VAUX1_6030: 1000 -- 3000 mV at 2800 mV Can you also check with MMC_DEBUG enabled for any clues. 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 -- 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] dma: cppi41: restore more registers
With active users over suspend/resume cycles, it turns out that
more registers, in particular DMA_TDFDQ and RXHPCRA0, have to be
restored on resume.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/dma/cppi41.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 89decc9..9a298b1 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -141,6 +141,9 @@ struct cppi41_dd {
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
struct chan_queues td_queue;
+
+ /* context for suspend/resume */
+ unsigned int dma_tdfdq;
};
#define FIST_COMPLETION_QUEUE 93
@@ -1045,6 +1048,7 @@ static int cppi41_suspend(struct device *dev)
{
struct cppi41_dd *cdd = dev_get_drvdata(dev);
+ cdd-dma_tdfdq = cppi_readl(cdd-ctrl_mem + DMA_TDFDQ);
cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
disable_sched(cdd);
@@ -1054,12 +1058,23 @@ static int cppi41_suspend(struct device *dev)
static int cppi41_resume(struct device *dev)
{
struct cppi41_dd *cdd = dev_get_drvdata(dev);
+ struct cppi41_channel *c;
int i;
for (i = 0; i DESCS_AREAS; i++)
cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
+ list_for_each_entry(c, cdd-ddev.channels, chan.device_node)
+ if (!c-is_tx)
+ cppi_writel(c-q_num, c-gcr_reg + RXHPCRA0);
+
init_sched(cdd);
+
+ cppi_writel(cdd-dma_tdfdq, cdd-ctrl_mem + DMA_TDFDQ);
+ cppi_writel(cdd-scratch_phys, cdd-qmgr_mem + QMGR_LRAM0_BASE);
+ cppi_writel(QMGR_SCRATCH_SIZE, cdd-qmgr_mem + QMGR_LRAM_SIZE);
+ cppi_writel(0, cdd-qmgr_mem + QMGR_LRAM1_BASE);
+
cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
return 0;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] dma: cppi41: use cppi41_pop_desc() where possible
Use cppi41_pop_desc() when appropriate instead of open-coding the same
functionality again. That makes the code more readable. The function has
to be moved some lines up for this change.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/dma/cppi41.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 9a298b1..7747bf7 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -266,6 +266,15 @@ static u32 pd_trans_len(u32 val)
return val ((1 (DESC_LENGTH_BITS_NUM + 1)) - 1);
}
+static u32 cppi41_pop_desc(struct cppi41_dd *cdd, unsigned queue_num)
+{
+ u32 desc;
+
+ desc = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(queue_num));
+ desc = ~0x1f;
+ return desc;
+}
+
static irqreturn_t cppi41_irq(int irq, void *data)
{
struct cppi41_dd *cdd = data;
@@ -303,8 +312,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
q_num = __fls(val);
val = ~(1 q_num);
q_num += 32 * i;
- desc = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(q_num));
- desc = ~0x1f;
+ desc = cppi41_pop_desc(cdd, q_num);
c = desc_to_chan(cdd, desc);
if (WARN_ON(!c)) {
pr_err(%s() q %d desc %08x\n, __func__,
@@ -520,15 +528,6 @@ static void cppi41_compute_td_desc(struct cppi41_desc *d)
d-pd0 = DESC_TYPE_TEARD DESC_TYPE;
}
-static u32 cppi41_pop_desc(struct cppi41_dd *cdd, unsigned queue_num)
-{
- u32 desc;
-
- desc = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(queue_num));
- desc = ~0x1f;
- return desc;
-}
-
static int cppi41_tear_down_chan(struct cppi41_channel *c)
{
struct cppi41_dd *cdd = c-cdd;
@@ -612,7 +611,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
WARN_ON(!c-td_retry);
if (!c-td_desc_seen) {
- desc_phys = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(c-q_num));
+ desc_phys = cppi41_pop_desc(cdd, c-q_num);
WARN_ON(!desc_phys);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] dma: cppi41: more suspend/resume patches
While my first series makes the cppi41 driver survive suspend/resume cycles as long as users are fully removed and added back after resume, here are some more patches which make it all work completely. Patch #1 restores more registers on resume time. Patch #2 is a cosmetic cleanup that emerged while digging through the driver and gaining a basic idea of how it's implemented. Nothing fancy. Patch #3, however, gives me headaches. I can't fully explain what's going on, but I can tell for sure that if fixes a problem that I stared on for many hours. The problem is that on resume, the musb core will detect that some of the suspended USB devices' endpoints are stalled. Which is something that is unrelated to the dma driver, it just seems to be an expected condition. That, however, makes the musb core call cppi41_dma_channel_abort() - cppi41_tear_down_chan(), which is an otherwise untravelled code path. When that function is called for a channel which has all of td_queued, td_seen and td_desc_seen set to FALSE, I'm always getting a warning like this: [ 17.105981] [ cut here ] [ 17.110861] WARNING: CPU: 0 PID: 122 at drivers/dma/cppi41.c:644 cppi41_dma_control+0x378/0x3f8 [cppi41]() [ 17.120990] Modules linked in: musb_dsps musb_hdrc cppi41 snd_soc_cs4271 snd_soc_ak4104 snd_soc_davinci_mcasp musb_am335x [ 17.132583] CPU: 0 PID: 122 Comm: usb-storage Not tainted 3.12.0-rc3-00073-gb73d497-dirty #975 [ 17.141670] [c00135b8] (unwind_backtrace+0x0/0xf4) from [c0011418] (show_stack+0x10/0x14) [ 17.150636] [c0011418] (show_stack+0x10/0x14) from [c003597c] (warn_slowpath_common+0x6c/0x84) [ 17.160052] [c003597c] (warn_slowpath_common+0x6c/0x84) from [c0035a30] (warn_slowpath_null+0x1c/0x24) [ 17.170198] [c0035a30] (warn_slowpath_null+0x1c/0x24) from [bf015824] (cppi41_dma_control+0x378/0x3f8 [cppi41]) [ 17.181370] [bf015824] (cppi41_dma_control+0x378/0x3f8 [cppi41]) from [bf023974] (cppi41_dma_channel_abort+0xb0/0x124 [musb_hd) [ 17.194111] [bf023974] (cppi41_dma_channel_abort+0xb0/0x124 [musb_hdrc]) from [bf02031c] (musb_host_rx+0x2b0/0x404 [musb_hdrc]) [ 17.206565] [bf02031c] (musb_host_rx+0x2b0/0x404 [musb_hdrc]) from [bf01ca70] (musb_interrupt+0x70/0x95c [musb_hdrc]) [ 17.218102] [bf01ca70] (musb_interrupt+0x70/0x95c [musb_hdrc]) from [bf02f640] (dsps_interrupt+0x174/0x254 [musb_dsps]) [ 17.229817] [bf02f640] (dsps_interrupt+0x174/0x254 [musb_dsps]) from [c00686d0] (handle_irq_event_percpu+0x38/0x194) [ 17.241238] [c00686d0] (handle_irq_event_percpu+0x38/0x194) from [c0068868] (handle_irq_event+0x3c/0x5c) [ 17.251565] [c0068868] (handle_irq_event+0x3c/0x5c) from [c006aa58] (handle_level_irq+0x90/0xf4) [ 17.261163] [c006aa58] (handle_level_irq+0x90/0xf4) from [c0067f30] (generic_handle_irq+0x2c/0x3c) [ 17.270942] [c0067f30] (generic_handle_irq+0x2c/0x3c) from [c000eae4] (handle_IRQ+0x38/0x84) [ 17.280174] [c000eae4] (handle_IRQ+0x38/0x84) from [c00085b8] (omap3_intc_handle_irq+0x68/0x74) [ 17.289678] [c00085b8] (omap3_intc_handle_irq+0x68/0x74) from [c0011f04] (__irq_svc+0x44/0x78) [ 17.299085] Exception stack(0xcedf1d18 to 0xcedf1d60) [ 17.304391] 1d00: 0001 c083c10c [ 17.312981] 1d20: cec4cb80 6013 cec68010 cee2e640 ced12c00 6013 [ 17.321572] 1d40: cee955cc 0080 c08640ac cedf1d60 c007af4c c0511ab8 2013 [ 17.330177] [c0011f04] (__irq_svc+0x44/0x78) from [c0511ab8] (_raw_spin_unlock_irqrestore+0x64/0x68) [ 17.340156] [c0511ab8] (_raw_spin_unlock_irqrestore+0x64/0x68) from [bf01ee78] (musb_urb_enqueue+0x70/0x520 [musb_hdrc]) [ 17.351974] [bf01ee78] (musb_urb_enqueue+0x70/0x520 [musb_hdrc]) from [c0344248] (usb_hcd_submit_urb+0xa0/0x26c) [ 17.363044] [c0344248] (usb_hcd_submit_urb+0xa0/0x26c) from [c0352724] (usb_stor_msg_common+0x84/0x134) [ 17.373283] [c0352724] (usb_stor_msg_common+0x84/0x134) from [c0352b38] (usb_stor_bulk_transfer_buf+0x48/0x7c) [ 17.384160] [c0352b38] (usb_stor_bulk_transfer_buf+0x48/0x7c) from [c0352dfc] (usb_stor_Bulk_transport+0x144/0x2fc) [ 17.395491] [c0352dfc] (usb_stor_Bulk_transport+0x144/0x2fc) from [c0353524] (usb_stor_invoke_transport+0x20/0x48c) [ 17.406817] [c0353524] (usb_stor_invoke_transport+0x20/0x48c) from [c0354960] (usb_stor_control_thread+0x164/0x228) [ 17.418158] [c0354960] (usb_stor_control_thread+0x164/0x228) from [c0050e60] (kthread+0xb4/0xb8) [ 17.427759] [c0050e60] (kthread+0xb4/0xb8) from [c000e2c8] (ret_from_fork+0x14/0x2c) [ 17.436250] ---[ end trace 0606f8051ee8bb0d ]--- Note that the line numbers don't match the current code in mainline due to some debugging code, but it should be clear where the warning comes from. With patch #3 applied, I made this problem go away, and I can suspend resume with all musb related drivers active just fine. The only issue I have is that I don't fully understand the reason, as it seems to me that my patch
[PATCH 3/3] dma: cppi41: move -EAGAIN in tear_down
In cppi41_tear_down_chan(), bail out earlier in case td_seen is unset
instead of popping another descriptor when td_desc_seen is also unset.
My system ran into WARN() condition multiple times when
cppi41_tear_down_chan() was called for channels that had all of
td_queued, td_seen and td_seen set to false.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/dma/cppi41.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 7747bf7..6decf34 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -586,6 +586,9 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
}
c-td_seen = 1;
}
+
+ if (c-td_retry)
+ return -EAGAIN;
}
if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
@@ -606,8 +609,6 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
* descriptor before the TD we fetch it from enqueue, it has to be
* there waiting for us.
*/
- if (!c-td_seen c-td_retry)
- return -EAGAIN;
WARN_ON(!c-td_retry);
if (!c-td_desc_seen) {
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] usb: musb_dsps: support for suspend and resume
I've been working on some patches that allow suspending and resuming
the musb-dsps platform. This was tested for host mode only.
With these patches applied, I can successfully bring an AM335x board
to suspend with a USB media connected, and access it again after
resume.
This works for both PIO mode and CPPI41 enabled configurations,
together with my cppi41 patches that I posted here:
http://marc.info/?l=linux-usbm=138063429219730w=2
More testing is certainly appreciated.
Thanks,
Daniel
Daniel Mack (5):
usb: musb: move port reset to worker
usb: musb: call musb_port_suspend from musb_bus_suspend
usb: musb: conditionally save and restore the context on suspend
usb: musb: dsps: add {tx,rx}_mode to wrapper
usb: musb: dsps: add support for suspend and resume
drivers/usb/musb/musb_core.c| 24 +++-
drivers/usb/musb/musb_core.h| 3 ++
drivers/usb/musb/musb_dsps.c| 64 +
drivers/usb/musb/musb_host.c| 2 ++
drivers/usb/musb/musb_host.h| 4 +++
drivers/usb/musb/musb_virthub.c | 15 ++
include/linux/usb/musb.h| 1 +
7 files changed, 106 insertions(+), 7 deletions(-)
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] usb: musb: conditionally save and restore the context on suspend
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.
The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c | 17 -
include/linux/usb/musb.h | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2b9f4b4..f17604e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2152,6 +2152,7 @@ static int musb_suspend(struct device *dev)
{
struct musb *musb = dev_to_musb(dev);
unsigned long flags;
+ struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
spin_lock_irqsave(musb-lock, flags);
@@ -2165,16 +2166,30 @@ static int musb_suspend(struct device *dev)
*/
}
+ if (plat-restore_after_suspend)
+ musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
static int musb_resume_noirq(struct device *dev)
{
- /* for static cmos like DaVinci, register values were preserved
+ struct musb *musb = dev_to_musb(dev);
+ struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
+
+ /*
+* For static cmos like DaVinci, register values were preserved
* unless for some reason the whole soc powered down or the USB
* module got reset through the PSC (vs just being disabled).
+*
+* The plaform data tells us about the necessity of saving and
+* restoring the context across a suspend cycle.
*/
+
+ if (plat-restore_after_suspend)
+ musb_restore_context(musb);
+
return 0;
}
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..296be6c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -100,6 +100,7 @@ struct musb_hdrc_platform_data {
u8 mode;
u8 has_mailbox:1;
+ u8 restore_after_suspend:1;
/* for clk_get() */
const char *clock;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] usb: musb: dsps: add support for suspend and resume
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 60
1 file changed, 60 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f3085bc..ac68e29 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8 poll_seconds;
};
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+ u32 control;
+ u32 epintr;
+ u32 coreintr;
+ u32 phy_utmi;
+ u32 mode;
+ u32 tx_mode;
+ u32 rx_mode;
+};
+
/**
* DSPS glue structure.
*/
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+ struct dsps_context context;
};
/**
@@ -504,6 +519,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+ pdata.restore_after_suspend = 1;
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -627,11 +643,55 @@ static const struct of_device_id musb_dsps_of_match[] = {
};
MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ glue-context.control = dsps_readl(mbase, wrp-control);
+ glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+ glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+ glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+ glue-context.mode = dsps_readl(mbase, wrp-mode);
+ glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+ glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+ return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ dsps_writel(mbase, wrp-control, glue-context.control);
+ dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+ dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+ dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+ dsps_writel(mbase, wrp-mode, glue-context.mode);
+ dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+ dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+ musb-port_reset_state = false;
+ schedule_work(musb-port_reset_work);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
static struct platform_driver dsps_usbss_driver = {
.probe = dsps_probe,
.remove = dsps_remove,
.driver = {
.name = musb-dsps,
+ .pm = dsps_pm_ops,
.of_match_table = of_match_ptr(musb_dsps_of_match),
},
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] usb: musb: dsps: add {tx,rx}_mode to wrapper
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 4047cbb..f3085bc 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+ u16 tx_mode;
+ u16 rx_mode;
/* bit positions for control */
unsignedreset:5;
@@ -600,6 +602,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi = 0xe0,
.mode = 0xe8,
+ .tx_mode= 0x70,
+ .rx_mode= 0x74,
.reset = 0,
.otg_disable= 21,
.iddig = 8,
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] usb: musb: move port reset to worker
musb_port_reset() sleeps, so we can't call it from atomic context. It
is, however, called from places inside musb_hub_control() while
musb-lock is held, which leads to a scheduling while atomic warning.
Fix this by moving the logic into a worker, and call it where the
function was previously called directly.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c| 7 +++
drivers/usb/musb/musb_core.h| 3 +++
drivers/usb/musb/musb_host.h| 2 ++
drivers/usb/musb/musb_virthub.c | 13 -
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 18e877f..2b9f4b4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1699,6 +1699,12 @@ static void musb_irq_work(struct work_struct *data)
}
}
+static void musb_port_reset_work(struct work_struct *data)
+{
+ struct musb *musb = container_of(data, struct musb, port_reset_work);
+ musb_port_reset(musb);
+}
+
/* --
* Init support
*/
@@ -1857,6 +1863,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
+ INIT_WORK(musb-port_reset_work, musb_port_reset_work);
/* attach to the IRQ */
if (request_irq(nIrq, musb-isr, 0, dev_name(dev), musb)) {
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 65f3917..9529512 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -294,6 +294,9 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
+ struct work_struct port_reset_work;
+ boolport_reset_state;
+
u16 hwvers;
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..843f48e 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
extern void musb_root_disconnect(struct musb *musb);
extern void musb_host_resume_root_hub(struct musb *musb);
extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_reset(struct musb *musb);
#else
static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
{
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)
{}
static inline void musb_host_resume_root_hub(struct musb *musb){}
static inline void musb_host_poll_rh_status(struct musb *musb) {}
static inline void musb_host_poke_root_hub(struct musb *musb) {}
+static inline void musb_port_reset(struct musb *musb) {}
#endif
struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index a523950..30b43a1 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -155,7 +155,7 @@ static void musb_port_suspend(struct musb *musb, bool
do_suspend)
}
}
-static void musb_port_reset(struct musb *musb, bool do_reset)
+void musb_port_reset(struct musb *musb)
{
u8 power;
void __iomem*mbase = musb-mregs;
@@ -173,7 +173,7 @@ static void musb_port_reset(struct musb *musb, bool
do_reset)
* the appropriate amount of time has passed
*/
power = musb_readb(mbase, MUSB_POWER);
- if (do_reset) {
+ if (musb-port_reset_state) {
/*
* If RESUME is set, we must make sure it stays minimum 20 ms.
@@ -356,8 +356,10 @@ int musb_hub_control(
/* finish RESET signaling? */
if ((musb-port1_status USB_PORT_STAT_RESET)
-time_after_eq(jiffies, musb-rh_timer))
- musb_port_reset(musb, false);
+time_after_eq(jiffies, musb-rh_timer)) {
+ musb-port_reset_state = false;
+ schedule_work(musb-port_reset_work);
+ }
/* finish RESUME signaling? */
if ((musb-port1_status MUSB_PORT_STAT_RESUME)
@@ -412,7 +414,8 @@ int musb_hub_control(
musb_start(musb);
break;
case USB_PORT_FEAT_RESET:
- musb_port_reset(musb, true);
+ musb-port_reset_state = true;
+ schedule_work(musb-port_reset_work);
break;
case USB_PORT_FEAT_SUSPEND:
musb_port_suspend(musb, true);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_host.c| 2 ++
drivers/usb/musb/musb_host.h| 2 ++
drivers/usb/musb/musb_virthub.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 9a2b8c8..2b60596 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8 devctl;
+ musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 843f48e..dcffea7 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
extern void musb_host_resume_root_hub(struct musb *musb);
extern void musb_host_poke_root_hub(struct musb *musb);
extern void musb_port_reset(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
#else
static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
{
@@ -123,6 +124,7 @@ static inline void musb_host_resume_root_hub(struct musb
*musb) {}
static inline void musb_host_poll_rh_status(struct musb *musb) {}
static inline void musb_host_poke_root_hub(struct musb *musb) {}
static inline void musb_port_reset(struct musb *musb) {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
#endif
struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 30b43a1..9f3a0f3 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -90,7 +90,7 @@ static void musb_start(struct musb *musb)
musb_writeb(regs, MUSB_DEVCTL, devctl);
}
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
{
struct usb_otg *otg = musb-xceiv-otg;
u8 power;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On 10/01/2013 06:13 AM, Sricharan R wrote: Hi, On Monday 30 September 2013 08:39 PM, Rob Herring wrote: On 09/30/2013 08:59 AM, Sricharan R wrote: 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's interrupt is mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. Seems like interrupt-map property is what you need here. http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Versatile Express also has an example. OK, but the idea was not to tie up the crossbar-interrupt numbers at the DTS level, but to assign it dynamically during runtime. This was one of the comments that came up with first crossbar support patches, which was assigning a interrupt line to crossbar number in the DTS and setting it up in crossbar probe. Is there an actual usecase on a single h/w design that you run out of interrupts and it is a user decision which interrupts to use? You could fill in the interrupt-map at run-time. It would have to be early (bootloader or early kernel init) and can't be at request_irq time. https://lkml.org/lkml/2013/7/18/416 Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and that did not go as well. Finally was asked to handle this as a part of GIC driver with a separate domain. http://www.spinics.net/lists/linux-omap/msg97085.html This has nothing to do with the GIC, so it does not belong there. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap: edma: add suspend suspend/resume hooks
This patch adds support for edma driver. I know the intermediate code in arch/arm/common is going to be purged eventually when the real dma-engine driver lands, so I don't know whether it's reasonable to include my patch after all. It might just server as template for the suspend/resume functions in the final driver, or maybe anyone wants to include that intermediate hack for the time being. Successfully tested on an AM335x board with davinci-mcasp enabled audio. A patch to make the latter work after suspend has been posted on alsa-devel. Thanks, Dainel Daniel Mack (1): ARM: omap: edma: add suspend suspend/resume hooks arch/arm/common/edma.c | 133 + 1 file changed, 133 insertions(+) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: On 10/01/2013 06:13 AM, Sricharan R wrote: Hi, On Monday 30 September 2013 08:39 PM, Rob Herring wrote: On 09/30/2013 08:59 AM, Sricharan R wrote: 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's interrupt is mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. Seems like interrupt-map property is what you need here. http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Versatile Express also has an example. OK, but the idea was not to tie up the crossbar-interrupt numbers at the DTS level, but to assign it dynamically during runtime. This was one of the comments that came up with first crossbar support patches, which was assigning a interrupt line to crossbar number in the DTS and setting it up in crossbar probe. Is there an actual usecase on a single h/w design that you run out of interrupts and it is a user decision which interrupts to use? Yes. There are 240 peripheral interrupts connected out of which 160 can be used in this specific case. You could fill in the interrupt-map at run-time. It would have to be early (bootloader or early kernel init) and can't be at request_irq time. Well all options are tried before coming up to the $subject solution. It was suggested by Thomas in the last review. https://lkml.org/lkml/2013/7/18/416 Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and that did not go as well. Finally was asked to handle this as a part of GIC driver with a separate domain. http://www.spinics.net/lists/linux-omap/msg97085.html This has nothing to do with the GIC, so it does not belong there. Well the router makes connections from peripheral to GIC. Thomas can better explain it but I think since its doing irq routing for GIC on a given hardware, I don't see any issue having some generic map/unmap function in GIC. The actual implementation is still outside of GIC. Regards, Sasntosh -- 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: omap: edma: add suspend suspend/resume hooks
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.
The code was shamelessly taken from an ancient BSP tree.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/common/edma.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2a72169..d787f14 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -258,6 +258,20 @@ struct edma {
void *data);
void *data;
} intr_data[EDMA_MAX_DMACH];
+
+ struct {
+ struct edmacc_param *prm_set;
+ unsigned int *ch_map; /* 64 registers */
+ unsigned int *que_num; /* 8 registers */
+ unsigned int sh_esr;
+ unsigned int sh_esrh;
+ unsigned int sh_eesr;
+ unsigned int sh_eesrh;
+ unsigned int sh_iesr;
+ unsigned int sh_iesrh;
+ unsigned int que_tc_map;
+ unsigned int que_pri;
+ } context;
};
static struct edma *edma_cc[EDMA_MAX_CC];
@@ -1655,6 +1669,16 @@ static int edma_probe(struct platform_device *pdev)
memcpy_toio(edmacc_regs_base[j] + PARM_OFFSET(i),
dummy_paramset, PARM_SIZE);
+ /* resume context */
+ edma_cc[j]-context.prm_set =
+ kzalloc((sizeof(struct edmacc_param) *
+edma_cc[j]-num_slots), GFP_KERNEL);
+ edma_cc[j]-context.ch_map =
+ kzalloc((sizeof(unsigned int) *
+edma_cc[j]-num_channels), GFP_KERNEL);
+ edma_cc[j]-context.que_num =
+ kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL);
+
/* Mark all channels as unused */
memset(edma_cc[j]-edma_unused, 0xff,
sizeof(edma_cc[j]-edma_unused));
@@ -1762,6 +1786,114 @@ static int edma_probe(struct platform_device *pdev)
return 0;
}
+static int edma_pm_suspend(struct device *dev)
+{
+ int i, j;
+
+ pm_runtime_get_sync(dev);
+
+ for (i = 0; i arch_num_cc; i++) {
+ struct edma *ecc = edma_cc[i];
+
+ /* backup channel data */
+ for (j = 0; j ecc-num_channels; j++)
+ ecc-context.ch_map[j] =
+ edma_read_array(i, EDMA_DCHMAP, j);
+
+ /* backup DMA Queue Number */
+ for (j = 0; j 8; j++)
+ ecc-context.que_num[j] =
+ edma_read_array(i, EDMA_DMAQNUM, j);
+
+ /* backup DMA shadow Event Set data */
+ ecc-context.sh_esr = edma_shadow0_read_array(i, SH_ESR, 0);
+ ecc-context.sh_esrh = edma_shadow0_read_array(i, SH_ESR, 1);
+
+ /* backup DMA Shadow Event Enable Set data */
+ ecc-context.sh_eesr =
+ edma_shadow0_read_array(i, SH_EER, 0);
+ ecc-context.sh_eesrh =
+ edma_shadow0_read_array(i, SH_EER, 1);
+
+ /* backup DMA Shadow Interrupt Enable Set data */
+ ecc-context.sh_iesr =
+ edma_shadow0_read_array(i, SH_IER, 0);
+ ecc-context.sh_iesrh =
+ edma_shadow0_read_array(i, SH_IER, 1);
+
+ ecc-context.que_tc_map = edma_read(i, EDMA_QUETCMAP);
+
+ /* backup DMA Queue Priority data */
+ ecc-context.que_pri = edma_read(i, EDMA_QUEPRI);
+
+ /* backup paramset */
+ for (j = 0; j ecc-num_slots; j++)
+ memcpy_fromio(ecc-context.prm_set[j],
+ edmacc_regs_base[i] + PARM_OFFSET(j),
+ PARM_SIZE);
+ }
+
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+ int i, j;
+
+ pm_runtime_get_sync(dev);
+
+ for (i = 0; i arch_num_cc; i++) {
+ struct edma *ecc = edma_cc[i];
+
+ /* restore channel data */
+ for (j = 0; j ecc-num_channels; j++) {
+ edma_write_array(i, EDMA_DCHMAP, j,
+ecc-context.ch_map[j]);
+ }
+
+ /* restore DMA Queue Number */
+ for (j = 0; j 8; j++) {
+ edma_write_array(i, EDMA_DMAQNUM, j,
+ecc-context.que_num[j]);
+ }
+
+ /* restore DMA shadow Event Set data */
+ edma_shadow0_write_array(i, SH_ESR, 0, ecc-context.sh_esr);
+ edma_shadow0_write_array(i, SH_ESR, 1, ecc-context.sh_esrh);
+
Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD
Hi, On Thu, Sep 26, 2013 at 02:00:59AM +0200, Pavel Machek wrote: On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote: On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote: twl-phy.notifier is not initalized Signed-off-by: Pali Rohár pali.ro...@gmail.com diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155 100644 --- a/drivers/usb/phy/phy-twl4030-usb.c +++ b/drivers/usb/phy/phy-twl4030-usb.c @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev) if (device_create_file(pdev-dev, dev_attr_vbus)) dev_warn(pdev-dev, could not create sysfs file\n); + ATOMIC_INIT_NOTIFIER_HEAD(twl-phy.notifier); + /* Our job is to use irqs and status from the power module * to keep the transceiver disabled when nothing's connected. * I sent above patch week ago. Did you already included it? look at my testing branch. Felipe prefers you to go MAINTAINERS file for git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git entry. After few clicks, you'll find out your two patches in https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing . So yes, it seems that after 10+ flames Felipe was _not_ lazy to send, Thanks for a patch mail was too much work. Apparently, we'll need Documentation/HowToBeGoodMaintainer file... I only send my automated emails after properly testing them. They sit in 'testing' for as long as necessary. After all the test is done, they'll be moved to 'next' at which point you get your email notification and they reach linux-next for the next day. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 5/5] usb: musb: dsps: add support for suspend and resume
Hi, On Tue, Oct 01, 2013 at 03:39:57PM +0200, Daniel Mack wrote: The dsps platform needs to save save some registers at suspend time and restore them after resume. This patch adds a struct for these registers, and also lets the musb core know that the core registers need to be saved as well. Signed-off-by: Daniel Mack zon...@gmail.com this last patch didn't apply. can you rebase on my 'testing' branch ? -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On 10/01/2013 08:57 AM, Santosh Shilimkar wrote: On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: On 10/01/2013 06:13 AM, Sricharan R wrote: Hi, On Monday 30 September 2013 08:39 PM, Rob Herring wrote: On 09/30/2013 08:59 AM, Sricharan R wrote: 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's interrupt is mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. Seems like interrupt-map property is what you need here. http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Versatile Express also has an example. OK, but the idea was not to tie up the crossbar-interrupt numbers at the DTS level, but to assign it dynamically during runtime. This was one of the comments that came up with first crossbar support patches, which was assigning a interrupt line to crossbar number in the DTS and setting it up in crossbar probe. Is there an actual usecase on a single h/w design that you run out of interrupts and it is a user decision which interrupts to use? Yes. There are 240 peripheral interrupts connected out of which 160 can be used in this specific case. Yes, I understand the SOC connections. That does not answer my question. The 240 interrupts are likely to be limited to fewer by board design, pinmuxing, etc. How do you handle the 161st interrupt request? Will never happen? Just rely on the random driver probe ordering? You could fill in the interrupt-map at run-time. It would have to be early (bootloader or early kernel init) and can't be at request_irq time. Well all options are tried before coming up to the $subject solution. It was suggested by Thomas in the last review. https://lkml.org/lkml/2013/7/18/416 Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and that did not go as well. Finally was asked to handle this as a part of GIC driver with a separate domain. http://www.spinics.net/lists/linux-omap/msg97085.html This has nothing to do with the GIC, so it does not belong there. Well the router makes connections from peripheral to GIC. Thomas can better explain it but I think since its doing irq routing for GIC on a given hardware, I don't see any issue having some generic map/unmap function in GIC. The actual implementation is still outside of GIC. I read Thomas' reply as don't put this crap in his code. You can call it generic, but it is not. It is specific to the GIC and looks like an abuse of irqdomains to me. Look where the function declaration for register_routable_domain_ops is. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] usb: musb: dsps: add support for suspend and resume
On 01.10.2013 16:59, Felipe Balbi wrote: On Tue, Oct 01, 2013 at 03:39:57PM +0200, Daniel Mack wrote: The dsps platform needs to save save some registers at suspend time and restore them after resume. This patch adds a struct for these registers, and also lets the musb core know that the core registers need to be saved as well. Signed-off-by: Daniel Mack zon...@gmail.com this last patch didn't apply. can you rebase on my 'testing' branch ? I've seen that you already applied the others, so I'm going to resend only that last one. Hope that's ok. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: omap: edma: add suspend suspend/resume hooks
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.
The code was shamelessly taken from an ancient BSP tree.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/common/edma.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2a72169..d787f14 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -258,6 +258,20 @@ struct edma {
void *data);
void *data;
} intr_data[EDMA_MAX_DMACH];
+
+ struct {
+ struct edmacc_param *prm_set;
+ unsigned int *ch_map; /* 64 registers */
+ unsigned int *que_num; /* 8 registers */
+ unsigned int sh_esr;
+ unsigned int sh_esrh;
+ unsigned int sh_eesr;
+ unsigned int sh_eesrh;
+ unsigned int sh_iesr;
+ unsigned int sh_iesrh;
+ unsigned int que_tc_map;
+ unsigned int que_pri;
+ } context;
};
static struct edma *edma_cc[EDMA_MAX_CC];
@@ -1655,6 +1669,16 @@ static int edma_probe(struct platform_device *pdev)
memcpy_toio(edmacc_regs_base[j] + PARM_OFFSET(i),
dummy_paramset, PARM_SIZE);
+ /* resume context */
+ edma_cc[j]-context.prm_set =
+ kzalloc((sizeof(struct edmacc_param) *
+edma_cc[j]-num_slots), GFP_KERNEL);
+ edma_cc[j]-context.ch_map =
+ kzalloc((sizeof(unsigned int) *
+edma_cc[j]-num_channels), GFP_KERNEL);
+ edma_cc[j]-context.que_num =
+ kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL);
+
/* Mark all channels as unused */
memset(edma_cc[j]-edma_unused, 0xff,
sizeof(edma_cc[j]-edma_unused));
@@ -1762,6 +1786,114 @@ static int edma_probe(struct platform_device *pdev)
return 0;
}
+static int edma_pm_suspend(struct device *dev)
+{
+ int i, j;
+
+ pm_runtime_get_sync(dev);
+
+ for (i = 0; i arch_num_cc; i++) {
+ struct edma *ecc = edma_cc[i];
+
+ /* backup channel data */
+ for (j = 0; j ecc-num_channels; j++)
+ ecc-context.ch_map[j] =
+ edma_read_array(i, EDMA_DCHMAP, j);
+
+ /* backup DMA Queue Number */
+ for (j = 0; j 8; j++)
+ ecc-context.que_num[j] =
+ edma_read_array(i, EDMA_DMAQNUM, j);
+
+ /* backup DMA shadow Event Set data */
+ ecc-context.sh_esr = edma_shadow0_read_array(i, SH_ESR, 0);
+ ecc-context.sh_esrh = edma_shadow0_read_array(i, SH_ESR, 1);
+
+ /* backup DMA Shadow Event Enable Set data */
+ ecc-context.sh_eesr =
+ edma_shadow0_read_array(i, SH_EER, 0);
+ ecc-context.sh_eesrh =
+ edma_shadow0_read_array(i, SH_EER, 1);
+
+ /* backup DMA Shadow Interrupt Enable Set data */
+ ecc-context.sh_iesr =
+ edma_shadow0_read_array(i, SH_IER, 0);
+ ecc-context.sh_iesrh =
+ edma_shadow0_read_array(i, SH_IER, 1);
+
+ ecc-context.que_tc_map = edma_read(i, EDMA_QUETCMAP);
+
+ /* backup DMA Queue Priority data */
+ ecc-context.que_pri = edma_read(i, EDMA_QUEPRI);
+
+ /* backup paramset */
+ for (j = 0; j ecc-num_slots; j++)
+ memcpy_fromio(ecc-context.prm_set[j],
+ edmacc_regs_base[i] + PARM_OFFSET(j),
+ PARM_SIZE);
+ }
+
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+ int i, j;
+
+ pm_runtime_get_sync(dev);
+
+ for (i = 0; i arch_num_cc; i++) {
+ struct edma *ecc = edma_cc[i];
+
+ /* restore channel data */
+ for (j = 0; j ecc-num_channels; j++) {
+ edma_write_array(i, EDMA_DCHMAP, j,
+ecc-context.ch_map[j]);
+ }
+
+ /* restore DMA Queue Number */
+ for (j = 0; j 8; j++) {
+ edma_write_array(i, EDMA_DMAQNUM, j,
+ecc-context.que_num[j]);
+ }
+
+ /* restore DMA shadow Event Set data */
+ edma_shadow0_write_array(i, SH_ESR, 0, ecc-context.sh_esr);
+ edma_shadow0_write_array(i, SH_ESR, 1, ecc-context.sh_esrh);
+
Re: [RFC 00/15] Device Tree schemas and validation
Hi Rob,
On 01/10/2013 15:17, Rob Herring wrote:
On 10/01/2013 03:06 AM, Benoit Cousson wrote:
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit of comments about at least the bindings syntax:-(
I'd like to know if this is the right direction and if it worth pursuing
in that direction.
The idea was to have at least some base for further discussion during
ARM KS 2013.
I feel alone :-(
If you have any comment, go ahead!
Thanks for taking this on!
This is interesting approach using the dts syntax,
Well, this was discussed a little bit on the list, and it has the big
advantage of re-using the parser already included in DTC for free.
In term or readability, it avoids to re-defining a brand new syntax for
people who are already familiar with the DTS one.
but I worry that the
validation will only be as good as the schema written and the review of
the schema.
Well, sure, but unfortunately, that will always be the case :-(
The bindings definition being quite open, there is no easy way to ensure
proper schema / bindings without careful review of the schema. There is
no such thing as a free beer... Unfortunately :-)
I think the schema needs to define the binding rather than
define the checks. Then the schema can feed the validation checks.
This format does not seem to me as easily being able to generate
documentation from the schema which I believe is one of the goals.
Indeed, but I think is it easy to generate any kind of readable format
for the documentation purpose if needed from the actual format.
Otherwise, we should consider a schema format based on kerneldoc type of
syntax to improve readability. I'm just afraid it will become harder
then to define complex schema.
BTW, what kind of documentation are you expecting here? Is is a text
that can be added on top of each schema?
I for
one don't care to review the documentation and the schema for every binding.
I would like to ensure we can start with the basics and have some
generic rules. Some examples:
- flag compatible strings in dts files that are not documented
This is almost done with the last patch of the series. Nodes are already
checked, properties are missing.
- check required properties
Done as well.
- check properties against cell sizes
Yeah, that one is still to be done.
- a node with reg property must have a unit address
Easy to add.
- flag properties with _
Easy to add as well.
- check properties are the correct data type
Already done for a couple of data type.
Thanks for your comments. Being the very first one, you might get a free
beer... meaning there might be such thing as a free beer :-)
Thanks,
Benoit
Thanks,
Benoit
On 24/09/2013 18:52, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
[1] http://www.spinics.net/lists/arm-kernel/msg262224.html
=== What it does? ===
For now device-tree bindings are defined in a not standardized
text-based format and thus any one can write the documentation for a
binding as he wish. In addition to this there is no automated way to
check if a dts is conform to the available bindings.
The goal of this series of patch is to fix this situation by adding a
well defined way to write bindings in a human-readable format. These
bindings will be written through files called schemas.
=== What is a schema? ===
A schema is a file describing the constraints that one or several nodes
of a dts must conform to. Schemas must use the file extension .schema.
A schema can check that:
- A node has a given property
- An array has a valid size
- A node contains the required children.
- A property has the correct type.
- A property has the correct value.
A schema can as well recursively check the constraints for parent nodes.
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
=== How to defined a schema? ===
A binding directory has been added at the root of repository. Users can
add schema files anywhere in it but a nice way would be to keep the same
structure as the binding directory in the documentation.
To demonstrate how to write a schema and its capability I will use the
OMAP DTS schemas when applicable.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the compatible properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
interrupts = 0x0
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote: On 10/01/2013 08:57 AM, Santosh Shilimkar wrote: On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: On 10/01/2013 06:13 AM, Sricharan R wrote: Hi, On Monday 30 September 2013 08:39 PM, Rob Herring wrote: On 09/30/2013 08:59 AM, Sricharan R wrote: 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's interrupt is mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. Seems like interrupt-map property is what you need here. http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Versatile Express also has an example. OK, but the idea was not to tie up the crossbar-interrupt numbers at the DTS level, but to assign it dynamically during runtime. This was one of the comments that came up with first crossbar support patches, which was assigning a interrupt line to crossbar number in the DTS and setting it up in crossbar probe. Is there an actual usecase on a single h/w design that you run out of interrupts and it is a user decision which interrupts to use? Yes. There are 240 peripheral interrupts connected out of which 160 can be used in this specific case. Yes, I understand the SOC connections. That does not answer my question. The 240 interrupts are likely to be limited to fewer by board design, pinmuxing, etc. yes limited by different board designs ... How do you handle the 161st interrupt request? Will never happen? Just rely on the random driver probe ordering? Well the board dts are expected to provide the peripheral support info to optimise it. If a board actually has more than 160 peripherals available then in that case the 161 interrupt will not be mapped. You could fill in the interrupt-map at run-time. It would have to be early (bootloader or early kernel init) and can't be at request_irq time. Well all options are tried before coming up to the $subject solution. It was suggested by Thomas in the last review. https://lkml.org/lkml/2013/7/18/416 Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and that did not go as well. Finally was asked to handle this as a part of GIC driver with a separate domain. http://www.spinics.net/lists/linux-omap/msg97085.html This has nothing to do with the GIC, so it does not belong there. Well the router makes connections from peripheral to GIC. Thomas can better explain it but I think since its doing irq routing for GIC on a given hardware, I don't see any issue having some generic map/unmap function in GIC. The actual implementation is still outside of GIC. I read Thomas' reply as don't put this crap in his code. That was for the IRQCHIP based approach and as part of that review Thomas suggested why not irqdomain and suggested a prototype code as well. You can call it generic, but it is not. It is specific to the GIC and looks like an abuse of irqdomains to me. Look where the function declaration for register_routable_domain_ops is. I am not sure why you call it abuse of irqdomain since the map/unmap are exactly the interfaces where the logical to physical irq connections are made. Look at existing GIC code as well. I still let Thomas give his expert comment whether it is abusive because it it was, am sure he wouldn't have suggested that. Now if your concern is the register_routable_domain_ops() then we are open to hear if there is any better way to do that. Thats why the series is still RFC. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/15] Device Tree schemas and validation
Hi Rob, On 01/10/2013 15:17, Rob Herring wrote: On 10/01/2013 03:06 AM, Benoit Cousson wrote: + more DT maintainers folks Hi all, I know this is mostly boring user space code, but I was expecting a little bit of comments about at least the bindings syntax:-( I'd like to know if this is the right direction and if it worth pursuing in that direction. The idea was to have at least some base for further discussion during ARM KS 2013. I feel alone :-( If you have any comment, go ahead! Benoit, Sorry, I meant to ask earlier but forgot. Shouldn't this development be based on the upstream DTC repository and not the in-kernel copy of the DTC? Thanks, jdl -- 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 5/5] usb: musb: dsps: add support for suspend and resume
On Tue, Oct 01, 2013 at 05:04:04PM +0200, Daniel Mack wrote: On 01.10.2013 16:59, Felipe Balbi wrote: On Tue, Oct 01, 2013 at 03:39:57PM +0200, Daniel Mack wrote: The dsps platform needs to save save some registers at suspend time and restore them after resume. This patch adds a struct for these registers, and also lets the musb core know that the core registers need to be saved as well. Signed-off-by: Daniel Mack zon...@gmail.com this last patch didn't apply. can you rebase on my 'testing' branch ? I've seen that you already applied the others, so I'm going to resend only that last one. Hope that's ok. That's perfectly fine ;-) Thanks -- balbi signature.asc Description: Digital signature
[PATCH v3] usb: musb: dsps: add support for suspend and resume
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 60
1 file changed, 60 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 5eba143..f2f4b3a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8 poll_seconds;
};
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+ u32 control;
+ u32 epintr;
+ u32 coreintr;
+ u32 phy_utmi;
+ u32 mode;
+ u32 tx_mode;
+ u32 rx_mode;
+};
+
/**
* DSPS glue structure.
*/
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+ struct dsps_context context;
};
/**
@@ -504,6 +519,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+ pdata.restore_after_suspend = 1;
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -627,11 +643,55 @@ static const struct of_device_id musb_dsps_of_match[] = {
};
MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ glue-context.control = dsps_readl(mbase, wrp-control);
+ glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+ glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+ glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+ glue-context.mode = dsps_readl(mbase, wrp-mode);
+ glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+ glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+ return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ dsps_writel(mbase, wrp-control, glue-context.control);
+ dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+ dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+ dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+ dsps_writel(mbase, wrp-mode, glue-context.mode);
+ dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+ dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+ musb-port_reset_state = false;
+ schedule_work(musb-port_reset_work);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
static struct platform_driver dsps_usbss_driver = {
.probe = dsps_probe,
.remove = dsps_remove,
.driver = {
.name = musb-dsps,
+ .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once
On 10/01/2013 03:09 PM, Daniel Mack wrote: Hi Sebastian, Hi Daniel, sorry for the long delay, I got distracted by other things. No problem. Well, I didn't merge the descriptors. Look again at my changes please. A simplified version of the code as it stands is: for (i = 0; i DESCS_AREAS; i++) cdd-cd = dma_alloc_coherent(dev, ..., cdd-descs_phys, GFP_KERNEL); for (i = 0; i DESCS_AREAS; i++) dma_free_coherent(dev, mem_decs, cdd-cd, cdd-descs_phys); So you're effectively allocating and freeing the same pointer DESCS_AREAS times, which is certainly not what you wanted. Well, no but since DESCS_AREAS is 1 it does not matter. And this just doesn't hit you because DESCS_AREAS is always 1: exactly. BUILD_BUG_ON(DESCS_AREAS != 1); So, after all, my patch doesn't really change any of the runtime behaviour. Consider it a cosmetic cleanup if you wish :) But it looks strange (in my opinion at least). But now, that I look again at it yes you moved the alloc out of the loop and replaced mem_decs with the computation. So nothing changed but you moved it outside. Right I think one desc area should be enough so I would just remove the for loop and DESCS_AREAS as well. How does this sound to you? Thanks, Daniel Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once
On 01.10.2013 18:22, Sebastian Andrzej Siewior wrote: On 10/01/2013 03:09 PM, Daniel Mack wrote: A simplified version of the code as it stands is: for (i = 0; i DESCS_AREAS; i++) cdd-cd = dma_alloc_coherent(dev, ..., cdd-descs_phys, GFP_KERNEL); for (i = 0; i DESCS_AREAS; i++) dma_free_coherent(dev, mem_decs, cdd-cd, cdd-descs_phys); ... So, after all, my patch doesn't really change any of the runtime behaviour. Consider it a cosmetic cleanup if you wish :) But it looks strange (in my opinion at least). I still disagree, but maybe that doesn't matter any more, because ... But now, that I look again at it yes you moved the alloc out of the loop and replaced mem_decs with the computation. So nothing changed but you moved it outside. Right I think one desc area should be enough so I would just remove the for loop and DESCS_AREAS as well. How does this sound to you? That sound's like a good idea. Everything that make the driver smaller and easier to understand is certainly a good thing :) So we can drop this patch favor of your cleanup. However, I appreciate if you did it on top of the second round of patches I sent today please, because my resume() implementation uses DESCS_AREAS as well. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] pwm-backlight: Refactor backlight power on/off
On 09/23/2013 03:40 PM, Thierry Reding wrote:
In preparation for adding an optional regulator and enable GPIO to the
driver, split the power on and power off sequences into separate
functions to reduce code duplication at the multiple call sites.
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
+static void pwm_backlight_power_off(struct pwm_bl_data *pb)
+{
+ pwm_disable(pb-pwm);
Both the call-sites you're replacing do the following before pwm_disable():
pwm_config(pb-pwm, 0, pb-period);
While I agree that probably shouldn't be necessary, I think it's at
least worth mentioning that in the commit description just to make it
obvious that it was a deliberate change. Splitting that change into a
separate patch might be reasonable in order to keep refactoring and
functional changes separate, although perhaps it's not worth it.
There are also a couple unrelated whitespace changes thrown in here.
--
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 05/10] ARM: SAMSUNG: Initialize PWM backlight enable_gpio field
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
static void __init smdkv210_map_io(void)
@@ -70,6 +70,7 @@ static struct samsung_bl_drvdata samsung_dfl_bl_data
__initdata = {
.max_brightness = 255,
.dft_brightness = 255,
.pwm_period_ns = 78770,
+ .enable_gpio= -1,
.init = samsung_bl_init,
.exit = samsung_bl_exit,
},
@@ -121,6 +122,10 @@ void __init samsung_bl_set(struct samsung_bl_gpio_info
*gpio_info,
samsung_bl_data-lth_brightness = bl_data-lth_brightness;
if (bl_data-pwm_period_ns)
samsung_bl_data-pwm_period_ns = bl_data-pwm_period_ns;
+ if (bl_data-enable_gpio)
+ samsung_bl_data-enable_gpio = bl_data-enable_gpio;
+ if (bl_data-enable_gpio_flags)
+ samsung_bl_data-enable_gpio_flags = bl_data-enable_gpio_flags;
Won't this cause the core pwm_bl driver to request/manipulate the GPIO,
whereas this driver already does that inside the samsung_bl_init/exit
callbacks? I think you either need to adjust those callbacks, or not set
the new standard GPIO property in samsung_bl_data.
--
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 08/10] pwm-backlight: Use new enable_gpio field
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Make use of the new enable_gpio field and allow it to be set from DT as
well. Now that all legacy users of platform data have been converted to
initialize this field to an invalid value, it is safe to use the field
from the driver.
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
Optional properties:
+ - enable-gpios: a list of GPIOs to enable and disable the backlight
That seems to imply that multiple GPIOs are legal. Was that intended? If
not, I would suggest:
- enable-gpios: contains a single GPIO specifier for the GPIO which
enables/disables the backlight. See [1] for the format.
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
+ [1]: Documentation/devicetree/bindings/gpio/gpio.txt
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
@@ -51,12 +55,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data
*pb, int brightness,
pb-lth_brightness;
pwm_config(pb-pwm, duty_cycle, pb-period);
+
+ if (gpio_is_valid(pb-enable_gpio)) {
+ if (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb-enable_gpio, 0);
+ else
+ gpio_set_value(pb-enable_gpio, 1);
+ }
Feel completely free to ignore this, but when the difference in two
code-paths is solely in function parameters, I prefer to calculate the
parameter inside the if statement, then call the function outside the
conditional code, to highlight the common/different parts:
int value;
/* or an if statement for the next 1 line, if you don't like ?: */
value = (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW) ? 0 : 1;
gpio_set_value((pb-enable_gpio, value);
@@ -148,11 +168,10 @@ static int pwm_backlight_parse_dt(struct device *dev,
+ data-enable_gpio = of_get_named_gpio_flags(node, enable-gpios, 0,
+ flags);
+ if (gpio_is_valid(data-enable_gpio) (flags OF_GPIO_ACTIVE_LOW))
+ data-enable_gpio_flags |= PWM_BACKLIGHT_GPIO_ACTIVE_LOW;
This doesn't seem to handle deferred probe correctly; I would expect
something more like:
data-enable_gpio = of_get_named_gpio_flags(...);
if (data-enable_gpio == -EPROBE_DEFERRED)
return data-enable_gpio;
if (gpio_is_valid(...))
...
return 0;
I suppose it's possible that the value filters down to
gpio_request_one() and this actually does work out OK, but that feels
very accidental/implicit to me.
--
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: omap: edma: add suspend suspend/resume hooks
Daniel Mack zon...@gmail.com writes:
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.
Please add a little more detail abou why the EDMA loses its context
across suspend/resume (e.g. which power domain(s) its in, and why they
lose context across suspend/resume.
Also, is a full context save necessary every time? What if no channels
are in use? Also, is a full restore necessary every time? Are there
cases where the domain doesn't lose context and a restore would not be
necessary? Often this can be checked by reading register(s) that has a
known power-on reset value.
The code was shamelessly taken from an ancient BSP tree.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
+static int edma_pm_suspend(struct device *dev)
+{
+ int i, j;
+
+ pm_runtime_get_sync(dev);
+
+ for (i = 0; i arch_num_cc; i++) {
+ struct edma *ecc = edma_cc[i];
+
+ /* backup channel data */
+ for (j = 0; j ecc-num_channels; j++)
+ ecc-context.ch_map[j] =
+ edma_read_array(i, EDMA_DCHMAP, j);
+
+ /* backup DMA Queue Number */
+ for (j = 0; j 8; j++)
+ ecc-context.que_num[j] =
+ edma_read_array(i, EDMA_DMAQNUM, j);
+
+ /* backup DMA shadow Event Set data */
+ ecc-context.sh_esr = edma_shadow0_read_array(i, SH_ESR, 0);
+ ecc-context.sh_esrh = edma_shadow0_read_array(i, SH_ESR, 1);
+
+ /* backup DMA Shadow Event Enable Set data */
+ ecc-context.sh_eesr =
+ edma_shadow0_read_array(i, SH_EER, 0);
+ ecc-context.sh_eesrh =
+ edma_shadow0_read_array(i, SH_EER, 1);
+
+ /* backup DMA Shadow Interrupt Enable Set data */
+ ecc-context.sh_iesr =
+ edma_shadow0_read_array(i, SH_IER, 0);
+ ecc-context.sh_iesrh =
+ edma_shadow0_read_array(i, SH_IER, 1);
+
+ ecc-context.que_tc_map = edma_read(i, EDMA_QUETCMAP);
+
+ /* backup DMA Queue Priority data */
+ ecc-context.que_pri = edma_read(i, EDMA_QUEPRI);
+
+ /* backup paramset */
+ for (j = 0; j ecc-num_slots; j++)
+ memcpy_fromio(ecc-context.prm_set[j],
+ edmacc_regs_base[i] + PARM_OFFSET(j),
+ PARM_SIZE);
+ }
The actual context save doesn't belong here, it belongs in the
-runtime_suspend callback(), and conversly the context restore belongs
in the -runtime_resume() callback.
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] pwm-backlight: Use an optional power supply
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This commit
uses a power-supply regulator, if available, to power up and power down
the panel.
I think that all backlights require a power supply, albeit the supply
may not be SW-controllable. Hence, shouldn't the regulator be mandatory
in the binding, yet the driver be defensively coded such that if one
isn't specified, the driver continues to work?
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
@@ -253,6 +264,16 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
}
}
+ pb-power_supply = devm_regulator_get_optional(pdev-dev, power);
... so I think that should be devm_regulator_get(), since the regulator
isn't really optional.
+ if (IS_ERR(pb-power_supply)) {
+ if (PTR_ERR(pb-power_supply) != -ENODEV) {
+ ret = PTR_ERR(pb-power_supply);
+ goto err_gpio;
+ }
+
+ pb-power_supply = NULL;
If devm_regulator_get_optional() returns an error value or a valid
value, then I don't think that this driver should transmute error values
into NULL; NULL might be a perfectly valid regulator value. Related, I
think the if (pb-power_supply) tests should be replaced with if
(!IS_ERR(pb-power_supply)) instead.
--
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 10/10] pwm-backlight: Allow backlight to remain disabled on boot
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The default for backlight devices is to be enabled immediately when
registering with the backlight core. This can be useful for setups that
use a simple framebuffer device and where the backlight cannot otherwise
be hooked up to the panel.
However, when dealing with more complex setups, such as those of recent
ARM SoCs, this can be problematic. Since the backlight is usually setup
separately from the display controller, the probe order is not usually
deterministic. That can lead to situations where the backlight will be
powered up and the panel will show an uninitialized framebuffer.
Furthermore, subsystems such as DRM have advanced functionality to set
the power mode of a panel. In order to allow such setups to power up the
panel at exactly the right moment, a way is needed to prevent the
backlight core from powering the backlight up automatically when it is
registered.
This commit introduces a new boot_off field in the platform data (and
also implements getting the same information from device tree). When set
the initial backlight power mode will be set to off.
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+ - backlight-boot-off: keep the backlight disabled on boot
A few thoughts:
1) Does this property indicate that:
a) The current state of the backlight at boot. In which case, this will
need bootloader involvement to modify the value in the DT at boot time
based on whether the bootloader turned on the backlight:-(
b) That the driver should not turn on the backlight immediately? That
seems to describe driver behaviour more than HW. Is it appropriate to
put that into DT?
Your suggestion to make the backlight not turn on by default might be a
better fix?
2) Should the driver instead attempt to read the current state of the
GPIO output to determine whether the backlight is on? This may not be
possible on all HW.
3) Doesn't the following code in probe() (added in a previous patch)
need to be updated?
+ if (gpio_is_valid(pb-enable_gpio)) {
+ if (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb-enable_gpio, 0);
+ else
+ gpio_set_value(pb-enable_gpio, 1);
+ }
... That assumes that the backlight is on at boot, and hence presumably
after this patch still always turns on the backlight, only to turn it
off very quickly once the following code in this patch executes:
(and perhaps we also need to avoid turning the backlight off then on if
it was already on at boot)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
@@ -318,6 +320,12 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
}
bl-props.brightness = data-dft_brightness;
+
+ if (data-boot_off)
+ bl-props.power = FB_BLANK_POWERDOWN;
+ else
+ bl-props.power = FB_BLANK_UNBLANK;
--
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 01/10] pwm-backlight: Refactor backlight power on/off
On Tue, Oct 01, 2013 at 12:26:07PM -0600, Stephen Warren wrote:
On 09/23/2013 03:40 PM, Thierry Reding wrote:
In preparation for adding an optional regulator and enable GPIO to the
driver, split the power on and power off sequences into separate
functions to reduce code duplication at the multiple call sites.
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
+static void pwm_backlight_power_off(struct pwm_bl_data *pb)
+{
+ pwm_disable(pb-pwm);
Both the call-sites you're replacing do the following before pwm_disable():
pwm_config(pb-pwm, 0, pb-period);
While I agree that probably shouldn't be necessary, I think it's at
least worth mentioning that in the commit description just to make it
obvious that it was a deliberate change. Splitting that change into a
separate patch might be reasonable in order to keep refactoring and
functional changes separate, although perhaps it's not worth it.
Actually I'll add that back. I'm not sure exactly why I dropped it (it
may just have been oversight) and there have been reports that some HW
actually requires pwm_config(..., 0, ...) before pwm_disable() to turn
off properly.
There are also a couple unrelated whitespace changes thrown in here.
I think they increase readability, but I can certainly move them into a
separate patch.
Thierry
pgpctxOW5l0O1.pgp
Description: PGP signature
Re: [PATCH 05/10] ARM: SAMSUNG: Initialize PWM backlight enable_gpio field
On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
static void __init smdkv210_map_io(void)
@@ -70,6 +70,7 @@ static struct samsung_bl_drvdata samsung_dfl_bl_data
__initdata = {
.max_brightness = 255,
.dft_brightness = 255,
.pwm_period_ns = 78770,
+ .enable_gpio= -1,
.init = samsung_bl_init,
.exit = samsung_bl_exit,
},
@@ -121,6 +122,10 @@ void __init samsung_bl_set(struct samsung_bl_gpio_info
*gpio_info,
samsung_bl_data-lth_brightness = bl_data-lth_brightness;
if (bl_data-pwm_period_ns)
samsung_bl_data-pwm_period_ns = bl_data-pwm_period_ns;
+ if (bl_data-enable_gpio)
+ samsung_bl_data-enable_gpio = bl_data-enable_gpio;
+ if (bl_data-enable_gpio_flags)
+ samsung_bl_data-enable_gpio_flags = bl_data-enable_gpio_flags;
Won't this cause the core pwm_bl driver to request/manipulate the GPIO,
whereas this driver already does that inside the samsung_bl_init/exit
callbacks? I think you either need to adjust those callbacks, or not set
the new standard GPIO property in samsung_bl_data.
I don't think so. The samsung_bl_data is a copy of samsung_dfl_bl_data
augmented by board-specific settings. So in fact copying these values
here is essential to allow boards to override the enable_gpio and flags
fields. Currently no board sets the enable_gpio to a valid GPIO so it's
all still handled by the callbacks only.
Thierry
pgpbvsUk3QTMs.pgp
Description: PGP signature
Re: [PATCH 08/10] pwm-backlight: Use new enable_gpio field
On Tue, Oct 01, 2013 at 12:39:36PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Make use of the new enable_gpio field and allow it to be set from DT as
well. Now that all legacy users of platform data have been converted to
initialize this field to an invalid value, it is safe to use the field
from the driver.
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
Optional properties:
+ - enable-gpios: a list of GPIOs to enable and disable the backlight
That seems to imply that multiple GPIOs are legal. Was that intended? If
not, I would suggest:
- enable-gpios: contains a single GPIO specifier for the GPIO which
enables/disables the backlight. See [1] for the format.
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
+ [1]: Documentation/devicetree/bindings/gpio/gpio.txt
Yes, that sounds better. Indeed only a single GPIO is supported. Adding
more than one would require representing the timing between the two and
that will take us back to where we left off with the power sequences.
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
@@ -51,12 +55,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data
*pb, int brightness,
pb-lth_brightness;
pwm_config(pb-pwm, duty_cycle, pb-period);
+
+ if (gpio_is_valid(pb-enable_gpio)) {
+ if (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb-enable_gpio, 0);
+ else
+ gpio_set_value(pb-enable_gpio, 1);
+ }
Feel completely free to ignore this, but when the difference in two
code-paths is solely in function parameters, I prefer to calculate the
parameter inside the if statement, then call the function outside the
conditional code, to highlight the common/different parts:
int value;
/* or an if statement for the next 1 line, if you don't like ?: */
value = (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW) ? 0 : 1;
gpio_set_value((pb-enable_gpio, value);
I actually tried that, but it looked cluttered, so I opted for the
alternative. Not that this matters all that much, because beginning with
3.13 the GPIO subsystem should be able to handle the active low flag
internally using the new gpiod_*() API. I plan on converting the driver
to use that during the next cycle.
@@ -148,11 +168,10 @@ static int pwm_backlight_parse_dt(struct device *dev,
+ data-enable_gpio = of_get_named_gpio_flags(node, enable-gpios, 0,
+ flags);
+ if (gpio_is_valid(data-enable_gpio) (flags OF_GPIO_ACTIVE_LOW))
+ data-enable_gpio_flags |= PWM_BACKLIGHT_GPIO_ACTIVE_LOW;
This doesn't seem to handle deferred probe correctly; I would expect
something more like:
data-enable_gpio = of_get_named_gpio_flags(...);
if (data-enable_gpio == -EPROBE_DEFERRED)
return data-enable_gpio;
if (gpio_is_valid(...))
...
return 0;
I suppose it's possible that the value filters down to
gpio_request_one() and this actually does work out OK, but that feels
very accidental/implicit to me.
Yes, I think it does indeed propagate to gpio_request_one(), but you're
right, it should be caught explicitly.
Thierry
pgpQ6o_fNIUqu.pgp
Description: PGP signature
Re: [RFC 00/15] Device Tree schemas and validation
On Tue, Oct 1, 2013 at 10:06 AM, Benoit Cousson bcous...@baylibre.com wrote: Hi Rob, On 01/10/2013 15:17, Rob Herring wrote: On 10/01/2013 03:06 AM, Benoit Cousson wrote: + more DT maintainers folks Hi all, I know this is mostly boring user space code, but I was expecting a little bit of comments about at least the bindings syntax:-( I'd like to know if this is the right direction and if it worth pursuing in that direction. The idea was to have at least some base for further discussion during ARM KS 2013. I feel alone :-( If you have any comment, go ahead! Thanks for taking this on! This is interesting approach using the dts syntax, Well, this was discussed a little bit on the list, and it has the big advantage of re-using the parser already included in DTC for free. In term or readability, it avoids to re-defining a brand new syntax for people who are already familiar with the DTS one. but I worry that the validation will only be as good as the schema written and the review of the schema. Well, sure, but unfortunately, that will always be the case :-( The bindings definition being quite open, there is no easy way to ensure proper schema / bindings without careful review of the schema. There is no such thing as a free beer... Unfortunately :-) I think the schema needs to define the binding rather than define the checks. Then the schema can feed the validation checks. This format does not seem to me as easily being able to generate documentation from the schema which I believe is one of the goals. Indeed, but I think is it easy to generate any kind of readable format for the documentation purpose if needed from the actual format. Otherwise, we should consider a schema format based on kerneldoc type of syntax to improve readability. I'm just afraid it will become harder then to define complex schema. BTW, what kind of documentation are you expecting here? Is is a text that can be added on top of each schema? I would expect the schema to replace Documentation/devicetree/bindings/* over time. I think the thing that needs to be worked out here is how to add free form multi-line text. I for one don't care to review the documentation and the schema for every binding. I would like to ensure we can start with the basics and have some generic rules. Some examples: - flag compatible strings in dts files that are not documented This is almost done with the last patch of the series. Nodes are already checked, properties are missing. - check required properties Done as well. - check properties against cell sizes Yeah, that one is still to be done. - a node with reg property must have a unit address Easy to add. - flag properties with _ Easy to add as well. - check properties are the correct data type Already done for a couple of data type. Good to know. It wasn't really clear what common items are checked. An example schema for clocks or gpio (or any other common) binding would be nice. Do you have a run with all the warnings found? Thanks for your comments. Being the very first one, you might get a free beer... meaning there might be such thing as a free beer :-) In that case, it all looks perfect. :) Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] pwm-backlight: Use an optional power supply
On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This commit
uses a power-supply regulator, if available, to power up and power down
the panel.
I think that all backlights require a power supply, albeit the supply
may not be SW-controllable. Hence, shouldn't the regulator be mandatory
in the binding, yet the driver be defensively coded such that if one
isn't specified, the driver continues to work?
That has already changed in my local version of this patch.
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
@@ -253,6 +264,16 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
}
}
+ pb-power_supply = devm_regulator_get_optional(pdev-dev, power);
... so I think that should be devm_regulator_get(), since the regulator
isn't really optional.
+ if (IS_ERR(pb-power_supply)) {
+ if (PTR_ERR(pb-power_supply) != -ENODEV) {
+ ret = PTR_ERR(pb-power_supply);
+ goto err_gpio;
+ }
+
+ pb-power_supply = NULL;
If devm_regulator_get_optional() returns an error value or a valid
value, then I don't think that this driver should transmute error values
into NULL; NULL might be a perfectly valid regulator value. Related, I
think the if (pb-power_supply) tests should be replaced with if
(!IS_ERR(pb-power_supply)) instead.
All of that is already done in my local tree. This actually turns out to
work rather smoothly with the new support for optional regulators. The
regulator core will give you a dummy regulator (assuming it's there
physically but hasn't been wired up in software) that's always on, so
the driver doesn't even have to special case it anymore.
Thierry
pgpMjIbcA3a4c.pgp
Description: PGP signature
Re: [PATCH 05/10] ARM: SAMSUNG: Initialize PWM backlight enable_gpio field
On 10/01/2013 02:43 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this
field needs to be initialized explicitly.
static void __init smdkv210_map_io(void)
@@ -70,6 +70,7 @@ static struct samsung_bl_drvdata
samsung_dfl_bl_data __initdata = { .max_brightness = 255,
.dft_brightness = 255, .pwm_period_ns = 78770, + .enable_gpio
= -1, .init = samsung_bl_init, .exit =
samsung_bl_exit, }, @@ -121,6 +122,10 @@ void __init
samsung_bl_set(struct samsung_bl_gpio_info *gpio_info,
samsung_bl_data-lth_brightness = bl_data-lth_brightness; if
(bl_data-pwm_period_ns) samsung_bl_data-pwm_period_ns =
bl_data-pwm_period_ns; + if (bl_data-enable_gpio) +
samsung_bl_data-enable_gpio = bl_data-enable_gpio; + if
(bl_data-enable_gpio_flags) +
samsung_bl_data-enable_gpio_flags =
bl_data-enable_gpio_flags;
Won't this cause the core pwm_bl driver to request/manipulate the
GPIO, whereas this driver already does that inside the
samsung_bl_init/exit callbacks? I think you either need to adjust
those callbacks, or not set the new standard GPIO property in
samsung_bl_data.
I don't think so. The samsung_bl_data is a copy of
samsung_dfl_bl_data augmented by board-specific settings. So in
fact copying these values here is essential to allow boards to
override the enable_gpio and flags fields. Currently no board sets
the enable_gpio to a valid GPIO so it's all still handled by the
callbacks only.
Oh yes, you're right. I was confusing the new enable_gpio field in
pwm_bl's platform data with some other field in a custom data structure.
One minor point though:
+ if (bl_data-enable_gpio) + samsung_bl_data-enable_gpio =
bl_data-enable_gpio;
That assumes that enable_gpio==0 means none, whereas you've gone to
great pains in the rest of the series to allow 0 to be a valid GPIO
ID. right now, the default value of samsung_bl_data-enable_gpio is
-1, and if !bl_data-enable_gpio, that value won't be propagated across.
--
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 09/10] pwm-backlight: Use an optional power supply
On 10/01/2013 02:53 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This
commit uses a power-supply regulator, if available, to power up
and power down the panel.
I think that all backlights require a power supply, albeit the
supply may not be SW-controllable. Hence, shouldn't the regulator
be mandatory in the binding, yet the driver be defensively coded
such that if one isn't specified, the driver continues to work?
That has already changed in my local version of this patch.
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
@@ -253,6 +264,16 @@ static int pwm_backlight_probe(struct
platform_device *pdev) } }
+ pb-power_supply = devm_regulator_get_optional(pdev-dev,
power);
... so I think that should be devm_regulator_get(), since the
regulator isn't really optional.
+ if (IS_ERR(pb-power_supply)) { + if
(PTR_ERR(pb-power_supply) != -ENODEV) { + ret =
PTR_ERR(pb-power_supply); +goto err_gpio; +
} + +
pb-power_supply = NULL;
If devm_regulator_get_optional() returns an error value or a
valid value, then I don't think that this driver should transmute
error values into NULL; NULL might be a perfectly valid regulator
value. Related, I think the if (pb-power_supply) tests should be
replaced with if (!IS_ERR(pb-power_supply)) instead.
All of that is already done in my local tree. This actually turns
out to work rather smoothly with the new support for optional
regulators. The regulator core will give you a dummy regulator
(assuming it's there physically but hasn't been wired up in
software) that's always on, so the driver doesn't even have to
special case it anymore.
OK, hopefully it (the regulator core) complains about the missing DT
property though; I assume you're using regulator_get() not
regulator_get_optional(), since the supply really is not optional.
--
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 10/10] pwm-backlight: Allow backlight to remain disabled on boot
On Tue, Oct 01, 2013 at 12:50:51PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The default for backlight devices is to be enabled immediately when
registering with the backlight core. This can be useful for setups that
use a simple framebuffer device and where the backlight cannot otherwise
be hooked up to the panel.
However, when dealing with more complex setups, such as those of recent
ARM SoCs, this can be problematic. Since the backlight is usually setup
separately from the display controller, the probe order is not usually
deterministic. That can lead to situations where the backlight will be
powered up and the panel will show an uninitialized framebuffer.
Furthermore, subsystems such as DRM have advanced functionality to set
the power mode of a panel. In order to allow such setups to power up the
panel at exactly the right moment, a way is needed to prevent the
backlight core from powering the backlight up automatically when it is
registered.
This commit introduces a new boot_off field in the platform data (and
also implements getting the same information from device tree). When set
the initial backlight power mode will be set to off.
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+ - backlight-boot-off: keep the backlight disabled on boot
A few thoughts:
1) Does this property indicate that:
a) The current state of the backlight at boot. In which case, this will
need bootloader involvement to modify the value in the DT at boot time
based on whether the bootloader turned on the backlight:-(
I was pretty much following the regulator bindings here. But the meaning
is different indeed, see below.
b) That the driver should not turn on the backlight immediately? That
seems to describe driver behaviour more than HW. Is it appropriate to
put that into DT?
That's what it was supposed to mean. The idea is, and I mentioned that
in the commit message, that when wired up with a higher-level API such
as DRM, then usually that framework knows exactly when to enable the
backlight. Having the backlight enable itself on probe may cause the
panel to light up with no content or garbage.
Your suggestion to make the backlight not turn on by default might be a
better fix?
I think so too, but the problem in this case is that users of this
driver heretofore assumed that it would be turned on by default. I think
that's been common practice for all backlight drivers. Adding a property
to DT was supposed to be a way to keep backwards compatibility with any
existing users while at the same time allowing the backlight to be used
in a more modern system. I don't really have any other ideas how to
achieve this.
It is quite possible that the only reason why turning on the backlight
at probe time is the current default is because backlight_properties'
.power field is by default initialized to 0, which turns out to be the
value of FB_BLANK_UNBLANK. That's been the source of quite a bit of
confusion (I could tell you stories of how people tried to convince me
that there must be a bug in the Linux kernel because writing a 0 to the
backlight's bl_power field in sysfs turns the backlight on instead of
off). The same is true for DPMS modes in DRM and X, where on has the
value 0.
Now there have been plans to overhaul the backlight subsystem for quite
some time. One of the goals was to decouple it from the FB subsystem,
which might help solve this to some degree. At the same time sysfs is an
ABI, so we can't just go and change it randomly. The same is true for
the default behaviour of enabling the backlight at boot. That can
equally be considered an ABI and changing it will cause the majority of
devices to regress, and that's not something that I look forward to
taking the blame for...
2) Should the driver instead attempt to read the current state of the
GPIO output to determine whether the backlight is on? This may not be
possible on all HW.
3) Doesn't the following code in probe() (added in a previous patch)
need to be updated?
+ if (gpio_is_valid(pb-enable_gpio)) {
+ if (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb-enable_gpio, 0);
+ else
+ gpio_set_value(pb-enable_gpio, 1);
+ }
... That assumes that the backlight is on at boot, and hence presumably
after this patch still always turns on the backlight, only to turn it
off very quickly once the following code in this patch executes:
(and perhaps we also need to avoid turning the backlight off then on if
it was already on at boot)
Yes, that's a good point. Depending on the outcome of the above
discussion I'll update this to match the expectations.
Thierry
pgpOKJtRJ_AH6.pgp
Description: PGP signature
Re: [PATCH 05/10] ARM: SAMSUNG: Initialize PWM backlight enable_gpio field
On Tue, Oct 01, 2013 at 02:58:22PM -0600, Stephen Warren wrote:
On 10/01/2013 02:43 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this
field needs to be initialized explicitly.
static void __init smdkv210_map_io(void)
@@ -70,6 +70,7 @@ static struct samsung_bl_drvdata
samsung_dfl_bl_data __initdata = { .max_brightness = 255,
.dft_brightness = 255, .pwm_period_ns = 78770, + .enable_gpio
= -1, .init = samsung_bl_init, .exit =
samsung_bl_exit, }, @@ -121,6 +122,10 @@ void __init
samsung_bl_set(struct samsung_bl_gpio_info *gpio_info,
samsung_bl_data-lth_brightness = bl_data-lth_brightness; if
(bl_data-pwm_period_ns) samsung_bl_data-pwm_period_ns =
bl_data-pwm_period_ns; + if (bl_data-enable_gpio) +
samsung_bl_data-enable_gpio = bl_data-enable_gpio; +if
(bl_data-enable_gpio_flags) +
samsung_bl_data-enable_gpio_flags =
bl_data-enable_gpio_flags;
Won't this cause the core pwm_bl driver to request/manipulate the
GPIO, whereas this driver already does that inside the
samsung_bl_init/exit callbacks? I think you either need to adjust
those callbacks, or not set the new standard GPIO property in
samsung_bl_data.
I don't think so. The samsung_bl_data is a copy of
samsung_dfl_bl_data augmented by board-specific settings. So in
fact copying these values here is essential to allow boards to
override the enable_gpio and flags fields. Currently no board sets
the enable_gpio to a valid GPIO so it's all still handled by the
callbacks only.
Oh yes, you're right. I was confusing the new enable_gpio field in
pwm_bl's platform data with some other field in a custom data structure.
One minor point though:
+ if (bl_data-enable_gpio) + samsung_bl_data-enable_gpio =
bl_data-enable_gpio;
That assumes that enable_gpio==0 means none, whereas you've gone to
great pains in the rest of the series to allow 0 to be a valid GPIO
ID. right now, the default value of samsung_bl_data-enable_gpio is
-1, and if !bl_data-enable_gpio, that value won't be propagated across.
Right, that check should now be:
if (bl_data-enable_gpio = 0)
Well, it depends. It would be possible for the default to specify a
valid GPIO and for a board to override it with -1 (and provide a set of
corresponding callbacks). In that case the right thing to do here would
be not to check at all.
Then again, I don't think that will ever happen, because no fixed GPIO
will ever be a good default. So changing to = 0 instead of != 0 should
work fine.
Again, starting with 3.13 this should become a lot easier to handle
since the GPIO subsystem will gain functionality to use a per-board
lookup table, similarly to what the regulator and PWM subsystems do.
Once that's in place I plan to make another pass over all users of the
pwm-backlight driver and replace the enable_gpio field with a GPIO
lookup table, so that the driver can uniformly request them using a
simple gpiod_get().
Thierry
pgp6CLx44qy6C.pgp
Description: PGP signature
Re: [PATCH 09/10] pwm-backlight: Use an optional power supply
On Tue, Oct 01, 2013 at 02:59:43PM -0600, Stephen Warren wrote:
On 10/01/2013 02:53 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This
commit uses a power-supply regulator, if available, to power up
and power down the panel.
I think that all backlights require a power supply, albeit the
supply may not be SW-controllable. Hence, shouldn't the regulator
be mandatory in the binding, yet the driver be defensively coded
such that if one isn't specified, the driver continues to work?
That has already changed in my local version of this patch.
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
@@ -253,6 +264,16 @@ static int pwm_backlight_probe(struct
platform_device *pdev) } }
+ pb-power_supply = devm_regulator_get_optional(pdev-dev,
power);
... so I think that should be devm_regulator_get(), since the
regulator isn't really optional.
+ if (IS_ERR(pb-power_supply)) { + if
(PTR_ERR(pb-power_supply) != -ENODEV) { +ret =
PTR_ERR(pb-power_supply); + goto err_gpio; +
} + +
pb-power_supply = NULL;
If devm_regulator_get_optional() returns an error value or a
valid value, then I don't think that this driver should transmute
error values into NULL; NULL might be a perfectly valid regulator
value. Related, I think the if (pb-power_supply) tests should be
replaced with if (!IS_ERR(pb-power_supply)) instead.
All of that is already done in my local tree. This actually turns
out to work rather smoothly with the new support for optional
regulators. The regulator core will give you a dummy regulator
(assuming it's there physically but hasn't been wired up in
software) that's always on, so the driver doesn't even have to
special case it anymore.
OK, hopefully it (the regulator core) complains about the missing DT
property though; I assume you're using regulator_get() not
regulator_get_optional(), since the supply really is not optional.
It doesn't always. There's a pr_warn() in _regulator_get(), but that's
only for non-DT (since for DT, has_full_constraints is set to true in
regulator_init_complete()). Actually that would mean that the regulator
core will complain as long as init isn't complete. But since, like many
other drivers, pwm-backlight could use deferred probing it's likely to
end up being probed after init.
Cc'ing Mark Brown.
Thierry
pgpqgdHYE7QEt.pgp
Description: PGP signature
Re: [PATCH] ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT
Hi,
Any comments about the below patch? If my analysis is correct, this issue
needs to be fixed before any boards that set ONENAND_SYNC_READWRITE can
be converted to DT. So the fix should be applied preferably during the
current rc-cycle.
A.
On Fri, Sep 20, 2013 at 11:01:06PM +0300, Aaro Koskinen wrote:
With DT-based boot, the GPMC OneNAND sync mode setup does not work
correctly. During the async mode setup, sync flags gets incorrectly
set in the onenand_async data and the system crashes during the async
setup. Also, the sync mode never gets set in gpmc_onenand_data-flags, so
even without the crash, the actual sync mode setup would never be called.
The patch fixes this by adjusting the gpmc_onenand_data-flags when the
data is read from the DT. Also while doing this we force the onenand_async
to be always async.
The patch enables to use the following DTS chunk (that should correspond
the arch/arm/mach-omap2/board-rm680.c board file setup) with Nokia N950,
which currently crashes with 3.12-rc1. The crash output can be also
found below.
gpmc {
ranges = 0 0 0x0400 0x2000;
onenand@0,0 {
#address-cells = 1;
#size-cells = 1;
reg = 0 0 0x2000;
gpmc,sync-read;
gpmc,sync-write;
gpmc,burst-length = 16;
gpmc,burst-read;
gpmc,burst-wrap;
gpmc,burst-write;
gpmc,device-width = 2;
gpmc,mux-add-data = 2;
gpmc,cs-on-ns = 0;
gpmc,cs-rd-off-ns = 87;
gpmc,cs-wr-off-ns = 87;
gpmc,adv-on-ns = 0;
gpmc,adv-rd-off-ns = 10;
gpmc,adv-wr-off-ns = 10;
gpmc,oe-on-ns = 15;
gpmc,oe-off-ns = 87;
gpmc,we-on-ns = 0;
gpmc,we-off-ns = 87;
gpmc,rd-cycle-ns = 112;
gpmc,wr-cycle-ns = 112;
gpmc,access-ns = 81;
gpmc,page-burst-access-ns = 15;
gpmc,bus-turnaround-ns = 0;
gpmc,cycle2cycle-delay-ns = 0;
gpmc,wait-monitoring-ns = 0;
gpmc,clk-activation-ns = 5;
gpmc,wr-data-mux-bus-ns = 30;
gpmc,wr-access-ns = 81;
gpmc,sync-clk-ps = 15000;
};
};
[1.467559] GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
[1.474822] GPMC CS0: cs_rd_off : 1 ticks, 5 ns (was 24 ticks) 5 ns
[1.482116] GPMC CS0: cs_wr_off : 14 ticks, 71 ns (was 24 ticks) 71 ns
[1.489349] GPMC CS0: adv_on: 0 ticks, 0 ns (was 0 ticks) 0 ns
[1.496582] GPMC CS0: adv_rd_off: 3 ticks, 15 ns (was 3 ticks) 15 ns
[1.503845] GPMC CS0: adv_wr_off: 3 ticks, 15 ns (was 3 ticks) 15 ns
[1.511077] GPMC CS0: oe_on : 3 ticks, 15 ns (was 4 ticks) 15 ns
[1.518310] GPMC CS0: oe_off: 1 ticks, 5 ns (was 24 ticks) 5 ns
[1.525543] GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
[1.532806] GPMC CS0: we_off: 8 ticks, 40 ns (was 24 ticks) 40 ns
[1.540039] GPMC CS0: rd_cycle : 4 ticks, 20 ns (was 29 ticks) 20 ns
[1.547302] GPMC CS0: wr_cycle : 4 ticks, 20 ns (was 29 ticks) 20 ns
[1.554504] GPMC CS0: access: 0 ticks, 0 ns (was 23 ticks) 0 ns
[1.561767] GPMC CS0: page_burst_access: 0 ticks, 0 ns (was 3 ticks)
0 ns
[1.569641] GPMC CS0: bus_turnaround: 0 ticks, 0 ns (was 0 ticks)
0 ns
[1.577270] GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks)
0 ns
[1.585144] GPMC CS0: wait_monitoring: 0 ticks, 0 ns (was 0 ticks)
0 ns
[1.592834] GPMC CS0: clk_activation: 0 ticks, 0 ns (was 0 ticks)
0 ns
[1.600463] GPMC CS0: wr_data_mux_bus: 5 ticks, 25 ns (was 8 ticks)
25 ns
[1.608154] GPMC CS0: wr_access : 0 ticks, 0 ns (was 23 ticks) 0 ns
[1.615386] GPMC CS0 CLK period is 5 ns (div 1)
[1.625122] Unhandled fault: external abort on non-linefetch (0x1008) at
0xf009e442
[1.633178] Internal error: : 1008 [#1] ARM
[1.637573] Modules linked in:
[1.640777] CPU: 0 PID: 1 Comm: swapper Not tainted
3.12.0-rc1-n9xx-los.git-5318619-6-g4baa700-dirty #26
[1.651123] task: ef04c000 ti: ef05 task.ti: ef05
[1.656799] PC is at gpmc_onenand_setup+0x98/0x1e0
[1.661865] LR is at gpmc_cs_set_timings+0x494/0x5a4
[1.667083] pc : [c002e040]lr : [c001f384]psr: 6113
[1.667083] sp : ef051d10 ip : ef051ce0 fp : ef051d94
[1.679138] r10: c0caaf60 r9 : ef05 r8 : ef18b32c
[1.684631] r7 : f008 r6 : c0caaf60 r5 : r4 : f009e400
[1.691497] r3 : f009e442 r2 : 8005 r1 : 0014 r0 :
[1.698333] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[1.706024] Control: 10c5387d Table: af290019 DAC:
Re: [RFC 00/15] Device Tree schemas and validation
On 09/24/2013 10:52 AM, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
Sorry, this is probably going to sound a bit negative. Hopefully you
find it constructive though.
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
I'm not convinced that's a good decision.
DT is a language for representing data.
The validation checks described by schemas are rules, or code, and not
static data.
So, while I'm sure it's possible to shoe-horn at least some reasonable
subset of DT validation into DT syntax itself, I feel it's unlikely to
yield something that's scalable enough.
For example, it's easy to specify that a property must be 2 cells long.
What if it could be any multiple of two? That's a lot of numbers to
explicitly enumerate as data. Sure, you can then invent syntax to
represent that specific rule (parameterized by 2), but what about the
next similar-but-different rule? The only approach I can think of to
that is to allow the schema to contain arbitrary expressions, which
would likely need to morph into arbitary statements not just
expressions. Once you're there, I think the schema would be better
represented as a programming language rather than as a data structure
that could have code hooked into it.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the compatible properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
...
To write a schema which will validate OMAP Timers like the one above,
one may write the following schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
What about DT nodes that don't have a compatible value? We certainly
have some of those already like /memory and /chosen. We should be able
to validate their schema too. This probably doesn't invalidate being
able to look things up by compatible value though; it just means we need
some additional mechanisms too.
* Define constraints on properties
To define constraints on a property one has to create a node in a schema
which has as name the name of the property that one want to validate.
To specify constraints on the property ti,hwmods of OMAP Timers one
can write this schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
...
};
compatible and ti,hwmods are both properties in the DT file. However, in
the schema above, one appears as a property, and one as a node. I don't
like that inconsistency. It'd be better if compatible was a node too.
If one want to use a regular as property name one can write this schema:
/dts-v1/;
/ {
compatible = abc;
def {
name = def[0-9];
Isn't it valid to have a property named name within the node itself?
How do you differentiate between specifying the node name and the name
property?
What if the node name needs more validation than just a regex. For
example, suppose we want to validate the
unit-name-must-match-reg-address rule. We need to write some complex
expression using data extracted from reg to calculate the unit address.
Equally, the node name perhaps has to exist in some global list of
acceptable node names. It would be extremely tricky if not impossible to
do that with a regex.
...
};
};
Above one can see that the name property override the node name.
Override implies that dtc would change the node name during compilation.
I think s/override/validate/ or s/override/overrides the validation
rules for/?
* Require the presence of a property inside a node or inside one of its
parents
...
/dts-v1/;
/ {
compatible = ti,twl[0-9]+-rtc;
interrupt-controller {
is-required;
can-be-inherited;
interrupt-controller isn't a good example here, since it isn't a
property that would typically be inherited. Why not use interrupt-parent
instead?
One can check if 'node' has the following subnode 'subnode1', 'subnode2',
and 'abc' with the schema below:
/dts-v1/;
/ {
compatible = comp;
children = abc, subnode[0-9];
};
How is the schema for each sub-node specified?
What if some nodes are optional and some required? The conditions where
a sub-node is required might be complex, and I think we'd always want to
be able to represent them in whatever schema language we chose.
The most obvious way would be to
Re: [PATCH 0/7] DRA7: DT thermal support
On 14:32-20131001, Eduardo Valentin wrote: Hello all, This is a complementary patch series with themal DT support for DRA7. Although this work depends on the thermal dt parser work [1], I decided to share it before hand. It also depends on DRA7 DT base port support, which I fetched from Rajendra's tree [2]. This patch series has been runtime tested on DRA7-evm. All best, [1] - https://lkml.org/lkml/2013/9/26/787 [2] - git://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v3 Eduardo Valentin (7): arm: dts: add dra7 DSPEVE thermal data arm: dts: add dra7 IVA thermal data arm: dts: dra7: add bandgap entry arm: dts: add cooling properties on dra7 cpu node arm: dts: dra7: add thermal data arm: dts: add tmp102 i2c sensor node on dra7-evm arm: dts: add thermal zones info on tmp102 for DRA7-EVM arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 28 arch/arm/boot/dts/dra7-evm.dts | 23 +++ arch/arm/boot/dts/dra7-iva-thermal.dtsi| 28 arch/arm/boot/dts/dra7.dtsi| 27 ++- 4 files changed, 105 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi +Benoit, Tony, Linux-omap. Ref: http://marc.info/?l=linux-pmm=138065243027014w=2 Tony, Benoit, The following diff[1] is probably needed to ensure that right audience is addressed. Eduardo, could you send an updated series with Tony, Benoit and linux-omap in the loop? [1] diff --git a/MAINTAINERS b/MAINTAINERS index 284969f..3442671 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5969,6 +5969,7 @@ M:Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org S: Maintained +F: arch/arm/boot/dts/*dra7* F: arch/arm/boot/dts/*omap* F: arch/arm/boot/dts/*am3* -- 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 0/7] DRA7: DT thermal support
On 01-10-2013 18:58, Nishanth Menon wrote: On 14:32-20131001, Eduardo Valentin wrote: Hello all, This is a complementary patch series with themal DT support for DRA7. Although this work depends on the thermal dt parser work [1], I decided to share it before hand. It also depends on DRA7 DT base port support, which I fetched from Rajendra's tree [2]. This patch series has been runtime tested on DRA7-evm. All best, [1] - https://lkml.org/lkml/2013/9/26/787 [2] - git://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v3 Eduardo Valentin (7): arm: dts: add dra7 DSPEVE thermal data arm: dts: add dra7 IVA thermal data arm: dts: dra7: add bandgap entry arm: dts: add cooling properties on dra7 cpu node arm: dts: dra7: add thermal data arm: dts: add tmp102 i2c sensor node on dra7-evm arm: dts: add thermal zones info on tmp102 for DRA7-EVM arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 28 arch/arm/boot/dts/dra7-evm.dts | 23 +++ arch/arm/boot/dts/dra7-iva-thermal.dtsi| 28 arch/arm/boot/dts/dra7.dtsi| 27 ++- 4 files changed, 105 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi +Benoit, Tony, Linux-omap. Ref: http://marc.info/?l=linux-pmm=138065243027014w=2 Tony, Benoit, The following diff[1] is probably needed to ensure that right audience is addressed. Well, yeah. thinking of this series now I probably should have mentioned clear that it is not ready for merge. Not only because it depends on a working in progress I have referred at [1], but because we lack completely dra7 files (at linus tree we have no files under arch/arm/boot/dts/*dra7*). Therefore, I mentioned in this cover letter that I actually based this work on top of [2] and [1]. Apologies if it was not clear enough for you. Just to make clear, the intention of this patch set was to share and use yet another example of the usage of the work at [1]. Thus the audience was directed to the cc and to lists I used. Eduardo, could you send an updated series with Tony, Benoit and linux-omap in the loop? Well sure, once it has the right dependency in place. [1] diff --git a/MAINTAINERS b/MAINTAINERS index 284969f..3442671 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5969,6 +5969,7 @@ M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org S: Maintained +F: arch/arm/boot/dts/*dra7* I believe, once we have them merged, then I suppose this diff is applicable. F: arch/arm/boot/dts/*omap* F: arch/arm/boot/dts/*am3* -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
