Re: [PATCH 207/493] i2c: remove use of __devinit
Hi Bill, On Mon, 19 Nov 2012 13:22:36 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Can you please point me/us to the discussion explaining the rationale behind this move, and the explanation of what will be done exactly? While I can easily understand that we want to drop CONFIG_HOTPLUG and always enable hot-plug support, I don't see where we are going with removing __devinit annotations and the like. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: OMAP: ads7846: fix pendown debounce setting
On Mon, Nov 19, 2012 at 06:03:56PM +0200, Igor Grinberg wrote: Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the pendown GPIO debounce time setting by the below sequence: gpio_request_one() gpio_set_debounce() gpio_free() It also revealed a bug in the OMAP GPIO handling code which prevented the GPIO debounce clock to be disabled and CORE transition to low power states. Commit c9c55d9 (gpio/omap: fix off-mode bug: clear debounce settings on free/reset) fixes the OMAP GPIO handling code by making sure that the GPIO debounce clock gets disabled if no GPIO is requested from current bank. While fixing the OMAP GPIO handling code (in the right way), the above commit makes the gpio_request-set_debounce-free sequence invalid as after freeing the GPIO, the debounce settings are lost. This patch set: 1) Adds the pendown GPIO debounce time setting to the platform data structure of the ads7846 driver. 2) Fixes the OMAP platform code to pass the debounce time value to the driver instead of handling it by itself. Igor Grinberg (2): ads7846: enable pendown GPIO debounce time setting ARM: OMAP: ads7846: fix pendown debounce setting Makes sense to me. Tony, I have some stuff to push for 3.7 final, mind if I pick OMAP change as well? Thanks. -- Dmitry -- 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
[RFC/RFT] OMAP: N770: remove custom implementation of ads7846_get_pendown_state
The default implementation matches exactly our custom one so we can switch
to using the default one. As a bonus the driver will take care of setting
GPIO line for us.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
No hardware so not tested...
Thanks!
arch/arm/mach-omap1/board-nokia770.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 7d5c06d..be6490b 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -112,17 +112,6 @@ static void __init mipid_dev_init(void)
omapfb_set_lcd_config(nokia770_lcd_config);
}
-static void __init ads7846_dev_init(void)
-{
- if (gpio_request(ADS7846_PENDOWN_GPIO, ADS7846 pendown) 0)
- printk(KERN_ERR can't get ads7846 pen down GPIO\n);
-}
-
-static int ads7846_get_pendown_state(void)
-{
- return !gpio_get_value(ADS7846_PENDOWN_GPIO);
-}
-
static struct ads7846_platform_data nokia770_ads7846_platform_data __initdata
= {
.x_max = 0x0fff,
.y_max = 0x0fff,
@@ -131,7 +120,7 @@ static struct ads7846_platform_data
nokia770_ads7846_platform_data __initdata =
.debounce_max = 10,
.debounce_tol = 3,
.debounce_rep = 1,
- .get_pendown_state = ads7846_get_pendown_state,
+ .gpio_pendown = ADS7846_PENDOWN_GPIO,
};
static struct spi_board_info nokia770_spi_board_info[] __initdata = {
@@ -241,7 +230,6 @@ static void __init omap_nokia770_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
hwa742_dev_init();
- ads7846_dev_init();
mipid_dev_init();
omap1_usb_init(nokia770_usb_config);
nokia770_mmc_init();
--
1.7.11.7
--
Dmitry
--
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 119/493] usb: remove use of __devexit_p
On 11/19/2012 07:21 PM, Bill Pemberton :
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Alexander Shishkin alexander.shish...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
Cc: Li Yang le...@freescale.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Wan ZongShun mcuos@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
[..]
drivers/usb/host/ehci-atmel.c| 2 +-
drivers/usb/host/ohci-at91.c | 2 +-
For Atmel:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
[..]
diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c
index 6f3b6e2..855d538 100644
--- a/drivers/usb/c67x00/c67x00-drv.c
+++ b/drivers/usb/c67x00/c67x00-drv.c
@@ -219,7 +219,7 @@ static int __devexit c67x00_drv_remove(struct
platform_device *pdev)
static struct platform_driver c67x00_driver = {
.probe = c67x00_drv_probe,
- .remove = __devexit_p(c67x00_drv_remove),
+ .remove = c67x00_drv_remove,
.driver = {
.owner = THIS_MODULE,
.name = c67x00,
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 0f5ca4b..5659730 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -252,7 +252,7 @@ MODULE_DEVICE_TABLE(of, ci13xxx_imx_dt_ids);
static struct platform_driver ci13xxx_imx_driver = {
.probe = ci13xxx_imx_probe,
- .remove = __devexit_p(ci13xxx_imx_remove),
+ .remove = ci13xxx_imx_remove,
.driver = {
.name = imx_usb,
.owner = THIS_MODULE,
diff --git a/drivers/usb/chipidea/ci13xxx_msm.c
b/drivers/usb/chipidea/ci13xxx_msm.c
index b01feb3..406c5af 100644
--- a/drivers/usb/chipidea/ci13xxx_msm.c
+++ b/drivers/usb/chipidea/ci13xxx_msm.c
@@ -89,7 +89,7 @@ static int __devexit ci13xxx_msm_remove(struct
platform_device *pdev)
static struct platform_driver ci13xxx_msm_driver = {
.probe = ci13xxx_msm_probe,
- .remove = __devexit_p(ci13xxx_msm_remove),
+ .remove = ci13xxx_msm_remove,
.driver = { .name = msm_hsusb, },
};
diff --git a/drivers/usb/chipidea/ci13xxx_pci.c
b/drivers/usb/chipidea/ci13xxx_pci.c
index 918e149..e1cb2fb 100644
--- a/drivers/usb/chipidea/ci13xxx_pci.c
+++ b/drivers/usb/chipidea/ci13xxx_pci.c
@@ -147,7 +147,7 @@ static struct pci_driver ci13xxx_pci_driver = {
.name = UDC_DRIVER_NAME,
.id_table = ci13xxx_pci_id_table,
.probe= ci13xxx_pci_probe,
- .remove = __devexit_p(ci13xxx_pci_remove),
+ .remove = ci13xxx_pci_remove,
};
module_pci_driver(ci13xxx_pci_driver);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index f69d029..46f23f2 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -523,7 +523,7 @@ static int __devexit ci_hdrc_remove(struct
platform_device *pdev)
static struct platform_driver ci_hdrc_driver = {
.probe = ci_hdrc_probe,
- .remove = __devexit_p(ci_hdrc_remove),
+ .remove = ci_hdrc_remove,
.driver = {
.name = ci_hdrc,
},
diff --git a/drivers/usb/chipidea/usbmisc_imx6q.c
b/drivers/usb/chipidea/usbmisc_imx6q.c
index 416e3fc..81238a4 100644
--- a/drivers/usb/chipidea/usbmisc_imx6q.c
+++ b/drivers/usb/chipidea/usbmisc_imx6q.c
@@ -136,7 +136,7 @@ static int __devexit usbmisc_imx6q_remove(struct
platform_device *pdev)
static struct platform_driver usbmisc_imx6q_driver = {
.probe = usbmisc_imx6q_probe,
- .remove = __devexit_p(usbmisc_imx6q_remove),
+ .remove = usbmisc_imx6q_remove,
.driver = {
.name = usbmisc_imx6q,
.owner = THIS_MODULE,
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index e71a62a..1a02442 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -583,7 +583,7 @@ static int __devexit dwc3_remove(struct platform_device
*pdev)
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
- .remove = __devexit_p(dwc3_remove),
+ .remove = dwc3_remove,
.driver = {
.name = dwc3,
},
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index dc35c54..19a9818 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -196,7 +196,7 @@ MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
static struct platform_driver dwc3_exynos_driver = {
.probe = dwc3_exynos_probe,
- .remove = __devexit_p(dwc3_exynos_remove),
+ .remove =
[PATCH v3 3/5] ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone
Set ti,pmic-shutdown-controller for BeagleBone in am335x-bone.dts
file, this flag is used by the driver to set tps65217 PMIC status
to OFF when PWR_EN toggle.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 2c33888..1d55190 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -88,6 +88,8 @@
/include/ tps65217.dtsi
tps {
+ ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-always-on;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] rtc: OMAP: Add system pm_power_off to rtc driver
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Added while (1); after the above steps to make sure that no other
process acquire cpu. Otherwise we might see an unexpected behaviour
because we are shutting down all the power rails of SoC except RTC.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 81 +++-
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..c31f93a 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,63 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ spinlock_t lock;
+ unsigned long flags, time;
+
+ spin_lock_init(lock);
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add shutdown time to the current value */
+ time += SHUTDOWN_TIME_SEC;
+
+ /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
+ rtc_time_to_tm(time, tm);
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /*
+* pmic_pwr_enable is controlled by means of ALARM2 event. So here
+* programming alarm2 expiry time and enabling alarm2 interrupt
+*/
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+ /* Enable alarm2 interrupt */
+ val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
+ writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
+ rtc_base + OMAP_RTC_INTERRUPTS_REG);
+
+ /* Do not allow to
[PATCH v3 2/5] mfd: tps65217: Set PMIC to shutdown on PWR_EN toggle
From: Colin Foe-Parker colin.foepar...@logicpd.com
Set tps65217 PMIC status to OFF if power enable toggle is supported.
By setting this bit to 1 to enter PMIC to OFF state when PWR_EN pin
is pulled low. Also adds a DT flag to specify that device pmic
supports shutdown control or not.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move the additions to tps65217 MFD driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
.../devicetree/bindings/regulator/tps65217.txt |4
drivers/mfd/tps65217.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d316fb8..4f05d20 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -11,6 +11,9 @@ Required properties:
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
+Optional properties:
+- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
+
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@@ -20,6 +23,7 @@ Example:
tps: tps@24 {
compatible = ti,tps65217;
+ ti,pmic-shutdown-controller;
regulators {
dcdc1_reg: dcdc1 {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 3fb32e6..c7f17d8 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
unsigned int version;
unsigned int chip_id = ids-driver_data;
const struct of_device_id *match;
+ bool status_off = false;
int ret;
if (client-dev.of_node) {
@@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return -EINVAL;
}
chip_id = (unsigned int)match-data;
+ status_off = of_property_read_bool(client-dev.of_node,
+ ti,pmic-shutdown-controller);
}
if (!chip_id) {
@@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return ret;
}
+ /* Set the PMIC to shutdown on PWR_EN toggle */
+ if (status_off) {
+ ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
+ TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
+ TPS65217_PROTECT_NONE);
+ if (ret)
+ dev_warn(tps-dev, unable to set the status OFF\n);
+ }
+
dev_info(tps-dev, TPS65217 ID %#x version 1.%d\n,
(version TPS65217_CHIPID_CHIP_MASK) 4,
version TPS65217_CHIPID_REV_MASK);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix compilation error in cm_common.c
On 11/20/2012 10:25 AM, Constantine Shulyupin wrote: From: Constantine Shulyupin co...@makelinux.com Added required linux/errno.h Signed-off-by: Constantine Shulyupin co...@makelinux.com This supposed to be already fixed: https://patchwork.kernel.org/patch/1728521/ --- arch/arm/mach-omap2/cm_common.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c index 3246cef..3fafc27 100644 --- a/arch/arm/mach-omap2/cm_common.c +++ b/arch/arm/mach-omap2/cm_common.c @@ -13,6 +13,7 @@ #include linux/kernel.h #include linux/init.h +#include linux/errno.h #include cm2xxx.h #include cm3xxx.h -- Péter -- 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/3] pwm: Drivers for twl4030/6030 PWMs and LEDs
Hello, Changes since v2: - New PWM cycle calculation for twl-pwm driver and twl4030's pwm-twl-led with comment to document the expected behaviour. Changes cince v1: - The turn on/off sequence has been corrected for twl4030 PWMs as suggested by Grazvydas Ignotas - Comment section added to the new drivers to describe what they are controlling The series has been tested (with additional, pending patches): Zoom2 for twl4030 PWM0 (keypad light), PWM1 (LCD backlight) BeagleBoard for twl4030 LEDB (PWMB - pmu_stat led) OMAP4 Blaze (SDP4430) for twl6030 PWM1 (keypad light), PWM2 (LCD backlight) and LED (charging indication led). Intro mail from v1: The currently available pwm-twl6030.c driver only supports TWL6030's Charging indication LED. Remove this driver and add two new ones which implements support for all PWM driven outputs: pwm-twl driver supports twl4030 (PWM 0/1) and twl6030 (PWM 1/2) instances pwm-twl-led driver supports twl4030 (PWM driven LED A/B ports) and twl6030's Charging indication LED (PWM driven). Regards, Peter --- Peter Ujfalusi (3): pwm: Remove pwm-twl6030 driver pwm: New driver to support PWMs on TWL4030/6030 series of PMICs pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs drivers/pwm/Kconfig | 19 ++- drivers/pwm/Makefile | 3 +- drivers/pwm/pwm-twl-led.c | 303 ++ drivers/pwm/pwm-twl.c | 330 ++ drivers/pwm/pwm-twl6030.c | 184 -- 5 files changed, 650 insertions(+), 189 deletions(-) create mode 100644 drivers/pwm/pwm-twl-led.c create mode 100644 drivers/pwm/pwm-twl.c delete mode 100644 drivers/pwm/pwm-twl6030.c -- 1.8.0 -- 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/3] pwm: Remove pwm-twl6030 driver
This driver only supported the Charging indicator LED.
New set of drivers going to provide support for both PWMs and LEDs for twl4030
and twl6030 series of PMICs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 9 ---
drivers/pwm/Makefile | 1 -
drivers/pwm/pwm-twl6030.c | 184 --
3 files changed, 194 deletions(-)
delete mode 100644 drivers/pwm/pwm-twl6030.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..e678005 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -142,15 +142,6 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
-config PWM_TWL6030
- tristate TWL6030 PWM support
- depends on TWL4030_CORE
- help
- Generic PWM framework driver for TWL6030.
-
- To compile this driver as a module, choose M here: the module
- will be called pwm-twl6030.
-
config PWM_VT8500
tristate vt8500 pwm support
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..29cf57e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,5 +11,4 @@ obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
-obj-$(CONFIG_PWM_TWL6030) += pwm-twl6030.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl6030.c b/drivers/pwm/pwm-twl6030.c
deleted file mode 100644
index 8e63878..000
--- a/drivers/pwm/pwm-twl6030.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * twl6030_pwm.c
- * Driver for PHOENIX (TWL6030) Pulse Width Modulator
- *
- * Copyright (C) 2010 Texas Instruments
- * Author: Hemanth V heman...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see http://www.gnu.org/licenses/.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/pwm.h
-#include linux/i2c/twl.h
-#include linux/slab.h
-
-#define LED_PWM_CTRL1 0xF4
-#define LED_PWM_CTRL2 0xF5
-
-/* Max value for CTRL1 register */
-#define PWM_CTRL1_MAX 255
-
-/* Pull down disable */
-#define PWM_CTRL2_DIS_PD (1 6)
-
-/* Current control 2.5 milli Amps */
-#define PWM_CTRL2_CURR_02 (2 4)
-
-/* LED supply source */
-#define PWM_CTRL2_SRC_VAC (1 2)
-
-/* LED modes */
-#define PWM_CTRL2_MODE_HW (0 0)
-#define PWM_CTRL2_MODE_SW (1 0)
-#define PWM_CTRL2_MODE_DIS (2 0)
-
-#define PWM_CTRL2_MODE_MASK0x3
-
-struct twl6030_pwm_chip {
- struct pwm_chip chip;
-};
-
-static int twl6030_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- int ret;
- u8 val;
-
- /* Configure PWM */
- val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_02 | PWM_CTRL2_SRC_VAC |
- PWM_CTRL2_MODE_HW;
-
- ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
- if (ret 0) {
- dev_err(chip-dev, %s: Failed to configure PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- return 0;
-}
-
-static int twl6030_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
-{
- u8 duty_cycle = (duty_ns * PWM_CTRL1_MAX) / period_ns;
- int ret;
-
- ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, duty_cycle, LED_PWM_CTRL1);
- if (ret 0) {
- pr_err(%s: Failed to configure PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- return 0;
-}
-
-static int twl6030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- int ret;
- u8 val;
-
- ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
- if (ret 0) {
- dev_err(chip-dev, %s: Failed to enable PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- /* Change mode to software control */
- val = ~PWM_CTRL2_MODE_MASK;
- val |= PWM_CTRL2_MODE_SW;
-
- ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
- if (ret 0) {
- dev_err(chip-dev, %s: Failed to enable PWM, Error %d\n,
- pwm-label, ret);
- return ret;
- }
-
- twl_i2c_read_u8(TWL6030_MODULE_ID1, val,
[PATCH v3 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl-led.c | 303 ++
3 files changed, 314 insertions(+)
create mode 100644 drivers/pwm/pwm-twl-led.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c577db9..49c2082 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -152,6 +152,16 @@ config PWM_TWL
To compile this driver as a module, choose M here: the module
will be called pwm-twl.
+config PWM_TWL_LED
+ tristate TWL4030/6030 PWM support for LED drivers
+ select HAVE_PWM
+ depends on TWL4030_CORE
+ help
+ Generic PWM framework driver for TWL4030/6030 LED.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-twl-led.
+
config PWM_VT8500
tristate vt8500 pwm support
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 3324c06..5f26134 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,4 +12,5 @@ obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
obj-$(CONFIG_PWM_TWL) += pwm-twl.o
+obj-$(CONFIG_PWM_TWL_LED) += pwm-twl-led.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
new file mode 100644
index 000..9468720
--- /dev/null
+++ b/drivers/pwm/pwm-twl-led.c
@@ -0,0 +1,303 @@
+/*
+ * Driver for TWL4030/6030 Pulse Width Modulator used as LED driver
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This driver is a complete rewrite of the former pwm-twl6030.c authorded by:
+ * Hemanth V heman...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/pwm.h
+#include linux/i2c/twl.h
+#include linux/slab.h
+
+/*
+ * This driver handles the PWM driven LED terminals of TWL4030 and TWL6030.
+ * To generate the signal on TWL4030:
+ * - LEDA uses PWMA
+ * - LEDB uses PWMB
+ * TWL6030 has one LED pin with dedicated LEDPWM
+ */
+
+#define TWL4030_LED_MAX0x7f
+#define TWL6030_LED_MAX0xff
+
+/* Registers, bits and macro for TWL4030 */
+#define TWL4030_LEDEN_REG 0x00
+#define TWL4030_PWMA_REG 0x01
+
+#define TWL4030_LEDXON (1 0)
+#define TWL4030_LEDXPWM(1 4)
+#define TWL4030_LED_PINS (TWL4030_LEDXON | TWL4030_LEDXPWM)
+#define TWL4030_LED_TOGGLE(led, x) ((x) (led))
+
+/* Register, bits and macro for TWL6030 */
+#define TWL6030_LED_PWM_CTRL1 0xf4
+#define TWL6030_LED_PWM_CTRL2 0xf5
+
+#define TWL6040_LED_MODE_HW0x00
+#define TWL6040_LED_MODE_ON0x01
+#define TWL6040_LED_MODE_OFF 0x02
+#define TWL6040_LED_MODE_MASK 0x03
+
+struct twl_pwmled_chip {
+ struct pwm_chip chip;
+};
+
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = DIV_ROUND_UP(duty_ns * TWL4030_LED_MAX, period_ns);
+ u8 pwm_config[2] = {1, 0};
+ int base, ret;
+
+ /*
+* To configure the duty period:
+* On-cycle is set to 1 (the minimum allowed value)
+* The off time of 0 is not configurable, so the mapping is:
+* 0 - off cycle = 2,
+* 1 - off cycle = 2,
+* 2 - off cycle = 3,
+* 125 - off cycle 127,
+* 126 - off cycle 1
+* When on cycle == off cycle the PWM will be always on
+*/
+ duty_cycle += 1;
+ if (duty_cycle == 1)
+ duty_cycle = 2;
+ else if (duty_cycle TWL4030_LED_MAX)
+ duty_cycle = 1;
+
+ base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
+
+ pwm_config[1] = duty_cycle;
+
+ ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
+ if (ret 0)
[PATCH v3 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
The driver supports the following PWM outputs:
TWL4030 PWM0 and PWM1
TWL6030 PWM1 and PWM2
On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
will select the correct mux so the PWM can be used. When the PWM has been
freed the original configuration going to be restored.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl.c | 330 ++
3 files changed, 341 insertions(+)
create mode 100644 drivers/pwm/pwm-twl.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e678005..c577db9 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -142,6 +142,16 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
+config PWM_TWL
+ tristate TWL4030/6030 PWM support
+ select HAVE_PWM
+ depends on TWL4030_CORE
+ help
+ Generic PWM framework driver for TWL4030/6030.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-twl.
+
config PWM_VT8500
tristate vt8500 pwm support
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 29cf57e..3324c06 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,4 +11,5 @@ obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
+obj-$(CONFIG_PWM_TWL) += pwm-twl.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c
new file mode 100644
index 000..fadf126
--- /dev/null
+++ b/drivers/pwm/pwm-twl.c
@@ -0,0 +1,330 @@
+/*
+ * Driver for TWL4030/6030 Generic Pulse Width Modulator
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/pwm.h
+#include linux/i2c/twl.h
+#include linux/slab.h
+
+/*
+ * This driver handles the PWMs of TWL4030 and TWL6030.
+ * The TRM names for the PWMs on TWL4030 are: PWM0, PWM1
+ * TWL6030 also have two PWMs named in the TRM as PWM1, PWM2
+ */
+
+#define TWL_PWM_MAX0x7f
+
+/* Registers, bits and macro for TWL4030 */
+#define TWL4030_GPBR1_REG 0x0c
+#define TWL4030_PMBR1_REG 0x0d
+
+/* GPBR1 register bits */
+#define TWL4030_PWMXCLK_ENABLE (1 0)
+#define TWL4030_PWMX_ENABLE(1 2)
+#define TWL4030_PWMX_BITS (TWL4030_PWMX_ENABLE | TWL4030_PWMXCLK_ENABLE)
+#define TWL4030_PWM_TOGGLE(pwm, x) ((x) (pwm))
+
+/* PMBR1 register bits */
+#define TWL4030_GPIO6_PWM0_MUTE_MASK (0x03 2)
+#define TWL4030_GPIO6_PWM0_MUTE_PWM0 (0x01 2)
+#define TWL4030_GPIO7_VIBRASYNC_PWM1_MASK (0x03 4)
+#define TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1 (0x03 4)
+
+/* Register, bits and macro for TWL6030 */
+#define TWL6030_TOGGLE3_REG0x92
+
+#define TWL6030_PWMXR (1 0)
+#define TWL6030_PWMXS (1 1)
+#define TWL6030_PWMXEN (1 2)
+#define TWL6030_PWM_TOGGLE(pwm, x) ((x) (pwm * 3))
+
+struct twl_pwm_chip {
+ struct pwm_chip chip;
+ u8 twl6030_toggle3;
+ u8 twl4030_pwm_mux;
+};
+
+static int twl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = DIV_ROUND_UP(duty_ns * TWL_PWM_MAX, period_ns);
+ u8 pwm_config[2] = {1, 0};
+ int base, ret;
+
+ /*
+* To configure the duty period:
+* On-cycle is set to 1 (the minimum allowed value)
+* The off time of 0 is not configurable, so the mapping is:
+* 0 - off cycle = 2,
+* 1 - off cycle = 2,
+* 2 - off cycle = 3,
+* 126 - off cycle 127,
+* 127 - off cycle 1
+* When on cycle == off cycle the PWM will be always on
+*/
+ duty_cycle += 1;
+ if (duty_cycle == 1)
+ duty_cycle = 2;
+ else if (duty_cycle TWL_PWM_MAX)
+ duty_cycle = 1;
+
+ base = pwm-hwpwm * 3;
+
+ pwm_config[1] = duty_cycle;
+
+ ret = twl_i2c_write(TWL_MODULE_PWM, pwm_config, base, 2);
+ if (ret 0)
+
Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
On 11/14/2012 07:08 PM, AnilKumar Ch wrote: Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register. Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver. Signed-off-by: AnilKumar Ch anilku...@ti.com This does not apply to net-next/master: Applying: ARM: dts: AM33XX: Add memory resource to d_can node error: patch failed: arch/arm/boot/dts/am33xx.dtsi:227 error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Patch failed at 0003 ARM: dts: AM33XX: Add memory resource to d_can node Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
RE: [PATCH] OMAP2+: enable TPS65217 support in omap2plus_defconfig
On Mon, Nov 19, 2012 at 17:15:25, Igor Mazanov wrote: TPS65217 is described in arch/arm/boot/dts/am335x-bone.dts but doesn't enabled in arch/arm/configs/omap2plus_defconfig. Enable TPS65217 support in omap2plus_defconfig. Signed-off-by: Igor Mazanov i.maza...@gmail.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..00f2ce3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -240,3 +240,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_MFD_CORE=y +CONFIG_MFD_TPS65217=y +CONFIG_REGULATOR_TPS65217=y Hi Igor, Can you try this, MFD_CORE is selected by default and note that remaining flags should be added at appropriate places. Author: AnilKumar Ch anilku...@ti.com Date: Tue Nov 20 15:34:51 2012 +0530 Custom: ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support Signed-off-by: AnilKumar Ch anilku...@ti.com diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..69ddbf7 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -132,9 +132,11 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_TPS65217=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TPS65217=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
On 11/20/2012 11:23 AM, AnilKumar, Chimata wrote: On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote: On 11/14/2012 07:08 PM, AnilKumar Ch wrote: Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register. Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver. Signed-off-by: AnilKumar Ch anilku...@ti.com This does not apply to net-next/master: Applying: ARM: dts: AM33XX: Add memory resource to d_can node error: patch failed: arch/arm/boot/dts/am33xx.dtsi:227 error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Patch failed at 0003 ARM: dts: AM33XX: Add memory resource to d_can node Marc, Sorry about this DT changes are present in linux-omap. Could you please take the driver changes only and ACK on remaining will help. Will do - I'm currently looking at the driver. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] can: c_can: Add d_can raminit support
On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM,
which holds all the message objects during transmission or
receiving of data. This initialization/de-initialization should
be done in synchronous with D_CAN clock.
In case of AM335X-EVM (active user of D_CAN driver) message RAM is
controlled through control module register for both instances. So
control module register details is required to initialization or
de-initialization of message RAM according to instance number.
Control module memory resource is obtained from D_CAN dt node and
instance number obtained from device tree aliases node.
Signed-off-by: AnilKumar Ch anilku...@ti.com
Some nitpicks inline.
Marc
---
drivers/net/can/c_can/c_can.c | 12 +++
drivers/net/can/c_can/c_can.h |3 +++
drivers/net/can/c_can/c_can_platform.c | 34
+++-
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e5180df..c15830c 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -233,6 +233,12 @@ static inline void c_can_pm_runtime_put_sync(const
struct c_can_priv *priv)
pm_runtime_put_sync(priv-device);
}
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool
enable)
+{
+ if (priv-ram_init)
+ priv-ram_init(priv, enable);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv-tx_next C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -1090,6 +1096,7 @@ static int c_can_open(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* open the can device */
err = open_candev(dev);
@@ -1118,6 +1125,7 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
exit_open_fail:
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return err;
}
@@ -1131,6 +1139,8 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1188,6 +1198,7 @@ int c_can_power_down(struct net_device *dev)
c_can_stop(dev);
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1206,6 +1217,7 @@ int c_can_power_up(struct net_device *dev)
WARN_ON(priv-type != BOSCH_D_CAN);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* Clear PDR and INIT bits */
val = priv-read_reg(priv, C_CAN_CTRL_EX_REG);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index e5ed41d..419de5c 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,9 @@ struct c_can_priv {
void *priv; /* for board-specific data */
u16 irqstatus;
enum c_can_dev_id type;
+ u32 __iomem *raminit_ctrlreg;
+ unsigned int instance;
+ void (*ram_init) (const struct c_can_priv *priv, bool enable);
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index ee141613..2e61d69 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -38,6 +38,8 @@
#include c_can.h
+#define CAN_RAMINIT_START_MASK(i)(1 (i))
+
/*
* 16-bit c_can registers can be arranged differently in the memory
* architecture of different implementations. For example: 16-bit
@@ -68,6 +70,24 @@ static void c_can_plat_write_reg_aligned_to_32bit(struct
c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
}
+static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
+{
+ u32 val;
+
+ if (!priv-raminit_ctrlreg || (priv-instance 0))
+ return;
Can you move this sanity check to the probe function and only assign
priv-ram_init if the above is true?
+
+ val = readl(priv-raminit_ctrlreg);
+ if (enable) {
+ val = ~CAN_RAMINIT_START_MASK(priv-instance);
+ val |= CAN_RAMINIT_START_MASK(priv-instance);
+ writel(val, priv-raminit_ctrlreg);
+ } else {
+ val = ~CAN_RAMINIT_START_MASK(priv-instance);
+ writel(val, priv-raminit_ctrlreg);
+ }
+}
+
static struct platform_device_id c_can_id_table[] = {
[BOSCH_C_CAN_PLATFORM] = {
.name = KBUILD_MODNAME,
@@ -99,7 +119,7 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
const struct of_device_id *match;
const struct platform_device_id *id;
struct pinctrl *pinctrl;
-
Re: [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases
On 11/14/2012 07:08 PM, AnilKumar Ch wrote: Add d_can instances to aliases node to get the D_CAN instance number from the driver. To initialize D_CAN message RAM, corresponding instance number is required. To initialize instance 0 message RAM then 0x1 should be written and for instance 1 message RAM, 0x2 should be written to control module register. With device-tree framework ip instance number is -1 by default for all instances. To get device id/instance number then modules should be added to DT aliases node. of_alias_get_id() gives the device id number based on number of alias nodes present in aliases node. Signed-off-by: AnilKumar Ch anilku...@ti.com Acked-by: Marc Kleine-Budde m...@pengutronix.de -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
RE: [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Mon, Nov 19, 2012 at 20:59:16, Daniel Mack wrote: This patch adds basic DT bindings for OMAP GPMC. ... + + if (of_get_property(child, ti,nand-ecc-use-elm, NULL)) + gpmc_nand_data-is_elm_used = 1; Can you set to bool value (true) here. Thanks Avinash -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On 11/20/2012 10:56 AM, Peter Ujfalusi wrote:
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl-led.c | 303
++
3 files changed, 314 insertions(+)
create mode 100644 drivers/pwm/pwm-twl-led.c
...
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
*pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = DIV_ROUND_UP(duty_ns * TWL4030_LED_MAX, period_ns);
+ u8 pwm_config[2] = {1, 0};
+ int base, ret;
+
+ /*
+ * To configure the duty period:
+ * On-cycle is set to 1 (the minimum allowed value)
+ * The off time of 0 is not configurable, so the mapping is:
+ * 0 - off cycle = 2,
+ * 1 - off cycle = 2,
+ * 2 - off cycle = 3,
+ * 125 - off cycle 127,
+ * 126 - off cycle 1
Oh, I missed to save the updated comment before I commited the change.
Can I just send and update patch instead of the whole series again?
+ * When on cycle == off cycle the PWM will be always on
+ */
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On Tue, Nov 20, 2012 at 12:54:11PM +0100, Peter Ujfalusi wrote:
On 11/20/2012 10:56 AM, Peter Ujfalusi wrote:
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl-led.c | 303
++
3 files changed, 314 insertions(+)
create mode 100644 drivers/pwm/pwm-twl-led.c
...
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
*pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = DIV_ROUND_UP(duty_ns * TWL4030_LED_MAX, period_ns);
+ u8 pwm_config[2] = {1, 0};
+ int base, ret;
+
+ /*
+* To configure the duty period:
+* On-cycle is set to 1 (the minimum allowed value)
+* The off time of 0 is not configurable, so the mapping is:
+* 0 - off cycle = 2,
+* 1 - off cycle = 2,
+* 2 - off cycle = 3,
+* 125 - off cycle 127,
+* 126 - off cycle 1
Oh, I missed to save the updated comment before I commited the change.
Can I just send and update patch instead of the whole series again?
Sure.
Sorry for taking so long to review this. I'm rather busy with other
things but I'll try to find some time to review properly tonight or
tomorrow.
Thierry
pgpNoPTamFVbI.pgp
Description: PGP signature
[PATCH] pwm: pwm-twl-led: Correct comment for cycle configuration
The original commit was not documenting correctly the behavior of the cycle configuration. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Thierry, small update to the new pwm-twl-led driver to correct the comment describing the cycle configuration for the PWMA/B of TWL4030. The update is on top of v3 of the twl pwm series: https://lkml.org/lkml/2012/11/20/193 Regards, Peter drivers/pwm/pwm-twl-led.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c index 9468720..e62b95e 100644 --- a/drivers/pwm/pwm-twl-led.c +++ b/drivers/pwm/pwm-twl-led.c @@ -73,8 +73,8 @@ static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device *pwm, * 0 - off cycle = 2, * 1 - off cycle = 2, * 2 - off cycle = 3, -* 125 - off cycle 127, -* 126 - off cycle 1 +* 126 - off cycle 127, +* 127 - off cycle 1 * When on cycle == off cycle the PWM will be always on */ duty_cycle += 1; -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] crypto: omap-aes updates
Great. You also worked on AES... Will take a loos asap. On Mon, Nov 19, 2012 at 9:03 PM, Mark A. Greer mgr...@animalcreek.com wrote: From: Mark A. Greer mgr...@animalcreek.com This series updates the crypto omap-aes driver and supporting infrastructure. Notes: a) Based on omap-sham patches recently submitted, XXX b) Since these patches will likely go though the OMAP tree (and not through the crypto tree), it would be nice if the crypto guy(s) would ACK or NACK patches 4-7 which modify the drivers/crypto/omap-sham.c driver. c) These have only been tested on an omap2420 h4 and an am37x evm. d) Many thanks to Jon Hunter for testing on his omap2420 h4. Mark A. Greer (7): ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no AES IP is present crypto: omap-aes: Remove cpu_is/omap_type check from driver crypto: omap-aes: Convert to use pm_runtime API crypto: omap-aes: Add code to use dmaengine API crypto: omap-aes: Remove usage of private DMA API arch/arm/mach-omap2/clock2430_data.c | 1 + arch/arm/mach-omap2/clock3xxx_data.c | 1 + arch/arm/mach-omap2/devices.c | 75 +--- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 38 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 +++ arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + drivers/crypto/omap-aes.c | 202 - 10 files changed, 251 insertions(+), 150 deletions(-) -- 1.7.12 -- 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] can: c_can: Add d_can raminit support
On Tue, Nov 20, 2012 at 16:20:41, Marc Kleine-Budde wrote:
On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM,
which holds all the message objects during transmission or
receiving of data. This initialization/de-initialization should
be done in synchronous with D_CAN clock.
In case of AM335X-EVM (active user of D_CAN driver) message RAM is
controlled through control module register for both instances. So
control module register details is required to initialization or
de-initialization of message RAM according to instance number.
Control module memory resource is obtained from D_CAN dt node and
instance number obtained from device tree aliases node.
Signed-off-by: AnilKumar Ch anilku...@ti.com
Some nitpicks inline.
Thanks for the review.
---
drivers/net/can/c_can/c_can.c | 12 +++
drivers/net/can/c_can/c_can.h |3 +++
drivers/net/can/c_can/c_can_platform.c | 34
+++-
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e5180df..c15830c 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -233,6 +233,12 @@ static inline void c_can_pm_runtime_put_sync(const
struct c_can_priv *priv)
pm_runtime_put_sync(priv-device);
}
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool
enable)
+{
+ if (priv-ram_init)
+ priv-ram_init(priv, enable);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv-tx_next C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -1090,6 +1096,7 @@ static int c_can_open(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* open the can device */
err = open_candev(dev);
@@ -1118,6 +1125,7 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
exit_open_fail:
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return err;
}
@@ -1131,6 +1139,8 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1188,6 +1198,7 @@ int c_can_power_down(struct net_device *dev)
c_can_stop(dev);
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1206,6 +1217,7 @@ int c_can_power_up(struct net_device *dev)
WARN_ON(priv-type != BOSCH_D_CAN);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* Clear PDR and INIT bits */
val = priv-read_reg(priv, C_CAN_CTRL_EX_REG);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index e5ed41d..419de5c 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,9 @@ struct c_can_priv {
void *priv; /* for board-specific data */
u16 irqstatus;
enum c_can_dev_id type;
+ u32 __iomem *raminit_ctrlreg;
+ unsigned int instance;
+ void (*ram_init) (const struct c_can_priv *priv, bool enable);
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index ee141613..2e61d69 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -38,6 +38,8 @@
#include c_can.h
+#define CAN_RAMINIT_START_MASK(i) (1 (i))
+
/*
* 16-bit c_can registers can be arranged differently in the memory
* architecture of different implementations. For example: 16-bit
@@ -68,6 +70,24 @@ static void c_can_plat_write_reg_aligned_to_32bit(struct
c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
}
+static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
+{
+ u32 val;
+
+ if (!priv-raminit_ctrlreg || (priv-instance 0))
+ return;
Can you move this sanity check to the probe function and only assign
priv-ram_init if the above is true?
Sure, I will change
+
+ val = readl(priv-raminit_ctrlreg);
+ if (enable) {
+ val = ~CAN_RAMINIT_START_MASK(priv-instance);
+ val |= CAN_RAMINIT_START_MASK(priv-instance);
+ writel(val, priv-raminit_ctrlreg);
+ } else {
+ val = ~CAN_RAMINIT_START_MASK(priv-instance);
+ writel(val, priv-raminit_ctrlreg);
+ }
+}
+
static struct platform_device_id c_can_id_table[] = {
[BOSCH_C_CAN_PLATFORM] = {
.name = KBUILD_MODNAME,
@@ -99,7 +119,7 @@ static int __devinit c_can_plat_probe(struct
Re: [PATCH 207/493] i2c: remove use of __devinit
On Tue, Nov 20, 2012 at 09:20:46AM +0100, Jean Delvare wrote: Hi Bill, On Mon, 19 Nov 2012 13:22:36 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Can you please point me/us to the discussion explaining the rationale behind this move, and the explanation of what will be done exactly? While I can easily understand that we want to drop CONFIG_HOTPLUG and always enable hot-plug support, I don't see where we are going with removing __devinit annotations and the like. It's actually very simple to understand. 1. CONFIG_HOTPLUG is going away; it's already defined to always be 'Y'. 2. This means that the the devinit sections will not be discarded anymore. 3. As a result, there's no point the devinit sections existing anymore. 4. As there's no devinit sections, the __devinit marker is entirely redundant and useless. The reason this is being done is because the benefit to cost ratio of this is far too high; it's well proven that people constantly get these markings wrong, and with most kernels having had hotplug enabled anyway, it's not providing much in the way of space saving benefit over the number of section conflicts it causes. So, it's been decided a few years ago that this is going to happen, with that justification, and it's been accepted by 300 odd kernel developers in at least one kernel summit when it was talked about... and it's been mentioned on mailing lists several times. -- 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 207/493] i2c: remove use of __devinit
On Tue, 20 Nov 2012 13:23:42 +, Russell King - ARM Linux wrote: On Tue, Nov 20, 2012 at 09:20:46AM +0100, Jean Delvare wrote: Hi Bill, On Mon, 19 Nov 2012 13:22:36 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Can you please point me/us to the discussion explaining the rationale behind this move, and the explanation of what will be done exactly? While I can easily understand that we want to drop CONFIG_HOTPLUG and always enable hot-plug support, I don't see where we are going with removing __devinit annotations and the like. It's actually very simple to understand. 1. CONFIG_HOTPLUG is going away; it's already defined to always be 'Y'. 2. This means that the the devinit sections will not be discarded anymore. 3. As a result, there's no point the devinit sections existing anymore. 4. As there's no devinit sections, the __devinit marker is entirely redundant and useless. Ah, yes, very simple indeed. Not sure how I managed to not understand it earlier today. Thanks for explaining. The reason this is being done is because the benefit to cost ratio of this is far too high; it's well proven that people constantly get these markings wrong, and with most kernels having had hotplug enabled anyway, it's not providing much in the way of space saving benefit over the number of section conflicts it causes. So, it's been decided a few years ago that this is Yes, I completely agree. going to happen, with that justification, and it's been accepted by 300 odd kernel developers in at least one kernel summit when it was talked Probably that was one I didn't attend to, as I can't remember this discussion. about... and it's been mentioned on mailing lists several times. Maybe LKML, which I don't read. So I wasn't aware of the plan before seeing Bill's patches. -- Jean Delvare -- 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] can: c_can: Add d_can raminit support
On 11/20/2012 02:05 PM, AnilKumar, Chimata wrote:
[...]
static struct platform_device_id c_can_id_table[] = {
[BOSCH_C_CAN_PLATFORM] = {
.name = KBUILD_MODNAME,
@@ -99,7 +119,7 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
const struct of_device_id *match;
const struct platform_device_id *id;
struct pinctrl *pinctrl;
- struct resource *mem;
+ struct resource *mem, *res;
int irq;
struct clk *clk;
@@ -178,6 +198,18 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
priv-can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
priv-read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv-write_reg = c_can_plat_write_reg_aligned_to_16bit;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ priv-raminit_ctrlreg =
+ devm_request_and_ioremap(pdev-dev, res);
What happens if there isn't a second IORESOURCE_MEM region? devm_request
will print an error in this case and any other error, too [1]. Do we
need streamlining here?
[1] http://lxr.free-electrons.com/source/drivers/base/platform.c#L59
I did not get what the point is.
In most of the cases above two API's returns NULL. Even res is NULL
nothing to worry, first condition in devm_request_and_ioremap() is
NULL pointer check of res. If res is NULL then devm_xx will return
NULL which result into printing of below warning.
+ if (!priv-raminit_ctrlreg)
+ dev_warn(pdev-dev, failed to obtain control
memory\n);
I will change this warning to info
if (!priv-raminit_ctrlreg)
dev_info(pdev-dev, control memory is not used for raminit\n);
That's more descriptive, good.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 065/493] i2c: remove use of __devexit_p
On Mon, 19 Nov 2012 13:20:14 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. As mentioned on the lm-sensors list for hwmon patches already, I think it would be much clearer to not split __devexit, __devexit_p, __devinit etc. removal into separate patches. One patch per subsystem would be easier to review and apply. If patches grow too large then you'd rather split in a different direction, for example drivers/i2c/muxes vs. drivers/i2c/busses or even grouped by related bus drivers (see entries I2C OVER PARALLEL PORT and I2C/SMBUS CONTROLLER DRIVERS FOR PC in MAINTAINERS for examples of meaningful groups.) -- Jean Delvare -- 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 119/493] usb: remove use of __devexit_p
Nicolas == Nicolas Ferre nicolas.fe...@atmel.com writes: Nicolas On 11/19/2012 07:21 PM, Bill Pemberton : CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Peter Korsgaard jac...@sunsite.dk Cc: Alexander Shishkin alexander.shish...@linux.intel.com Cc: Felipe Balbi ba...@ti.com Cc: Li Yang le...@freescale.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Wan ZongShun mcuos@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Nicolas [..] drivers/usb/host/ehci-atmel.c| 2 +- drivers/usb/host/ohci-at91.c | 2 +- Nicolas For Atmel: Nicolas Acked-by: Nicolas Ferre nicolas.fe...@atmel.com For c67x00 and g_hid: Acked-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT] OMAP: N770: remove custom implementation of ads7846_get_pendown_state
Hi, On Tue, Nov 20, 2012 at 12:30:53AM -0800, Dmitry Torokhov wrote: The default implementation matches exactly our custom one so we can switch to using the default one. As a bonus the driver will take care of setting GPIO line for us. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com --- No hardware so not tested... This seems to work. Tested-by: Aaro Koskinen aaro.koski...@iki.fi A minor nitpick, the board is just 770 not N770. :-) A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
On 2012-11-20 00:04, Tony Lindgren wrote: Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also? Yes if that's now needed for DSS. DSS works fine without CMA, at least for small displays, and when fb allocation is done at boot time. So it's not a strict need. I'm not sure how easily FB allocations start to fail without CMA, and how much CMA helps. I'm not even sure what's the default DMA pool size on OMAP... If it's the one set with coherent_pool kernel parameter, then the default seems to be 256K, which is quite small for video use. For CMA the default global area is 16M. Both can, of course, be changed with boot params or kernel config (at least for CMA). But I think it makes sense to have CMA by default even if non-CMA kernel would work. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Daniel == Daniel Mack zon...@gmail.com writes: Hi, In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout OMAP_ECC_HAMMING_CODE_HW_ROMCODE OMAP_ECC_BCH4_CODE_HW OMAP_ECC_BCH8_CODE_HW So selection of ecc layout data should come from DT not ecc mode. Ok, I see. I would still like to set them by string rather than magic numbers that map to enum entries. Valid values would be none, hw, hw-romcode, bch4 and bch8. Are you ok with that? Ok, that's nice. Better use ecc_opt instead of ecc_mode. Daniel I did some more extensive tests that include reading the same Daniel nand pages from both U-Boot and the kernel with BCH8 ECC, and Daniel it turns out that - is_elm_used needs to be set in the pdata Daniel in order to make this work. So what you're saying is that the choice of ELM or not is not just an optimization, it really changes the ECC layout? Perhaps it should be treated as a seperate layout (E.G. bch8-elm) then? -- Bye, Peter Korsgaard -- 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 270/493] arm: remove use of __devinit
On Mon, Nov 19, 2012 at 01:23:39PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu --- arch/arm/mach-msm/proc_comm.c| 2 +- arch/arm/mach-msm/smd.c | 2 +- Acked-by: David Brown dav...@codeaurora.org -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Sat, 17 Nov 2012 23:27:18 +0100, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 16:23 Fri 09 Nov , Stephen Warren wrote: On 11/09/2012 09:28 AM, Grant Likely wrote: However, I think the process for an end-user needs to be as simple as drop this .dts/.dtb file into some standard directory, and I imagine it'll be much easier for distros/... to make that process work if they're dealing with a .dtb that they can just blast into the kernel's firmware loader interface, rather than having to also locate the base-board .dts/.dtb file, and run dtc and/or other tools on both .dts files together. I've exactly the same issue on Calao or the new atmel boards We have lego boards with different cpu-modues running on differetn mother boards with diferrentdaugther boards on atmel we are lucky enough we can identity via 1-wire all of them but on Calao no On Somfy platform we can detect hardware version and need different pinctrl So personally I'll prefer to be able to request dtb from the kernel or push them from the userspace as it will depends where you will detect the hardware present The main concern will which part of the kenel will now handle hw detection? Along the lines of what you said above, it will depend on the board. If the board /can/ be detected, then the kernel should do so and request the appropriate configuration. If it cannot, then it simply must be left up to either userspace or something explicit in the boot devicetree. g. -- 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] OMAP2+: enable TPS65217 support in omap2plus_defconfig
On Tue, Nov 20, 2012 at 2:15 PM, AnilKumar, Chimata anilku...@ti.com wrote: On Mon, Nov 19, 2012 at 17:15:25, Igor Mazanov wrote: TPS65217 is described in arch/arm/boot/dts/am335x-bone.dts but doesn't enabled in arch/arm/configs/omap2plus_defconfig. Enable TPS65217 support in omap2plus_defconfig. Signed-off-by: Igor Mazanov i.maza...@gmail.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..00f2ce3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -240,3 +240,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_MFD_CORE=y +CONFIG_MFD_TPS65217=y +CONFIG_REGULATOR_TPS65217=y Hi Igor, Can you try this, MFD_CORE is selected by default and note that remaining flags should be added at appropriate places. Author: AnilKumar Ch anilku...@ti.com Date: Tue Nov 20 15:34:51 2012 +0530 Custom: ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support Signed-off-by: AnilKumar Ch anilku...@ti.com diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..69ddbf7 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -132,9 +132,11 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_TPS65217=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TPS65217=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y OK, I made changes as you say and it works. Thanks for a tip about default selection of CONFIG_MFD. Regards, Igor. Thanks AnilKumar -- 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: OMAP* Latest build failures
* Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]: On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' These are now gone, but we have a new warning: arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined but not used Jon, care to fix this one? And the randconfig found: drivers/staging/omap-thermal/omap-bandgap.c: In function 'omap_bandgap_readl': drivers/staging/omap-thermal/omap-bandgap.c:46:2: error: implicit declaration of function 'readl' drivers/staging/omap-thermal/omap-bandgap.c: In function 'omap_bandgap_writel': drivers/staging/omap-thermal/omap-bandgap.c:51:2: error: implicit declaration of function 'writel' Which, as its in staging, maybe its not important but it's another source of unnecessary failure. Radhesh Eduardo, can you fix this? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT] OMAP: N770: remove custom implementation of ads7846_get_pendown_state
* Aaro Koskinen aaro.koski...@iki.fi [121120 06:45]: Hi, On Tue, Nov 20, 2012 at 12:30:53AM -0800, Dmitry Torokhov wrote: The default implementation matches exactly our custom one so we can switch to using the default one. As a bonus the driver will take care of setting GPIO line for us. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com --- No hardware so not tested... This seems to work. Tested-by: Aaro Koskinen aaro.koski...@iki.fi A minor nitpick, the board is just 770 not N770. :-) Nice. Looks safe to merge along with other input related patches: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3 2/4] mfd: introduce retu-mfd driver
* Aaro Koskinen aaro.koski...@iki.fi [121112 11:11]:
Retu is a multi-function device found on Nokia Internet Tablets
implementing at least watchdog, RTC, headset detection and power button
functionality.
This patch implements minimum functionality providing register access,
IRQ handling and power off functions.
Samuel, you can pick this one up separately now that Wolfram has taken
the i2c-cbus driver.
Also, just noticed that this probably should depend on I2C_CBUS as this
chip will not communicate over other I2C adapters?
Regards,
Tony
Cc: sa...@linux.intel.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/mfd/Kconfig |9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/retu-mfd.c | 264
++
include/linux/mfd/retu.h | 22
4 files changed, 296 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/retu-mfd.c
create mode 100644 include/linux/mfd/retu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index acab3ef..7528c5e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1044,6 +1044,15 @@ config MFD_PALMAS
If you say yes here you get support for the Palmas
series of PMIC chips from Texas Instruments.
+config MFD_RETU
+ tristate Support for Retu multi-function device
+ select MFD_CORE
+ depends on I2C
+ select REGMAP_IRQ
+ help
+ Retu is a multi-function device found on Nokia Internet Tablets
+ (770, N800 and N810).
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d8ccb63..ad7879f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -138,3 +138,4 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+obj-$(CONFIG_MFD_RETU) += retu-mfd.o
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
new file mode 100644
index 000..7ff4a37
--- /dev/null
+++ b/drivers/mfd/retu-mfd.c
@@ -0,0 +1,264 @@
+/*
+ * Retu MFD driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall and Mikko Ylinen.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/module.h
+#include linux/regmap.h
+#include linux/mfd/core.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/moduleparam.h
+
+/* Registers */
+#define RETU_REG_ASICR 0x00/* ASIC ID and revision
*/
+#define RETU_REG_ASICR_VILMA (1 7)/* Bit indicating Vilma */
+#define RETU_REG_IDR 0x01/* Interrupt ID */
+#define RETU_REG_IMR 0x02/* Interrupt mask */
+
+/* Interrupt sources */
+#define RETU_INT_PWR 0 /* Power button */
+
+struct retu_dev {
+ struct regmap *regmap;
+ struct device *dev;
+ struct mutexmutex;
+ struct regmap_irq_chip_data *irq_data;
+};
+
+static struct resource retu_pwrbutton_res[] = {
+ {
+ .name = retu-pwrbutton,
+ .start = RETU_INT_PWR,
+ .end= RETU_INT_PWR,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell retu_devs[] = {
+ {
+ .name = retu-wdt
+ },
+ {
+ .name = retu-pwrbutton,
+ .resources = retu_pwrbutton_res,
+ .num_resources = ARRAY_SIZE(retu_pwrbutton_res),
+ }
+};
+
+static struct regmap_irq retu_irqs[] = {
+ [RETU_INT_PWR] = {
+ .mask = 1 RETU_INT_PWR,
+ }
+};
+
+static struct regmap_irq_chip retu_irq_chip = {
+ .name = RETU,
+ .irqs = retu_irqs,
+ .num_irqs = ARRAY_SIZE(retu_irqs),
+ .num_regs = 1,
+ .status_base= RETU_REG_IDR,
+ .mask_base = RETU_REG_IMR,
+ .ack_base = RETU_REG_IDR,
+};
+
+/* Retu device registered for the power off. */
+static struct retu_dev *retu_pm_power_off;
+
+int retu_read(struct retu_dev *rdev, u8 reg)
+{
+ int ret;
+ int value;
+
+
Re: [RESEND PATCH v3 2/4] mfd: introduce retu-mfd driver
* Tony Lindgren t...@atomide.com [121120 10:36]: * Aaro Koskinen aaro.koski...@iki.fi [121112 11:11]: Retu is a multi-function device found on Nokia Internet Tablets implementing at least watchdog, RTC, headset detection and power button functionality. This patch implements minimum functionality providing register access, IRQ handling and power off functions. Samuel, you can pick this one up separately now that Wolfram has taken the i2c-cbus driver. Also, just noticed that this probably should depend on I2C_CBUS as this chip will not communicate over other I2C adapters? Sorry meant to reply to [PATCH v4 2/4] mfd: introduce retu-mfd driver instead of this v3 thread. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
On Mon, Nov 19, 2012 at 1:19 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 11/19/2012 11:40 AM, Linus Walleij wrote: So what we're dealing with is: a LED-specific PWM, being used as a PWM with eternal dutycycle and then being used as GPIO. Well, we get to deal with it ... :-/ gpio/gpio-pwm driver? Yeah something like that, but such a driver would need some huge boilerplate saying that this approach isn't entirely sound. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ir-rx51: Handle signals properly
Hi,
* Timo Kokkonen timo.t.kokko...@iki.fi [121118 07:15]:
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
Good fixes in general.. But you won't be able to access the
omap_dm_timer functions after we enable ARM multiplatform support
for omap2+. That's for v3.9 probably right after v3.8-rc1.
We need to find some Linux generic API to use hardware timers
like this, so I've added Thomas Gleixner and linux-arm-kernel
mailing list to cc.
If no such API is available, then maybe we can export some of
the omap_dm_timer functions if Thomas is OK with that.
The other alternative is to set them up as platform_data
function pointers, but that won't work after we make omap2+
device tree only. And that really just postpones the problem.
Cheers,
Tony
@@ -163,13 +176,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int irq,
void *ptr)
return IRQ_HANDLED;
end:
- /* Stop TX here */
- lirc_rx51_off(lirc_rx51);
- lirc_rx51-wbuf_index = -1;
- omap_dm_timer_stop(lirc_rx51-pwm_timer);
- omap_dm_timer_stop(lirc_rx51-pulse_timer);
- omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
- wake_up_interruptible(lirc_rx51-wqueue);
+ lirc_rx51_stop_tx(lirc_rx51);
return IRQ_HANDLED;
}
@@ -249,8 +256,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if ((count WBUF_LEN) || (count % 2 == 0))
return -EINVAL;
- /* Wait any pending transfers to finish */
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ /* We can have only one transmit at a time */
+ if (lirc_rx51-wbuf_index = 0)
+ return -EBUSY;
if (copy_from_user(lirc_rx51-wbuf, buf, n))
return -EFAULT;
@@ -276,9 +284,18 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
/*
* Don't return back to the userspace until the transfer has
- * finished
+ * finished. However, we wish to not spend any more than 500ms
+ * in kernel. No IR code TX should ever take that long.
+ */
+ i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0,
+ HZ / 2);
+
+ /*
+ * Ensure transmitting has really stopped, even if the timers
+ * went mad or something else happened that caused it still
+ * sending out something.
*/
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ lirc_rx51_stop_tx(lirc_rx51);
/* We can sleep again */
lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
* Joerg Roedel j...@8bytes.org [121117 04:12]: On Mon, Nov 12, 2012 at 02:00:34PM -0800, Tony Lindgren wrote: Assuming Joerg is OK with these changes, I can push them into an immutable branch that Joerg can merge in as needed. Further patches on top of this series can then be queued by Joerg as arch/arm/*omap* and me are then out of the way of iommu development. Okay, from my side: Acked-by: Joerg Roedel j...@8bytes.org Please let me know which branch I need to pull into my tree when you merged these patches. Thanks, I've pushed it out to omap-for-v3.8/cleanup-headers-iommu at git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git so you can merge it into the iommu tree. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 159/493] usb: remove use of __devinit
On Mon, 19 Nov 2012, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu For all the __devinit* annotations and all the EHCI, OHCI, and UHCI drivers: Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
* Tomi Valkeinen tomi.valkei...@ti.com [121115 23:17]: I added your acks, and pushed: git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion It's based on -rc4 as my other branches are based on that. OK thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 064/493] hwspinlock: remove use of __devexit_p
On Mon, Nov 19, 2012 at 7:20 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Ohad Ben-Cohen o...@wizery.com Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 253/493] hwspinlock: remove use of __devinit
On Mon, Nov 19, 2012 at 7:23 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Ohad Ben-Cohen o...@wizery.com Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 403/493] hwspinlock: remove use of __devexit
On Mon, Nov 19, 2012 at 7:25 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Ohad Ben-Cohen o...@wizery.com Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP* Latest build failures
On 11/20/2012 11:57 AM, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]: On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' These are now gone, but we have a new warning: arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined but not used Jon, care to fix this one? Fix already available here [1]. I actually included this in my latest pull request with some other timer clean-ups [2]. Let me know if you are ok with this being part of this pull request or if you want to handle this separately. Cheers Jon [1] http://marc.info/?l=linux-omapm=135300866115036w=2 [2] http://marc.info/?l=linux-omapm=135308624321232w=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 00/16] OMAP USB Host cleanup
Hi Roger, * Kevin Hilman khil...@deeprootsystems.com [121119 15:24]: Roger Quadros rog...@ti.com writes: Kevin, On 11/16/2012 10:08 PM, Kevin Hilman wrote: Roger Quadros rog...@ti.com writes: Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) - Save power on Panda when EHCI driver is not loaded. Seeing the clock changes/cleanups, I gave this a spin on OMAP3 (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it fixed up the problem where CORE does not hit retention in idle when USB host is enabled, even with no devices attached. Unfortunately, it didn't help. :( oh that's bad. But this series wasn't meant to fix that ;). Oh, sorry. Yeah, I didn't mean this as a nak. Just an opportunity to complain to the maintainers that a long-standing issue needs to be addressed. It seems that drivers/mfd/omap-usb-host.c is one of the last users of cpu_is_omap macros blocking enabling ARM multiplatform support for omap2+. Please fix that ASAP as early as possible in this patch series to remove the dependencies between core omap code development and driver development. Basically you need to remove #include plat/cpu.h and pass the revision information in platform data (and device tree compatible flag when that is supported). Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] crypto: omap-aes: Remove cpu_is/omap_type check from driver
* Mark A. Greer mgr...@animalcreek.com [121119 11:06]:
From: Mark A. Greer mgr...@animalcreek.com
The omap-aes driver should not check the CPU class or the
type of OMAP device its on. The platform code should do
that instead.
Similar patch for this one too should be queued already.
Regards,
Tony
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 093a8af..628c3cc 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -941,11 +941,6 @@ static int __init omap_aes_mod_init(void)
{
pr_info(loading %s driver\n, omap-aes);
- if (!cpu_class_is_omap2() || omap_type() != OMAP2_DEVICE_TYPE_SEC) {
- pr_err(Unsupported cpu\n);
- return -ENODEV;
- }
-
return platform_driver_register(omap_aes_driver);
}
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] crypto: omap-sham: Add code to use dmaengine API
* Mark A. Greer mgr...@animalcreek.com [121119 10:58]: @@ -27,6 +29,10 @@ #include linux/platform_device.h #include linux/scatterlist.h #include linux/dma-mapping.h +#ifndef OMAP_SHAM_DMA_PRIVATE +#include linux/dmaengine.h +#include linux/omap-dma.h +#endif #include linux/pm_runtime.h #include linux/delay.h #include linux/crypto.h I think you should be able to drop the OMAP_SHAM_DMA_PRIVATE from the include after I'll post one more patch to move the omap private DMA header to linux/dma-mapping.h that we already have until the dmaengine conversion is completed. @@ -37,8 +43,10 @@ #include crypto/hash.h #include crypto/internal/hash.h +#ifdef OMAP_SHAM_DMA_PRIVATE #include plat/dma.h And then this can be dropped. #include mach/irqs.h But this needs to go too, as we have that only for omap1 when ARM multiplatform is enabled for omap2+. The interrupt should be passed in platform_data. However, if there are some indirect dependencies for omap1, you can just put it into ifdef CONFIG_ARCH_OMAP1 for now. There's probably the same issue for the other series you posted. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] can: c_can: Add d_can raminit support
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM,
which holds all the message objects during transmission or
receiving of data. This initialization/de-initialization should
be done in synchronous with D_CAN clock.
In case of AM335X-EVM (current user of D_CAN driver) message RAM is
controlled through control module register for both instances. So
control module register details is required to initialization or
de-initialization of message RAM according to instance number.
Control module memory resource is obtained from D_CAN dt node and
instance number obtained from device tree aliases node.
This patch was tested on AM335x-EVM along with pinctrl data addition
patch, d_can dt aliases addition and control module data addition.
pinctrl data addition is not added to am335x-evm.dts (only supports
CPLD profile#0) because d_can1 is supported under CPLD profile#1.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Changes from v1:
- Incorporated Marc's comments on v1
* sanity check moved to c_can_probe() from c_can_hw_raminit()
* device instance is assigned using conditional operator
* Changed warning to info to tell control module is not
used for raminit if there is no second IORESOURCE_MEM
- Dropped dt patches
* No changes from v1
* Those will go to linux-omap/master
drivers/net/can/c_can/c_can.c | 12
drivers/net/can/c_can/c_can.h |3 +++
drivers/net/can/c_can/c_can_platform.c | 33 +++-
3 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e5180df..c15830c 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -233,6 +233,12 @@ static inline void c_can_pm_runtime_put_sync(const struct
c_can_priv *priv)
pm_runtime_put_sync(priv-device);
}
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool enable)
+{
+ if (priv-ram_init)
+ priv-ram_init(priv, enable);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv-tx_next C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -1090,6 +1096,7 @@ static int c_can_open(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* open the can device */
err = open_candev(dev);
@@ -1118,6 +1125,7 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
exit_open_fail:
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return err;
}
@@ -1131,6 +1139,8 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1188,6 +1198,7 @@ int c_can_power_down(struct net_device *dev)
c_can_stop(dev);
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1206,6 +1217,7 @@ int c_can_power_up(struct net_device *dev)
WARN_ON(priv-type != BOSCH_D_CAN);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* Clear PDR and INIT bits */
val = priv-read_reg(priv, C_CAN_CTRL_EX_REG);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index e5ed41d..419de5c 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,9 @@ struct c_can_priv {
void *priv; /* for board-specific data */
u16 irqstatus;
enum c_can_dev_id type;
+ u32 __iomem *raminit_ctrlreg;
+ unsigned int instance;
+ void (*ram_init) (const struct c_can_priv *priv, bool enable);
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index ee141613..d1c31c8 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -38,6 +38,8 @@
#include c_can.h
+#define CAN_RAMINIT_START_MASK(i) (1 (i))
+
/*
* 16-bit c_can registers can be arranged differently in the memory
* architecture of different implementations. For example: 16-bit
@@ -68,6 +70,21 @@ static void c_can_plat_write_reg_aligned_to_32bit(struct
c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
}
+static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
+{
+ u32 val;
+
+ val = readl(priv-raminit_ctrlreg);
+ if (enable) {
+ val = ~CAN_RAMINIT_START_MASK(priv-instance);
+ val |= CAN_RAMINIT_START_MASK(priv-instance);
+ writel(val, priv-raminit_ctrlreg);
+ } else {
+ val =
RE: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
On Tue, Nov 20, 2012 at 15:56:32, Marc Kleine-Budde wrote: On 11/20/2012 11:23 AM, AnilKumar, Chimata wrote: On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote: On 11/14/2012 07:08 PM, AnilKumar Ch wrote: Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register. Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver. Signed-off-by: AnilKumar Ch anilku...@ti.com This does not apply to net-next/master: Applying: ARM: dts: AM33XX: Add memory resource to d_can node error: patch failed: arch/arm/boot/dts/am33xx.dtsi:227 error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Patch failed at 0003 ARM: dts: AM33XX: Add memory resource to d_can node Marc, Sorry about this DT changes are present in linux-omap. Could you please take the driver changes only and ACK on remaining will help. Will do - I'm currently looking at the driver. Hi Marc, Please ACK this patch as well. Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] input: misc: introduce retu-pwrbutton
Hi Aaro, On Sun, Nov 18, 2012 at 06:36:22PM +0200, Aaro Koskinen wrote: Add Retu power button driver. This patch (with minot edits) has been queued to 3.8. Thanks! -- Dmitry -- 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/7] ARM: OMAP2+: omap2plus_defconfig: Enable tps65910 PMIC
AM335X-EVM and AM335X-EVMSK devices have tps65910 PMIC regulator, one has to manually enable this support to use regulators. So this patch enables tps65910 mfd and regulator driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b0563dc..2cf6d0e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -135,10 +135,12 @@ CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65910=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] ARM: OMAP2+: omap2plus_defconfig: Enable DCAN controller
AM335X-EVM has BOSCH DCAN controller, one has to manually enable this support to use of DCAN controller. So this patch enables DCAN driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 5e1a763..d79f9c3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -54,6 +54,11 @@ CONFIG_IP_PNP_RARP=y # CONFIG_INET_LRO is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y +CONFIG_CAN=y +CONFIG_CAN_RAW=y +CONFIG_CAN_BCM=y +CONFIG_CAN_C_CAN=y +CONFIG_CAN_C_CAN_PLATFORM=y CONFIG_BT=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] ARM: OMAP2+: omap2plus_defconfig: Enable leds-gpio driver
AM335X-EVMSK and AM335X-BONE devices have gpio controlled user leds, one has to manually enable this support to use user leds. So this patch enables gpio-leds driver in omap2plus_defconfig. Also enables TRIGGER_TIMER and TRIGGER_HEARTBEAT. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 133f04a..5e1a763 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -202,6 +202,11 @@ CONFIG_MMC_UNSAFE_RESUME=y CONFIG_SDIO_UART=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_OMAP=y CONFIG_RTC_DRV_TWL92330=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] ARM: OMAP2+: omap2plus_defconfig: Enable matrix keypad driver
AM335X-EVM device have 3x2 matrix keypad, one has to manually enable this support to use matrix keypad. So this patch enables matrix keypad driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index cf08365..9f9a637 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -111,6 +111,7 @@ CONFIG_USB_KC2190=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y +CONFIG_KEYBOARD_MATRIX=y CONFIG_KEYBOARD_TWL4030=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ARM: OMAP2+: omap2plus_defconfig: Enable lis3lv02d accelerometer
AM335X-EVM and AM335X-EVMSK devices have lis331dlh accelerometer, one has to manually enable this support to use accelerometer. So this patch enables lis3lv02d driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 2cf6d0e..c69c08d 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -83,6 +83,8 @@ CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 +CONFIG_SENSORS_LIS3LV02D=y +CONFIG_SENSORS_LIS3_I2C=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_MULTI_LUN=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] ARM: OMAP2+: AM33XX: Enable few drivers in omap2plus_defconfig
This patch series enable tps65910, lis3lv02d accelerometer, tsl2550 ambient light sensor, matrix keypad, tmp275 temperature sensor, gpio leds and D_CAN drivers in omap2plus_defconfig. These are the peripherals present in AM33XX family of devices. AnilKumar Ch (7): ARM: OMAP2+: omap2plus_defconfig: Enable tps65910 PMIC ARM: OMAP2+: omap2plus_defconfig: Enable lis3lv02d accelerometer ARM: OMAP2+: omap2plus_defconfig: Enable tsl2550 ambient light sensor ARM: OMAP2+: omap2plus_defconfig: Enable matrix keypad driver ARM: OMAP2+: omap2plus_defconfig: Enable tmp275 sensor ARM: OMAP2+: omap2plus_defconfig: Enable leds-gpio driver ARM: OMAP2+: omap2plus_defconfig: Enable DCAN controller arch/arm/configs/omap2plus_defconfig | 17 + 1 file changed, 17 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] ARM: OMAP2+: omap2plus_defconfig: Enable tmp275 sensor
AM335x-evm device have temperature sensor, one has to manually enable this support to use of temperature sensor. So this patch enables tmp275 driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 9f9a637..133f04a 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -135,6 +135,7 @@ CONFIG_GPIO_SYSFS=y CONFIG_GPIO_TWL4030=y CONFIG_W1=y CONFIG_POWER_SUPPLY=y +CONFIG_SENSORS_LM75=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] ARM: OMAP2+: omap2plus_defconfig: Enable tsl2550 ambient light sensor
AM335x-evm device have tsl2550 ambient light sensor, one has to manually enable this support to use light sensor. So this patch enables tsl2550 driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c69c08d..cf08365 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -84,6 +84,7 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_SENSORS_LIS3LV02D=y +CONFIG_SENSORS_TSL2550=y CONFIG_SENSORS_LIS3_I2C=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
