* [PATCH] ARM: imx/mx25_3ds: Fix build failure
From: Uwe Kleine-König @ 2011-03-02 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299028552-13186-1-git-send-email-festevam@gmail.com>
On Tue, Mar 01, 2011 at 10:15:52PM -0300, Fabio Estevam wrote:
> Commit
> ca8d906 (ARM: mach-imx: mx25_3ds: add write-protect and card-detect for SD)
>
> assigned a non-existing member .cd_gpio in a struct esdhc_platform_data.
> This field can be added later after the esdhc patches are merged.
> Fix the build for now.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/mach-mx25_3ds.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx25_3ds.c b/arch/arm/mach-imx/mach-mx25_3ds.c
> index 561f07f..11c25f9 100644
> --- a/arch/arm/mach-imx/mach-mx25_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx25_3ds.c
> @@ -208,7 +208,6 @@ static const struct fsl_usb2_platform_data otg_device_pdata __initconst = {
>
> static const struct esdhc_platform_data mx25pdk_esdhc_pdata __initconst = {
> .wp_gpio = SD1_GPIO_WP,
> - .cd_gpio = SD1_GPIO_CD,
> };
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] MX1: Add structure, registration functions for framebuffer and rename LCDC INT
From: Gwenhael Goavec-Merou @ 2011-03-02 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
---
arch/arm/mach-imx/devices-imx1.h | 4 ++++
arch/arm/plat-mxc/devices/platform-imx-fb.c | 5 +++++
arch/arm/plat-mxc/include/mach/mx1.h | 2 +-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-imx/devices-imx1.h b/arch/arm/mach-imx/devices-imx1.h
index fd26715..da59365 100644
--- a/arch/arm/mach-imx/devices-imx1.h
+++ b/arch/arm/mach-imx/devices-imx1.h
@@ -9,6 +9,10 @@
#include <mach/mx1.h>
#include <mach/devices-common.h>
+extern const struct imx_imx_fb_data imx1_imx_fb_data __initconst;
+#define imx1_add_imx_fb(pdata) \
+ imx_add_imx_fb(&imx1_imx_fb_data, pdata)
+
extern const struct imx_imx_i2c_data imx1_imx_i2c_data __initconst;
#define imx1_add_imx_i2c(pdata) \
imx_add_imx_i2c(&imx1_imx_i2c_data, pdata)
diff --git a/arch/arm/plat-mxc/devices/platform-imx-fb.c b/arch/arm/plat-mxc/devices/platform-imx-fb.c
index 6100a7d..79a1cb1 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-fb.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-fb.c
@@ -16,6 +16,11 @@
.irq = soc ## _INT_LCDC, \
}
+#ifdef CONFIG_SOC_IMX1
+const struct imx_imx_fb_data imx1_imx_fb_data __initconst =
+ imx_imx_fb_data_entry_single(MX1, SZ_4K);
+#endif /* ifdef CONFIG_SOC_IMX1 */
+
#ifdef CONFIG_SOC_IMX21
const struct imx_imx_fb_data imx21_imx_fb_data __initconst =
imx_imx_fb_data_entry_single(MX21, SZ_4K);
diff --git a/arch/arm/plat-mxc/include/mach/mx1.h b/arch/arm/plat-mxc/include/mach/mx1.h
index 7c871b8..97b19e7 100644
--- a/arch/arm/plat-mxc/include/mach/mx1.h
+++ b/arch/arm/plat-mxc/include/mach/mx1.h
@@ -89,7 +89,7 @@
#define MX1_GPIO_INT_PORTA 11
#define MX1_GPIO_INT_PORTB 12
#define MX1_GPIO_INT_PORTC 13
-#define MX1_LCDC_INT 14
+#define MX1_INT_LCDC 14
#define MX1_SIM_INT 15
#define MX1_SIM_DATA_INT 16
#define MX1_RTC_INT 17
--
1.7.3.4
^ permalink raw reply related
* [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
From: Govindraj @ 2011-03-02 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <056ac5e848953fa5c37f7ed7a8cc1050@mail.gmail.com>
On Wed, Mar 2, 2011 at 12:46 AM, Sricharan R <r.sricharan@ti.com> wrote:
> Hi,
>>diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
>>index 755f4aa..530e9e3 100644
>>--- a/arch/arm/mach-omap2/serial.c
>>+++ b/arch/arm/mach-omap2/serial.c
>>@@ -44,6 +44,15 @@
>>
>> static int omap_uart_con_id __initdata = -1;
>>
>>+static struct omap_uart_port_info omap_serial_default_info[] = {
>>+ ? ? ?{
>>+ ? ? ? ? ? ? ?.dma_enabled ? ?= 0,
>>+ ? ? ? ? ? ? ?.dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
>>+ ? ? ? ? ? ? ?.dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
>>+ ? ? ? ? ? ? ?.idle_timeout ? = DEFAULT_IDLE_TIMEOUT,
>>+ ? ? ?},
>>+};
>>+
>> static int uart_idle_hwmod(struct omap_device *od)
>> {
>> ? ? ? omap_hwmod_idle(od->hwmods[0]);
>>@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
> omap_uart_latency[]
>>= {
>> ? ? ? },
>> };
>>
>>+#ifdef CONFIG_OMAP_MUX
>>+static struct omap_device_pad default_serial0_pads[] __initdata = {
>>+ ? ? ?{
>>+ ? ? ? ? ? ? ?.name ? = "uart1_rx.uart1_rx",
>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>+ ? ? ?},
>>+};
>>+
>>+static struct omap_device_pad default_serial1_pads[] __initdata = {
>>+ ? ? ?{
>>+ ? ? ? ? ? ? ?.name ? = "uart2_rx.uart2_rx",
>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>+ ? ? ?},
>>+};
>>+
>>+static struct omap_device_pad default_serial2_pads[] __initdata = {
>>+ ? ? ?{
>>+ ? ? ? ? ? ? ?.name ? = "uart3_rx_irrx.uart3_rx_irrx",
>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>+ ? ? ?},
>>+};
>>+
>>+static struct omap_device_pad default_omap36xx_serial3_pads[] __initdata
> =
>>{
>>+ ? ? ?{
>>+ ? ? ? ? ? ? ?.name ? = "gpmc_wait3.uart4_rx",
>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE2,
>>+ ? ? ?},
>>+};
>>+
>>+static struct omap_device_pad default_omap4_serial3_pads[] __initdata =
> {
>>+ ? ? ?{
>>+ ? ? ? ? ? ? ?.name ? = "uart4_rx.uart4_rx",
>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>+ ? ? ?},
>>+};
> Here only the UART RX pins are muxed, so what about the cts, rts, tx pins?
The intention here is to enable wakeup capabilities for uart rx pad.
AFAIK most of the boards are currently dependent on bootloader for
uart-muxing if any board is not dependent on bootloader then we
can use omap_serial_init_port along with board_mux_info from board.
Prior to this change uart wakeup is based on rx_pad and we were populating
offset and using omap_ctrl api's to read/write which is cleaned up now.
Most of boards are dependent on uart-rx wakeup to avoid breaking any
board support we
are using omap_serial_init by filling default values, which provides
us with same
environment but with right approach towards handling mux data with a
handshake with
hwmod framework.
So if any board needs specific mux they can go ahead and add required
mux data in
board file and use map_serial_init_port instead of current omap_serial_init.
> Is it consistent that across all socs that only UART3 would have UART/IRDA
> functions capability so that serial2 pads can always be called "rx_irxx"
> ?.
Yes from OMAP2420 to OMAP4430 uart3 can used as irda.
--
Thanks,
Govindraj.R
^ permalink raw reply
* [PATCH V4] ARM: EXYNOS4: Implement kernel timers using MCT
From: Kyungmin Park @ 2011-03-02 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <010b01cbd8ab$8d575830$a8060890$%kim@samsung.com>
On Wed, Mar 2, 2011 at 4:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Kyungmin Park wrote:
>>
>> Hi,
>>
>> MCT is only possible from EVT1.0 or later. The current universal_c210
>> used the EVT0 version.
>> So can you remove the ifdef and board can select which timer is used?
>> Please refer the omap implementation and how to use it.
>>
> Basically, "CONFIG_EXYNOS4_MCT" can be selected in kernel menuconfig.
> It means default one is using local timer which is included in every
> Exynos4210.
>
>> If we use the same configuration, It will be boot failed at
>> universal_c210 board.
>>
> No, see as above.
>
> One more basically, each machine specific CONFIGs should be selected in
> kernel menuconfig after "make exynos4_defconfig". Because each machine
> supports different components on each one now.
>
> As a note, however, I don't want to add each machine's defconfig. Maybe
> Russell also.
I agree, but there are better way, make it compile both and select
timer for each board.
Of course no need to add any statement if default timer is used.
BTW, What's the purpose of exynos4_defconfig? as you said, If I want
to use the MCT for EVT1 board,
then make defconfig and select it again? why do the these job?
Thank you,
Kyungmin Park
^ permalink raw reply
* [PATCH V4] ARM: EXYNOS4: Implement kernel timers using MCT
From: Kukjin Kim @ 2011-03-02 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim9XMD=x5dbm0vOcrCcrL0TRKvdb7CuXBv3r_qX@mail.gmail.com>
Kyungmin Park wrote:
>
> Hi,
>
> MCT is only possible from EVT1.0 or later. The current universal_c210
> used the EVT0 version.
> So can you remove the ifdef and board can select which timer is used?
> Please refer the omap implementation and how to use it.
>
Basically, "CONFIG_EXYNOS4_MCT" can be selected in kernel menuconfig.
It means default one is using local timer which is included in every
Exynos4210.
> If we use the same configuration, It will be boot failed at
> universal_c210 board.
>
No, see as above.
One more basically, each machine specific CONFIGs should be selected in
kernel menuconfig after "make exynos4_defconfig". Because each machine
supports different components on each one now.
As a note, however, I don't want to add each machine's defconfig. Maybe
Russell also.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Thank you,
> Kyungmin Park
>
> On Mon, Feb 28, 2011 at 2:16 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> > From: Changhwan Youn <chaos.youn@samsung.com>
> >
> > The Multi-Core Timer(MCT) of EXYNOS4 is designed for implementing
> > clock source timer and clock event timers. This patch implements
> > 1 clock source timer with 64 bit free running counter of MCT and
> > 2 clock event timers with two of 31-bit tick counters.
> >
> > Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
> > Cc: Ben Dooks <ben-linux@fluff.org>
> > Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> > ---
> > Changes since v3:
> > - Re-worked based on exynos4
> > - Changed member of clock_evetn_device like following
> > ?struct mct_clock_event_device {
> > ? ? ? ?struct clock_event_device *evt;
> > ?...
> > - Address comments from Russell King
> > ?Added static into "irqreturn_t exynos4_mct_comp_isr()"
> > ?Added .dev_id member into "struct irqaction mct_comp_event_irq"
> >
> > Changes since v2:
> > - Addressed comments from Russell King
> > ?Added mct_clock_event_device structure
> > - Removed suspend()/resume() which are not used now
> >
> > Changes since v1:
> > - Addressed comments from Russell King
> > ?(implemented global timer, used local timer and so on)
> > - Fixed small things
> >
> > ?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> > ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? ? | ? ?5 +
> > ?arch/arm/mach-exynos4/Makefile ? ? ? ? ? ? ? ?| ? 11 +-
> > ?arch/arm/mach-exynos4/include/mach/regs-mct.h | ? 52 +++
> > ?arch/arm/mach-exynos4/mct.c ? ? ? ? ? ? ? ? ? | ?421
> +++++++++++++++++++++++++
> > ?5 files changed, 488 insertions(+), 3 deletions(-)
> > ?create mode 100644 arch/arm/mach-exynos4/include/mach/regs-mct.h
> > ?create mode 100644 arch/arm/mach-exynos4/mct.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index ec3bf98..b4db99b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1366,7 +1366,7 @@ config LOCAL_TIMERS
> > ? ? ? ?bool "Use local timer interrupts"
> > ? ? ? ?depends on SMP
> > ? ? ? ?default y
> > - ? ? ? select HAVE_ARM_TWD if !ARCH_MSM_SCORPIONMP
> > + ? ? ? select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> > ? ? ? ?help
> > ? ? ? ? ?Enable support for local timers on SMP platforms, rather then
the
> > ? ? ? ? ?legacy IPI broadcast method. ?Local timers allows the system
> > diff --git a/arch/arm/mach-exynos4/Kconfig
b/arch/arm/mach-exynos4/Kconfig
> > index ad03840..77b5d93 100644
> > --- a/arch/arm/mach-exynos4/Kconfig
> > +++ b/arch/arm/mach-exynos4/Kconfig
> > @@ -15,6 +15,11 @@ config CPU_EXYNOS4210
> > ? ? ? ?help
> > ? ? ? ? ?Enable EXYNOS4210 CPU support
> >
> > +config EXYNOS4_MCT
> > + ? ? ? bool "Kernel timer support by MCT"
> > + ? ? ? help
> > + ? ? ? ? Use MCT (Multi Core Timer) as kernel timers
> > +
> > ?config EXYNOS4_DEV_PD
> > ? ? ? ?bool
> > ? ? ? ?help
> > diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-
> exynos4/Makefile
> > index 0558235..de20b91 100644
> > --- a/arch/arm/mach-exynos4/Makefile
> > +++ b/arch/arm/mach-exynos4/Makefile
> > @@ -13,11 +13,18 @@ obj- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?:=
> > ?# Core support for EXYNOS4 system
> >
> > ?obj-$(CONFIG_CPU_EXYNOS4210) ? += cpu.o init.o clock.o irq-combiner.o
> > -obj-$(CONFIG_CPU_EXYNOS4210) ? += setup-i2c0.o time.o gpiolib.o
irq-eint.o
> dma.o
> > +obj-$(CONFIG_CPU_EXYNOS4210) ? += setup-i2c0.o gpiolib.o irq-eint.o
dma.o
> > ?obj-$(CONFIG_CPU_FREQ) ? ? ? ? += cpufreq.o
> >
> > ?obj-$(CONFIG_SMP) ? ? ? ? ? ? ?+= platsmp.o headsmp.o
> > -obj-$(CONFIG_LOCAL_TIMERS) ? ? += localtimer.o
> > +
> > +ifeq ($(CONFIG_EXYNOS4_MCT),y)
> > +obj-y ? ? ? ? ? ? ? ? ? ? ? ? ?+= mct.o
> > +else
> > +obj-y ? ? ? ? ? ? ? ? ? ? ? ? ?+= time.o
> > +obj-$(CONFIG_LOCAL_TIMERS) ? ? += localtimer.o
> > +endif
> > +
> > ?obj-$(CONFIG_HOTPLUG_CPU) ? ? ?+= hotplug.o
> >
> > ?# machine support
(snip)
^ permalink raw reply
* [PATCH V2 6/6] ARM: SAMSUNG: Add PWM backlight support on Samsung S5PV210
From: Banajit Goswami @ 2011-03-02 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299050847-16148-1-git-send-email-banajit.g@samsung.com>
This patch adds support for LCD backlight control using PWM timer
for Samsung's SMDKV210 board.
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
Changes since v1:
- Used common GPIO macro
- Removed redundant timers
arch/arm/mach-s5pv210/Kconfig | 1 +
arch/arm/mach-s5pv210/mach-smdkv210.c | 43 +++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 53aabef..d7fd031 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -130,6 +130,7 @@ config MACH_SMDKV210
select SAMSUNG_DEV_ADC
select SAMSUNG_DEV_IDE
select SAMSUNG_DEV_KEYPAD
+ select SAMSUNG_DEV_PWM
select SAMSUNG_DEV_TS
select S5PV210_SETUP_FB_24BPP
select S5PV210_SETUP_I2C1
diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c b/arch/arm/mach-s5pv210/mach-smdkv210.c
index bc9fdb5..8833e7b 100644
--- a/arch/arm/mach-s5pv210/mach-smdkv210.c
+++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
@@ -18,6 +18,7 @@
#include <linux/fb.h>
#include <linux/gpio.h>
#include <linux/delay.h>
+#include <linux/pwm_backlight.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -43,6 +44,7 @@
#include <plat/keypad.h>
#include <plat/pm.h>
#include <plat/fb.h>
+#include <plat/gpio-cfg.h>
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKV210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -208,6 +210,45 @@ static struct s3c_fb_platdata smdkv210_lcd0_pdata __initdata = {
.setup_gpio = s5pv210_fb_gpio_setup_24bpp,
};
+static int smdkv210_backlight_init(struct device *dev)
+{
+ int ret;
+
+ ret = gpio_request(S5PV210_GPD0(3), "Backlight");
+ if (ret) {
+ printk(KERN_ERR "failed to request GPD for PWM-OUT 3\n");
+ return ret;
+ }
+
+ /* Configure GPIO pin with S5PV210_GPD_0_3_TOUT_3 */
+ s3c_gpio_cfgpin(S5PV210_GPD0(3), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+static void smdkv210_backlight_exit(struct device *dev)
+{
+ s3c_gpio_cfgpin(S5PV210_GPD0(3), S3C_GPIO_OUTPUT);
+ gpio_free(S5PV210_GPD0(3));
+}
+
+static struct platform_pwm_backlight_data smdkv210_backlight_data = {
+ .pwm_id = 3,
+ .max_brightness = 255,
+ .dft_brightness = 255,
+ .pwm_period_ns = 78770,
+ .init = smdkv210_backlight_init,
+ .exit = smdkv210_backlight_exit,
+};
+
+static struct platform_device smdkv210_backlight_device = {
+ .name = "pwm-backlight",
+ .dev = {
+ .parent = &s3c_device_timer[3].dev,
+ .platform_data = &smdkv210_backlight_data,
+ },
+};
+
static struct platform_device *smdkv210_devices[] __initdata = {
&s3c_device_adc,
&s3c_device_cfcon,
@@ -229,6 +270,8 @@ static struct platform_device *smdkv210_devices[] __initdata = {
&samsung_device_keypad,
&smdkv210_dm9000,
&smdkv210_lcd_lte480wv,
+ &s3c_device_timer[3],
+ &smdkv210_backlight_device,
};
static void __init smdkv210_dm9000_init(void)
--
1.6.5.2
^ permalink raw reply related
* [PATCH V2 5/6] ARM: SAMSUNG: Add PWM backlight support on Samsung S5PC100
From: Banajit Goswami @ 2011-03-02 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299050847-16148-1-git-send-email-banajit.g@samsung.com>
This patch adds support for LCD backlight using PWM timer for
Samsung SMDKC100 board.
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
Changes since v1:
- Used common GPIO macro
- Removed redundant timers
arch/arm/mach-s5pc100/Kconfig | 1 +
arch/arm/mach-s5pc100/mach-smdkc100.c | 49 ++++++++++++++++++++++++++++++---
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig
index b8fbf2f..608722f 100644
--- a/arch/arm/mach-s5pc100/Kconfig
+++ b/arch/arm/mach-s5pc100/Kconfig
@@ -58,6 +58,7 @@ config MACH_SMDKC100
select SAMSUNG_DEV_ADC
select SAMSUNG_DEV_IDE
select SAMSUNG_DEV_KEYPAD
+ select SAMSUNG_DEV_PWM
select SAMSUNG_DEV_TS
select S5PC100_SETUP_FB_24BPP
select S5PC100_SETUP_I2C1
diff --git a/arch/arm/mach-s5pc100/mach-smdkc100.c b/arch/arm/mach-s5pc100/mach-smdkc100.c
index dd192a2..22d5348 100644
--- a/arch/arm/mach-s5pc100/mach-smdkc100.c
+++ b/arch/arm/mach-s5pc100/mach-smdkc100.c
@@ -23,12 +23,15 @@
#include <linux/fb.h>
#include <linux/delay.h>
#include <linux/input.h>
+#include <linux/pwm_backlight.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <mach/map.h>
#include <mach/regs-fb.h>
+#include <mach/regs-gpio.h>
+
#include <video/platform_lcd.h>
#include <asm/irq.h>
@@ -107,9 +110,6 @@ static struct i2c_board_info i2c_devs1[] __initdata = {
static void smdkc100_lcd_power_set(struct plat_lcd_data *pd,
unsigned int power)
{
- /* backlight */
- gpio_direction_output(S5PC100_GPD(0), power);
-
if (power) {
/* module reset */
gpio_direction_output(S5PC100_GPH0(6), 1);
@@ -178,6 +178,45 @@ static struct samsung_keypad_platdata smdkc100_keypad_data __initdata = {
.rows = 2,
.cols = 8,
};
+
+static int smdkc100_backlight_init(struct device *dev)
+{
+ int ret;
+
+ ret = gpio_request(S5PC100_GPD(0), "Backlight");
+ if (ret) {
+ printk(KERN_ERR "failed to request GPF for PWM-OUT0\n");
+ return ret;
+ }
+
+ /* Configure GPIO pin with S5PC100_GPD_TOUT_0 */
+ s3c_gpio_cfgpin(S5PC100_GPD(0), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+static void smdkc100_backlight_exit(struct device *dev)
+{
+ s3c_gpio_cfgpin(S5PC100_GPD(0), S3C_GPIO_OUTPUT);
+ gpio_free(S5PC100_GPD(0));
+}
+
+static struct platform_pwm_backlight_data smdkc100_backlight_data = {
+ .pwm_id = 0,
+ .max_brightness = 255,
+ .dft_brightness = 255,
+ .pwm_period_ns = 78770,
+ .init = smdkc100_backlight_init,
+ .exit = smdkc100_backlight_exit,
+};
+
+static struct platform_device smdkc100_backlight_device = {
+ .name = "pwm-backlight",
+ .dev = {
+ .parent = &s3c_device_timer[0].dev,
+ .platform_data = &smdkc100_backlight_data,
+ },
+};
static struct platform_device *smdkc100_devices[] __initdata = {
&s3c_device_adc,
@@ -200,6 +238,8 @@ static struct platform_device *smdkc100_devices[] __initdata = {
&s5p_device_fimc1,
&s5p_device_fimc2,
&s5pc100_device_spdif,
+ &s3c_device_timer[0],
+ &smdkc100_backlight_device,
};
static struct s3c2410_ts_mach_info s3c_ts_platform __initdata = {
@@ -233,7 +274,6 @@ static void __init smdkc100_machine_init(void)
s5pc100_spdif_setup_gpio(S5PC100_SPDIF_GPD);
/* LCD init */
- gpio_request(S5PC100_GPD(0), "GPD");
gpio_request(S5PC100_GPH0(6), "GPH0");
smdkc100_lcd_power_set(&smdkc100_lcd_power_data, 0);
platform_add_devices(smdkc100_devices, ARRAY_SIZE(smdkc100_devices));
--
1.6.5.2
^ permalink raw reply related
* [PATCH V2 4/6] ARM: SAMSUNG: Add PWM backlight support on Samsung S5P6450
From: Banajit Goswami @ 2011-03-02 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299050847-16148-1-git-send-email-banajit.g@samsung.com>
This patch adds support for LCD backlight control using PWM timer
for Samsung SMDK6450 board.
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
Changes since v1:
- Used common GPIO macro
- Removed redundant timers
arch/arm/mach-s5p64x0/Kconfig | 1 +
arch/arm/mach-s5p64x0/mach-smdk6450.c | 43 +++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index be5888a..08b0a5b 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -48,6 +48,7 @@ config MACH_SMDK6450
select S3C_DEV_WDT
select S3C64XX_DEV_SPI
select SAMSUNG_DEV_ADC
+ select SAMSUNG_DEV_PWM
select SAMSUNG_DEV_TS
select S5P64X0_SETUP_I2C1
help
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6450.c b/arch/arm/mach-s5p64x0/mach-smdk6450.c
index 3a20de0..296cc0f 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6450.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6450.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/clk.h>
#include <linux/gpio.h>
+#include <linux/pwm_backlight.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -32,6 +33,7 @@
#include <mach/map.h>
#include <mach/regs-clock.h>
#include <mach/i2c.h>
+#include <mach/regs-gpio.h>
#include <plat/regs-serial.h>
#include <plat/gpio-cfg.h>
@@ -106,6 +108,45 @@ static struct s3c2410_uartcfg smdk6450_uartcfgs[] __initdata = {
#endif
};
+static int smdk6450_backlight_init(struct device *dev)
+{
+ int ret;
+
+ ret = gpio_request(S5P6450_GPF(15), "Backlight");
+ if (ret) {
+ printk(KERN_ERR "failed to request GPF for PWM-OUT1\n");
+ return ret;
+ }
+
+ /* Configure GPIO pin with S5P6450_GPF15_PWM_TOUT1 */
+ s3c_gpio_cfgpin(S5P6450_GPF(15), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+static void smdk6450_backlight_exit(struct device *dev)
+{
+ s3c_gpio_cfgpin(S5P6450_GPF(15), S3C_GPIO_OUTPUT);
+ gpio_free(S5P6450_GPF(15));
+}
+
+static struct platform_pwm_backlight_data smdk6450_backlight_data = {
+ .pwm_id = 1,
+ .max_brightness = 255,
+ .dft_brightness = 255,
+ .pwm_period_ns = 78770,
+ .init = smdk6450_backlight_init,
+ .exit = smdk6450_backlight_exit,
+};
+
+static struct platform_device smdk6450_backlight_device = {
+ .name = "pwm-backlight",
+ .dev = {
+ .parent = &s3c_device_timer[1].dev,
+ .platform_data = &smdk6450_backlight_data,
+ },
+};
+
static struct platform_device *smdk6450_devices[] __initdata = {
&s3c_device_adc,
&s3c_device_rtc,
@@ -115,6 +156,8 @@ static struct platform_device *smdk6450_devices[] __initdata = {
&s3c_device_wdt,
&samsung_asoc_dma,
&s5p6450_device_iis0,
+ &s3c_device_timer[1],
+ &smdk6450_backlight_device,
/* s5p6450_device_spi0 will be added */
};
--
1.6.5.2
^ permalink raw reply related
* [PATCH V2 3/6] ARM: SAMSUNG: Add PWM backlight support on Samsung S5P6440
From: Banajit Goswami @ 2011-03-02 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299050847-16148-1-git-send-email-banajit.g@samsung.com>
This patch adds support for LCD backlight control using PWM timer
for Samsung SMDK6440 board.
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
Changes since v1:
- Used common GPIO macro
- Removed redundant timers
arch/arm/mach-s5p64x0/Kconfig | 1 +
arch/arm/mach-s5p64x0/mach-smdk6440.c | 43 +++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index 164d278..be5888a 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -34,6 +34,7 @@ config MACH_SMDK6440
select S3C_DEV_WDT
select S3C64XX_DEV_SPI
select SAMSUNG_DEV_ADC
+ select SAMSUNG_DEV_PWM
select SAMSUNG_DEV_TS
select S5P64X0_SETUP_I2C1
help
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6440.c b/arch/arm/mach-s5p64x0/mach-smdk6440.c
index e5beb84..58941d7 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6440.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6440.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/clk.h>
#include <linux/gpio.h>
+#include <linux/pwm_backlight.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -32,6 +33,7 @@
#include <mach/map.h>
#include <mach/regs-clock.h>
#include <mach/i2c.h>
+#include <mach/regs-gpio.h>
#include <plat/regs-serial.h>
#include <plat/gpio-cfg.h>
@@ -88,6 +90,45 @@ static struct s3c2410_uartcfg smdk6440_uartcfgs[] __initdata = {
},
};
+static int smdk6440_backlight_init(struct device *dev)
+{
+ int ret;
+
+ ret = gpio_request(S5P6440_GPF(15), "Backlight");
+ if (ret) {
+ printk(KERN_ERR "failed to request GPF for PWM-OUT1\n");
+ return ret;
+ }
+
+ /* Configure GPIO pin with S5P6440_GPF15_PWM_TOUT1 */
+ s3c_gpio_cfgpin(S5P6440_GPF(15), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+static void smdk6440_backlight_exit(struct device *dev)
+{
+ s3c_gpio_cfgpin(S5P6440_GPF(15), S3C_GPIO_OUTPUT);
+ gpio_free(S5P6440_GPF(15));
+}
+
+static struct platform_pwm_backlight_data smdk6440_backlight_data = {
+ .pwm_id = 1,
+ .max_brightness = 255,
+ .dft_brightness = 255,
+ .pwm_period_ns = 78770,
+ .init = smdk6440_backlight_init,
+ .exit = smdk6440_backlight_exit,
+};
+
+static struct platform_device smdk6440_backlight_device = {
+ .name = "pwm-backlight",
+ .dev = {
+ .parent = &s3c_device_timer[1].dev,
+ .platform_data = &smdk6440_backlight_data,
+ },
+};
+
static struct platform_device *smdk6440_devices[] __initdata = {
&s3c_device_adc,
&s3c_device_rtc,
@@ -97,6 +138,8 @@ static struct platform_device *smdk6440_devices[] __initdata = {
&s3c_device_wdt,
&samsung_asoc_dma,
&s5p6440_device_iis,
+ &s3c_device_timer[1],
+ &smdk6440_backlight_device,
};
static struct s3c2410_platform_i2c s5p6440_i2c0_data __initdata = {
--
1.6.5.2
^ permalink raw reply related
* [PATCH V2 2/6] ARM: SAMSUNG: Add PWM backlight support on Samsung S3C6410
From: Banajit Goswami @ 2011-03-02 7:27 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for LCD backlight using PWM timer for
Samsung SMDK6410 board.
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
Changes since v1:
- Used common GPIO macro
- Removed redundant timers
arch/arm/mach-s3c64xx/Kconfig | 1 +
arch/arm/mach-s3c64xx/mach-smdk6410.c | 45 ++++++++++++++++++++++++++++++--
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index f3a953f..e4177e2 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -143,6 +143,7 @@ config MACH_SMDK6410
select S3C_DEV_USB_HSOTG
select S3C_DEV_WDT
select SAMSUNG_DEV_KEYPAD
+ select SAMSUNG_DEV_PWM
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select S3C64XX_SETUP_SDHCI
select S3C64XX_SETUP_I2C1
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index e85192a..4a3fe0c 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -28,6 +28,7 @@
#include <linux/delay.h>
#include <linux/smsc911x.h>
#include <linux/regulator/fixed.h>
+#include <linux/pwm_backlight.h>
#ifdef CONFIG_SMDK6410_WM1190_EV1
#include <linux/mfd/wm8350/core.h>
@@ -48,6 +49,7 @@
#include <mach/hardware.h>
#include <mach/regs-fb.h>
#include <mach/map.h>
+#include <mach/gpio-bank-f.h>
#include <asm/irq.h>
#include <asm/mach-types.h>
@@ -118,7 +120,6 @@ static void smdk6410_lcd_power_set(struct plat_lcd_data *pd,
{
if (power) {
gpio_direction_output(S3C64XX_GPF(13), 1);
- gpio_direction_output(S3C64XX_GPF(15), 1);
/* fire nRESET on power up */
gpio_direction_output(S3C64XX_GPN(5), 0);
@@ -126,7 +127,6 @@ static void smdk6410_lcd_power_set(struct plat_lcd_data *pd,
gpio_direction_output(S3C64XX_GPN(5), 1);
msleep(1);
} else {
- gpio_direction_output(S3C64XX_GPF(15), 0);
gpio_direction_output(S3C64XX_GPF(13), 0);
}
}
@@ -269,6 +269,45 @@ static struct samsung_keypad_platdata smdk6410_keypad_data __initdata = {
.cols = 8,
};
+static int smdk6410_backlight_init(struct device *dev)
+{
+ int ret;
+
+ ret = gpio_request(S3C64XX_GPF(15), "Backlight");
+ if (ret) {
+ printk(KERN_ERR "failed to request GPF for PWM-OUT1\n");
+ return ret;
+ }
+
+ /* Configure GPIO pin with S3C64XX_GPF15_PWM_TOUT1 */
+ s3c_gpio_cfgpin(S3C64XX_GPF(15), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+static void smdk6410_backlight_exit(struct device *dev)
+{
+ s3c_gpio_cfgpin(S3C64XX_GPF(15), S3C_GPIO_OUTPUT);
+ gpio_free(S3C64XX_GPF(15));
+}
+
+static struct platform_pwm_backlight_data smdk6410_backlight_data = {
+ .pwm_id = 1,
+ .max_brightness = 255,
+ .dft_brightness = 255,
+ .pwm_period_ns = 78770,
+ .init = smdk6410_backlight_init,
+ .exit = smdk6410_backlight_exit,
+};
+
+static struct platform_device smdk6410_backlight_device = {
+ .name = "pwm-backlight",
+ .dev = {
+ .parent = &s3c_device_timer[1].dev,
+ .platform_data = &smdk6410_backlight_data,
+ },
+};
+
static struct map_desc smdk6410_iodesc[] = {};
static struct platform_device *smdk6410_devices[] __initdata = {
@@ -298,6 +337,8 @@ static struct platform_device *smdk6410_devices[] __initdata = {
&s3c_device_rtc,
&s3c_device_ts,
&s3c_device_wdt,
+ &s3c_device_timer[1],
+ &smdk6410_backlight_device,
};
#ifdef CONFIG_REGULATOR
@@ -693,7 +735,6 @@ static void __init smdk6410_machine_init(void)
gpio_request(S3C64XX_GPN(5), "LCD power");
gpio_request(S3C64XX_GPF(13), "LCD power");
- gpio_request(S3C64XX_GPF(15), "LCD power");
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
--
1.6.5.2
^ permalink raw reply related
* [PATCH 1/5] ARM: mx35_3ds: Add I2C support
From: Jason Liu @ 2011-03-02 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301201703.GX22310@pengutronix.de>
Hi, Uwe,
2011/3/2 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hello,
>
> On Tue, Mar 01, 2011 at 04:59:44PM -0300, Fabio Estevam wrote:
>> + ? ? imx35_add_imx_i2c0(&mx35_3ds_i2c0_data);
> I'd slightly prefer using
>
> ? ? ? ?imx35_add_imx_i2c(0, ...)
>
> because I intend to remove the imx35_add_imx_i2c0-like macros soon. ?But
Could you please explain why you intend to remove
imx35_add_imx_i2c0-like macros?
What you would like to do instead? Thanks,
> if nothing else pops up there is no need to respin the series because of
> that.
>
> Other than that all 5 patches look good;
> ? ? ? ?Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Uwe Kleine-K?nig ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] S3C64XX: Fix keypad setup to configure correct number of rows
From: Kukjin Kim @ 2011-03-02 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299010582-32481-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Mark Brown wrote:
>
> From: Ben Dooks <ben-linux@fluff.org>
>
> The call to s3c_gpio_cfgrange_nopull() takes a size and base
> but this looks like it is trying to do base and end. This means
> it is configuring too many GPIOs and on the case of the Cragganmore
> means we're seeing an overflow of the ROW pins causing problems
> with the keyboard driver.
>
> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> arch/arm/mach-s3c64xx/setup-keypad.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/setup-keypad.c b/arch/arm/mach-
> s3c64xx/setup-keypad.c
> index f8ed0d2..1d4d0ee 100644
> --- a/arch/arm/mach-s3c64xx/setup-keypad.c
> +++ b/arch/arm/mach-s3c64xx/setup-keypad.c
> @@ -17,7 +17,7 @@
> void samsung_keypad_cfg_gpio(unsigned int rows, unsigned int cols)
> {
> /* Set all the necessary GPK pins to special-function 3: KP_ROW[x]
*/
> - s3c_gpio_cfgrange_nopull(S3C64XX_GPK(8), 8 + rows, S3C_GPIO_SFN(3));
> + s3c_gpio_cfgrange_nopull(S3C64XX_GPK(8), rows, S3C_GPIO_SFN(3));
>
> /* Set all the necessary GPL pins to special-function 3: KP_COL[x]
*/
> s3c_gpio_cfgrange_nopull(S3C64XX_GPL(0), cols, S3C_GPIO_SFN(3));
> --
> 1.7.2.3
Oops, you're right.
Applied into s5p-fixes-for-linus for 38.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH V3 4/4] mmc: sdhci-esdhc: enable esdhc on imx53
From: Zhu Richard-R65037 @ 2011-03-02 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301113115.GB2212@pengutronix.de>
Hi Wolfram:
Best Regards
Richard Zhu
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang at pengutronix.de]
> Sent: Tuesday, March 01, 2011 7:31 PM
> To: Zhu Richard-R65037
> Cc: linux-arm-kernel at lists.infradead.org; kernel at pengutronix.de; linux-
> mmc at vger.kernel.org; cjb at laptop.org; avorontsov at ru.mvista.com;
> eric at eukrea.com; linuxzsc at gmail.com; Zhao Richard-B20223;
> Freescale at lists.linaro.org; eric.miao at linaro.org
> Subject: Re: [PATCH V3 4/4] mmc: sdhci-esdhc: enable esdhc on imx53
>
> Hi Richard,
>
> > Thanks a lot for your review-comments firstly. :)
>
> You are welcome :)
>
> > > > +/* Abort type definition in the command register */
> > > > +#define SDHCI_CMD_ABORTCMD 0xC0
> > >
> > > Won't that belong into sd.h (unless I misunderstood your last mail)?
> > This is the bit definitions of the ABORTCMD CMD-TYPE on the bit6~7 of
> CMD register.
> > Here is the definition of the CMD register derived from SDHC spec. FYI.
> > D15 D14 D13 D08 D07 D06 D05 D04
> D03 D02 D01 D00
> > Rsvd Command Index Command Type Data Present Select Command Index
> Check Enable Command CRC Check Enable Rsvd Response Type Select
>
> Ack, I found that, too. Exactly because it is in the standard, I thought
> this should rather go into sd.h than sdhci-esdhc-imx.c. Would be a
> seperate patch, though.
>
Do you means the sdhci.h file?
I find that the sd.h file doesn't contain the bit definitions stuff of SD HOST CONTROLLER registers.
The sdhci.h file has them, such as:
#define SDHCI_COMMAND 0x0E
#define SDHCI_CMD_RESP_MASK 0x03
#define SDHCI_CMD_CRC 0x08
#define SDHCI_CMD_INDEX 0x10
#define SDHCI_CMD_DATA 0x20
> > >
> > > > +/* VENDOR SPEC register */
> > > > +#define SDHCI_VENDOR_SPEC 0xC0
> > > > +
> > > > +/*
> > > > + * The CMDTYPE of the CMD register(offset 0xE) should be set to
> > >
> > > Check spaces.
> > I used the <kernel_dir>/./scripts/checkpatch.pl script to check the
> patches, and didn't find that there are issues about the spaces.
> > Can you tell me what's kinds of spaces issue should be fixed?
>
> Space before opening brace -> "register (offset ..."
Accepted.
>
> > No, we can't keep it enabled all the time.
> > This bit should be set to '1'/clear to '0' at the begin/end of the
> transfer.
> > Unfortunately, We can't use it to fix CMD12 issue either, this bit is
> only used to fix SDIO Multi-BLK NO INT case.
>
> Ok, thanks for checking.
>
You are welcome. :)
> > IC guy insist that the CMD12 case is not a bug refer to the SD HOST
> > controller spec, the bit7-6 should be Set to 11b when the abort CMD is
> issued.
>
> That's a flaw in the core then? Need to investigate that.
>
> > > Hmm, to me, just using cpu_is_mx53() is more readable than
> > > introducing another layer of flags/quirks.
> > Hi Wolfram:
> > I discussed it with Richard Zhao before sending out these V3 patches.
> > As we know that there is not only mx53 has this issue, maybe some
> following SOCs have this issue too.
> > So we make a decision that we introduce another flags/quirks to
> > declare it for all those SOCs that required this mechanism in the end.
>
> Seems I am outnumbered on this matter, so OK. I just got a bit afraid of
> that approach seeing it didn't scale very well with sdhci.c.
>
Thanks.
> > > > +
> > > > +static struct sdhci_ops sdhci_esdhc_ops;
> > > > +
> > >
> > > Move them to the front. But I did this already, so no worries :) I
> > > will ping Chris to merge my series, so we will have something better
> > > to develop on.
> > >
> > Thanks.:)
>
> He pulled the changes now, so please rebase your patches against mmc-next.
> There is already a write_le-function now, but this should be not too hard,
> hopefully.
>
> Keep in mind that you don't need to cast void*.
Accepted.
>
> Regards,
>
> Wolfram
>
> --
> Pengutronix e.K. | Wolfram Sang
> |
> Industrial Linux Solutions | http://www.pengutronix.de/
> |
^ permalink raw reply
* [PATCH 2/7] OMAP2+: mux: Enable wakeup for wakeup enable requested pads
From: Varadarajan, Charulatha @ 2011-03-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298903958-6496-3-git-send-email-govindraj.raja@ti.com>
Govind,
Couple of minor comments.
On Mon, Feb 28, 2011 at 20:09, Govindraj.R <govindraj.raja@ti.com> wrote:
> For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
> are wakeup capable) enable the IO-daisy wakeup capability.
> During re-muxing avoid direct write with val as this can disturb if any
> mux done at bootloader level so read the pad then write back.
>
> Also add a api to fetch the wake-up status bit is set for given omap-hwmod
%s/a api/an API/
> device using available mux info which is added during omap_hwmod_mux_init.
> Wakeup status bit is needed for uart_resume_idle call from sram_idle path
> based on wake-up event has occurred for given uart we can enable clocks back.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
> ---
> ?arch/arm/mach-omap2/mux.c ? ? ? ? ? ? ? ? ? ?| ? 23 +++++++++++++++++++++++
> ?arch/arm/mach-omap2/mux.h ? ? ? ? ? ? ? ? ? ?| ? 13 +++++++++++++
> ?arch/arm/mach-omap2/omap_hwmod.c ? ? ? ? ? ? | ? 13 +++++++++++++
> ?arch/arm/plat-omap/include/plat/omap_hwmod.h | ? ?1 +
> ?4 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 98148b6..5338b93 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -317,6 +317,24 @@ err1:
> ? ? ? ?return NULL;
> ?}
>
> +/* Gets the wakeup status of given pad from omap-hwmod */
> +int omap_hwmod_mux_wakeup(struct omap_hwmod_mux_info *hmux)
> +{
> + ? ? ? int i;
> + ? ? ? unsigned int val = -EINVAL;
> +
> + ? ? ? for (i = 0; i < hmux->nr_pads; i++) {
> + ? ? ? ? ? ? ? struct omap_device_pad *pad = &hmux->pads[i];
> +
> + ? ? ? ? ? ? ? val = omap_mux_read(pad->partition, pad->mux->reg_offset);
> + ? ? ? }
> +
> + ? ? ? if (val > 0 && val & OMAP_WAKEUP_EVENT)
> + ? ? ? ? ? ? ? return 1;
> + ? ? ? else
No need of else here.
> + ? ? ? ? ? ? ? return 0;
> +}
> +
- V Charulatha
^ permalink raw reply
* [PATCH] msm: Add SSBI support for MSM8960
From: Kenneth Heitke @ 2011-03-02 4:20 UTC (permalink / raw)
To: linux-arm-kernel
Add the device definitions and platform data to support
SSBI on MSM8960 simulator and RUMI3 targets.
SSBI is the Qualcomm single-wire serial bus interface used
to connect the MSM devices to other devices.
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
---
This patch depends on the "[PATCH v3 x/2] msm: add single-wire serial
bus interface (SSBI) driver" patch series which is under review
arch/arm/mach-msm/board-msm8960.c | 15 +++++++++++++++
arch/arm/mach-msm/devices-msm8960.c | 16 ++++++++++++++++
arch/arm/mach-msm/devices.h | 1 +
arch/arm/mach-msm/include/mach/msm_iomap-8960.h | 4 ++++
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/board-msm8960.c b/arch/arm/mach-msm/board-msm8960.c
index 052cb35..bf1a24b 100644
--- a/arch/arm/mach-msm/board-msm8960.c
+++ b/arch/arm/mach-msm/board-msm8960.c
@@ -20,6 +20,7 @@
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/clkdev.h>
+#include <linux/msm_ssbi.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -59,21 +60,35 @@ static void __init msm8960_init_irq(void)
static struct platform_device *sim_devices[] __initdata = {
&msm8960_device_uart_gsbi2,
+ &msm8960_device_ssbi_pm8921,
};
static struct platform_device *rumi3_devices[] __initdata = {
&msm8960_device_uart_gsbi5,
};
+static struct msm_ssbi_platform_data msm8960_ssbi_pm8921_pdata = {
+ .controller_type = MSM_SBI_CTRL_PMIC_ARBITER,
+ .slave = {
+ .name = "pm8921-core",
+ },
+};
+
static void __init msm8960_sim_init(void)
{
msm_clock_init(msm_clocks_8960, msm_num_clocks_8960);
+ msm8960_device_ssbi_pm8921.dev.platform_data =
+ &msm8960_ssbi_pm8921_pdata;
+
platform_add_devices(sim_devices, ARRAY_SIZE(sim_devices));
}
static void __init msm8960_rumi3_init(void)
{
msm_clock_init(msm_clocks_8960, msm_num_clocks_8960);
+ msm8960_device_ssbi_pm8921.dev.platform_data =
+ &msm8960_ssbi_pm8921_pdata;
+
platform_add_devices(rumi3_devices, ARRAY_SIZE(rumi3_devices));
}
diff --git a/arch/arm/mach-msm/devices-msm8960.c b/arch/arm/mach-msm/devices-msm8960.c
index 894ff98..40ceb78 100644
--- a/arch/arm/mach-msm/devices-msm8960.c
+++ b/arch/arm/mach-msm/devices-msm8960.c
@@ -24,6 +24,7 @@
#include <mach/irqs-8960.h>
#include <mach/board.h>
+#include <mach/msm_iomap.h>
#include "devices.h"
#include "clock.h"
@@ -89,6 +90,21 @@ struct platform_device msm8960_device_uart_gsbi5 = {
.resource = resources_uart_gsbi5,
};
+static struct resource resources_ssbi_pm8921[] = {
+ {
+ .start = MSM_PMIC1_SSBI_CMD_PHYS,
+ .end = MSM_PMIC1_SSBI_CMD_PHYS + MSM_PMIC_SSBI_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+struct platform_device msm8960_device_ssbi_pm8921 = {
+ .name = "msm_ssbi",
+ .id = 0,
+ .resource = resources_ssbi_pm8921,
+ .num_resources = ARRAY_SIZE(resources_ssbi_pm8921),
+};
+
struct clk_lookup msm_clocks_8960[] = {
CLK_DUMMY("ce_clk", CE2_CLK, NULL, OFF),
CLK_DUMMY("gsbi_uart_clk", GSBI1_UART_CLK, NULL, OFF),
diff --git a/arch/arm/mach-msm/devices.h b/arch/arm/mach-msm/devices.h
index e7a0cb0..e7c7fe0 100644
--- a/arch/arm/mach-msm/devices.h
+++ b/arch/arm/mach-msm/devices.h
@@ -26,6 +26,7 @@ extern struct platform_device msm_device_uart3;
extern struct platform_device msm8960_device_uart_gsbi2;
extern struct platform_device msm8960_device_uart_gsbi5;
+extern struct platform_device msm8960_device_ssbi_pm8921;
extern struct platform_device msm_device_sdc1;
extern struct platform_device msm_device_sdc2;
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
index 3c9d960..2d2210f 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
@@ -45,4 +45,8 @@
#define MSM8960_TMR0_PHYS 0x0208A000
#define MSM8960_TMR0_SIZE SZ_4K
+#define MSM_PMIC1_SSBI_CMD_PHYS 0x00500000
+#define MSM_PMIC2_SSBI_CMD_PHYS 0x00C00000
+#define MSM_PMIC_SSBI_SIZE SZ_4K
+
#endif
--
1.7.3.3
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH v3 2/2] platform-drivers: msm: add single-wire serial bus interface (SSBI) driver
From: Kenneth Heitke @ 2011-03-02 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299038465-11782-1-git-send-email-kheitke@codeaurora.org>
SSBI is the Qualcomm single-wire serial bus interface used to connect
the MSM devices to the PMIC and other devices.
Since SSBI only supports a single slave, the driver gets the name of the
slave device passed in from the board file through the master device's
platform data.
SSBI registers pretty early (postcore), so that the PMIC can come up
before the board init. This is useful if the board init requires the
use of gpios that are connected through the PMIC.
Based on a patch by Dima Zavin <dima@android.com> that can be found at:
http://android.git.kernel.org/?p=kernel/msm.git;a=commitdiff;h=eb060bac4
This patch adds PMIC Arbiter support for the MSM8660. The PMIC Arbiter
is a hardware wrapper around the SSBI 2.0 controller that is designed to
overcome concurrency issues and security limitations. A controller_type
field is added to the platform data to specify the type of the SSBI
controller (1.0, 2.0, or PMIC Arbiter).
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
---
drivers/platform/Kconfig | 3 +
drivers/platform/Makefile | 1 +
drivers/platform/msm/Kconfig | 13 ++
drivers/platform/msm/Makefile | 4 +
drivers/platform/msm/ssbi.c | 396 +++++++++++++++++++++++++++++++++++++++++
include/linux/msm_ssbi.h | 49 +++++
6 files changed, 466 insertions(+), 0 deletions(-)
create mode 100644 drivers/platform/msm/Kconfig
create mode 100644 drivers/platform/msm/Makefile
create mode 100644 drivers/platform/msm/ssbi.c
create mode 100644 include/linux/msm_ssbi.h
diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index 8390dca..17b5df5 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -1,3 +1,6 @@
if X86
source "drivers/platform/x86/Kconfig"
endif
+if ARCH_MSM
+source "drivers/platform/msm/Kconfig"
+endif
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index 782953a..58c62bd 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_X86) += x86/
+obj-$(CONFIG_ARCH_MSM) += msm/
diff --git a/drivers/platform/msm/Kconfig b/drivers/platform/msm/Kconfig
new file mode 100644
index 0000000..413bb65
--- /dev/null
+++ b/drivers/platform/msm/Kconfig
@@ -0,0 +1,13 @@
+menu "Qualcomm MSM specific device drivers"
+ depends on ARCH_MSM
+
+config MSM_SSBI
+ bool "Qualcomm Single-wire Serial Bus Interface (SSBI)"
+ help
+ If you say yes to this option, support will be included for the
+ built-in SSBI interface on Qualcomm MSM family processors.
+
+ This is required for communicating with Qualcomm PMICs and
+ other devices that have the SSBI interface.
+
+endmenu
diff --git a/drivers/platform/msm/Makefile b/drivers/platform/msm/Makefile
new file mode 100644
index 0000000..ea8c1e4
--- /dev/null
+++ b/drivers/platform/msm/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for the MSM specific device drivers.
+#
+obj-$(CONFIG_MSM_SSBI) += ssbi.o
diff --git a/drivers/platform/msm/ssbi.c b/drivers/platform/msm/ssbi.c
new file mode 100644
index 0000000..b4fd02e
--- /dev/null
+++ b/drivers/platform/msm/ssbi.c
@@ -0,0 +1,396 @@
+/* Copyright (c) 2009-2011, Code Aurora Forum. All rights reserved.
+ * Copyright (c) 2010, Google Inc.
+ *
+ * Original authors: Code Aurora Forum
+ *
+ * Author: Dima Zavin <dima@android.com>
+ * - Largely rewritten from original to not be an i2c driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/msm_ssbi.h>
+
+/* SSBI 2.0 controller registers */
+#define SSBI2_CMD 0x0008
+#define SSBI2_RD 0x0010
+#define SSBI2_STATUS 0x0014
+#define SSBI2_MODE2 0x001C
+
+/* SSBI_CMD fields */
+#define SSBI_CMD_RDWRN (1 << 24)
+
+/* SSBI_STATUS fields */
+#define SSBI_STATUS_RD_READY (1 << 2)
+#define SSBI_STATUS_READY (1 << 1)
+#define SSBI_STATUS_MCHN_BUSY (1 << 0)
+
+/* SSBI_MODE2 fields */
+#define SSBI_MODE2_REG_ADDR_15_8_SHFT 0x04
+#define SSBI_MODE2_REG_ADDR_15_8_MASK (0x7f << SSBI_MODE2_REG_ADDR_15_8_SHFT)
+
+#define SET_SSBI_MODE2_REG_ADDR_15_8(MD, AD) \
+ (((MD) & 0x0F) | ((((AD) >> 8) << SSBI_MODE2_REG_ADDR_15_8_SHFT) & \
+ SSBI_MODE2_REG_ADDR_15_8_MASK))
+
+/* SSBI PMIC Arbiter command registers */
+#define SSBI_PA_CMD 0x0000
+#define SSBI_PA_RD_STATUS 0x0004
+
+/* SSBI_PA_CMD fields */
+#define SSBI_PA_CMD_RDWRN (1 << 24)
+#define SSBI_PA_CMD_ADDR_MASK 0x7fff /* REG_ADDR_7_0, REG_ADDR_8_14*/
+
+/* SSBI_PA_RD_STATUS fields */
+#define SSBI_PA_RD_STATUS_TRANS_DONE (1 << 27)
+#define SSBI_PA_RD_STATUS_TRANS_DENIED (1 << 26)
+
+#define SSBI_TIMEOUT_US 100
+
+struct msm_ssbi {
+ struct device *dev;
+ struct device *slave;
+ void __iomem *base;
+ spinlock_t lock;
+ enum msm_ssbi_controller_type controller_type;
+ int (*read)(struct msm_ssbi *, u16 addr, u8 *buf, int len);
+ int (*write)(struct msm_ssbi *, u16 addr, u8 *buf, int len);
+};
+
+#define to_msm_ssbi(dev) platform_get_drvdata(to_platform_device(dev))
+
+static inline u32 ssbi_readl(struct msm_ssbi *ssbi, u32 reg)
+{
+ return readl(ssbi->base + reg);
+}
+
+static inline void ssbi_writel(struct msm_ssbi *ssbi, u32 val, u32 reg)
+{
+ writel(val, ssbi->base + reg);
+}
+
+static int ssbi_wait_mask(struct msm_ssbi *ssbi, u32 set_mask, u32 clr_mask)
+{
+ u32 timeout = SSBI_TIMEOUT_US;
+ u32 val;
+
+ while (timeout--) {
+ val = ssbi_readl(ssbi, SSBI2_STATUS);
+ if (((val & set_mask) == set_mask) && ((val & clr_mask) == 0))
+ return 0;
+ udelay(1);
+ }
+
+ dev_err(ssbi->dev, "%s: timeout (status %x set_mask %x clr_mask %x)\n",
+ __func__, ssbi_readl(ssbi, SSBI2_STATUS), set_mask, clr_mask);
+ return -ETIMEDOUT;
+}
+
+static int
+msm_ssbi_read_bytes(struct msm_ssbi *ssbi, u16 addr, u8 *buf, int len)
+{
+ u32 cmd = SSBI_CMD_RDWRN | ((addr & 0xff) << 16);
+ int ret = 0;
+
+ if (ssbi->controller_type == MSM_SBI_CTRL_SSBI2) {
+ u32 mode2 = ssbi_readl(ssbi, SSBI2_MODE2);
+ mode2 = SET_SSBI_MODE2_REG_ADDR_15_8(mode2, addr);
+ ssbi_writel(ssbi, mode2, SSBI2_MODE2);
+ }
+
+ while (len) {
+ ret = ssbi_wait_mask(ssbi, SSBI_STATUS_READY, 0);
+ if (ret)
+ goto err;
+
+ ssbi_writel(ssbi, cmd, SSBI2_CMD);
+ ret = ssbi_wait_mask(ssbi, SSBI_STATUS_RD_READY, 0);
+ if (ret)
+ goto err;
+ *buf++ = ssbi_readl(ssbi, SSBI2_RD) & 0xff;
+ len--;
+ }
+
+err:
+ return ret;
+}
+
+static int
+msm_ssbi_write_bytes(struct msm_ssbi *ssbi, u16 addr, u8 *buf, int len)
+{
+ int ret = 0;
+
+ if (ssbi->controller_type == MSM_SBI_CTRL_SSBI2) {
+ u32 mode2 = ssbi_readl(ssbi, SSBI2_MODE2);
+ mode2 = SET_SSBI_MODE2_REG_ADDR_15_8(mode2, addr);
+ ssbi_writel(ssbi, mode2, SSBI2_MODE2);
+ }
+
+ while (len) {
+ ret = ssbi_wait_mask(ssbi, SSBI_STATUS_READY, 0);
+ if (ret)
+ goto err;
+
+ ssbi_writel(ssbi, ((addr & 0xff) << 16) | *buf, SSBI2_CMD);
+ ret = ssbi_wait_mask(ssbi, 0, SSBI_STATUS_MCHN_BUSY);
+ if (ret)
+ goto err;
+ buf++;
+ len--;
+ }
+
+err:
+ return ret;
+}
+
+static inline int
+msm_ssbi_pa_transfer(struct msm_ssbi *ssbi, u32 cmd, u8 *data)
+{
+ u32 timeout = SSBI_TIMEOUT_US;
+ u32 rd_status = 0;
+
+ ssbi_writel(ssbi, cmd, SSBI_PA_CMD);
+
+ while (timeout--) {
+ rd_status = ssbi_readl(ssbi, SSBI_PA_RD_STATUS);
+
+ if (rd_status & SSBI_PA_RD_STATUS_TRANS_DENIED) {
+ dev_err(ssbi->dev, "%s: transaction denied (0x%x)\n",
+ __func__, rd_status);
+ return -EPERM;
+ }
+
+ if (rd_status & SSBI_PA_RD_STATUS_TRANS_DONE) {
+ if (data)
+ *data = rd_status & 0xff;
+ return 0;
+ }
+ udelay(1);
+ }
+
+ dev_err(ssbi->dev, "%s: timeout, status 0x%x\n", __func__, rd_status);
+ return -ETIMEDOUT;
+}
+
+static int
+msm_ssbi_pa_read_bytes(struct msm_ssbi *ssbi, u16 addr, u8 *buf, int len)
+{
+ u32 cmd;
+ int ret = 0;
+
+ cmd = SSBI_PA_CMD_RDWRN | (addr & SSBI_PA_CMD_ADDR_MASK) << 8;
+
+ while (len) {
+ ret = msm_ssbi_pa_transfer(ssbi, cmd, buf);
+ if (ret)
+ goto err;
+ buf++;
+ len--;
+ }
+
+err:
+ return ret;
+}
+
+static int
+msm_ssbi_pa_write_bytes(struct msm_ssbi *ssbi, u16 addr, u8 *buf, int len)
+{
+ u32 cmd;
+ int ret = 0;
+
+ while (len) {
+ cmd = (addr & SSBI_PA_CMD_ADDR_MASK) << 8 | *buf;
+ ret = msm_ssbi_pa_transfer(ssbi, cmd, NULL);
+ if (ret)
+ goto err;
+ buf++;
+ len--;
+ }
+
+err:
+ return ret;
+}
+
+int msm_ssbi_read(struct device *dev, u16 addr, u8 *buf, int len)
+{
+ struct msm_ssbi *ssbi = to_msm_ssbi(dev);
+ unsigned long flags;
+ int ret;
+
+ if (ssbi->dev != dev)
+ return -ENXIO;
+
+ spin_lock_irqsave(&ssbi->lock, flags);
+ ret = ssbi->read(ssbi, addr, buf, len);
+ spin_unlock_irqrestore(&ssbi->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(msm_ssbi_read);
+
+int msm_ssbi_write(struct device *dev, u16 addr, u8 *buf, int len)
+{
+ struct msm_ssbi *ssbi = to_msm_ssbi(dev);
+ unsigned long flags;
+ int ret;
+
+ if (ssbi->dev != dev)
+ return -ENXIO;
+
+ spin_lock_irqsave(&ssbi->lock, flags);
+ ret = ssbi->write(ssbi, addr, buf, len);
+ spin_unlock_irqrestore(&ssbi->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(msm_ssbi_write);
+
+static int __devinit msm_ssbi_add_slave(struct msm_ssbi *ssbi,
+ const struct msm_ssbi_slave_info *slave)
+{
+ struct platform_device *slave_pdev;
+ int ret;
+
+ if (ssbi->slave) {
+ pr_err("slave already attached??\n");
+ return -EBUSY;
+ }
+
+ slave_pdev = platform_device_alloc(slave->name, -1);
+ if (!slave_pdev) {
+ pr_err("cannot allocate pdev for slave '%s'", slave->name);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ slave_pdev->dev.parent = ssbi->dev;
+ slave_pdev->dev.platform_data = slave->platform_data;
+
+ ret = platform_device_add(slave_pdev);
+ if (ret) {
+ pr_err("cannot add slave platform device for '%s'\n",
+ slave->name);
+ goto err;
+ }
+
+ ssbi->slave = &slave_pdev->dev;
+ return 0;
+
+err:
+ if (slave_pdev)
+ platform_device_put(slave_pdev);
+ return ret;
+}
+
+static int __devinit msm_ssbi_probe(struct platform_device *pdev)
+{
+ const struct msm_ssbi_platform_data *pdata = pdev->dev.platform_data;
+ struct resource *mem_res;
+ struct msm_ssbi *ssbi;
+ int ret = 0;
+
+ if (!pdata) {
+ pr_err("missing platform data\n");
+ return -EINVAL;
+ }
+
+ pr_debug("%s\n", pdata->slave.name);
+
+ ssbi = kzalloc(sizeof(struct msm_ssbi), GFP_KERNEL);
+ if (!ssbi) {
+ pr_err("can not allocate ssbi_data\n");
+ return -ENOMEM;
+ }
+
+ mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem_res) {
+ pr_err("missing mem resource\n");
+ ret = -EINVAL;
+ goto err_get_mem_res;
+ }
+
+ ssbi->base = ioremap(mem_res->start, resource_size(mem_res));
+ if (!ssbi->base) {
+ pr_err("ioremap of 0x%p failed\n", (void *)mem_res->start);
+ ret = -EINVAL;
+ goto err_ioremap;
+ }
+ ssbi->dev = &pdev->dev;
+ platform_set_drvdata(pdev, ssbi);
+
+ ssbi->controller_type = pdata->controller_type;
+ if (ssbi->controller_type == MSM_SBI_CTRL_PMIC_ARBITER) {
+ ssbi->read = msm_ssbi_pa_read_bytes;
+ ssbi->write = msm_ssbi_pa_write_bytes;
+ } else {
+ ssbi->read = msm_ssbi_read_bytes;
+ ssbi->write = msm_ssbi_write_bytes;
+ }
+
+ spin_lock_init(&ssbi->lock);
+
+ ret = msm_ssbi_add_slave(ssbi, &pdata->slave);
+ if (ret)
+ goto err_ssbi_add_slave;
+
+ return 0;
+
+err_ssbi_add_slave:
+ platform_set_drvdata(pdev, NULL);
+ iounmap(ssbi->base);
+err_ioremap:
+err_get_mem_res:
+ kfree(ssbi);
+ return ret;
+}
+
+static int __devexit msm_ssbi_remove(struct platform_device *pdev)
+{
+ struct msm_ssbi *ssbi = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+ iounmap(ssbi->base);
+ kfree(ssbi);
+ return 0;
+}
+
+static struct platform_driver msm_ssbi_driver = {
+ .probe = msm_ssbi_probe,
+ .remove = __exit_p(msm_ssbi_remove),
+ .driver = {
+ .name = "msm_ssbi",
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init msm_ssbi_init(void)
+{
+ return platform_driver_register(&msm_ssbi_driver);
+}
+postcore_initcall(msm_ssbi_init);
+
+static void __exit msm_ssbi_exit(void)
+{
+ platform_driver_unregister(&msm_ssbi_driver);
+}
+module_exit(msm_ssbi_exit)
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION("1.0");
+MODULE_ALIAS("platform:msm_ssbi");
+MODULE_AUTHOR("Dima Zavin <dima@android.com>");
diff --git a/include/linux/msm_ssbi.h b/include/linux/msm_ssbi.h
new file mode 100644
index 0000000..cfa47df
--- /dev/null
+++ b/include/linux/msm_ssbi.h
@@ -0,0 +1,49 @@
+/* Copyright (C) 2010 Google, Inc.
+ * Copyright (c) 2011, Code Aurora Forum. All rights reserved.
+ * Author: Dima Zavin <dima@android.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 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#ifndef _LINUX_MSM_SSBI_H
+#define _LINUX_MSM_SSBI_H
+
+#include <linux/types.h>
+
+struct msm_ssbi_slave_info {
+ const char *name;
+ void *platform_data;
+};
+
+enum msm_ssbi_controller_type {
+ MSM_SBI_CTRL_SSBI = 0,
+ MSM_SBI_CTRL_SSBI2,
+ MSM_SBI_CTRL_PMIC_ARBITER,
+};
+
+struct msm_ssbi_platform_data {
+ struct msm_ssbi_slave_info slave;
+ enum msm_ssbi_controller_type controller_type;
+};
+
+#ifdef CONFIG_MSM_SSBI
+int msm_ssbi_write(struct device *dev, u16 addr, u8 *buf, int len);
+int msm_ssbi_read(struct device *dev, u16 addr, u8 *buf, int len);
+#else
+static inline int msm_ssbi_write(struct device *dev, u16 addr, u8 *buf, int len)
+{
+ return -ENXIO;
+}
+static inline int msm_ssbi_read(struct device *dev, u16 addr, u8 *buf, int len)
+{
+ return -ENXIO;
+}
+#endif
+#endif
--
1.7.3.3
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH v3 1/2] MAINTAINERS: Add drivers/platform/msm to MSM subsystem
From: Kenneth Heitke @ 2011-03-02 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299038465-11782-1-git-send-email-kheitke@codeaurora.org>
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
---
MAINTAINERS | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 59869e4..696cb18 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -904,6 +904,7 @@ F: drivers/mmc/host/msm_sdcc.c
F: drivers/mmc/host/msm_sdcc.h
F: drivers/tty/serial/msm_serial.h
F: drivers/tty/serial/msm_serial.c
+F: drivers/platform/msm/
T: git git://codeaurora.org/quic/kernel/davidb/linux-msm.git
S: Maintained
--
1.7.3.3
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH v3 0/2] msm: add single-wire serial bus interface (SSBI) driver
From: Kenneth Heitke @ 2011-03-02 4:01 UTC (permalink / raw)
To: linux-arm-kernel
Patch history
v3: move SSBI driver to drivers/platform/msm
v2: move SSBI driver to drivers//msm from arch/arm/mach-msm
Kenneth Heitke (2):
MAINTAINERS: Add drivers/platform/msm to MSM subsystem
platform-drivers: msm: add single-wire serial bus interface (SSBI)
driver
MAINTAINERS | 1 +
drivers/platform/Kconfig | 3 +
drivers/platform/Makefile | 1 +
drivers/platform/msm/Kconfig | 13 ++
drivers/platform/msm/Makefile | 4 +
drivers/platform/msm/ssbi.c | 396 +++++++++++++++++++++++++++++++++++++++++
include/linux/msm_ssbi.h | 49 +++++
7 files changed, 467 insertions(+), 0 deletions(-)
create mode 100644 drivers/platform/msm/Kconfig
create mode 100644 drivers/platform/msm/Makefile
create mode 100644 drivers/platform/msm/ssbi.c
create mode 100644 include/linux/msm_ssbi.h
--
1.7.3.3
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Ryan Mallon @ 2011-03-02 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DBD8C.70904@codeaurora.org>
On 03/02/2011 04:46 PM, Saravana Kannan wrote:
> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
<snip>
>> The only real objection I have to adding the SoC family information is
>> basically to discourage it being abused by userspace. I can see it being
>> useful in debug situations, but I can also see stupid userspace
>> applications explicitly testing for some particular SoC, rather than
>> more correctly (IMHO) checking for presence of certain drivers etc.
>
> True, but so many other things could be misused by stupid userspace
> programs. When there are legitimate usecases, I think we shouldn't
> prevent them just because we think a stupid userspace program could
> misuse it.
>
> Again, although you might not be gung-ho about this, I think I have at
> least made you indifferent/mildly supportive to adding socinfo. If you
> don't mind, I would like to wait for others to chime in before
> continuing this discussion.
Agreed.
In general I am in support of having the SoC information exposed
somewhere. I think we just want to be careful that it doesn't become a
dumping ground for anything and everything SoC related whether the
information is useful or not. I think each piece of exposed information
should have a genuine use case, not just "because we can".
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Saravana Kannan @ 2011-03-02 3:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DBAED.7070805@bluewatersys.com>
On 03/01/2011 07:35 PM, Ryan Mallon wrote:
> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>>> is a
>>>>>> better solution to identify the different implementations of socinfo
>>>>>> without having to maintain some "unique id" list in the kernel,
>>>>>> then I'm
>>>>>> all for it. But cpuinfo is not it.
>>>>>
>>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>>> file makes a bit more sense, but should probably be called 'mach'
>>>>> rather
>>>>> than 'arch' to avoid this confusion :-).
>>>>
>>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>>> long as we can all agree on it. I care more about the content of the
>>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>>> better since it's generic enough to not force, say omap3 and omap4, to
>>>> report different values.
>>>>
>>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>>
>>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>>
>>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>>> filenames if they are already in /sys/devices/system/soc/.
>>
>> Makes sense. We can drop the soc- prefix. So the contenders left: family
>> vs<somethingelse>. Would still be nice if the other folks chime in.
>>
>>>> If we settle on this, may be it would be easier to get this through.
>>>>
>>>>> I still think it is a solution in search of a problem though. What
>>>>> userspace programs need to know what specific SoC they are on? My
>>>>> feeling is that if userspace needs to know this information, then it is
>>>>> probably dicking around with things that should be managed by the
>>>>> kernel. Differences in available peripherals, etc can be determined by
>>>>> looking at existing sysfs files.
>>>>
>>>> I certainly have seen several use cases. Couple of easy examples:
>>>>
>>>> * A lot of test scripts would find this very useful. For example, some
>>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>>> would lock up the system if you try to turn it off while the CPU is
>>>> running.
>>>
>>> I don't follow here. Do you mean a struct clk clock or something else?
>>> Why is userspace allowed to disable a clock which will effectively hang
>>> the system? :-).
>>
>> Ah, sorry. Didn't give enough details. To give some context, I manage
>> the clock stuff for MSM. The MSM clock driver exports clock control thru
>> debugfs. We have test scripts that bang the clocks to test them. Each
>> SoC has a different set of "touch me and you die" clocks that the test
>> script shouldn't mess with. This socinfo would be useful for those test
>> cases.
>
> Ah, okay. This is still within a single SoC family though since we don't
> yet (AFAIK) support mutliple SoCs in a single kernel.
Yes, my example was within a single SoC family. But since this is user
space example, it doesn't matter if a single kernel can support multiple
SoCs/SoC families. We could still have one userspace code that might
want to support multiple SoC families.
Anyway, I think we are in agreement here. So, will stop discussing this
point.
>>>> * Some of the user space tools might want to report different "product
>>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>>> running on.
>>>
>>> This makes more sense. It would actually be useful for custom USB
>>> devices (gadget) which can be done from user space.
>>
>> Hmm... didn't know USB devices/gadgets could be handled from userspace.
>
> The gadgetfs driver allows for writing custom usb device
> implementations. The SoC info could be used to set the USB
> vendor/product id. Again, I see this more useful within the SoC family
> (ie at91sam9260 vs at91sam9263) rather than between families. From an
> embedded perspective at least, I think it is unlikely for an application
> to need to work on multiple SoC families.
>
> The only real objection I have to adding the SoC family information is
> basically to discourage it being abused by userspace. I can see it being
> useful in debug situations, but I can also see stupid userspace
> applications explicitly testing for some particular SoC, rather than
> more correctly (IMHO) checking for presence of certain drivers etc.
True, but so many other things could be misused by stupid userspace
programs. When there are legitimate usecases, I think we shouldn't
prevent them just because we think a stupid userspace program could
misuse it.
Again, although you might not be gung-ho about this, I think I have at
least made you indifferent/mildly supportive to adding socinfo. If you
don't mind, I would like to wait for others to chime in before
continuing this discussion.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Ryan Mallon @ 2011-03-02 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DB7CB.7070701@codeaurora.org>
On 03/02/2011 04:21 PM, Saravana Kannan wrote:
> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>> is a
>>>>> better solution to identify the different implementations of socinfo
>>>>> without having to maintain some "unique id" list in the kernel,
>>>>> then I'm
>>>>> all for it. But cpuinfo is not it.
>>>>
>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>> file makes a bit more sense, but should probably be called 'mach'
>>>> rather
>>>> than 'arch' to avoid this confusion :-).
>>>
>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>> long as we can all agree on it. I care more about the content of the
>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>> better since it's generic enough to not force, say omap3 and omap4, to
>>> report different values.
>>>
>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>
>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>
>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>> filenames if they are already in /sys/devices/system/soc/.
>
> Makes sense. We can drop the soc- prefix. So the contenders left: family
> vs <somethingelse>. Would still be nice if the other folks chime in.
>
>>> If we settle on this, may be it would be easier to get this through.
>>>
>>>> I still think it is a solution in search of a problem though. What
>>>> userspace programs need to know what specific SoC they are on? My
>>>> feeling is that if userspace needs to know this information, then it is
>>>> probably dicking around with things that should be managed by the
>>>> kernel. Differences in available peripherals, etc can be determined by
>>>> looking at existing sysfs files.
>>>
>>> I certainly have seen several use cases. Couple of easy examples:
>>>
>>> * A lot of test scripts would find this very useful. For example, some
>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>> would lock up the system if you try to turn it off while the CPU is
>>> running.
>>
>> I don't follow here. Do you mean a struct clk clock or something else?
>> Why is userspace allowed to disable a clock which will effectively hang
>> the system? :-).
>
> Ah, sorry. Didn't give enough details. To give some context, I manage
> the clock stuff for MSM. The MSM clock driver exports clock control thru
> debugfs. We have test scripts that bang the clocks to test them. Each
> SoC has a different set of "touch me and you die" clocks that the test
> script shouldn't mess with. This socinfo would be useful for those test
> cases.
Ah, okay. This is still within a single SoC family though since we don't
yet (AFAIK) support mutliple SoCs in a single kernel.
>>> * Some of the user space tools might want to report different "product
>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>> running on.
>>
>> This makes more sense. It would actually be useful for custom USB
>> devices (gadget) which can be done from user space.
>
> Hmm... didn't know USB devices/gadgets could be handled from userspace.
The gadgetfs driver allows for writing custom usb device
implementations. The SoC info could be used to set the USB
vendor/product id. Again, I see this more useful within the SoC family
(ie at91sam9260 vs at91sam9263) rather than between families. From an
embedded perspective at least, I think it is unlikely for an application
to need to work on multiple SoC families.
The only real objection I have to adding the SoC family information is
basically to discourage it being abused by userspace. I can see it being
useful in debug situations, but I can also see stupid userspace
applications explicitly testing for some particular SoC, rather than
more correctly (IMHO) checking for presence of certain drivers etc.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* [RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X
From: Richard Zhao @ 2011-03-02 3:28 UTC (permalink / raw)
To: linux-arm-kernel
Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
and every board can be selected/unselected, and SOC_XXX be selected
by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.
If everyone is happty with that, I'd like to clean up ARCH_MX3X too.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index f065a0d..518a39e 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -1,14 +1,4 @@
if ARCH_MX5
-# ARCH_MX51 and ARCH_MX50 are left for compatibility
-
-config ARCH_MX50
- bool
-
-config ARCH_MX51
- bool
-
-config ARCH_MX53
- bool
config SOC_IMX50
bool
@@ -16,7 +6,6 @@ config SOC_IMX50
select ARCH_MXC_IOMUX_V3
select ARCH_MXC_AUDMUX_V2
select ARCH_HAS_CPUFREQ
- select ARCH_MX50
config SOC_IMX51
bool
@@ -24,13 +13,11 @@ config SOC_IMX51
select ARCH_MXC_IOMUX_V3
select ARCH_MXC_AUDMUX_V2
select ARCH_HAS_CPUFREQ
- select ARCH_MX51
config SOC_IMX53
bool
select MXC_TZIC
select ARCH_MXC_IOMUX_V3
- select ARCH_MX53
comment "MX5 platforms:"
diff --git a/arch/arm/mach-mx5/Makefile.boot b/arch/arm/mach-mx5/Makefile.boot
index e928be1..cdc70b3 100644
--- a/arch/arm/mach-mx5/Makefile.boot
+++ b/arch/arm/mach-mx5/Makefile.boot
@@ -1,9 +1,9 @@
- zreladdr-$(CONFIG_ARCH_MX50) := 0x70008000
-params_phys-$(CONFIG_ARCH_MX50) := 0x70000100
-initrd_phys-$(CONFIG_ARCH_MX50) := 0x70800000
- zreladdr-$(CONFIG_ARCH_MX51) := 0x90008000
-params_phys-$(CONFIG_ARCH_MX51) := 0x90000100
-initrd_phys-$(CONFIG_ARCH_MX51) := 0x90800000
- zreladdr-$(CONFIG_ARCH_MX53) := 0x70008000
-params_phys-$(CONFIG_ARCH_MX53) := 0x70000100
-initrd_phys-$(CONFIG_ARCH_MX53) := 0x70800000
+ zreladdr-$(CONFIG_SOC_MX50) := 0x70008000
+params_phys-$(CONFIG_SOC_MX50) := 0x70000100
+initrd_phys-$(CONFIG_SOC_MX50) := 0x70800000
+ zreladdr-$(CONFIG_SOC_MX51) := 0x90008000
+params_phys-$(CONFIG_SOC_MX51) := 0x90000100
+initrd_phys-$(CONFIG_SOC_MX51) := 0x90800000
+ zreladdr-$(CONFIG_SOC_MX53) := 0x70008000
+params_phys-$(CONFIG_SOC_MX53) := 0x70000100
+initrd_phys-$(CONFIG_SOC_MX53) := 0x70800000
diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index 33530d2..be7df13 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -194,7 +194,7 @@ static int __init imxXX_add_imx_dma(void)
} else
#endif
-#if defined(CONFIG_ARCH_MX51)
+#if defined(CONFIG_SOC_IMX51)
if (cpu_is_mx51()) {
imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51_to1;
ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
diff --git a/arch/arm/plat-mxc/include/mach/irqs.h b/arch/arm/plat-mxc/include/mach/irqs.h
index ba65c92..a3d930d 100644
--- a/arch/arm/plat-mxc/include/mach/irqs.h
+++ b/arch/arm/plat-mxc/include/mach/irqs.h
@@ -23,17 +23,17 @@
#define MXC_GPIO_IRQ_START MXC_INTERNAL_IRQS
/* these are ordered by size to support multi-SoC kernels */
-#if defined CONFIG_ARCH_MX53
+#if defined CONFIG_SOC_IMX53
#define MXC_GPIO_IRQS (32 * 7)
#elif defined CONFIG_ARCH_MX2
#define MXC_GPIO_IRQS (32 * 6)
-#elif defined CONFIG_ARCH_MX50
+#elif defined CONFIG_SOC_IMX50
#define MXC_GPIO_IRQS (32 * 6)
#elif defined CONFIG_ARCH_MX1
#define MXC_GPIO_IRQS (32 * 4)
#elif defined CONFIG_ARCH_MX25
#define MXC_GPIO_IRQS (32 * 4)
-#elif defined CONFIG_ARCH_MX51
+#elif defined CONFIG_SOC_IMX51
#define MXC_GPIO_IRQS (32 * 4)
#elif defined CONFIG_ARCH_MXC91231
#define MXC_GPIO_IRQS (32 * 4)
diff --git a/arch/arm/plat-mxc/include/mach/memory.h b/arch/arm/plat-mxc/include/mach/memory.h
index 8386140..f1e9c0a 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -34,11 +34,11 @@
# define PHYS_OFFSET MX3x_PHYS_OFFSET
# elif defined CONFIG_ARCH_MXC91231
# define PHYS_OFFSET MXC91231_PHYS_OFFSET
-# elif defined CONFIG_ARCH_MX50
+# elif defined CONFIG_SOC_IMX50
# define PHYS_OFFSET MX50_PHYS_OFFSET
-# elif defined CONFIG_ARCH_MX51
+# elif defined CONFIG_SOC_IMX51
# define PHYS_OFFSET MX51_PHYS_OFFSET
-# elif defined CONFIG_ARCH_MX53
+# elif defined CONFIG_SOC_IMX53
# define PHYS_OFFSET MX53_PHYS_OFFSET
# endif
#endif
diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
index 04c7a26..3781f2f 100644
--- a/arch/arm/plat-mxc/include/mach/mxc.h
+++ b/arch/arm/plat-mxc/include/mach/mxc.h
@@ -127,7 +127,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx35() (0)
#endif
-#ifdef CONFIG_ARCH_MX50
+#ifdef CONFIG_SOC_IMX50
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
@@ -139,7 +139,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx50() (0)
#endif
-#ifdef CONFIG_ARCH_MX51
+#ifdef CONFIG_SOC_IMX51
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
@@ -151,7 +151,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx51() (0)
#endif
-#ifdef CONFIG_ARCH_MX53
+#ifdef CONFIG_SOC_IMX53
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index c895922..daeafc2 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -476,7 +476,7 @@ config MTD_NAND_MPC5121_NFC
config MTD_NAND_MXC
tristate "MXC NAND support"
- depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || ARCH_MX51
+ depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || SOC_IMX51
help
This enables the driver for the NAND flash controller on the
MXC processors.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bb233a9..9f9d3f7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -164,10 +164,10 @@ config SPI_IMX_VER_0_4
def_bool y if ARCH_MX31
config SPI_IMX_VER_0_7
- def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
+ def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
config SPI_IMX_VER_2_3
- def_bool y if ARCH_MX51 || ARCH_MX53
+ def_bool y if SOC_IMX51 || SOC_IMX53
config SPI_IMX
tristate "Freescale i.MX SPI controllers"
--
1.7.1
^ permalink raw reply related
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Saravana Kannan @ 2011-03-02 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DB566.4090908@bluewatersys.com>
On 03/01/2011 07:11 PM, Ryan Mallon wrote:
> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>>> better solution to identify the different implementations of socinfo
>>>> without having to maintain some "unique id" list in the kernel, then I'm
>>>> all for it. But cpuinfo is not it.
>>>
>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>> file makes a bit more sense, but should probably be called 'mach' rather
>>> than 'arch' to avoid this confusion :-).
>>
>> Sorry for the confusion. Sure, I don't care much for the filename as
>> long as we can all agree on it. I care more about the content of the
>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>> better since it's generic enough to not force, say omap3 and omap4, to
>> report different values.
>>
>> Linus Walleij, Eduardo, Maxime, Andrei,
>>
>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>> <somethingelse>) and the path /sys/devices/system/soc/.
>
> 'family' sounds good. I don't think we need the 'soc-' prefix on
> filenames if they are already in /sys/devices/system/soc/.
Makes sense. We can drop the soc- prefix. So the contenders left: family
vs <somethingelse>. Would still be nice if the other folks chime in.
>> If we settle on this, may be it would be easier to get this through.
>>
>>> I still think it is a solution in search of a problem though. What
>>> userspace programs need to know what specific SoC they are on? My
>>> feeling is that if userspace needs to know this information, then it is
>>> probably dicking around with things that should be managed by the
>>> kernel. Differences in available peripherals, etc can be determined by
>>> looking at existing sysfs files.
>>
>> I certainly have seen several use cases. Couple of easy examples:
>>
>> * A lot of test scripts would find this very useful. For example, some
>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>> would lock up the system if you try to turn it off while the CPU is
>> running.
>
> I don't follow here. Do you mean a struct clk clock or something else?
> Why is userspace allowed to disable a clock which will effectively hang
> the system? :-).
Ah, sorry. Didn't give enough details. To give some context, I manage
the clock stuff for MSM. The MSM clock driver exports clock control thru
debugfs. We have test scripts that bang the clocks to test them. Each
SoC has a different set of "touch me and you die" clocks that the test
script shouldn't mess with. This socinfo would be useful for those test
cases.
>> * Some of the user space tools might want to report different "product
>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>> running on.
>
> This makes more sense. It would actually be useful for custom USB
> devices (gadget) which can be done from user space.
Hmm... didn't know USB devices/gadgets could be handled from userspace.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Ryan Mallon @ 2011-03-02 3:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DB1B1.4060908@codeaurora.org>
On 03/02/2011 03:55 PM, Saravana Kannan wrote:
> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>> better solution to identify the different implementations of socinfo
>>> without having to maintain some "unique id" list in the kernel, then I'm
>>> all for it. But cpuinfo is not it.
>>
>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>> file makes a bit more sense, but should probably be called 'mach' rather
>> than 'arch' to avoid this confusion :-).
>
> Sorry for the confusion. Sure, I don't care much for the filename as
> long as we can all agree on it. I care more about the content of the
> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
> better since it's generic enough to not force, say omap3 and omap4, to
> report different values.
>
> Linus Walleij, Eduardo, Maxime, Andrei,
>
> Would like to hear your opinion on the file name (soc-family vs. mach vs
> <somethingelse>) and the path /sys/devices/system/soc/.
'family' sounds good. I don't think we need the 'soc-' prefix on
filenames if they are already in /sys/devices/system/soc/.
>
> If we settle on this, may be it would be easier to get this through.
>
>> I still think it is a solution in search of a problem though. What
>> userspace programs need to know what specific SoC they are on? My
>> feeling is that if userspace needs to know this information, then it is
>> probably dicking around with things that should be managed by the
>> kernel. Differences in available peripherals, etc can be determined by
>> looking at existing sysfs files.
>
> I certainly have seen several use cases. Couple of easy examples:
>
> * A lot of test scripts would find this very useful. For example, some
> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
> would lock up the system if you try to turn it off while the CPU is
> running.
I don't follow here. Do you mean a struct clk clock or something else?
Why is userspace allowed to disable a clock which will effectively hang
the system? :-).
> * Some of the user space tools might want to report different "product
> id/type" (nothing to do with USB, etc) depending on what SOC it is
> running on.
This makes more sense. It would actually be useful for custom USB
devices (gadget) which can be done from user space.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* [PATCH 2/6] ARM: pxa2xx: reorganize I2C files
From: Eric Miao @ 2011-03-02 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D9426.8030905@fluff.org>
On Wed, Mar 2, 2011 at 8:49 AM, Ben Dooks <ben-linux@fluff.org> wrote:
> On 23/02/11 11:38, Sebastian Andrzej Siewior wrote:
>>
>> This patch moves the platform data definition from
>> arch/arm/plat-pxa/include/plat/i2c.h to include/linux/i2c/pxa-i2c.h so
>> it can be accessed from x86 the same way as on ARM.
>>
>> This change should make no functional change to the PXA code. The move
>> is verified by building the following defconfigs:
>> ? cm_x2xx_defconfig corgi_defconfig em_x270_defconfig ezx_defconfig
>> ? imote2_defconfig pxa3xx_defconfig spitz_defconfig zeus_defconfig
>> ? raumfeld_defconfig magician_defconfig mmp2_defconfig pxa168_defconfig
>> ? pxa910_defconfig
>>
>
> Russell/others, you OK with this going through my tree?
>
Ben, I'm fine that you take this change. Trivial changes to me, so
I expect no significant merge conflicts.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox