[PATCH] Fix IGEPv2 second MMC channel power supply
Commit 72f381ba056 removed an unused regulator entry, but left
the second MMC channel (used by the Libertas WLAN mudule) without
link to power regulator. This causes the SDIO module to fail being
detected.
This patch adds a second supply to the existing MMC1 regulator,
and let MMC2 hang off it. With that patch, the second channel is
properly detected.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier m...@misterjones.org
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
Note that this doesn't fix WLAN itself on 2.6.37-rc1...
arch/arm/mach-omap2/board-igep0020.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..b66d114 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -257,8 +257,9 @@ static inline void __init igep2_init_smsc911x(void) { }
static struct omap_board_config_kernel igep2_config[] __initdata = {
};
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
- .supply = vmmc,
+static struct regulator_consumer_supply igep2_vmmc1_supplies[] = {
+ [0] = { .supply = vmmc, },
+ [1] = { .supply = vmmc, },
};
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
@@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = igep2_vmmc1_supply,
+ .num_consumer_supplies = 2,
+ .consumer_supplies = igep2_vmmc1_supplies,
};
static struct omap2_hsmmc_info mmc[] = {
@@ -376,7 +377,8 @@ static int igep2_twl_gpio_setup(struct device *dev,
* link regulators to MMC adapters ... we know the
* regulators will be set up only *after* we return.
*/
- igep2_vmmc1_supply.dev = mmc[0].dev;
+ igep2_vmmc1_supplies[0].dev = mmc[0].dev;
+ igep2_vmmc1_supplies[1].dev = mmc[1].dev;
/*
* REVISIT: need ehci-omap hooks for external VBUS
--
1.7.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
Hello. On 14-11-2010 14:34, Marc Zyngier wrote: Commit 72f381ba056 removed an unused regulator entry, but left Linus has aksed to also specify the commit summary in parentheses. Signed-off-by: Marc Zyngierm...@misterjones.org Cc: Enric Balletbo i Serraeballe...@gmail.com Cc: Tony Lindgrent...@atomide.com WBR, Sergei -- 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] Fix IGEPv2 second MMC channel power supply
Hi,
On Sun, 14 Nov 2010 11:34:12 +, Marc Zyngier m...@misterjones.org
wrote:
@@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = igep2_vmmc1_supply,
+ .num_consumer_supplies = 2,
use ARRAY_SIZE(igep2_vmmc1_supplies),
--
balbi
--
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] Fix IGEPv2 second MMC channel power supply
2010/11/14 Felipe Balbi m...@felipebalbi.com:
Hi,
On Sun, 14 Nov 2010 11:34:12 +, Marc Zyngier m...@misterjones.org
wrote:
@@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = igep2_vmmc1_supply,
+ .num_consumer_supplies = 2,
use ARRAY_SIZE(igep2_vmmc1_supplies),
--
balbi
Why we need to define an unexistent regulator in board file ? This
should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
configuration ?
Cheers,
Enric
--
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] Fix IGEPv2 second MMC channel power supply
On Sun, 14 Nov 2010 19:11:46 +0100 Enric Balletbò i Serra eballe...@gmail.com wrote: Why we need to define an unexistent regulator in board file ? This should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel configuration ? I'm not adding another regulator, but instead simply exposing the fact (or rather my guess) that the same regulator (vmmc1) is powering the two MMC channels. Not having access to the board schematics, I can't tell if that reflects the reality or not. But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's just papering over the issue. We should be exposing what's really on the board (a fixed regulator if that's the case). M. -- I'm the slime oozin' out from your TV set... -- 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.
Boards can register such devices using platform data such as in the following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
.polarity = 1 // Active-high
};
static struct platform_device pwm_device = {
.name = omap-pwm,
.id = 0,
.dev= {
.platform_data = pwm_config
}
};
Signed-off-by: Grant Erickson maratho...@gmail.com
---
arch/arm/plat-omap/Kconfig|9 +
arch/arm/plat-omap/Makefile |2 +
arch/arm/plat-omap/include/plat/pwm.h | 29 ++
arch/arm/plat-omap/pwm.c | 450 +
4 files changed, 490 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 92c5bb7..4797b0e 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -164,6 +164,15 @@ config OMAP_DM_TIMER
help
Select this option if you want to use OMAP Dual-Mode timers.
+config HAVE_PWM
+ bool Use PWM timers
+ depends on OMAP_DM_TIMER
+ help
+ Select this option if you want to be able to request and use
+ one or more of the OMAP dual-mode timers as a generic PWM device
+ compatible with other generic PWM drivers such as the backlight or
+ beeper driver.
+
config OMAP_SERIAL_WAKE
bool Enable wake-up events for serial ports
depends on ARCH_OMAP1 OMAP_MUX
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..9e5347b 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,5 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+
+obj-$(CONFIG_HAVE_PWM) += pwm.o
diff --git a/arch/arm/plat-omap/include/plat/pwm.h
b/arch/arm/plat-omap/include/plat/pwm.h
new file mode 100644
index 000..04030cd
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/pwm.h
@@ -0,0 +1,29 @@
+/*
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.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.
+ *
+ *Description:
+ * This file is defines platform-specific configuration data for
+ * the OMAP generic PWM platform driver.
+ */
+
+#ifndef _OMAP2_PWM_H
+#define _OMAP2_PWM_H
+
+/**
+ * struct omap2_pwm_platform_config - OMAP platform-specific data for PWMs
+ * @timer_id: the OMAP dual-mode timer ID.
+ * @polarity: the polarity (active-high or -low) of the PWM.
+ *
+ * This identifies the OMAP dual-mode timer (dmtimer) that will be bound
+ * to the PWM.
+ */
+struct omap2_pwm_platform_config {
+ int timer_id;
+ bool polarity;
+};
+
+#endif /* _OMAP2_PWM_H */
diff --git a/arch/arm/plat-omap/pwm.c b/arch/arm/plat-omap/pwm.c
new file mode 100644
index 000..c6d103d
--- /dev/null
+++ b/arch/arm/plat-omap/pwm.c
@@ -0,0 +1,450 @@
+/*
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.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.
+ *
+ *Description:
+ * This file is the core OMAP2/3 support for the generic, Linux
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pwm.h
+#include mach/hardware.h
+#include plat/dmtimer.h
+#include plat/pwm.h
+
+/* Preprocessor Definitions */
+
+#undef OMAP_PWM_DEBUG
+
+#if defined(OMAP_PWM_DEBUG)
+#define DBG(args...) \
+ do {\
+ pr_info(args); \
+ } while (0)
+#define DEV_DBG(dev, args...) \
+ do {\
+ dev_info(dev, args);\
+ } while (0)
+#else
+#define DBG(args...) \
+ do { } while (0)
+#define DEV_DBG(dev, args...) \
+ do { } while (0)
+#endif /* defined(OMAP_PWM_DEBUG) */
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+/* Type Definitions */
+
+/**
+ * struct pwm_device - opaque internal PWM device instance state
+ * @head: list head for all PWMs managed by this driver.
+ * @pdev: corresponding platform device associated with this device instance.
+ * @dm_timer:
RE: [PATCH v2 0/2] OMAP3: Display Support
Tomi Valkeinen wrote: Hi, On Tue, 2010-10-26 at 06:28 +0200, ext Samreen wrote: This patch series adds the Display Support for OMAP3 platforms and the corresponding changes in the board files. Version2: - Optimised to configure INTBR from gpio to PWM1 mode setting and enabling of the PWM1 mode only when its not in PWM1 mode. This patch set doesn't seem to apply to the latest kernel, conflicts in arch/arm/mach-omap2/board-zoom-peripherals.c and arch/arm/mach-omap2/include/mach/board-zoom.h. Can you rebase and resend? Tomi Sure, Will rebase and post it out soon. Warm Regards, Samreen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
Hi, bryan...@canonical.com wrote: On Wed, Nov 10, 2010 at 10:35 PM, Tomi Valkeinen [snip] For both panel power on and off some panels require some sleep times: when powering on, the video interface has to be enabled for some time before the panel can be enabled, and similarly when powering off the video interface needs to be on for some time after the panel has been disabled. Actually, in my previous version patches, I introduced .power_on_delay and .power_off_delay in panel_configs, which contains the sleep value for msleep(). But Archit told me this is not necessary, so I removed that. I had asked you to remove it from omap_dss_device to a more specific struct for the generic dpi driver :) It should be in the 'panel_generic_dpi_data' struct now. Regards, 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
Re: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
On Mon, Nov 15, 2010 at 12:05 PM, Taneja, Archit arc...@ti.com wrote: Hi, bryan...@canonical.com wrote: On Wed, Nov 10, 2010 at 10:35 PM, Tomi Valkeinen [snip] For both panel power on and off some panels require some sleep times: when powering on, the video interface has to be enabled for some time before the panel can be enabled, and similarly when powering off the video interface needs to be on for some time after the panel has been disabled. Actually, in my previous version patches, I introduced .power_on_delay and .power_off_delay in panel_configs, which contains the sleep value for msleep(). But Archit told me this is not necessary, so I removed that. I had asked you to remove it from omap_dss_device to a more specific struct for the generic dpi driver :) Yeah, no problem. It should be in the 'panel_generic_dpi_data' struct now. I think the delay value is related to panel, which can be found in sharp_ls and sharp_lq drivers. So it might be in the panel_configs struct? Thanks, -Bryan -- 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] OMAP4: Extend clock database.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, November 10, 2010 5:54 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit Subject: Re: [PATCH v2] OMAP4: Extend clock database. Thara Gopinath th...@ti.com writes: This patch extends the OMAP4 clock data to include various x2 clock nodes as the clock framework skips a *2 whie calculating the dpll locked frequency. The clock databse extensions are autogenerated using the scripts maintained by Benoit Cousson. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Thara Gopinath th...@ti.com The subject could be a bit more descriptive here, something like: OMAP4: clock: add various DPLL x2 clock nodes or something similar. Will fix and post V3 Thanks, 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] OMAP4: Extend clock database.
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Saturday, October 30, 2010 3:07 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; Cousson, Benoit Subject: Re: [PATCH v2] OMAP4: Extend clock database. Thara, On Wed, 27 Oct 2010, Thara Gopinath wrote: This patch extends the OMAP4 clock data to include various x2 clock nodes as the clock framework skips a *2 whie calculating the dpll locked frequency. The clock databse extensions are autogenerated using the scripts maintained by Benoit Cousson. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 427 -- 1 files changed, 248 insertions(+), 179 deletions(-) diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach- omap2/clock44xx_data.c index 1599836..94896af 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -17,10 +17,6 @@ * 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. - * - * XXX Some of the ES1 clocks have been removed/changed; once support - * is added for discriminating clocks by ES level, these should be added back - * in. */ Please don't remove this comment unless you're also adding the ES1 clocks back. Hello Paul, I did not remove this. The script did :-). But I will manually add it back and post v3. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] OMAP3: Display Support
This patch series adds the Display Support for OMAP3 platforms and the corresponding changes in the board files. Version3: - Rebase to the latest LO Version2: - Optimised to configure INTBR from gpio to PWM1 mode setting and enabling of the PWM1 mode only when its not in PWM1 mode. Kishore Y (2): OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3 OMAP3: Enable display on ZOOM2/3/3630SDP arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-display.c | 168 + arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++- arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + arch/arm/mach-omap2/include/mach/board-zoom.h |3 + 7 files changed, 224 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-display.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
From: Kishore Y kishor...@ti.com
Board-zoom-display.c added as a common file for display functionality
on boards zoom2, zoom3 and 3630sdp.
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/board-zoom-display.c | 168 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++-
arch/arm/mach-omap2/include/mach/board-zoom.h |3 +
4 files changed, 221 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..7b20341 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -146,16 +146,19 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
new file mode 100644
index 000..6bcd436
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-zoom-peripherals.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c/twl.h
+#include linux/spi/spi.h
+#include plat/mcspi.h
+#include plat/display.h
+
+#define LCD_PANEL_RESET_GPIO_PROD 96
+#define LCD_PANEL_RESET_GPIO_PILOT 55
+#define LCD_PANEL_QVGA_GPIO56
+
+static void zoom_lcd_panel_init(void)
+{
+ int ret;
+ unsigned char lcd_panel_reset_gpio;
+
+ lcd_panel_reset_gpio = (omap_rev() OMAP3430_REV_ES3_0) ?
+ LCD_PANEL_RESET_GPIO_PROD :
+ LCD_PANEL_RESET_GPIO_PILOT;
+
+ ret = gpio_request(lcd_panel_reset_gpio, lcd reset);
+ if (ret) {
+ pr_err(Failed to get LCD reset GPIO (gpio%d).\n,
+ lcd_panel_reset_gpio);
+ return;
+ }
+ gpio_direction_output(lcd_panel_reset_gpio, 1);
+
+ ret = gpio_request(LCD_PANEL_QVGA_GPIO, lcd qvga);
+ if (ret) {
+ pr_err(Failed to get LCD_PANEL_QVGA_GPIO (gpio%d).\n,
+ LCD_PANEL_QVGA_GPIO);
+ goto err0;
+ }
+ gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
+
+ return;
+err0:
+ gpio_free(lcd_panel_reset_gpio);
+}
+
+static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+}
+
+/*
+ * PWMA/B register offsets (TWL4030_MODULE_PWMA)
+ */
+#define TWL_INTBR_PMBR10xD
+#define TWL_INTBR_GPBR10xC
+#define TWL_LED_PWMON 0x0
+#define TWL_LED_PWMOFF 0x1
+
+static int zoom_set_bl_intensity(struct omap_dss_device *dssdev, int level)
+{
+ unsigned char c;
+ u8 mux_pwm, enb_pwm;
+
+ if (level 100)
+ return -1;
+
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, mux_pwm, TWL_INTBR_PMBR1);
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, enb_pwm, TWL_INTBR_GPBR1);
+
+ if (level == 0) {
+ /* disable pwm1 output and clock */
+ enb_pwm = enb_pwm 0xF5;
+ /* change pwm1 pin to gpio pin */
+ mux_pwm = mux_pwm 0xCF;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR,
+ enb_pwm, TWL_INTBR_GPBR1);
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR,
+
[PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. http://www.spinics.net/lists/linux-omap/msg38995.html sricharan (5): OMAP4: hsmmc: Initialise the mmc mux pins OMAP4: usb-musb: Initialise the usb mux pins. OMAP4: mcbsp: Initialise the mcbsp mux pins OMAP4: board-4430sdp: Initialise the mcspi mux pins OMAP4: serial: Initialise the uart mux pins arch/arm/mach-omap2/board-4430sdp.c | 20 arch/arm/mach-omap2/devices.c | 83 +++ arch/arm/mach-omap2/mcbsp.c | 33 +- arch/arm/mach-omap2/serial.c| 38 arch/arm/mach-omap2/usb-musb.c | 41 + 5 files changed, 214 insertions(+), 1 deletions(-) While doing some internal reviews, there were few debates about existing mux framework usage. I am summarising that discussion here and would like to hear more on this from the community. 1. PAD configuration for all pins should be done in a central place(board file) Pros: a. All pins configured in a central place. Easy to ensure coverage and maintenance. Single place to look for all mux related settings b. Drivers, unless they have run time pad configuration requirements need not worry about muxing. Cons: a. Adds a lot of duplicate data in different board files assuming most of the pins will be connected the same way across different boards. 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP4: hsmmc: Initialise the mmc mux pins
Use the mux framework to initialise the mmc mux pins.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/devices.c | 83 +
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index eaf3799..56b1ac9 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -784,6 +784,89 @@ static inline void omap2_mmc_mux(struct
omap_mmc_platform_data *mmc_controller,
* For MMC3 the pins need to be muxed in the board-*.c files
*/
}
+
+ if (cpu_is_omap44xx()) {
+ switch (controller_nr) {
+ case 0:
+ /* MMC 1 */
+ omap_mux_init_signal(sdmmc1_clk.sdmmc1_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_cmd.sdmmc1_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat0.sdmmc1_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+ if (mmc_controller-slots[0].caps
+ (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+ omap_mux_init_signal(sdmmc1_dat1.sdmmc1_dat1,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat2.sdmmc1_dat2,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat3.sdmmc1_dat3,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ if (mmc_controller-slots[0].caps
+ MMC_CAP_8_BIT_DATA) {
+ omap_mux_init_signal(sdmmc1_dat4.sdmmc1_dat4,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat5.sdmmc1_dat5,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat6.sdmmc1_dat6,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat7.sdmmc1_dat7,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ break;
+ case 1:
+ /* MMC2 */
+ omap_mux_init_signal(gpmc_noe.sdmmc2_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(gpmc_nwe.sdmmc2_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(gpmc_ad0.sdmmc2_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+ if (mmc_controller-slots[0].caps
+ (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+ omap_mux_init_signal(gpmc_ad1.sdmmc2_dat1,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(gpmc_ad2.sdmmc2_dat2,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(gpmc_ad3.sdmmc2_dat3,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ if (mmc_controller-slots[0].caps
+ MMC_CAP_8_BIT_DATA) {
+ omap_mux_init_signal(gpmc_ad4.sdmmc2_dat4,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(gpmc_ad5.sdmmc2_dat5,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(gpmc_ad6.sdmmc2_dat6,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(gpmc_ad7.sdmmc2_dat7,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ break;
+ case 4:
+ /* MMC5 only for omap4 */
+ omap_mux_init_signal(sdmmc5_clk.sdmmc5_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc5_cmd.sdmmc5_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc5_dat0.sdmmc5_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+ if (mmc_controller-slots[0].caps
+
[PATCH 2/5] OMAP4: usb-musb: Initialise the usb mux pins.
Use the mux framework to initialise the musb mux pins.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/usb-musb.c | 41
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 33a5cde..27cb348 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -29,6 +29,7 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include mux.h
#ifdef CONFIG_USB_MUSB_SOC
@@ -85,6 +86,44 @@ static struct platform_device musb_device = {
.resource = musb_resources,
};
+static void __init usb_musb_mux_init(struct omap_musb_board_data *board_data)
+{
+ if (board_data-interface_type == MUSB_INTERFACE_UTMI) {
+ /* MUSB - UTMI PIN MUX configurations */
+ omap_mux_init_signal(usba0_otg_ce.usba0_otg_ce,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(usba0_otg_dp.usba0_otg_dp,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usba0_otg_dm.usba0_otg_dm,
+ OMAP_PIN_INPUT);
+ } else {
+ /* MUSB - ULPI PIN MUX configurations */
+ omap_mux_init_signal(usbb1_ulpitll_clk.usbb1_ulpiphy_clk,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_stp.usbb1_ulpiphy_stp,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dir.usbb1_ulpiphy_dir,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7,
+ OMAP_PIN_INPUT);
+ }
+}
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
if (cpu_is_omap243x()) {
@@ -95,6 +134,8 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
+
+ usb_musb_mux_init(board_data);
}
musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
--
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 3/5] OMAP4: mcbsp: Initialise the mcbsp mux pins
Use the mux framework to initialise the mcbsp mux pins
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/mcbsp.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index f9c9df5..491e3f6 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -25,6 +25,7 @@
#include control.h
+#include mux.h
/* McBSP internal signal muxing functions */
@@ -287,9 +288,39 @@ static int __init omap2_mcbsp_init(void)
if (cpu_is_omap34xx())
omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
OMAP34XX_MCBSP_PDATA_SZ);
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
omap_mcbsp_register_board_cfg(omap44xx_mcbsp_pdata,
OMAP44XX_MCBSP_PDATA_SZ);
+ /* MCBSP1 PIN MUX configurations */
+ omap_mux_init_signal(abe_mcbsp1_clkx.abe_slimbus1_clock,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(abe_mcbsp1_dr.abe_slimbus1_data,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(abe_mcbsp1_dx.abe_mcbsp1_dx,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(abe_mcbsp1_fsx.abe_mcbsp1_fsx,
+ OMAP_PIN_INPUT);
+
+ /* MCBSP2 PIN MUX configurations */
+ omap_mux_init_signal(abe_mcbsp2_clkx.abe_mcbsp2_clkx,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(abe_mcbsp2_dr.abe_mcbsp2_dr,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(abe_mcbsp2_dx.abe_mcbsp2_dx,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(abe_mcbsp2_fsx.abe_mcbsp2_fsx,
+ OMAP_PIN_INPUT);
+
+ /* MCBSP 3 is configured as MCPDM */
+ omap_mux_init_signal(abe_pdm_ul_data.abe_pdm_ul_data,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(abe_pdm_dl_data.abe_pdm_dl_data,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(abe_pdm_frame.abe_pdm_frame,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(abe_pdm_lb_clk.abe_pdm_lb_clk,
+ OMAP_PIN_INPUT_PULLDOWN);
+ }
return omap_mcbsp_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 5/5] OMAP4: serial: Initialise the uart mux pins
Use the mux framework to initialise the uart mux pins.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/serial.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ba8a5cc..6890054 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -44,6 +44,7 @@
#include cm.h
#include prm-regbits-34xx.h
#include control.h
+#include mux.h
#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
#define UART_OMAP_WER 0x17/* Wake-up enable register */
@@ -839,6 +840,41 @@ void __init omap_serial_init_port(int port)
uart-errata |= UART_ERRATA_i202_MDR1_ACCESS;
}
+/*
+ * omap_serial_init_mux() - Initialize the PINMUX configurations
+ * for all supported UART modules.
+ */
+static void __init omap_serial_init_mux(void)
+{
+ if (cpu_is_omap44xx()) {
+ /* UART 2 MUX */
+ omap_mux_init_signal(uart2_cts.uart2_cts,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(uart2_rts.uart2_rts,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(uart2_rx.uart2_rx,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(uart2_tx.uart2_tx,
+ OMAP_PIN_OUTPUT);
+
+ /* UART 3 MUX */
+ omap_mux_init_signal(uart3_cts_rctx.uart3_cts_rctx,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(uart3_rts_sd.uart3_rts_sd,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(uart3_rx_irrx.uart3_rx_irrx,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(uart3_tx_irtx.uart3_tx_irtx,
+ OMAP_PIN_OUTPUT);
+
+ /* UART 4 MUX */
+ omap_mux_init_signal(uart4_rx.uart4_rx,
+ OMAP_PIN_INPUT);
+ omap_mux_init_signal(uart4_tx.uart4_tx,
+ OMAP_PIN_OUTPUT);
+ }
+}
+
/**
* omap_serial_init() - intialize all supported serial ports
*
@@ -850,6 +886,8 @@ void __init omap_serial_init(void)
{
struct omap_uart_state *uart;
+ omap_serial_init_mux();
+
list_for_each_entry(uart, uart_list, node)
omap_serial_init_port(uart-num);
}
--
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 4/5] OMAP4: board-4430sdp: Initialise the mcspi mux pins
Use the mux framework to initialise the mcspi mux pins.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 323b62e..c0ffea1 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -501,6 +501,25 @@ static void __init omap_sfh7741prox_init(void)
}
}
+static void __init omap_mcspi_mux_init(void)
+{
+ /* PIN MUX for MCSPI1 */
+ omap_mux_init_signal(mcspi1_clk.mcspi1_clk, OMAP_PIN_INPUT);
+ omap_mux_init_signal(mcspi1_somi.mcspi1_somi, OMAP_PIN_INPUT);
+ omap_mux_init_signal(mcspi1_simo.mcspi1_simo, OMAP_PIN_INPUT);
+ omap_mux_init_signal(mcspi1_cs0.mcspi1_cs0, OMAP_PIN_INPUT);
+ /*
+* CS1 should be configured as gpio 138
+* to avoid interference with CS0
+*/
+ omap_mux_init_signal(mcspi1_cs1.gpio_138, OMAP_PIN_INPUT);
+
+ /* PIN MUX for MCSPI4. This is not connected to any device */
+ omap_mux_init_signal(mcspi4_clk.mcspi4_clk, OMAP_PIN_INPUT);
+ omap_mux_init_signal(mcspi4_somi.mcspi4_somi, OMAP_PIN_INPUT);
+ omap_mux_init_signal(mcspi4_simo.mcspi4_simo, OMAP_PIN_INPUT);
+ omap_mux_init_signal(mcspi4_cs0.mcspi4_cs0, OMAP_PIN_INPUT_PULLDOWN);
+}
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -529,6 +548,7 @@ static void __init omap_4430sdp_init(void)
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
+ omap_mcspi_mux_init();
status = omap_ethernet_init();
if (status) {
pr_err(Ethernet initialization failed: %d\n, status);
--
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
