Re: [PATCH V2 0/2] OMAPDSS: DISPC: Peformance improvement of DISPC Scaling
On Mon, 2011-12-19 at 14:03 +0530, Chandrabhanu Mahapatra wrote: Hi everyone, the following patch set directs to improve the scaling performance of DISPC module which consists of two pacthes. The first patch is based on code of Lajos Molnar la...@ti.com from Android Kernel, which updates the code with new set of coefficients to improve the scaling performance. The second patch is based on some very valuable suggestions by Sebastien Fagard s-fag...@ti.com and directs to modify the clock requirements for scaling to support OMAP4 and avoid clock failure issues. I have tested these patches on OMAP2, OMAP3 AND OMAP4. To test on 2430SDP board I have created a patch to enable the display which will follow later. All your comments and suggestions are welcome. Thanks, this looks good. Applied to DSS master branch. There was a minor conflict with the Makefile, but I fixed that. Btw, when doing new versions of a patch series, it would be good to have a short history of the series in the introduction email, so that the reviewers can easily see what's new in each version. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] OMAP: DSS2: Support for UMSH-8173MD TFT panel
Hi, On Fri, 2011-12-16 at 18:30 +0100, Daniel Mack wrote: Signed-off-by: Daniel Mack zon...@gmail.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de --- v2 is a resent with .power_on_delay and .acb values corrected. The code itself is fine, but please provide a commit description. Patches should always have a commit description, even if the patch is trivial and the desc would be more or less the same as the subject. Tomi signature.asc Description: This is a digitally signed message part
[PATCH v2 1/2] OMAPDSS: HDMI: Move duplicate code from boardfile
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c | 23 +++
include/video/omapdss.h|2 ++
4 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73b1e99..c3bd640 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -595,20 +595,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static void sdp4430_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
@@ -838,9 +824,9 @@ static void omap_4430sdp_display_init(void)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
sdp4430_lcd_init();
- sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
+ omap_hdmi_init();
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a5b576b..d95df2e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -478,21 +478,6 @@ int __init omap4_panda_dvi_init(void)
return r;
}
-
-static void omap4_panda_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
@@ -555,8 +540,8 @@ void omap4_panda_display_init(void)
if (r)
pr_err(error initializing panda DVI\n);
- omap4_panda_hdmi_mux_init();
omap_display_init(omap4_panda_dss_data);
+ omap_hdmi_init();
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index dce9905..8436088 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -29,6 +29,7 @@
#include plat/omap-pm.h
#include plat/common.h
+#include mux.h
#include control.h
#include display.h
@@ -96,6 +97,20 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static void omap4_hdmi_mux_pads()
+{
+ /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
+ omap_mux_init_signal(hdmi_hpd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_cec,
+ OMAP_PIN_INPUT_PULLUP);
+ /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
+ omap_mux_init_signal(hdmi_ddc_scl,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_ddc_sda,
+ OMAP_PIN_INPUT_PULLUP);
+}
+
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift;
@@ -129,6 +144,14 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
+int omap_hdmi_init(void)
+{
+ if (cpu_is_omap44xx())
+ omap4_hdmi_mux_pads();
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
if (cpu_is_omap44xx())
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 378c7ed..0cb0469 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -309,6 +309,8 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+/* HDMI mux init*/
+extern int omap_hdmi_init(void);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe
[PATCH v3 2/2] OMAPDSS: HDMI: Disable DDC internal pull up
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are external pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|9 -
arch/arm/mach-omap2/board-omap4panda.c | 10 +-
arch/arm/mach-omap2/display.c | 22 +++---
include/video/omapdss.h|6 +-
4 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c3bd640..4af874a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -826,7 +826,14 @@ static void omap_4430sdp_display_init(void)
sdp4430_lcd_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
- omap_hdmi_init();
+ /*
+* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
+* later have external pull up on the HDMI I2C lines
+*/
+ if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
+ omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d95df2e..00103e3 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -541,7 +541,15 @@ void omap4_panda_display_init(void)
pr_err(error initializing panda DVI\n);
omap_display_init(omap4_panda_dss_data);
- omap_hdmi_init();
+
+ /*
+* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
+* later have external pull up on the HDMI I2C lines
+*/
+ if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
+ omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 8436088..ffd9bd9 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -97,8 +97,11 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
-static void omap4_hdmi_mux_pads()
+static void omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
{
+ u32 reg;
+ u16 control_i2c_1;
+
/* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
omap_mux_init_signal(hdmi_hpd,
OMAP_PIN_INPUT_PULLUP);
@@ -109,6 +112,19 @@ static void omap4_hdmi_mux_pads()
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
OMAP_PIN_INPUT_PULLUP);
+
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor.
+*/
+ if (flags OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP) {
+ control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
+ reg = omap4_ctrl_pad_readl(control_i2c_1);
+ reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
+ OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
+ omap4_ctrl_pad_writel(reg, control_i2c_1);
+ }
}
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
@@ -144,10 +160,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
-int omap_hdmi_init(void)
+int omap_hdmi_init(enum omap_hdmi_flags flags)
{
if (cpu_is_omap44xx())
- omap4_hdmi_mux_pads();
+ omap4_hdmi_mux_pads(flags);
return 0;
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 0cb0469..05da097 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -200,6 +200,10 @@ enum omap_dss_clk_source {
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI,/* OMAP4: PLL2_CLK2 */
};
+enum omap_hdmi_flags {
+ OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 0,
+};
+
/* RFBI */
struct rfbi_timings {
@@ -310,7 +314,7 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
/* HDMI mux init*/
-extern int omap_hdmi_init(void);
+extern int omap_hdmi_init(enum omap_hdmi_flags flags);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.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 v3 2/2] OMAPDSS: HDMI: Disable DDC internal pull up
On Tue, 2011-12-20 at 14:08 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are external pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
Signed-off-by: Mythri P K mythr...@ti.com
snip
struct rfbi_timings {
@@ -310,7 +314,7 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
/* HDMI mux init*/
-extern int omap_hdmi_init(void);
+extern int omap_hdmi_init(enum omap_hdmi_flags flags);
These patches you sent are broken. You add the omap_hdmi_init line in
the previous patch, and change it here, but the lines are different
(this one has two spaces between int and omap_hdmi_init, and the
previous doesn't) so the patches cannot be applied.
I guess you hand edited them, or did something else manually. Never do
that. Use git rebase or similar methods to edit the patches, and create
the whole patch set with git-format-patch in one go.
If you absolutely have to edit the patch files, apply them to your git
tree afterwards and use git-format-patch to create the patch series
before sending.
And an introductory email with version history would be nice also.
Tomi
signature.asc
Description: This is a digitally signed message part
[RFC PATCH] arm:omap:omap4: Remove hardcoded reg-offs for PWRSTCTRL PWRSTST
PRM module in AM33XX is closer to OMAP4 PRM module, so it makes complete
sense to reuse all the code from existing OMAP4 implementation.
Having said that, ther is a catch here with respect to AM33XX device,
The register offset in PRM module is not consistent
across (crazy IP integration), for example,
PRM_XXX PWRSTCTRL PWRSTST RSTCTRL RSTST
===
PRM_PER_MOD:0x0C, 0x08, 0x00, 0x04
PRM_WKUP_MOD: 0x04, 0x08, 0x00, 0x0C
PRM_MPU_MOD:0x00, 0x04, 0x08, NA
PRM_DEVICE_MOD: NA, NA, 0x00, 0x08
So in order to reuse the existing OMAP4 code, we have to add
separate entry for register offsets, especially
PWRSTCTRL PWRSTST.
This patch removes the existing hard-coded way of providing
offset to omap4_prminst_xxx API's and instead use offsets
provided in powerdomains_data.
This patch has been boot tested on AM/DM37x, OMAP4-Panda and AM335XEVM
platform.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c| 26 +-
arch/arm/mach-omap2/powerdomain.h |4
arch/arm/mach-omap2/powerdomain44xx.c | 24
arch/arm/mach-omap2/powerdomains44xx_data.c |8
arch/arm/mach-omap2/prcm44xx.h |4 +++-
arch/arm/mach-omap2/prminst44xx.c | 11 ++-
6 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..4fd53d4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1288,14 +1288,14 @@ static int _assert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
- ohri.rst_shift);
- else if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx() || cpu_is_am33xx())
return omap4_prminst_assert_hardreset(ohri.rst_shift,
oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
oh-prcm.omap4.rstctrl_offs);
+ else if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
+ ohri.rst_shift);
else
return -EINVAL;
}
@@ -1322,11 +1322,7 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
- ohri.rst_shift,
- ohri.st_shift);
- } else if (cpu_is_omap44xx()) {
+ if (cpu_is_omap44xx() || cpu_is_am33xx()) {
if (ohri.st_shift)
pr_err(omap_hwmod: %s: %s: hwmod data error: OMAP4
does not support st_shift\n,
oh-name, name);
@@ -1334,6 +1330,10 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
oh-prcm.omap4.rstctrl_offs);
+ } else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
+ ohri.rst_shift,
+ ohri.st_shift);
} else {
return -EINVAL;
}
@@ -1364,14 +1364,14 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- return
omap2_prm_is_hardreset_asserted(oh-prcm.omap2.module_offs,
- ohri.st_shift);
- } else if (cpu_is_omap44xx()) {
+ if (cpu_is_omap44xx() || cpu_is_am33xx()) {
return omap4_prminst_is_hardreset_asserted(ohri.rst_shift,
oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
oh-prcm.omap4.rstctrl_offs);
+ } else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ return
omap2_prm_is_hardreset_asserted(oh-prcm.omap2.module_offs,
+ ohri.st_shift);
[PATCH] mmc: omap: remove clock rate hard coding
From: Balaji TK balaj...@ti.com
MMC master clock rate can vary for each instance of the MMC controller
on the device. Use clk_get_rate instead to get the value.
Signed-off-by: Balaji TK balaj...@ti.com
Reviewed-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d5fe43d..5b35c7e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -120,7 +120,6 @@
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20
-#define OMAP_MMC_MASTER_CLOCK 9600
#define OMAP_MMC_MIN_CLOCK 40
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
@@ -598,12 +597,12 @@ static void omap_hsmmc_disable_irq(struct omap_hsmmc_host
*host)
}
/* Calculate divisor for the given clock frequency */
-static u16 calc_divisor(struct mmc_ios *ios)
+static u16 calc_divisor(struct omap_hsmmc_host *host, struct mmc_ios *ios)
{
u16 dsor = 0;
if (ios-clock) {
- dsor = DIV_ROUND_UP(OMAP_MMC_MASTER_CLOCK, ios-clock);
+ dsor = DIV_ROUND_UP(clk_get_rate(host-fclk), ios-clock);
if (dsor 250)
dsor = 250;
}
@@ -623,7 +622,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(ios) 6) | (DTO 16);
+ regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
--
1.7.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] mmc: omap: remove clock rate hard coding
On Tue, Dec 20, 2011 at 3:12 PM, Venkatraman S svenk...@ti.com wrote: From: Balaji TK balaj...@ti.com MMC master clock rate can vary for each instance of the MMC controller on the device. Use clk_get_rate instead to get the value. Signed-off-by: Balaji TK balaj...@ti.com Reviewed-by: Venkatraman S svenk...@ti.com --- Finally. Feel free to add if you need one Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] OMAP: DSS2: Support for UMSH-8173MD TFT panel
This patch adds support for Microtip Technologies' UMSH-8173MD 800x480
RGB TFT panel. Tested with an OMAP3 board.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 519c47d..cbcf164 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -297,6 +297,31 @@ static struct panel_config generic_dpi_panels[] = {
.name = apollon,
},
+
+ /* Microtips Technologies - UMSH-8173MD */
+ {
+ {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock= 34560,
+
+ .hsw= 13,
+ .hfp= 101,
+ .hbp= 101,
+
+ .vsw= 23,
+ .vfp= 1,
+ .vbp= 1,
+ },
+ .acbi = 0x0,
+ .acb= 0x0,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC,
+ .power_on_delay = 0,
+ .power_off_delay= 0,
+ .name = UMSH-8173MD,
+ },
};
struct panel_drv_data {
--
1.7.7.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] ARM: OMAP: avoid NULL pointer dereference when no PMIC is configured
Hi Igor,
On 12/19/2011 09:10 AM, Igor Grinberg wrote:
On 12/18/11 21:13, Daniel Mack wrote:
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/vp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 66bd700..5407173 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -41,6 +41,11 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
u32 val, sys_clk_rate, timeout, waittime;
u32 vddmin, vddmax, vstepmin, vstepmax;
+if (!voltdm-pmic) {
+pr_err(%s: No PMIC configured.\n, __func__, voltdm-name);
You are passing two parameters to pr_err(), but use only one...
Of course not. I wonder why the compiler didn't yell at me about that.
Also, I don't know if this is the right thing to do here,
so Cc'ed Paul and Kevin.
That is the other question ideed. In the case I was facing on a custom
board, I was running into this without any configured PMIC. Clearly,
derferencing a NULL pointer here is no good thing to do.
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 v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR
On Tuesday 20 December 2011 04:31 AM, Rob Herring wrote: On 12/19/2011 08:05 AM, Aneesh V wrote: This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller. The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future. The second patch provides the bindings for the EMIF controller. The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards. Thanks to Rajendra for answering my numerous queries on device tree. This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version. There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data. Thanks for pointing this out. I looked into this a bit. I see some difficulties in adopting SPD for our needs. 1. Our primary target is LPDDR2 and I can't seem to find an SPD standard for LPDDR2. Maybe, because automatic memory detection is not that critical in the embedded world. 2. I did find one for DDR SDRAM memories(Appendix D, Rev 1.0 - maybe for the first generation of PC DDR memories). But many of the AC timing parameters needed to program our controller are not listed in it. 3. We do not really need DDR3 support at the moment because we do not intend to scale DDR frequency in platforms with DDR3 memory. This is due the to limited operating frequency range of DDR3. So, I was wondering whether I should limit the binding to only LPDDR2 and have an SPD based binding for DDR2/DDR3 if that is required later? What do you think? In general, is it really feasible to parse the DTB before DDR is initialized? As pointed out by Tony we rely on bootloader for the initial SDRAM configuration. The kernel SDRAM controller driver is used mainly for DVFS and thermal management. best regards, Aneesh -- 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 v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR
On Tuesday 20 December 2011 05:05 AM, Tony Lindgren wrote: * Rob Herringrobherri...@gmail.com [111219 14:29]: On 12/19/2011 08:05 AM, Aneesh V wrote: This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller. The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future. The second patch provides the bindings for the EMIF controller. The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards. Thanks to Rajendra for answering my numerous queries on device tree. This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version. There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data. I agree generic JEDEC standard would be good for the DT. Please see my comments in reply to Rob's mail. SPD doesn't seems to have a standard for LPDDR2. What JEDEC has now is not suitable for our needs. In general, is it really feasible to parse the DTB before DDR is initialized? Changing timings is still needed for DVFS during runtime. But we can boot to userspace with bootloader set timings, so I'm As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space. thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like: .compatible = ti,omap3630, sdram-micron-mt46h32m32lf-6; And that should allow the SDRC driver to only accept timings for sdram-micron-mt46h32m32lf-6. Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right? br, Aneesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] usb: renesas: gadget: use generic map/unmap routines
Hi,
On Mon, Dec 19, 2011 at 05:46:56PM -0800, Kuninori Morimoto wrote:
I tried this patch, but renesas_usbhs didn't work.
It seems have some bugs.
1. renesas_usbhs dma needs pkt-dma, but this patch didn't care it.
2. dma direction seems wrong
(dir needs 0/1, not DMA_xxx_DEVICE for usb_gadget_xx_request())
And, renesas_usbhs can not use scatter/gather type dma
#
# this is not super important, but
#
# int usb_gadget_map_request(struct usb_gadget *gadget,
# struct usb_request *req, int direction)
#
# this direction = 0/1 is a little bit un-understandable for me.
# it is difficult to understand which direction ? from code.
# if direction = DMA_TO_DEVICE/DMA_FROM_DEVICE, it is understandable ;P
I see. The thing is that we want usb_gadget_map/unmap_request() to
handle that. In the long run, we might want to have a direction flag on
the public struct usb_request and remove this extra parameter, but I'm
still considering that :-)
Can you please add below fix patch ?
thanks, will do as soon as you fix below :-)
diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
b/drivers/usb/renesas_usbhs/mod_gadget.c
index cb92a1d..c467067 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -173,15 +173,32 @@ static int usbhsg_dma_map_ctrl(struct usbhs_pkt *pkt,
int map)
struct usbhsg_uep *uep = usbhsg_pipe_to_uep(pipe);
struct usbhsg_gpriv *gpriv = usbhsg_uep_to_gpriv(uep);
enum dma_data_direction dir;
+ int ret;
- dir = usbhs_pipe_is_dir_in(pipe) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+ dir = !usbhs_pipe_is_dir_in(pipe);
if (map) {
- return usb_gadget_map_request(gpriv-gadget, req, dir);
+ if (req-num_sgs) /* it can not use scatter/gather */
+ return -EIO;
it would be better to through a big fat WARN() in this case. Gadget
drivers are supposed to check whether you support SGs (by looking into
gadget-sg_suported) before giving you a request with SGs.
+ if (pkt-dma != DMA_ADDR_INVALID)
+ return -EIO;
no no, we want to remove the whole DMA_ADDR_INVALID thing. What we're
doing now is that UDC is required to map the request buffer. So gadget
drivers must not do it. We shouldn't have this DMA_ADDR_INVALID macro
anymore :-)
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH] AM35xx: disable checking for reserved feature bits
-Original Message- From: Hilman, Kevin Sent: Saturday, December 10, 2011 6:51 AM To: Tony Lindgren Cc: Ilya Yanok; linux-omap@vger.kernel.org; w...@denx.de; d...@denx.de; sash...@emcraft.com; Hiremath, Vaibhav Subject: Re: [PATCH] AM35xx: disable checking for reserved feature bits Tony Lindgren t...@atomide.com writes: [...] This feature selection mechanism is clearly not scaling to newer SoCs. While this patch works around the problem, IMO, we need a more scalable solution. Agreed. snip This should be coordinated with the splitting of feature detection as posted by Vaibhave in thread [RFC PATCH] arm:omap: cleanup split omap2/3/4_check_revision function thread. Vaibhav, Feel free to take my proposed patch and develop it further and include it in your rework of the SoC/feature detection. Kevin, I spend some time on this, and I think it is not possible to use HWMOD Entries for feature check. Reason being, - The whole revision story is built upon howkeye and silicon rev. And both remains same for different devices in same family, For example, omap3430, omap3503 and omap3515 (for that matter all AM37x) all will have same howkeye and silicon revision no. Also, in the kernel we have something like. # define cpu_is_omap3515() (cpu_is_omap3430()\ (!omap3_has_iva())\ (omap3_has_sgx())) # define cpu_is_omap3525() (cpu_is_omap3430()\ (!omap3_has_sgx())\ (omap3_has_iva())) Which means, you can not do IP detection before check_feature function. - The current omap_hwmod__data.c uses silicon version alone and only differentiate between silicon versions. We do not differentiate between different family of devices while registering hwmod data. So the conclusion is, we have to stick to check_feature function. Thanks, Vaibhav 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 1/3] usb: musb: fix pm_runtime mismatches
On Mon, Dec 19, 2011 at 10:20:09PM +0200, Felipe Contreras wrote: On Mon, Dec 19, 2011 at 10:11 AM, Felipe Balbi ba...@ti.com wrote: On Fri, Dec 16, 2011 at 01:05:08AM +0200, Felipe Contreras wrote: Properly call pm_runtime_put() afer pm_runttime_get() on errors. Untested. sorry, but I'm not applying untested patches. I need someone to give a Tested-by. I'm pretty sure most people don't test the exit paths, but fine, don't apply them. Who needs power management anyway. if it wasn't tested you can't claim $SUBJECT makes PM magically work. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: musb: fix pm_runtime mismatch
On Mon, Dec 19, 2011 at 10:01:54PM +0200, Felipe Contreras wrote: From: Felipe Contreras felipe.contre...@gmail.com In musb_init_controller() there's a pm_runtime_put(), but there's no pm_runtime_get(), which creates a mismatch that causes the driver to sleep when it shouldn't. This was introduced in 7acc619[1], but it wasn't triggered in my setup until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW; when PM is working as it was supposed to. However, it seems most of the time this is used in a way that keeps the counter above 0, so nobody noticed. Also, it seems to depend on the configuration used in versions before 3.1, but not later (or in it). I found the problem by loading isp1704_charger before any usb gadgets: http://article.gmane.org/gmane.linux.kernel/1226122 All versions after 2.6.39 are affected. [1] usb: musb: Idle path retention and offmode support for OMAP3 [2] OMAP2+: musb: hwmod adaptation for musb registration [3] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 Cc: sta...@vger.kernel.org Cc: Hema HK hem...@ti.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com applied, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/4] usb: musb: trivial cleanup
On Mon, Dec 19, 2011 at 10:17:49PM +0200, Felipe Contreras wrote: From: Felipe Contreras felipe.contre...@gmail.com enabled driver || !enabled can be simplified to !enabled || driver. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com applied, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 3/4] usb: musb: remove a bit of indentation
On Mon, Dec 19, 2011 at 10:17:50PM +0200, Felipe Contreras wrote: From: Felipe Contreras felipe.contre...@gmail.com And use dev instead of musb-controller. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com applied, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 4/4] musb: omap2430: avoid pm_runtime_disable()
Hi, On Mon, Dec 19, 2011 at 10:17:51PM +0200, Felipe Contreras wrote: From: Felipe Contreras felipe.contre...@gmail.com These are handled by drivers core, and in a way that doesn't wake up the devices. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com applied, thanks -- balbi signature.asc Description: Digital signature
RE: [PATCH-V4 0/3] Introducing TI's New SoC/board AM335XEVM
-Original Message- From: Hilman, Kevin Sent: Friday, December 02, 2011 11:04 PM To: Mohammed, Afzal Cc: Hiremath, Vaibhav; Russell King; linux-omap@vger.kernel.org; t...@atomide.com; linux-arm-ker...@lists.infradead.org; p...@pwsan.com Subject: Re: [PATCH-V4 0/3] Introducing TI's New SoC/board AM335XEVM Mohammed, Afzal af...@ti.com writes: Hi Kevin, On Thu, Dec 01, 2011 at 20:40:03, Hilman, Kevin wrote: Hiremath, Vaibhav hvaib...@ti.com writes: : We can detect the board using on-board EEPROM, so same mach-id should work for both EVM and Beagle. And also going forward with device tree approach we may not need different id's, right? Right, which is why I'm wondering why are there sevral new AM33x mach-types when only one of them is being used: 3684TI AM335X IA EVMam335xiaevm Afzal Mohammed 3589TI AM335X EVM am335xevm Vaibhav Bedia 3808Beaglebone Boardbeaglebone Steven Kipisz Russell has been trying to cleanup athe mach-types, so if these others are not going to be used, I suggest they be deleted. 3684-TI AM335X IA EVM is required as IA EVM uses a different UART, because of which early prints can't be captured, problem mentioned in http://marc.info/?l=linux-omapm=131286938723617w=2 This problem will be solved by using the device tree. Kevin, Will this solve earlyprintk as well? Thanks, Vaibhav 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 V2 0/2] OMAPDSS: DISPC: Peformance improvement of DISPC Scaling
On Tue, Dec 20, 2011 at 2:06 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2011-12-19 at 14:03 +0530, Chandrabhanu Mahapatra wrote: Hi everyone, the following patch set directs to improve the scaling performance of DISPC module which consists of two pacthes. The first patch is based on code of Lajos Molnar la...@ti.com from Android Kernel, which updates the code with new set of coefficients to improve the scaling performance. The second patch is based on some very valuable suggestions by Sebastien Fagard s-fag...@ti.com and directs to modify the clock requirements for scaling to support OMAP4 and avoid clock failure issues. I have tested these patches on OMAP2, OMAP3 AND OMAP4. To test on 2430SDP board I have created a patch to enable the display which will follow later. All your comments and suggestions are welcome. Thanks, this looks good. Applied to DSS master branch. There was a minor conflict with the Makefile, but I fixed that. Btw, when doing new versions of a patch series, it would be good to have a short history of the series in the introduction email, so that the reviewers can easily see what's new in each version. Tomi Thanks Tomi ! Its a good idea to including history of the series in the introduction. I will do so in further patches to come. -- Chandrabhanu Mahapatra Texas Instruments India Pvt. Ltd. -- 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: Interesting L3 driver panic on v3.2-rc5 on 3530
Hi Ilya, On Tuesday 20 December 2011 06:09 AM, Ilya Yanok wrote: Hi Paul, Paul Walmsleypaulat pwsan.com writes: [0.238494] Kernel BUG at c0033e34 [verbose debug info unavailable] [0.245025] Internal error: Oops - undefined instruction: 0 [#1] SMP [0.262390] PC is at omap3_l3_app_irq+0x108/0x12c I'm getting the same error on one of my AM3517 boards. L3_SI_FLAG_STATUS_0 register has bit 15 set that means Display SS IA burst timeout according to the RM. Regards, Ilya. Do the bootloaders on these boards enable display? There was a patch which got into the kernel in 3.2-rc4: b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1 ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader This tries to disable any display outputs if enabled in bootloader. If this issue didn't happen before, we might want to look into this code. Could you share what debug prints you get from the function omap_dss_reset() (its in arch/arm/mach-omap2/display.c) Thanks, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR
Hi Aneesh, On 12/20/2011 11:44 AM, Aneesh V wrote: On Tuesday 20 December 2011 05:05 AM, Tony Lindgren wrote: * Rob Herringrobherri...@gmail.com [111219 14:29]: On 12/19/2011 08:05 AM, Aneesh V wrote: This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller. The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future. The second patch provides the bindings for the EMIF controller. The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards. Thanks to Rajendra for answering my numerous queries on device tree. This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version. There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data. I agree generic JEDEC standard would be good for the DT. Please see my comments in reply to Rob's mail. SPD doesn't seems to have a standard for LPDDR2. What JEDEC has now is not suitable for our needs. In general, is it really feasible to parse the DTB before DDR is initialized? Changing timings is still needed for DVFS during runtime. But we can boot to userspace with bootloader set timings, so I'm As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space. Maybe it is the case, but that does not mean it should. We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint. thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like: .compatible = ti,omap3630, sdram-micron-mt46h32m32lf-6; And that should allow the SDRC driver to only accept timings for sdram-micron-mt46h32m32lf-6. Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right? Yes, that's the theory, but referring to Olof's point, this is not necessarily the goal of DT to store all the information that are not board dependent. In this case, each DDR will have it sets of well known AC timings data that will never depend of the board config. In this case, storing that inside DT might not be the best solution. In fact we always had the same kind of discussion for the pinmux data and for the clock data... The conclusion being that most of the static data does not have to be in the DTS. But since Linus was complaining about the huge amount of data inside the kernel, it is not obvious what the best solution is:-) Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: board-generic: Replace #if defined by #ifdef for consistency
Hi Tony,
What about that patch?
This is the only one that is missing in lo.
I know it is not a big deal, but it will make things a little bit cleaner.
Thanks,
Benoit
On 12/6/2011 5:49 PM, Benoit Cousson wrote:
The file contains a mix of #ifdef and #if defined().
Replace the #if... by #ifdef.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/board-generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index fb55fa3..09f44e0 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -92,7 +92,7 @@ static void __init omap3_init(void)
}
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#ifdef CONFIG_SOC_OMAP2420
static const char *omap242x_boards_compat[] __initdata = {
ti,omap2420,
NULL,
@@ -110,7 +110,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened
Device Tree))
MACHINE_END
#endif
-#if defined(CONFIG_SOC_OMAP2430)
+#ifdef CONFIG_SOC_OMAP2430
static const char *omap243x_boards_compat[] __initdata = {
ti,omap2430,
NULL,
@@ -128,7 +128,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened
Device Tree))
MACHINE_END
#endif
-#if defined(CONFIG_ARCH_OMAP3)
+#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
NULL,
@@ -146,7 +146,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
MACHINE_END
#endif
-#if defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
static const char *omap4_boards_compat[] __initdata = {
ti,omap4,
NULL,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] ARM: OMAP2+: Interrupt controllers adaptation to DT
Hi Tony and Rob, Here is the series to take advantage of the new DT interrupt init mechanism. Thanks to Marc's CONFIG_MULTI_IRQ_HANDLER series, OMAP4 just has to use the default GIC binding and does not need some OMAP specific hacks anymore. OMAP2 and 3 are using a simple interrupt controller that can thus expose a simpler binding. This update, compared to v1 [1], is introducing the IRQ domain for the OMAP23 INTC by default for both DT and none-DT build. Please note that in the near future that code can even be simplier with the introduction of the domain support inside generic irq chip. This series is based on lo/dt branch to get the needed cleanup and fixes for OMAP. The series is available here for reference: git://gitorious.org/omap-pm/linux.git for_3.3/2_dt_irq Regards, Benoit [1] http://www.spinics.net/lists/linux-omap/msg61152.html Benoit Cousson (5): arm/dts: OMAP4: Update DTS file with new GIC bindings ARM: OMAP2/3: intc: Add irqdomain support ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC ARM: OMAP2+: board-generic: Use of_irq_init API .../devicetree/bindings/arm/omap/intc.txt | 27 +++ arch/arm/boot/dts/omap3.dtsi |6 ++- arch/arm/boot/dts/omap4.dtsi |3 +- arch/arm/mach-omap2/board-generic.c| 30 +++-- arch/arm/mach-omap2/common.h | 10 arch/arm/mach-omap2/irq.c | 48 ++-- 6 files changed, 103 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] ARM: OMAP2/3: intc: Add irqdomain support
Introduce the usage of the irqdomain to prepare the DT support.
The irq_base is still hard coded to 0 to allow non-DT drivers
to work with the previous assumption that was hwirq = irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/mach-omap2/irq.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 42b1d65..2f65dfd 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -17,6 +17,7 @@
#include mach/hardware.h
#include asm/exception.h
#include asm/mach/irq.h
+#include linux/irqdomain.h
/* selected INTC register offsets */
@@ -57,6 +58,8 @@ static struct omap_irq_bank {
},
};
+static struct irq_domain domain;
+
/* Structure to save interrupt controller context */
struct omap3_intc_regs {
u32 sysconfig;
@@ -158,6 +161,17 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
if (WARN_ON(!omap_irq_base))
return;
+ /*
+* XXX: Use a 0 irq_base for the moment since the legacy devices
+* created statically are expected a hwirq = irq mapping.
+* A proper offset will be added later, when IRQ resource creation
+* will be handled by DT.
+*/
+ domain.irq_base = 0;
+ domain.nr_irq = nr_irqs;
+ domain.ops = irq_domain_simple_ops;
+ irq_domain_add(domain);
+
for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
struct omap_irq_bank *bank = irq_banks + i;
@@ -225,8 +239,10 @@ out:
irqnr = readl_relaxed(base_addr + INTCPS_SIR_IRQ_OFFSET);
irqnr = ACTIVEIRQ_MASK;
- if (irqnr)
+ if (irqnr) {
+ irqnr = irq_domain_to_irq(domain, irqnr);
handle_IRQ(irqnr, regs);
+ }
} while (irqnr);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] arm/dts: OMAP4: Update DTS file with new GIC bindings
The GIC binding was updated in 3.2 and expect 3 interrupt-cells.
- Update the #interrupt-cells
- interrupt-parent seems to be needed as well for the top level GIC
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap4.dtsi |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..bede009 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -95,7 +95,8 @@
gic: interrupt-controller@48241000 {
compatible = arm,cortex-a9-gic;
interrupt-controller;
- #interrupt-cells = 1;
+ interrupt-parent;
+ #interrupt-cells = 3;
reg = 0x48241000 0x1000,
0x48240100 0x0100;
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
---
.../devicetree/bindings/arm/omap/intc.txt | 27 ++
arch/arm/mach-omap2/common.h | 10 ++
arch/arm/mach-omap2/irq.c | 30 ++--
3 files changed, 64 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ ti,omap2-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32 and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = ti,omap2-intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..bcfccc2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -156,6 +156,16 @@ void omap3_intc_resume_idle(void);
void omap2_intc_handle_irq(struct pt_regs *regs);
void omap3_intc_handle_irq(struct pt_regs *regs);
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ return 0;
+}
+#endif
+
/*
* wfi used in low power code. Directly opcode is used instead
* of instruction to avoid mulit-omap build break
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 2f65dfd..f3722b1 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -18,6 +18,8 @@
#include asm/exception.h
#include asm/mach/irq.h
#include linux/irqdomain.h
+#include linux/of.h
+#include linux/of_address.h
/* selected INTC register offsets */
@@ -180,7 +182,7 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank-base_reg = ioremap(base, SZ_4K);
if (!bank-base_reg) {
- printk(KERN_ERR Could not ioremap irq bank%i\n, i);
+ pr_err(Could not ioremap irq bank%i\n, i);
continue;
}
@@ -193,8 +195,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
nr_banks++;
}
- printk(KERN_INFO Total of %ld interrupts on %d active controller%s\n,
- nr_of_irqs, nr_banks, nr_banks 1 ? s : );
+ pr_info(Total of %ld interrupts on %d active controller%s\n,
+ nr_of_irqs, nr_banks, nr_banks 1 ? s : );
}
void __init omap2_init_irq(void)
@@ -252,6 +254,28 @@ asmlinkage void __exception_irq_entry
omap2_intc_handle_irq(struct pt_regs *regs
omap_intc_handle_irq(base_addr, regs);
}
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ struct resource res;
+ u32 nr_irqs = 96;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, res)) {
+ WARN(1, unable to get intc registers\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, ti,intc-size, nr_irqs))
+ pr_warn(unable to get intc-size, default to %d\n, nr_irqs);
+
+ omap_init_irq(res.start, nr_irqs);
+ domain.of_node = of_node_get(node);
+
+ return 0;
+}
+
#ifdef CONFIG_ARCH_OMAP3
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
Update the DTS with the proper information required by the
INTC bindings.
- Add the number of interrupt lines
- Add the reg and the compatible entries.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap3.dtsi |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..6866dc7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -54,10 +54,12 @@
ranges;
ti,hwmods = l3_main;
- intc: interrupt-controller@1 {
- compatible = ti,omap3-intc;
+ intc: interrupt-controller@4820 {
+ compatible = ti,omap2-intc;
interrupt-controller;
#interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
};
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] ARM: OMAP2+: board-generic: Use of_irq_init API
Use the of_irq_init API introduced in 3.2 to handle
interrupt-controller with DT.
Update the irq_match table to map the proper XXX_of_init
functions for INTC and GIC drivers.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/mach-omap2/board-generic.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e493877..2529017 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -12,6 +12,7 @@
* published by the Free Software Foundation.
*/
#include linux/io.h
+#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
#include linux/i2c/twl.h
@@ -24,6 +25,17 @@
#include common.h
#include common-board-devices.h
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = ti,omap2-intc, .data = intc_of_init, },
+ { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
+ { }
+};
+
+static void __init omap_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
/*
* XXX: Still needed to boot until the i2c twl driver is adapted to
* device-tree
@@ -58,18 +70,8 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
-static struct of_device_id intc_match[] __initdata = {
- { .compatible = ti,omap3-intc, },
- { .compatible = arm,cortex-a9-gic, },
- { }
-};
-
static void __init omap_generic_init(void)
{
- struct device_node *node = of_find_matching_node(NULL, intc_match);
- if (node)
- irq_domain_add_simple(node, 0);
-
omap_serial_init();
omap_sdrc_init(NULL, NULL);
@@ -103,7 +105,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -122,7 +124,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -141,7 +143,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap3_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap3_init,
.timer = omap3_timer,
@@ -160,7 +162,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = gic_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
.init_machine = omap4_init,
.timer = omap4_timer,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR
Hi Benoit On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote: Hi Aneesh, snip In general, is it really feasible to parse the DTB before DDR is initialized? Changing timings is still needed for DVFS during runtime. But we can boot to userspace with bootloader set timings, so I'm As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space. Maybe it is the case, but that does not mean it should. We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint. thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like: .compatible = ti,omap3630, sdram-micron-mt46h32m32lf-6; And that should allow the SDRC driver to only accept timings for sdram-micron-mt46h32m32lf-6. Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right? Yes, that's the theory, but referring to Olof's point, this is not necessarily the goal of DT to store all the information that are not board dependent. In this case, each DDR will have it sets of well known AC timings data that will never depend of the board config. In this case, storing that inside DT might not be the best solution. In fact we always had the same kind of discussion for the pinmux data and for the clock data... The conclusion being that most of the static data does not have to be in the DTS. But since Linus was complaining about the huge amount of data inside the kernel, it is not obvious what the best solution is:-) Hmm.. I get the point now. Linus' complaint is what I had in mind too. My humble opinion is to have such data in DTS but re-use it as much as possible. That is, we could have something like a sdram-micron- mt46h32m32lf-6.dtsi(as you suggested before) that can be included by board level DTS files. I think the fact that dts files are organized at arch level today is limiting such re-use. Please correct me if I am wrong. br, Aneesh -- 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 04/10] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
Hi Andrew,
I've never got any feedback on this patch from Alessandro and it seems
that you took care of some rtc stuff recently.
Thanks in advance,
Benoit
On 12/9/2011 3:02 PM, Benoit Cousson wrote:
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Alessandro Zummoa.zu...@towertech.it
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12
drivers/rtc/rtc-twl.c | 10 --
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
new file mode 100644
index 000..596e0c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -0,0 +1,12 @@
+* TI twl RTC
+
+The TWL family (twl4030/6030) contains a RTC.
+
+Required properties:
+- compatible : Should be twl4030-rtc
+
+Examples:
+
+rtc@0 {
+compatible = ti,twl4030-rtc;
+};
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 20687d5..d43b4f6 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -550,6 +550,11 @@ static int twl_rtc_resume(struct platform_device *pdev)
#define twl_rtc_resume NULL
#endif
+static const struct of_device_id twl_rtc_of_match[] = {
+ {.compatible = ti,twl4030-rtc, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_rtc_of_match);
MODULE_ALIAS(platform:twl_rtc);
static struct platform_driver twl4030rtc_driver = {
@@ -559,8 +564,9 @@ static struct platform_driver twl4030rtc_driver = {
.suspend= twl_rtc_suspend,
.resume = twl_rtc_resume,
.driver = {
- .owner = THIS_MODULE,
- .name = twl_rtc,
+ .owner = THIS_MODULE,
+ .name = twl_rtc,
+ .of_match_table = twl_rtc_of_match,
},
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/11] OMAP4: Add DT support for i2c and twl6030
Hi Tony and Rob, Here is the updated version of the i2c + twl DT adaptation series. This update, compared to v2 [1], is adding some dedicated dtsi files for the twl PMIC and audio IC. These devices will contain a huge amount of regulator nodes and thus deserve a dedicated file to avoid every boards to redefine the same data. The twl patch is now included in Samuel's for-next branch and thus dropped from this update. The i2c binding was cleaned as suggested by Rob to avoid all the ugly hexa flags inside the DTS. The pm.c was updated to prevent the SR / VP initialization in the DT context since none of them is DT aware for the moment. A couple of basic i2c devices are added for panda, beagle and sdp board. Patches are based on for_3.3/2_dt_irq, to get the latest GIC binding, and are available here: git://gitorious.org/omap-pm/linux.git for_3.3/3_omap_dt_i2c_twl Tested on Beagle and sdp4430. Comments are welcome. Regards, Benoit [1] http://www.spinics.net/lists/linux-omap/msg61260.html Benoit Cousson (11): ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT i2c: OMAP: Add DT support for i2c controller rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030 arm/dts: OMAP4: Add i2c controller nodes arm/dts: OMAP3: Add i2c controller nodes arm/dts: twl6030: Add DTS file for twl6030 PMIC arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC arm/dts: omap4-panda: Add twl6030 and i2c EEPROM arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM ARM: OMAP2+: board-generic: Remove i2c static init Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++ Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 +++ arch/arm/boot/dts/omap3-beagle.dts | 29 ++ arch/arm/boot/dts/omap3.dtsi | 21 arch/arm/boot/dts/omap4-panda.dts | 34 +++ arch/arm/boot/dts/omap4-sdp.dts| 53 ++ arch/arm/boot/dts/omap4.dtsi | 28 ++ arch/arm/boot/dts/twl4030.dtsi | 21 arch/arm/boot/dts/twl6030.dtsi | 22 arch/arm/mach-omap2/board-generic.c| 48 +- arch/arm/mach-omap2/pm.c |8 ++ drivers/i2c/busses/i2c-omap.c | 101 +--- drivers/rtc/rtc-twl.c | 10 ++- 13 files changed, 334 insertions(+), 83 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt create mode 100644 arch/arm/boot/dts/twl4030.dtsi create mode 100644 arch/arm/boot/dts/twl6030.dtsi -- 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 01/11] ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT
In the case of DT, the PMIC and SR initialization will be done using
a completely different mechanism.
Disable this part if a DT blob is available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..ad4f693 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -227,6 +227,14 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
+ /*
+* In the case of DT, the PMIC and SR initialization will be done using
+* a completely different mechanism.
+* Disable this part if a DT blob is available.
+*/
+ if (of_have_populated_dt())
+ return 0;
+
/* Init the voltage layer */
omap_pmic_late_init();
omap_voltage_late_init();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/11] arm/dts: OMAP4: Add i2c controller nodes
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap4.dtsi | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bede009..9872283 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -100,5 +100,33 @@
reg = 0x48241000 0x1000,
0x48240100 0x0100;
};
+
+ i2c1: i2c@1 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c1;
+ };
+
+ i2c2: i2c@2 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c2;
+ };
+
+ i2c3: i2c@3 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c3;
+ };
+
+ i2c4: i2c@4 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c4;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/11] arm/dts: OMAP3: Add i2c controller nodes
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap3.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6866dc7..697b210 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,5 +61,26 @@
ti,intc-size = 96;
reg = 0x4820 0x1000;
};
+
+ i2c1: i2c@1 {
+ compatible = ti,omap3-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c1;
+ };
+
+ i2c2: i2c@2 {
+ compatible = ti,omap3-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c2;
+ };
+
+ i2c3: i2c@3 {
+ compatible = ti,omap3-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c3;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/11] arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC
Add a dedicated DTS file for the twl4030/5030 Power + Audio IC.
This chip is a big SoC that will be reused in a lot of various
OMAP3 boards.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/twl4030.dtsi
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
new file mode 100644
index 000..8be5223
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ */
+twl {
+ compatible = ti,twl4030;
+ interrupt-controller;
+ #interrupt-cells = 1;
+
+ rtc {
+ compatible = ti,twl4030-rtc;
+ interrupts = 11;
+ };
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/11] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4-panda.dts | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9755ad5..29646dc 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -18,3 +18,37 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+i2c1 {
+ clock-frequency = 40;
+
+ twl: twl@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = gic;
+ };
+};
+
+/include/ twl6030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+* Display monitor features are burnt in their EEPROM as EDID data.
+* The EEPROM is connected as I2C slave device.
+*/
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
+
+i2c4 {
+ clock-frequency = 40;
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/11] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
Add required clock frequencies for the i2c client devices existing
on beagle board.
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap3-beagle.dts | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 9f72cd4..714ba5d 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -18,3 +18,32 @@
reg = 0x8000 0x2000; /* 512 MB */
};
};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/11] arm/dts: twl6030: Add DTS file for twl6030 PMIC
Add a dedicated DTS file for the twl6030 Power IC.
This chip is a big SoC that will be reused in a lot of various
OMAP4+ boards.
Note: This file is supposed to be included in a board DTS that will
create the twl node in order to allow the twl reference to work.
Exmaple:
...
i2c1 {
twl: twl@48 {
reg = 0x48;
interrupts = 0 7 4;
interrupt-controller;
interrupt-parent = gic;
};
};
/include/ twl6030.dtsi
...
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/twl6030.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/twl6030.dtsi
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
new file mode 100644
index 000..b7b4e5e
--- /dev/null
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+twl {
+ compatible = ti,twl6030;
+ interrupt-controller;
+ #interrupt-cells = 1;
+
+ rtc {
+ compatible = ti,twl4030-rtc;
+ interrupts = 11;
+ };
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/11] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
Update DTS file with required clock frequencies
for the i2c client devices existing on sdp4430.
Add the twl6030 node inside the i2c1 controller node.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add the RTC submodule inside the twl node.
Add tmp105 temperature sensor in i2c3
Add bh1780 Ambient Light Sensor in i2c3
Add hmc5843 3-Axis Digital Compass in i2c4
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4-sdp.dts | 53 +++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 63c6b2b..17e829a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -18,3 +18,56 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+i2c1 {
+ clock-frequency = 40;
+
+ twl: twl@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = gic;
+ };
+};
+
+/include/ twl6030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+ reg = 0x48072000 0x100, 0x48072100 0x100, 0x48072200 0x100;
+};
+
+i2c3 {
+ clock-frequency = 40;
+
+ /*
+* Temperature Sensor
+* http://www.ti.com/lit/ds/symlink/tmp105.pdf
+*/
+ tmp105@48 {
+ compatible = ti,tmp105;
+ reg = 0x48;
+ };
+
+ /*
+* Ambient Light Sensor
+* http://www.rohm.com/products/databook/sensor/pdf/bh1780gli-e.pdf
+*/
+ bh1780@29 {
+ compatible = rohm,bh1780;
+ reg = 0x29;
+ };
+};
+
+i2c4 {
+ clock-frequency = 40;
+
+ /*
+* 3-Axis Digital Compass
+* http://www.sparkfun.com/datasheets/Sensors/Magneto/HMC5843.pdf
+*/
+ hmc5843@1e {
+ compatible = honeywell,hmc5843;
+ reg = 0x1e;
+ };
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/11] ARM: OMAP2+: board-generic: Remove i2c static init
This mainly reverts the commit that was adding the i2c static init.
Since the i2c and twl nodes are now present, there is no need
for the static initialization anymore.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 48 +-
1 files changed, 2 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 2529017..38f105d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,7 +15,6 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
-#include linux/i2c/twl.h
#include mach/hardware.h
#include asm/hardware/gic.h
@@ -36,34 +35,6 @@ static void __init omap_init_irq(void)
of_irq_init(irq_match);
}
-/*
- * XXX: Still needed to boot until the i2c twl driver is adapted to
- * device-tree
- */
-#ifdef CONFIG_ARCH_OMAP4
-static struct twl4030_platform_data sdp4430_twldata = {
- .irq_base = TWL6030_IRQ_BASE,
- .irq_end= TWL6030_IRQ_END,
-};
-
-static void __init omap4_i2c_init(void)
-{
- omap4_pmic_init(twl6030, sdp4430_twldata);
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct twl4030_platform_data beagle_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end= TWL4030_IRQ_END,
-};
-
-static void __init omap3_i2c_init(void)
-{
- omap3_pmic_init(twl4030, beagle_twldata);
-}
-#endif
-
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = simple-bus, },
{ .compatible = ti,omap-infra, },
@@ -78,21 +49,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
-#ifdef CONFIG_ARCH_OMAP4
-static void __init omap4_init(void)
-{
- omap4_i2c_init();
- omap_generic_init();
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static void __init omap3_init(void)
-{
- omap3_i2c_init();
- omap_generic_init();
-}
-#endif
#if defined(CONFIG_SOC_OMAP2420)
static const char *omap242x_boards_compat[] __initdata = {
@@ -145,7 +101,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.init_early = omap3430_init_early,
.init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
- .init_machine = omap3_init,
+ .init_machine = omap_generic_init,
.timer = omap3_timer,
.dt_compat = omap3_boards_compat,
MACHINE_END
@@ -164,7 +120,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.init_early = omap4430_init_early,
.init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
- .init_machine = omap4_init,
+ .init_machine = omap_generic_init,
.timer = omap4_timer,
.dt_compat = omap4_boards_compat,
MACHINE_END
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/11] i2c: OMAP: Add DT support for i2c controller
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kevin Hilman khil...@ti.com
---
Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++
drivers/i2c/busses/i2c-omap.c | 101 +---
2 files changed, 96 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/omap-i2c.txt
b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
new file mode 100644
index 000..56564aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
@@ -0,0 +1,30 @@
+I2C for OMAP platforms
+
+Required properties :
+- compatible : Must be ti,omap3-i2c or ti,omap4-i2c
+- ti,hwmods : Must be i2cn, n being the instance number (1-based)
+- #address-cells = 1;
+- #size-cells = 0;
+
+Recommended properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
+ the default 100 kHz frequency will be used.
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+
+Note: Current implementation will fetch base address, irq and dma
+from omap hwmod data base during device registration.
+Future plan is to migrate hwmod data base contents into device tree
+blob so that, all the required data will be used from device tree dts
+file.
+
+Examples :
+
+i2c1: i2c@0 {
+compatible = ti,omap3-i2c;
+#address-cells = 1;
+#size-cells = 0;
+ti,hwmods = i2c1;
+clock-frequency = 40;
+};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a43d002..dcbc1ec 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -37,6 +37,8 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/io.h
+#include linux/of_i2c.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
@@ -182,7 +184,9 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
- u32 speed; /* Speed of bus in Khz */
+ u32 speed; /* Speed of bus in kHz */
+ u32 dtrev; /* extra revision from DT */
+ u32 flags;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -266,11 +270,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
- struct omap_i2c_bus_platform_data *pdata;
-
- pdata = dev-dev-platform_data;
-
- if (pdata-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
@@ -291,13 +291,10 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
- struct omap_i2c_bus_platform_data *pdata;
u16 iv;
- pdata = dev-dev-platform_data;
-
dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (pdata-rev == OMAP_I2C_IP_VERSION_2)
+ if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
else
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
@@ -320,9 +317,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long timeout;
unsigned long internal_clk = 0;
struct clk *fclk;
- struct omap_i2c_bus_platform_data *pdata;
-
- pdata = dev-dev-platform_data;
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
@@ -373,7 +367,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- if (pdata-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
+ if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
* The I2C functional clock is the armxor_ck, so there's
* no need to get armxor_ck separately. Now, if OMAP2420
@@ -397,7 +391,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
- if (!(pdata-flags OMAP_I2C_FLAG_SIMPLE_CLOCK)) {
+ if (!(dev-flags OMAP_I2C_FLAG_SIMPLE_CLOCK)) {
/*
* HSI2C controller
[PATCH v3 03/11] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Alessandro Zummo a.zu...@towertech.it
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12
drivers/rtc/rtc-twl.c | 10 --
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
new file mode 100644
index 000..596e0c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -0,0 +1,12 @@
+* TI twl RTC
+
+The TWL family (twl4030/6030) contains a RTC.
+
+Required properties:
+- compatible : Should be twl4030-rtc
+
+Examples:
+
+rtc@0 {
+compatible = ti,twl4030-rtc;
+};
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 20687d5..d43b4f6 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -550,6 +550,11 @@ static int twl_rtc_resume(struct platform_device *pdev)
#define twl_rtc_resume NULL
#endif
+static const struct of_device_id twl_rtc_of_match[] = {
+ {.compatible = ti,twl4030-rtc, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_rtc_of_match);
MODULE_ALIAS(platform:twl_rtc);
static struct platform_driver twl4030rtc_driver = {
@@ -559,8 +564,9 @@ static struct platform_driver twl4030rtc_driver = {
.suspend= twl_rtc_suspend,
.resume = twl_rtc_resume,
.driver = {
- .owner = THIS_MODULE,
- .name = twl_rtc,
+ .owner = THIS_MODULE,
+ .name = twl_rtc,
+ .of_match_table = twl_rtc_of_match,
},
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/11] i2c: OMAP: Add DT support for i2c controller
On 12/20/2011 10:27 AM, Benoit Cousson wrote:
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kevin Hilman khil...@ti.com
One issue below, otherwise:
Reviewed-by: Rob Herring rob.herr...@calxeda.com
@@ -1001,15 +1019,24 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
- if (pdata != NULL) {
- speed = pdata-clkrate;
+ match = of_match_device(omap_i2c_of_match, pdev-dev);
+ if (match) {
+ u32 freq = 10; /* default to 10 Hz */
+
+ pdata = match-data;
+ dev-dtrev = pdata-rev;
+ dev-flags = pdata-flags;
+
+ of_property_read_u32(node, clock-frequency, freq);
+ /* convert DT freq value in Hz into kHz for speed */
+ dev-speed = freq / 1000;
+ } else if (pdata != NULL) {
+ dev-speed = pdata-clkrate;
+ dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
- } else {
- speed = 100;/* Default speed */
- dev-set_mpu_wkup_lat = NULL;
+ dev-dtrev = pdata-rev;
If you get here, pdata is NULL.
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 v3 07/11] arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC
On 12/20/2011 10:27 AM, Benoit Cousson wrote:
Add a dedicated DTS file for the twl4030/5030 Power + Audio IC.
This chip is a big SoC that will be reused in a lot of various
OMAP3 boards.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/twl4030.dtsi
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
new file mode 100644
index 000..8be5223
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ */
+twl {
+ compatible = ti,twl4030;
+ interrupt-controller;
+ #interrupt-cells = 1;
+
+ rtc {
+ compatible = ti,twl4030-rtc;
+ interrupts = 11;
Can't this vary? Not only the irq#, but the parent controller's number
of cells can vary.
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 v3 07/11] arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC
On 12/20/2011 10:47 AM, Rob Herring wrote:
On 12/20/2011 10:27 AM, Benoit Cousson wrote:
Add a dedicated DTS file for the twl4030/5030 Power + Audio IC.
This chip is a big SoC that will be reused in a lot of various
OMAP3 boards.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/twl4030.dtsi
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
new file mode 100644
index 000..8be5223
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ */
+twl {
+compatible = ti,twl4030;
+interrupt-controller;
+#interrupt-cells = 1;
+
+rtc {
+compatible = ti,twl4030-rtc;
+interrupts = 11;
Can't this vary? Not only the irq#, but the parent controller's number
of cells can vary.
Never mind. I see this is the RTC interrupt within the twl4030 chip.
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: [GIT PULL] Borderline fixes for v3.2-rc6
* Olof Johansson o...@lixom.net [111219 20:20]: Hi Tony, On Mon, Dec 19, 2011 at 11:42 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here are two fixes that could potentially go into v3.2 -rc cycle. One fixes a harmless but annoying warning that happens on omap 34xx processors during boot. The other one fixes booting on pretty rare secure mode development board, but that's fixed in features that never worked earlier either style. We can surely wait on these fixes, but if you have something going upstream anyways, then these might be worth considering too. The hwmod patch is a regression so that one I'll take, the other one is a little less obvious that it should go in now. Also, shouldn't it be cc:d stable in that case? Yes let's not worry about the second one, it adds new functionality and it's for a currently rare case. Let me know what you prefer (rebase with a cc: stable) or take out the secure mode patch. I'm collecting a small series of fixes so I'll pull it in tomorrow for that. I've branched it out into fixes-hwmod-regression with just that same commit in it. The second patch in this series will be pulled in with fixes-non-critical-part2. Updated pull request below. Regards, Tony The following changes since commit e5fe29c7198a1f6616286dfc8602a69da165cb3f: Felipe Contreras (1): ARM: OMAP: rx51: fix USB are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-hwmod-regression Felipe Contreras (1): ARM: OMAP: hwmod data: fix iva and mailbox hwmods for OMAP 3 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 1 files changed, 0 insertions(+), 4 deletions(-) -- 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: [GIT PULL] Borderline fixes for v3.2-rc6
On Tue, Dec 20, 2011 at 9:10 AM, Tony Lindgren t...@atomide.com wrote: * Olof Johansson o...@lixom.net [111219 20:20]: Hi Tony, On Mon, Dec 19, 2011 at 11:42 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here are two fixes that could potentially go into v3.2 -rc cycle. One fixes a harmless but annoying warning that happens on omap 34xx processors during boot. The other one fixes booting on pretty rare secure mode development board, but that's fixed in features that never worked earlier either style. We can surely wait on these fixes, but if you have something going upstream anyways, then these might be worth considering too. The hwmod patch is a regression so that one I'll take, the other one is a little less obvious that it should go in now. Also, shouldn't it be cc:d stable in that case? Yes let's not worry about the second one, it adds new functionality and it's for a currently rare case. Let me know what you prefer (rebase with a cc: stable) or take out the secure mode patch. I'm collecting a small series of fixes so I'll pull it in tomorrow for that. I've branched it out into fixes-hwmod-regression with just that same commit in it. The second patch in this series will be pulled in with fixes-non-critical-part2. Updated pull request below. Thanks, I pulled fixes-hwmod-regression into fixes and fixes-hwmod into next/fixes-non-critical. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:57]: Resending because of a typo in the Cc: list, sorry. 8-- In preparation to converting Amstrad Delta on-board latches to basic_mmio_gpio devices, registration of platform devices which depend on latches and will require initialization of their GPIO pins first, should be moved out of .machine_init down to late_initcall level, as the gpio-generic driver is not available until device_initcall time. The latch reset operation, which will be replaced with GPIO initialization, must also be moved to late_initcall for the same reason. Since there was already another, separate arch_initcall function for setting up one of those latch dependent devices, the on-board modem device, reuse that function, i.e., rename it to a name that matches the new purpose, extend with other device setup relocated from .machine_init, and move down to the late_initcall level. While being at it, add missing gpio_free() in case the modem platform device registration fails. In addition, defer registration of the Amstrad Delta ASoC and serio devices, done from their device driver files, until late_initcall time, as those drivers will depend on their GPIO pins already requested from the board late_init() function until updated to register their GPIO pins themselves. Thanks to Tony Lindgren t...@atomide.com who suggested this approach instead of shifting up the gpio-generic driver initialization. ... --- a/drivers/input/serio/ams_delta_serio.c +++ b/drivers/input/serio/ams_delta_serio.c @@ -165,6 +165,9 @@ serio: kfree(ams_delta_serio); return err; } +#ifndef MODULE +late_initcall(ams_delta_serio_init); +#else module_init(ams_delta_serio_init); static void __exit ams_delta_serio_exit(void) @@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void) gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA); } module_exit(ams_delta_serio_exit); +#endif diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c index ccb8a6a..1764a3b 100644 --- a/sound/soc/omap/ams-delta.c +++ b/sound/soc/omap/ams-delta.c @@ -636,6 +636,9 @@ err: platform_device_put(ams_delta_audio_platform_device); return ret; } +#ifndef MODULE +late_initcall(ams_delta_module_init); +#else module_init(ams_delta_module_init); static void __exit ams_delta_module_exit(void) @@ -657,6 +660,7 @@ static void __exit ams_delta_module_exit(void) platform_device_unregister(ams_delta_audio_platform_device); } module_exit(ams_delta_module_exit); +#endif MODULE_AUTHOR(Janusz Krzysztofik jkrzy...@tis.icnet.pl); MODULE_DESCRIPTION(ALSA SoC driver for Amstrad E3 (Delta) videophone); This looks a bit odd.. I think these drivers should be converted to a proper platform_driver so you can get rid of the machine_is_ams_delta check in the init. Then you can rely on the probe to match the device. To deal with the init order issues, you can pass a set_power function pointer in platform_data that the driver can use. Or set up a fixed regulator for it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interesting L3 driver panic on v3.2-rc5 on 3530
Hi Archit, On 20.12.2011 16:23, Archit Taneja wrote: [0.238494] Kernel BUG at c0033e34 [verbose debug info unavailable] [0.245025] Internal error: Oops - undefined instruction: 0 [#1] SMP [0.262390] PC is at omap3_l3_app_irq+0x108/0x12c I'm getting the same error on one of my AM3517 boards. L3_SI_FLAG_STATUS_0 register has bit 15 set that means Display SS IA burst timeout according to the RM. Regards, Ilya. Do the bootloaders on these boards enable display? Yes, U-Boot on the problematic board enables the display. Disabling display support in U-Boot makes this problem go away. There was a patch which got into the kernel in 3.2-rc4: b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1 ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader This tries to disable any display outputs if enabled in bootloader. If this issue didn't happen before, we might want to look into this code. Hm. I can't say reverting this patch solves the problem completely. It seems to me that the bug triggers more rarely without this patch but I can't say for sure: it might be just a coincedence. Could you share what debug prints you get from the function omap_dss_reset() (its in arch/arm/mach-omap2/display.c) I can't see much debug output from this function/file. The only line is dss_core: softreset done and it's the same regardless of the bug was triggered or not. Do you wish me to add some debugging output and present the results? It would be great if you could say what data to dump. Regards, Ilya. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: musb: fix pm_runtime mismatches
On Tue, Dec 20, 2011 at 1:19 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Dec 19, 2011 at 10:20:09PM +0200, Felipe Contreras wrote: On Mon, Dec 19, 2011 at 10:11 AM, Felipe Balbi ba...@ti.com wrote: On Fri, Dec 16, 2011 at 01:05:08AM +0200, Felipe Contreras wrote: Properly call pm_runtime_put() afer pm_runttime_get() on errors. Untested. sorry, but I'm not applying untested patches. I need someone to give a Tested-by. I'm pretty sure most people don't test the exit paths, but fine, don't apply them. Who needs power management anyway. if it wasn't tested you can't claim $SUBJECT makes PM magically work. It's clear from the code, no need to test to see that pm_runtime_get() is called but not pm_runtime_put(), thus the device remains active, thus PM would not work after that. -- Felipe Contreras -- 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
[GIT PULL] ARM: OMAP: device PM constraints: preparatory support
Hi Tony These patches prepare for the introduction of the powerdomain device PM constraints, via the standard Linux device PM mechanism that Rafael Wysocki introduced. After the powerdomain device PM constraints go in, we should be able to remove some of the OMAP PM interface (currently via platform_data function pointers) currently in our tree. The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50: Linux 3.2-rc5 (2011-12-09 15:09:32 -0800) are available in the git repository at: git://git.pwsan.com/linux-2.6 jp_hwmod_pm_dev_lat_devel_3.3 Jean Pihet (2): ARM: OMAP2+: hwmod: manage the wake-up latency constraints ARM: OMAP: omap_device: register to the per-device PM QoS framework arch/arm/mach-omap2/omap_hwmod.c | 54 ++- arch/arm/plat-omap/include/plat/omap_hwmod.h |5 ++ arch/arm/plat-omap/omap_device.c | 74 ++ 3 files changed, 132 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] mcx: support for HTKW mcx board
Hi Igor,
On 15.12.2011 14:40, Igor Grinberg wrote:
+r = gpio_request_array(mcx_dss_gpios, ARRAY_SIZE(mcx_dss_gpios));
+if (r) {
+pr_err(failed to get DSS control GPIOs\n);
+return;
+}
+
+omap_mux_init_gpio(LCD_BKLIGHT_EN, OMAP_PIN_OUTPUT);
+omap_mux_init_gpio(LCD_LVL_SFHT_BUF_ENn, OMAP_PIN_OUTPUT);
+omap_mux_init_gpio(LCD_PWR_ENn, OMAP_PIN_OUTPUT);
+omap_mux_init_gpio(HDMI_TRCVR_PDn, OMAP_PIN_OUTPUT);
Shouldn't you mux the pins, before you access the GPIO
(e.g. before the gpio_request_array()).
Are there any safety problems?
No, there are no problems. I will move mux settings above
gpio_request_array() call.
+static struct omap2_hsmmc_info mmc[] = {
+{
+.mmc= 1,
+.caps = MMC_CAP_4_BIT_DATA,
+.gpio_cd= SD_CARD_CD,
+.gpio_wp= SD_CARD_WP,
+.ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34 |
+MMC_VDD_165_195,
The ocr_mask will be overridden, by the following patch:
-
commit e89715a7e48d505f42813a4e3ee0f0efb49832ba
Author: Abhilash K V abhilash...@ti.com
Date: Fri Dec 9 12:27:36 2011 -0800
ARM: OMAP: hsmmc: Support for AM3517 MMC1 voltages
--
in Tony's hsmmc branch.
IMO it should be fixed, by adding a check if the ocr_mask is
already set...
I can't send a patch for this right now...
Well, I think I should just drop the .ocr_mask field then. Everything
works fine for me with the above mentioned patch.
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+OMAP3_MUX(CHASSIS_DMAREQ3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
+OMAP_PULL_ENA | OMAP_PULL_UP),
+OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
+OMAP_PULL_ENA | OMAP_PULL_UP),
Hmm... pullup for output? Is this needed for kind of safety?
This is a mistake indeed. Will remove the pullups.
+static void __init mcx_init(void)
+{
+int err;
+
+omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+mcx_i2c_init();
+platform_add_devices(mcx_devices, ARRAY_SIZE(mcx_devices));
+omap_serial_init();
Shouldn't this one be before the mcx_i2c_init() call?
Well, I think I've taken this order from some other board init... I
think the idea was to bring up regulator chip earlier. But I can move
serial up with no problem.
+mcx_display_init();
+
+/* Configure EHCI ports */
+err = gpio_request_one(USB_HOST_PWR_EN, GPIOF_OUT_INIT_HIGH,
+USB_HOST_PWR_EN);
+if (err)
+pr_warn(Failed to request USB host power enable GPIO\n);
empty line here will improve the readability.
Ok.
Regards, Ilya.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
On Tuesday 20 of December 2011 at 19:06:11, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:57]: Resending because of a typo in the Cc: list, sorry. 8-- In preparation to converting Amstrad Delta on-board latches to basic_mmio_gpio devices, registration of platform devices which depend on latches and will require initialization of their GPIO pins first, should be moved out of .machine_init down to late_initcall level, as the gpio-generic driver is not available until device_initcall time. The latch reset operation, which will be replaced with GPIO initialization, must also be moved to late_initcall for the same reason. Since there was already another, separate arch_initcall function for setting up one of those latch dependent devices, the on-board modem device, reuse that function, i.e., rename it to a name that matches the new purpose, extend with other device setup relocated from .machine_init, and move down to the late_initcall level. While being at it, add missing gpio_free() in case the modem platform device registration fails. In addition, defer registration of the Amstrad Delta ASoC and serio devices, done from their device driver files, until late_initcall time, as those drivers will depend on their GPIO pins already requested from the board late_init() function until updated to register their GPIO pins themselves. Thanks to Tony Lindgren t...@atomide.com who suggested this approach instead of shifting up the gpio-generic driver initialization. ... --- a/drivers/input/serio/ams_delta_serio.c +++ b/drivers/input/serio/ams_delta_serio.c @@ -165,6 +165,9 @@ serio: kfree(ams_delta_serio); return err; } +#ifndef MODULE +late_initcall(ams_delta_serio_init); +#else module_init(ams_delta_serio_init); static void __exit ams_delta_serio_exit(void) @@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void) gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA); } module_exit(ams_delta_serio_exit); +#endif diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c index ccb8a6a..1764a3b 100644 --- a/sound/soc/omap/ams-delta.c +++ b/sound/soc/omap/ams-delta.c @@ -636,6 +636,9 @@ err: platform_device_put(ams_delta_audio_platform_device); return ret; } +#ifndef MODULE +late_initcall(ams_delta_module_init); +#else module_init(ams_delta_module_init); static void __exit ams_delta_module_exit(void) @@ -657,6 +660,7 @@ static void __exit ams_delta_module_exit(void) platform_device_unregister(ams_delta_audio_platform_device); } module_exit(ams_delta_module_exit); +#endif MODULE_AUTHOR(Janusz Krzysztofik jkrzy...@tis.icnet.pl); MODULE_DESCRIPTION(ALSA SoC driver for Amstrad E3 (Delta) videophone); This looks a bit odd.. I think these drivers should be converted to a proper platform_driver so you can get rid of the machine_is_ams_delta check in the init. Then you can rely on the probe to match the device. Mostly true, but first of all, I don't pretend to solve all problems with all Amstrad Delta specific drivers in this patch series. I'm concentrating on converting latches to GPIO pins, and updating those drivers to access those pins with gpiolib API instead of accessing the latches with the board specific API. Nothing more. Now, regarding the serio driver, you are absolutely right, the device registration could be better moved out of the driver file to the board file. I'll probably do this some time in the future, once I'm ready with the latches related stuff, i.e. the ams_delta_latch_write() is finally removed from the board file as no longer used by any driver, and find some spare time again. For now, I'm moving that serio device/driver initialization to late_initcall with patch 2/7, and back to device_initcall once converted to gpiolib (patch 7/7). Is this acceptable? If not, let's drop those forward and back moves, and the driver will get broken with 2/7, but get repaired with 7/7, OK? Regarding the sound card: the sound/soc/omap/ams-delta.c file is not a device driver per se, but rather a piece of code which sets up a platform device representing the sound card, i.e., provides platform device description and platform data, including device specific callbacks, to be used by the generic 'soc-audio' driver. There is no single platform_driver_register() called from that file, only platform_device_register() or alike. That code seems to belong logically to the board setup, but was always maintained, among 12 others, and for reasons not known to me with my relatively short experience as a kernel developer, inside the sound/soc/omap/ subtree, not under arch/arm/mach- omap1/. Like all those 12 others, including sdp4430 which is quite recent I guess, it makes use of the machine_is_* function as if it was a part of a board files set. Then, the only
Re: [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
On Tue, Dec 20, 2011 at 12:28:32AM +0100, Janusz Krzysztofik wrote: diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c index d4d08bd..56ffd7c 100644 --- a/drivers/input/serio/ams_delta_serio.c +++ b/drivers/input/serio/ams_delta_serio.c @@ -165,6 +165,9 @@ serio: kfree(ams_delta_serio); return err; } +#ifndef MODULE +late_initcall(ams_delta_serio_init); +#else module_init(ams_delta_serio_init); static void __exit ams_delta_serio_exit(void) @@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void) gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA); } module_exit(ams_delta_serio_exit); +#endif It's worth noting: #ifndef MODULE #define late_initcall(fn) __define_initcall(7,fn,7) #else /* MODULE */ #define late_initcall(fn) module_init(fn) So really, all these ifndefs aren't required. Just change the module_init() to late_initcall(). -- 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: [alsa-devel] [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
On Tuesday 20 of December 2011 at 21:40:46, Russell King - ARM Linux wrote: On Tue, Dec 20, 2011 at 12:28:32AM +0100, Janusz Krzysztofik wrote: diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c index d4d08bd..56ffd7c 100644 --- a/drivers/input/serio/ams_delta_serio.c +++ b/drivers/input/serio/ams_delta_serio.c @@ -165,6 +165,9 @@ serio: kfree(ams_delta_serio); return err; } +#ifndef MODULE +late_initcall(ams_delta_serio_init); +#else module_init(ams_delta_serio_init); static void __exit ams_delta_serio_exit(void) @@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void) gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA); } module_exit(ams_delta_serio_exit); +#endif It's worth noting: #ifndef MODULE #define late_initcall(fn) __define_initcall(7,fn,7) #else /* MODULE */ #define late_initcall(fn) module_init(fn) So really, all these ifndefs aren't required. Just change the module_init() to late_initcall(). Thanks, I'll follow your pattern. My reason for using those ifdefery was a comment still found in include/linux/init.h: #else /* MODULE */ /* Don't use these in modules, but some people do... */ #define early_initcall(fn) module_init(fn) #define core_initcall(fn) module_init(fn) ... #define late_initcall(fn) module_init(fn) Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 12:03]: On Tuesday 20 of December 2011 at 19:06:11, Tony Lindgren wrote: To deal with the init order issues, you can pass a set_power function pointer in platform_data that the driver can use. Or set up a fixed regulator for it. I'm already working on the follow up patch series mentioned in the cover letter, and yes, I'm using the fixed regulator. Be patient, please, as my resources are somehow limited. Yes, I understand. For this patch I'm fine with the late_initcall changes Russell suggested, then the rest can be done in separate patches later on. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] omap-serial: add RS485 mode support
Add support for asserting RTS line while TX is in progress. OMAP
hardware doesn't support auto-RS485 mode so we control the line from
software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX
empty interrupt.
We use SER_RS485_RTS_ON_SEND flag to control the polarity of RTS signal
(RTS is asserted high during transmition if this flag is set and low
otherwise) though I'm not sure if this is what this flag is for...
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Changes from V1:
- rebased onto current linux-omap/master
arch/arm/plat-omap/include/plat/omap-serial.h |3 +
drivers/tty/serial/omap-serial.c | 126 ++---
include/linux/serial_reg.h|2 +
3 files changed, 118 insertions(+), 13 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..d6f5eee 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -136,6 +136,9 @@ struct uart_omap_port {
u32 latency;
u32 calc_latency;
struct work_struct qos_work;
+ struct serial_rs485 rs485;
+ unsigned inttx_in_progress:1,
+ tx_wait_end:1;
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ca24ab3..1483c43 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -39,12 +39,14 @@
#include linux/irq.h
#include linux/pm_runtime.h
#include linux/of.h
+#include linux/uaccess.h
#include plat/dma.h
#include plat/dmtimer.h
#include plat/omap-serial.h
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+#define OMAP_RS485_SUPPORTED (SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND)
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
@@ -126,6 +128,45 @@ static void serial_omap_enable_ms(struct uart_port *port)
pm_runtime_put(up-pdev-dev);
}
+static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
+{
+ if (!(up-ier UART_IER_THRI)) {
+ up-ier |= UART_IER_THRI;
+ serial_out(up, UART_IER, up-ier);
+ }
+}
+
+static inline void serial_omap_disable_ier_thri(struct uart_omap_port *up)
+{
+ if (up-ier UART_IER_THRI) {
+ up-ier = ~UART_IER_THRI;
+ serial_out(up, UART_IER, up-ier);
+ }
+}
+
+static inline void serial_omap_thri_mode(struct uart_omap_port *up)
+{
+ unsigned char scr = serial_in(up, UART_OMAP_SCR);
+
+ if (up-tx_wait_end)
+ scr |= UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+ else
+ scr = ~UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+ serial_out(up, UART_OMAP_SCR, scr);
+}
+
+static inline void serial_omap_update_rts(struct uart_omap_port *up)
+{
+ unsigned char mcr = up-mcr;
+ int rts_on_send = up-rs485.flags SER_RS485_RTS_ON_SEND;
+
+ if ((up-rs485.flags SER_RS485_ENABLED)
+ ((up-tx_in_progress rts_on_send) ||
+!(up-tx_in_progress || rts_on_send)))
+ mcr |= UART_MCR_RTS;
+ serial_out(up, UART_MCR, mcr);
+}
+
static void serial_omap_stop_tx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -146,11 +187,13 @@ static void serial_omap_stop_tx(struct uart_port *port)
}
pm_runtime_get_sync(up-pdev-dev);
- if (up-ier UART_IER_THRI) {
- up-ier = ~UART_IER_THRI;
- serial_out(up, UART_IER, up-ier);
+ if (!(up-rs485.flags SER_RS485_ENABLED)) {
+ serial_omap_disable_ier_thri(up);
+ } else {
+ up-tx_wait_end = 1;
+ serial_omap_thri_mode(up);
+ serial_omap_enable_ier_thri(up);
}
-
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
}
@@ -268,14 +311,6 @@ static void transmit_chars(struct uart_omap_port *up)
serial_omap_stop_tx(up-port);
}
-static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
-{
- if (!(up-ier UART_IER_THRI)) {
- up-ier |= UART_IER_THRI;
- serial_out(up, UART_IER, up-ier);
- }
-}
-
static void serial_omap_start_tx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -283,6 +318,18 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;
+ if (up-rs485.flags SER_RS485_ENABLED) {
+ if (!up-tx_in_progress) {
+ up-tx_in_progress = 1;
+ serial_omap_update_rts(up);
+ }
+ if (up-tx_wait_end) {
+ up-tx_wait_end = 0;
+ serial_omap_thri_mode(up);
+
Re: [PATCH v3 02/11] i2c: OMAP: Add DT support for i2c controller
Hi,
On Tue, Dec 20, 2011 at 8:27 AM, Benoit Cousson b-cous...@ti.com wrote:
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a43d002..dcbc1ec 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -37,6 +37,8 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/io.h
+#include linux/of_i2c.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
[...]
@@ -1165,6 +1195,7 @@ static struct platform_driver omap_i2c_driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
.pm = OMAP_I2C_PM_OPS,
+ .of_match_table = of_match_ptr(omap_i2c_of_match),
},
};
of_match_ptr() comes from linux/of.h, so you need to include that to
not break !CONFIG_OF builds.
-Olof
--
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] omap-serial: add RS485 mode support
Hi, On Tue, Dec 20, 2011 at 10:23:32PM +0100, Ilya Yanok wrote: Add support for asserting RTS line while TX is in progress. OMAP hardware doesn't support auto-RS485 mode so we control the line from software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX empty interrupt. Sorry to bring bad news, but software RS485 is not mainlinable [1]. You can browse linux-serial for RS485 to find more threads about it. Regards, Wolfram [1] http://article.gmane.org/gmane.linux.serial/3619/ -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH v2 1/7 v2] ARM: OMAP1: ams-delta: register latch dependent devices later
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require initialization of their GPIO pins first,
should be moved out of .machine_init down to late_initcall level, as the
gpio-generic driver is not available until device_initcall time. The
latch reset operation, which will be replaced with GPIO initialization,
must also be moved to late_initcall for the same reason.
Since there was already another, separate arch_initcall function for
setting up one of those latch dependent devices, the on-board modem
device, reuse that function, i.e., rename it to a name that matches the
new purpose, extend with other device setup relocated from
.machine_init, and move down to the late_initcall level.
While being at it, add missing gpio_free() in case the modem platform
device registration fails.
Thanks to Tony Lindgren t...@atomide.com who suggested this approach
instead of shifting up the gpio-generic driver initialization.
In addition, defer registration of the Amstrad Delta ASoC and serio
devices, done from their device driver files, until late_initcall time,
as those drivers will depend on their GPIO pins already requested from
the board late_init() function until updated to register their GPIO pins
themselves.
Created and tested against linux-3.2-rc6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes since the initial version of this patch:
* use late_initcall() unconditionally in modules, requested by Russell
King (thanks!); an updated patch 7/7 will follow,
* in the changelog message, move credits to Tony up a bit, since the
person responsible for other changes (he might not necessarily like)
is me, not him ;).
Comments copied from this patch initial submission:
This patch was not present in the initial submission, it replaces the
old patch 1/10, providing an alternative solution not touching the
gpio-generic driver.
arch/arm/mach-omap1/board-ams-delta.c | 28
drivers/input/serio/ams_delta_serio.c |2 +-
sound/soc/omap/ams-delta.c|2 +-
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b0f15d2..50987c9 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -275,11 +275,14 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
};
static struct platform_device *ams_delta_devices[] __initdata = {
- ams_delta_nand_device,
ams_delta_kp_device,
+ ams_delta_camera_device,
+};
+
+static struct platform_device *late_devices[] __initdata = {
+ ams_delta_nand_device,
ams_delta_lcd_device,
ams_delta_led_device,
- ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
-
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
#ifdef CONFIG_LEDS_TRIGGERS
@@ -345,13 +345,18 @@ static struct platform_device ams_delta_modem_device = {
},
};
-static int __init ams_delta_modem_init(void)
+static int __init late_init(void)
{
int err;
if (!machine_is_ams_delta())
return -ENODEV;
+ /* Clear latch2 (NAND, LCD, modem enable) */
+ ams_delta_latch2_write(~0, 0);
+
+ platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+
omap_cfg_reg(M14_1510_GPIO2);
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
@@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void)
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
- return platform_device_register(ams_delta_modem_device);
+ err = platform_device_register(ams_delta_modem_device);
+ if (err)
+ goto gpio_free;
+ return 0;
+
+gpio_free:
+ gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+ return err;
}
-arch_initcall(ams_delta_modem_init);
+late_initcall(late_init);
static void __init ams_delta_map_io(void)
{
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..835d37a 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -165,7 +165,7 @@ serio:
kfree(ams_delta_serio);
return err;
}
-module_init(ams_delta_serio_init);
+late_initcall(ams_delta_serio_init);
static void __exit ams_delta_serio_exit(void)
{
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index ccb8a6a..be81bc7
Re: [PATCH V2] omap-serial: add RS485 mode support
Hi Wolfram, On 21.12.2011 01:53, Wolfram Sang wrote: Add support for asserting RTS line while TX is in progress. OMAP hardware doesn't support auto-RS485 mode so we control the line from software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX empty interrupt. Sorry to bring bad news, but software RS485 is not mainlinable [1]. You can browse linux-serial for RS485 to find more threads about it. I see. Actually I searched the lists and seen that completely software solution (using timers) was never merged. This is somewhere in between: hardware can fire an interrupt exactly after both TX FIFO and shift register are emptied so it's only the interrupt latency that affects the timing. Thanks for your reply anyway. We will have to maintain this patch in our tree then. Regards, Ilya. -- 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] input: serio: ams-delta: toggle keyboard power over GPIO
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
While requesting and initializing GPIO pins used, also take care of one
extra pin KEYBRD_DATAOUT which, even if not used by the driver, belongs
to the device and affects its functioning.
Once done, move the driver initialization back to the device_initcall
level, reverting the temporary chane introduced with patch 1/7 ARM:
OMAP1: ams-delta: register latch dependent devices later. That change
is no longer required once the driver takes care of registering used
GPIO pins, and it's better to initialize the device before others using
the latch2 based GPIO pins, otherwise a garbage is reported on boot,
perhaps due to random data already captured by the FIQ handler while the
keyboard related latch bits are written with random values during
initialization of those other latch2 dependent devices.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
I'm submitting only this one refreshed on top of updated 1/7. All others
(2/7-6/7) don't require any refresh, can be rebased smoothly.
Thanks,
Janusz
Changes against version 2:
* refreshed on top of updated patch 1/7 v2,
* changelog: corrected patch 1/7 summary (was inaccurate).
Changes against initial version:
* was 9/10,
* rebased on top of v2 of patch 2/7, just in case,
* moved AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT pin handling from the board
code to the driver,
* reverted a temporary change to the driver initcall level, introduced
by the new solution provided with patch 1/7.
arch/arm/mach-omap1/board-ams-delta.c | 10
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/input/serio/ams_delta_serio.c | 53
:x 3 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 3aba8f9..673cf21 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -227,16 +227,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_pwr,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_dataout,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
.flags = GPIOF_OUT_INIT_LOW,
.label = scard_rstin,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index e9ad673..027e79e 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
-#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define AMD_DELTA_LATCH2_SCARD_CMDVCC 0x0800
#define AMS_DELTA_LATCH2_MODEM_NRESET 0x1000
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index 835d37a..ef1ec40 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void
*dev_id)
static int ams_delta_serio_open(struct serio *serio)
{
/* enable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
- AMD_DELTA_LATCH2_KEYBRD_PWR);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
return 0;
}
@@ -101,9 +100,32 @@ static int ams_delta_serio_open(struct serio *serio)
static void ams_delta_serio_close(struct serio *serio)
{
/* disable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-data,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-clock,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-power,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-dataout,
+ },
+};
+
static int __init ams_delta_serio_init(void)
{
int err;
@@ -123,19 +145,11 @@ static int __init ams_delta_serio_init(void)
Re: [PATCH] am35xx-emac: move generic EMAC init to separate file
Hi Paul, On 16.12.2011 10:13, Paul Walmsley wrote: Ok, let's wait for Paul's answer and then I'll prepare a separate patch. Unfortunately the AM3517 TRM (SPRUGR0) here doesn't really have the same level of clock integration information that the WBU TRMs have, so it's kind of hard to tell what's going on :-( Looking at Figure 22-1 EMAC and MDIO Block Diagram, it appears that what we call emac_fck is really just an optional functional clock for the MDIO PHY? Hm. I have to admit I'm completely lost here. CONTROL_IPSS_CLK_CTRL register has bit controlling Func clock of CPGMAC. But there is no mention of this clock anywhere else in the manual. I can't find neither where it comes from nor how it's used. According to the current sources it comes from external 50MHz RMII clock, do you think this is correct? EMAC section speaks something about variable frequency peripheral clock which is used to generate MDIO bus clock signal. But I can't find any information on that clock in the other parts of the document. It seems to me the EMAC section was just copied from DaVinci RM without any editing... And it sounds like the AM35xx clock that we call emac_ick is actually a combined interface and functional clock for the EMAC and MDIO IP blocks? I guess a combined interface/functional clock would make sense, since the EMAC seems to contain a DMA controller. Maybe Ranjith can provide some more information; he's cc'ed. In any case, your changes sound reasonable to me, so a patch to the clock file sounds good. I'd suggest both changing the clkdev aliases and renaming emac_fck - that's a confusing name and I don't think it's in the TRM as such. Actually it's called Func clock in the manual (see CONTROL_IPSS_CLK_CTRL). Do you still think we have to rename it? I have another concern: changing clkdev aliases make things work for me but now I'm not sure if this change is really correct... Regards, Ilya. -- 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] am35xx-emac: move generic EMAC init to separate file
AM35xx SoCs include DaVinci EMAC IP. Initialization code in
board-am3517evm.c is pretty board independent and will work for any
AM35xx based board so move this code to it's own file to be reused by
other boards.
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Changes from V1:
- removed clock aliases
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/am35xx-emac.c | 131 +
arch/arm/mach-omap2/am35xx-emac.h | 16
arch/arm/mach-omap2/board-am3517evm.c | 114 +
4 files changed, 152 insertions(+), 112 deletions(-)
create mode 100644 arch/arm/mach-omap2/am35xx-emac.c
create mode 100644 arch/arm/mach-omap2/am35xx-emac.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..5d75cb5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -270,4 +270,7 @@ smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o
+emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
+obj-y += $(emac-m) $(emac-y)
+
obj-y += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
new file mode 100644
index 000..eb23a09
--- /dev/null
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ * Author: Ranjith Lohithakshan ranji...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/davinci_emac.h
+#include linux/platform_device.h
+#include plat/irqs.h
+#include mach/am35xx.h
+
+#include control.h
+
+static struct mdio_platform_data am35xx_mdio_pdata;
+
+static struct resource am35xx_mdio_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+ .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device am35xx_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(am35xx_mdio_resources),
+ .resource = am35xx_mdio_resources,
+ .dev.platform_data = am35xx_mdio_pdata,
+};
+
+static void am35xx_enable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+ AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35xx_disable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct emac_platform_data am35xx_emac_pdata = {
+ .ctrl_reg_offset= AM35XX_EMAC_CNTRL_OFFSET,
+ .ctrl_mod_reg_offset= AM35XX_EMAC_CNTRL_MOD_OFFSET,
+ .ctrl_ram_offset= AM35XX_EMAC_CNTRL_RAM_OFFSET,
+ .ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE,
+ .version= EMAC_VERSION_2,
+ .hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
+ .interrupt_enable = am35xx_enable_ethernet_int,
+ .interrupt_disable = am35xx_disable_ethernet_int,
+};
+
+static struct resource am35xx_emac_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE,
+ .end= AM35XX_IPSS_EMAC_BASE + 0x2,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+ .end= INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+ .end= INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start =
[PATCH] OMAP3: clock3xxx_data: change EMAC clocks aliases
Rename EMAC clocks to match driver expectations: both davinci_emac and
davinci_mdio drivers call clk_get(dev, NULL) so we have to provide
(davinci_emac, NULL) and (davinci_mdio.0, NULL) clocks instead of
(davinci_emac, emac_clk) and (davinci_emac, phy_clk) resp.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
arch/arm/mach-omap2/clock3xxx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d75e5f6..1a60661 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3465,8 +3465,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, ipss_ick, ipss_ick, CK_AM35XX),
CLK(NULL, rmii_ck, rmii_ck, CK_AM35XX),
CLK(NULL, pclk_ck, pclk_ck, CK_AM35XX),
- CLK(davinci_emac, emac_clk, emac_ick, CK_AM35XX),
- CLK(davinci_emac, phy_clk, emac_fck, CK_AM35XX),
+ CLK(davinci_emac, NULL, emac_ick, CK_AM35XX),
+ CLK(davinci_mdio.0, NULL, emac_fck, CK_AM35XX),
CLK(vpfe-capture, master, vpfe_ick, CK_AM35XX),
CLK(vpfe-capture, slave,vpfe_fck, CK_AM35XX),
CLK(musb-am35x, ick, hsotgusb_ick_am35xx,
CK_AM35XX),
--
1.7.6.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 2/3] cpuidle: fix error handling in __cpuidle_register_device
Fix the error handling in __cpuidle_register_device to include
the missing list_del. Move it to a label, which will simplify
the error handling when coupled states are added.
Signed-off-by: Colin Cross ccr...@android.com
---
drivers/cpuidle/cpuidle.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 1486b3c..ea00a16 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -318,13 +318,18 @@ static int __cpuidle_register_device(struct
cpuidle_device *dev)
per_cpu(cpuidle_devices, dev-cpu) = dev;
list_add(dev-device_list, cpuidle_detected_devices);
- if ((ret = cpuidle_add_sysfs(sys_dev))) {
- module_put(cpuidle_driver-owner);
- return ret;
- }
+ ret = cpuidle_add_sysfs(sys_dev);
+ if (ret)
+ goto err_sysfs;
dev-registered = 1;
return 0;
+
+err_sysfs:
+ module_put(cpuidle_driver-owner);
+ list_del(dev-device_list);
+ per_cpu(cpuidle_devices, dev-cpu) = NULL;
+ return ret;
}
/**
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] cpuidle: refactor out cpuidle_enter_state
Split the code to enter a state and update the stats into a helper
function, cpuidle_enter_state, and export it. This function will
be called by the coupled state code to handle entering the safe
state and the final coupled state.
Signed-off-by: Colin Cross ccr...@android.com
---
drivers/cpuidle/cpuidle.c | 43 +--
drivers/cpuidle/cpuidle.h |2 ++
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 06ce268..1486b3c 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -54,6 +54,34 @@ static void cpuidle_kick_cpus(void) {}
static int __cpuidle_register_device(struct cpuidle_device *dev);
/**
+ * cpuidle_enter_state
+ *
+ * enter the state and update stats
+ */
+int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
+ int next_state)
+{
+ int entered_state;
+ struct cpuidle_state *target_state;
+
+ target_state = drv-states[next_state];
+
+ entered_state = target_state-enter(dev, drv, next_state);
+
+ if (entered_state = 0) {
+ /* Update cpuidle counters */
+ /* This can be moved to within driver enter routine
+* but that results in multiple copies of same code.
+*/
+ dev-states_usage[entered_state].time +=
+ (unsigned long long)dev-last_residency;
+ dev-states_usage[entered_state].usage++;
+ }
+
+ return entered_state;
+}
+
+/**
* cpuidle_idle_call - the main idle loop
*
* NOTE: no locks or semaphores should be used here
@@ -63,7 +91,6 @@ int cpuidle_idle_call(void)
{
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
struct cpuidle_driver *drv = cpuidle_get_driver();
- struct cpuidle_state *target_state;
int next_state, entered_state;
if (off)
@@ -92,26 +119,14 @@ int cpuidle_idle_call(void)
return 0;
}
- target_state = drv-states[next_state];
-
trace_power_start(POWER_CSTATE, next_state, dev-cpu);
trace_cpu_idle(next_state, dev-cpu);
- entered_state = target_state-enter(dev, drv, next_state);
+ entered_state = cpuidle_enter_state(dev, drv, next_state);
trace_power_end(dev-cpu);
trace_cpu_idle(PWR_EVENT_EXIT, dev-cpu);
- if (entered_state = 0) {
- /* Update cpuidle counters */
- /* This can be moved to within driver enter routine
-* but that results in multiple copies of same code.
-*/
- dev-states_usage[entered_state].time +=
- (unsigned long long)dev-last_residency;
- dev-states_usage[entered_state].usage++;
- }
-
/* give the governor an opportunity to reflect on the outcome */
if (cpuidle_curr_governor-reflect)
cpuidle_curr_governor-reflect(dev, entered_state);
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index 38c3fd8..dd2df8f 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -14,6 +14,8 @@ extern struct list_head cpuidle_detected_devices;
extern struct mutex cpuidle_lock;
extern spinlock_t cpuidle_driver_lock;
extern int cpuidle_disabled(void);
+int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
+ int next_state);
/* idle loop */
extern void cpuidle_install_idle_handler(void);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] cpuidle: add support for states that affect multiple cpus
On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the cpus cannot be independently powered down, either due to sequencing restrictions (on Tegra 2, cpu 0 must be the last to power down), or due to HW bugs (on OMAP4460, a cpu powering up will corrupt the gic state unless the other cpu runs a work around). Each cpu has a power state that it can enter without coordinating with the other cpu (usually Wait For Interrupt, or WFI), and one or more coupled power states that affect blocks shared between the cpus (L2 cache, interrupt controller, and sometimes the whole SoC). Entering a coupled power state must be tightly controlled on both cpus. The easiest solution to implementing coupled cpu power states is to hotplug all but one cpu whenever possible, usually using a cpufreq governor that looks at cpu load to determine when to enable the secondary cpus. This causes problems, as hotplug is an expensive operation, so the number of hotplug transitions must be minimized, leading to very slow response to loads, often on the order of seconds. This file implements an alternative solution, where each cpu will wait in the WFI state until all cpus are ready to enter a coupled state, at which point the coupled state function will be called on all cpus at approximately the same time. Once all cpus are ready to enter idle, they are woken by an smp cross call. At this point, there is a chance that one of the cpus will find work to do, and choose not to enter suspend. A final pass is needed to guarantee that all cpus will call the power state enter function at the same time. During this pass, each cpu will increment the ready counter, and continue once the ready counter matches the number of online coupled cpus. If any cpu exits idle, the other cpus will decrement their counter and retry. To use coupled cpuidle states, a cpuidle driver must: Set struct cpuidle_device.coupled_cpus to the mask of all coupled cpus, usually the same as cpu_possible_mask if all cpus are part of the same cluster. The coupled_cpus mask must be set in the struct cpuidle_device for each cpu. Set struct cpuidle_device.safe_state to a state that is not a coupled state. This is usually WFI. Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each state that affects multiple cpus. Provide a struct cpuidle_state.enter function for each state that affects multiple cpus. This function is guaranteed to be called on all cpus at approximately the same time. The driver should ensure that the cpus all abort together if any cpu tries to abort once the function is called. Signed-off-by: Colin Cross ccr...@android.com Cc: Len Brown len.br...@intel.com Cc: Kevin Hilman khil...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Amit Kucheria amit.kuche...@linaro.org Cc: Arjan van de Ven ar...@linux.intel.com Cc: Trinabh Gupta g.trin...@gmail.com Cc: Deepthi Dharwar deep...@linux.vnet.ibm.com --- drivers/cpuidle/Kconfig |3 + drivers/cpuidle/Makefile |1 + drivers/cpuidle/coupled.c | 413 + drivers/cpuidle/cpuidle.c | 14 ++- drivers/cpuidle/cpuidle.h | 39 + include/linux/cpuidle.h |7 + 6 files changed, 476 insertions(+), 1 deletions(-) create mode 100644 drivers/cpuidle/coupled.c diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig index 7dbc4a8..7a72e55 100644 --- a/drivers/cpuidle/Kconfig +++ b/drivers/cpuidle/Kconfig @@ -18,3 +18,6 @@ config CPU_IDLE_GOV_MENU bool depends on CPU_IDLE NO_HZ default y + +config ARCH_NEEDS_CPU_IDLE_COUPLED + def_bool n diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile index 5634f88..38c8f69 100644 --- a/drivers/cpuidle/Makefile +++ b/drivers/cpuidle/Makefile @@ -3,3 +3,4 @@ # obj-y += cpuidle.o driver.o governor.o sysfs.o governors/ +obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c new file mode 100644 index 000..3fb7d24 --- /dev/null +++ b/drivers/cpuidle/coupled.c @@ -0,0 +1,413 @@ +/* + * coupled.c - helper functions to enter the same idle state on multiple cpus + * + * Copyright (c) 2011 Google, Inc. + * + * Author: Colin Cross ccr...@android.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#include linux/kernel.h +#include linux/cpu.h +#include linux/cpuidle.h +#include linux/mutex.h +#include linux/sched.h +#include linux/slab.h +#include linux/spinlock.h + +#include
[PATCH 0/3] coupled cpuidle state support
On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
cpus cannot be independently powered down, either due to
sequencing restrictions (on Tegra 2, cpu 0 must be the last to
power down), or due to HW bugs (on OMAP4460, a cpu powering up
will corrupt the gic state unless the other cpu runs a work
around). Each cpu has a power state that it can enter without
coordinating with the other cpu (usually Wait For Interrupt, or
WFI), and one or more coupled power states that affect blocks
shared between the cpus (L2 cache, interrupt controller, and
sometimes the whole SoC). Entering a coupled power state must
be tightly controlled on both cpus.
The easiest solution to implementing coupled cpu power states is
to hotplug all but one cpu whenever possible, usually using a
cpufreq governor that looks at cpu load to determine when to
enable the secondary cpus. This causes problems, as hotplug is an
expensive operation, so the number of hotplug transitions must be
minimized, leading to very slow response to loads, often on the
order of seconds.
This patch series implements an alternative solution, where each
cpu will wait in the WFI state until all cpus are ready to enter
a coupled state, at which point the coupled state function will
be called on all cpus at approximately the same time.
Once all cpus are ready to enter idle, they are woken by an smp
cross call. At this point, there is a chance that one of the
cpus will find work to do, and choose not to enter suspend. A
final pass is needed to guarantee that all cpus will call the
power state enter function at the same time. During this pass,
each cpu will increment the ready counter, and continue once the
ready counter matches the number of online coupled cpus. If any
cpu exits idle, the other cpus will decrement their counter and
retry.
To use coupled cpuidle states, a cpuidle driver must:
Set struct cpuidle_device.coupled_cpus to the mask of all
coupled cpus, usually the same as cpu_possible_mask if all cpus
are part of the same cluster. The coupled_cpus mask must be
set in the struct cpuidle_device for each cpu.
Set struct cpuidle_device.safe_state to a state that is not a
coupled state. This is usually WFI.
Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
state that affects multiple cpus.
Provide a struct cpuidle_state.enter function for each state
that affects multiple cpus. This function is guaranteed to be
called on all cpus at approximately the same time. The driver
should ensure that the cpus all abort together if any cpu tries
to abort once the function is called.
This series was functionally tested on v3.0, but has only been
compile-tested on v3.2 after the removal of per-cpu state fields.
This patch set has a few disadvantages over the hotplug governor,
but I think they are all fairly minor:
* Worst-case interrupt latency can be increased. If one cpu
receives an interrupt while the other is spinning in the
ready_count loop, the second cpu will be stuck with
interrupts off until the first cpu finished processing
its interrupt and exits idle. This will increase the worst
case interrupt latency by the worst-case interrupt processing
time, but should be very rare.
* Interrupts are processed while still inside pm_idle.
Normally, interrupts are only processed at the very end of
pm_idle, just before it returns to the idle loop. Coupled
states requires processing interrupts inside
cpuidle_enter_state_coupled in order to distinguish between
the smp_cross_call from another cpu that is now idle and an
interrupt that should cause idle to exit.
I don't see a way to fix this without either being able to
read the next pending irq from the interrupt chip, or
querying the irq core for which interrupts were processed.
* Since interrupts are processed inside cpuidle, the next
timer event could change. The new timer event will be
handled correctly, but the idle state decision made by
the governor will be out of date, and will not be revisited.
The governor select function could be called again every time,
but this could lead to a lot of work being done by an idle
cpu if the other cpu was mostly busy.
* The spinlock that protects requested_state and ready_count is
should probably be replaced with careful use of atomics and
barriers.
None of the platforms I work with have an SMP idle implementation
upstream, so I can't easily show a patch that converts a platform
from hotplug governor to coupled cpuidle states. Instead, I'll
give a quick example implementation assuming functions that handle
hotplug and single-cpu idle already exist.
static int mach_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
ktime_t enter, exit;
s64 us;
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
Re: [PATCH] am35xx-emac: move generic EMAC init to separate file
On Wed, 21 Dec 2011, Ilya Yanok wrote: On 16.12.2011 10:13, Paul Walmsley wrote: Ok, let's wait for Paul's answer and then I'll prepare a separate patch. Unfortunately the AM3517 TRM (SPRUGR0) here doesn't really have the same level of clock integration information that the WBU TRMs have, so it's kind of hard to tell what's going on :-( Looking at Figure 22-1 EMAC and MDIO Block Diagram, it appears that what we call emac_fck is really just an optional functional clock for the MDIO PHY? Hm. I have to admit I'm completely lost here. CONTROL_IPSS_CLK_CTRL register has bit controlling Func clock of CPGMAC. Yeah, I don't think that's correct. Or rather, it's imprecise. It might be true from a strict integration perspective, but it's misleading. But there is no mention of this clock anywhere else in the manual. I can't find neither where it comes from nor how it's used. According to the current sources it comes from external 50MHz RMII clock, do you think this is correct? I think that part is correct. And it sounds like the AM35xx clock that we call emac_ick is actually a combined interface and functional clock for the EMAC and MDIO IP blocks? I guess a combined interface/functional clock would make sense, since the EMAC seems to contain a DMA controller. Maybe Ranjith can provide some more information; he's cc'ed. In any case, your changes sound reasonable to me, so a patch to the clock file sounds good. I'd suggest both changing the clkdev aliases and renaming emac_fck - that's a confusing name and I don't think it's in the TRM as such. Actually it's called Func clock in the manual (see CONTROL_IPSS_CLK_CTRL). Do you still think we have to rename it? I guess we have other optional functional clocks with _fck suffixes, so it's probably not such a big deal. I have another concern: changing clkdev aliases make things work for me but now I'm not sure if this change is really correct... Well, sounds like it's better than what we currently have. - Paul -- 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] mmc: omap: remove clock rate hard coding
On Tue, Dec 20, 2011 at 15:12, S, Venkatraman wrote:
From: Balaji TK balaj...@ti.com
MMC master clock rate can vary for each instance of the MMC controller
on the device. Use clk_get_rate instead to get the value.
Signed-off-by: Balaji TK balaj...@ti.com
Reviewed-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d5fe43d..5b35c7e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -120,7 +120,6 @@
#define MMC_AUTOSUSPEND_DELAY100
#define MMC_TIMEOUT_MS 20
-#define OMAP_MMC_MASTER_CLOCK9600
#define OMAP_MMC_MIN_CLOCK 40
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAME omap_hsmmc
@@ -598,12 +597,12 @@ static void omap_hsmmc_disable_irq(struct
omap_hsmmc_host *host)
}
/* Calculate divisor for the given clock frequency */
-static u16 calc_divisor(struct mmc_ios *ios)
+static u16 calc_divisor(struct omap_hsmmc_host *host, struct mmc_ios *ios)
{
u16 dsor = 0;
if (ios-clock) {
- dsor = DIV_ROUND_UP(OMAP_MMC_MASTER_CLOCK, ios-clock);
+ dsor = DIV_ROUND_UP(clk_get_rate(host-fclk), ios-clock);
if (dsor 250)
dsor = 250;
}
@@ -623,7 +622,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(ios) 6) | (DTO 16);
+ regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
--
1.7.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
Tested on AM335x platform.
Tested-by: Hebbar, Gururaja gururaja.heb...@ti.com
Regards,
Gururaja
--
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] am35xx-emac: move generic EMAC init to separate file
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ilya Yanok
Sent: Wednesday, December 21, 2011 4:57 AM
To: linux-omap@vger.kernel.org
Cc: sash...@emcraft.com; Ilya Yanok
Subject: [PATCH V2] am35xx-emac: move generic EMAC init to separate file
AM35xx SoCs include DaVinci EMAC IP. Initialization code in
board-am3517evm.c is pretty board independent and will work for any
AM35xx based board so move this code to it's own file to be reused by
other boards.
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Changes from V1:
- removed clock aliases
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/am35xx-emac.c | 131
+
arch/arm/mach-omap2/am35xx-emac.h | 16
arch/arm/mach-omap2/board-am3517evm.c | 114 +---
-
4 files changed, 152 insertions(+), 112 deletions(-)
create mode 100644 arch/arm/mach-omap2/am35xx-emac.c
create mode 100644 arch/arm/mach-omap2/am35xx-emac.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..5d75cb5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -270,4 +270,7 @@ smsc911x-$(CONFIG_SMSC911X) :=
gpmc-smsc911x.o
obj-y+= $(smsc911x-m) $(smsc911x-y)
obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o
+emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
+obj-y+= $(emac-m) $(emac-y)
+
obj-y+= common-board-devices.o
twl-common.o
diff --git a/arch/arm/mach-omap2/am35xx-emac.c b/arch/arm/mach-
omap2/am35xx-emac.c
new file mode 100644
index 000..eb23a09
--- /dev/null
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ * Author: Ranjith Lohithakshan ranji...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/davinci_emac.h
+#include linux/platform_device.h
+#include plat/irqs.h
+#include mach/am35xx.h
+
+#include control.h
+
+static struct mdio_platform_data am35xx_mdio_pdata;
+
+static struct resource am35xx_mdio_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+ .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
This will not be board independent, using AM35xx everywhere.
To make it completely board independent, you should get all this platform
specific data from board file. Probably have emac_init() function here and
pass the data.
Do you know any other platform or device using this IP?
Thanks,
Vaibhav
+
+static struct platform_device am35xx_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(am35xx_mdio_resources),
+ .resource = am35xx_mdio_resources,
+ .dev.platform_data = am35xx_mdio_pdata,
+};
+
+static void am35xx_enable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+ AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35xx_disable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct emac_platform_data am35xx_emac_pdata = {
+ .ctrl_reg_offset= AM35XX_EMAC_CNTRL_OFFSET,
+ .ctrl_mod_reg_offset= AM35XX_EMAC_CNTRL_MOD_OFFSET,
+ .ctrl_ram_offset= AM35XX_EMAC_CNTRL_RAM_OFFSET,
+ .ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE,
+ .version= EMAC_VERSION_2,
+ .hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
+ .interrupt_enable =
[PATCH] omap: use usleep_range() instead of mdelay()/udelay()
From e4db974edb5c46360465462518a88b83f1bdedf6 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov dmitry.anti...@linaro.org
Date: Wed, 21 Dec 2011 10:57:08 +0400
Subject: [PATCH] omap: use usleep_range() instead of mdelay()/udelay()
---
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
arch/arm/mach-omap2/vc.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 58775e3..e5dff64 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -145,7 +145,7 @@ int omap4430_phy_suspend(struct device *dev, int suspend)
/* power on the phy */
if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
__raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
+ usleep_range(20, 201000);
}
/* restore the context */
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 031d116..57f44d5 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -151,7 +151,7 @@ void omap_vc_post_scale(struct voltagedomain *voltdm,
/* SMPS slew rate / step size. 2us added as buffer. */
smps_delay = ((smps_steps * voltdm-pmic-step_size) /
voltdm-pmic-slew_rate) + 2;
- udelay(smps_delay);
+ usleep_range(smps_delay, smps_delay + 10);
}
/* vc_bypass_scale - VC bypass method of voltage scaling */
--
1.7.7.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
