RE: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmodright before timer init
Hello Santosh,
On Wed, 23 Feb 2011, Santosh Shilimkar wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, February 23, 2011 12:42 PM
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-
omap2/timer-gp.c
index 0fc550e..a4e51a2 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -40,10 +40,11 @@
#include plat/dmtimer.h
#include asm/localtimer.h
#include asm/sched_clock.h
+#include plat/common.h
#include timer-gp.h
+#include plat/omap_hwmod.h
-#include plat/common.h
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -133,9 +134,13 @@ static void __init
omap2_gp_clockevent_init(void)
{
u32 tick_rate;
int src;
+ const char *clockevent_hwmod_name;
inited = 1;
+ clockevent_hwmod_name = (gptimer_id == 12) ? timer12 :
timer1;
+ omap_hwmod_late_init_one(clockevent_hwmod_name);
+
Do we need above hard-coding ? This takes away flexibility of
choosing system timer from board files, right ?
Am I missing something here?
You are absolutely right. That was an error on my part. I propose the
following change instead - please let me know what you think.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Wed, 23 Feb 2011 00:14:08 -0700
Subject: [PATCH] OMAP2+: clockevent: late-init GPTIMER clockevent hwmod right
before timer init
Late-initialize the GPTIMER hwmod used for the clockevent source immediately
before it is used. This avoids the need to late-initialize all of the hwmods
until the boot process is further along. (In general, we want to defer
as much as possible until late in the boot process.)
This second version fixes a bug pointed out by Santosh Shilimkar
santosh.shilim...@ti.com, that would cause the kernel to use an
incorrect timer hwmod name if the selected GPTIMER was not 1 or 12 -
thanks Santosh. Also, Tarun Kanti DebBarma tarun.ka...@ti.com
pointed out that the original patch did not apply cleanly; this has
now been fixed.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/timer-gp.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 7b7c268..d23767f 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -39,10 +39,11 @@
#include asm/mach/time.h
#include plat/dmtimer.h
#include asm/localtimer.h
+#include plat/common.h
+#include plat/omap_hwmod.h
#include timer-gp.h
-#include plat/common.h
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -132,9 +133,13 @@ static void __init omap2_gp_clockevent_init(void)
{
u32 tick_rate;
int src;
+ char *clockevent_hwmod_name;
inited = 1;
+ sprintf(clockevent_hwmod_name, timer%d, gptimer_id);
+ omap_hwmod_late_init_one(clockevent_hwmod_name);
+
gptimer = omap_dm_timer_request_specific(gptimer_id);
BUG_ON(gptimer == NULL);
gptimer_wakeup = gptimer;
--
1.7.2.3
RE: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmodright before timer init
Hello Santosh,
On Thu, 24 Feb 2011, Paul Walmsley wrote:
I propose the following change instead - please let me know what you
think.
Oops - the patch I sent you was not completely refreshed in the local
tree. Here is the correct one.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Wed, 23 Feb 2011 00:14:08 -0700
Subject: [PATCH] OMAP2+: clockevent: late-init GPTIMER clockevent hwmod right
before timer init
Late-initialize the GPTIMER hwmod used for the clockevent source immediately
before it is used. This avoids the need to late-initialize all of the hwmods
until the boot process is further along. (In general, we want to defer
as much as possible until late in the boot process.)
This second version fixes a bug pointed out by Santosh Shilimkar
santosh.shilim...@ti.com, that would cause the kernel to use an
incorrect timer hwmod name if the selected GPTIMER was not 1 or 12 -
thanks Santosh. Also, Tarun Kanti DebBarma tarun.ka...@ti.com
pointed out that the original patch did not apply cleanly; this has
now been fixed.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/timer-gp.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 7b7c268..b289d53 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -39,10 +39,11 @@
#include asm/mach/time.h
#include plat/dmtimer.h
#include asm/localtimer.h
+#include plat/common.h
+#include plat/omap_hwmod.h
#include timer-gp.h
-#include plat/common.h
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -132,9 +133,13 @@ static void __init omap2_gp_clockevent_init(void)
{
u32 tick_rate;
int src;
+ char clockevent_hwmod_name[8]; /* 8 = sizeof(timerXX0) */
inited = 1;
+ sprintf(clockevent_hwmod_name, timer%d, gptimer_id);
+ omap_hwmod_late_init_one(clockevent_hwmod_name);
+
gptimer = omap_dm_timer_request_specific(gptimer_id);
BUG_ON(gptimer == NULL);
gptimer_wakeup = gptimer;
--
1.7.2.3
RE: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmod right before timer init
Hello Tarun On Wed, 23 Feb 2011, DebBarma, Tarun Kanti wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Wednesday, February 23, 2011 12:42 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren; Hilman, Kevin; Shilimkar, Santosh; Cousson, Benoit Subject: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmod right before timer init I am not able to apply this patch. Patch 1-7 applied successfully on top of: 04aa67d Merge branch 'for-tony' of git://gitorious.org/usb/usb into omap-for-linus Thanks, it seems that there was a stray header change left in my original tree. The updated version is here: http://marc.info/?l=linux-omapm=129853532211359w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: State of LDP3430 platform
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, February 24, 2011 4:20 AM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Paul Walmsley; Shilimkar, Santosh; Woodruff, Richard Subject: Re: State of LDP3430 platform * Russell King - ARM Linux li...@arm.linux.org.uk [110212 08:09]: On Sat, Feb 12, 2011 at 04:02:16PM +, Russell King - ARM Linux wrote: Another LDP3430 report... The LDP3430 seems to be getting there, but: 1. LCD screen seems wrong. The X display looks rather large, and flickery - looks like the LCD timing parameters are wrong. Some text disappears off the RHS. fbset reports: mode 240x320-510 # D: 48.001 MHz, H: 168.424 kHz, V: 510.375 Hz geometry 240 320 240 320 16 timings 20833 3 39 2 7 3 1 accel false rgba 5/11,6/5,5/0,0/0 kernel config: CONFIG_FB_OMAP=y CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2 with the supplied kernel: mode 640x480-64 # D: 21.601 MHz, H: 31.396 kHz, V: 63.813 Hz geometry 640 480 640 640 16 timings 46295 40 4 8 2 4 2 accel false rgba 5/11,6/5,5/0,0/0 so the LCD timings in the kernel appear to be wrong for the panel on the LDP. What is 'CONFIG_FB_OMAP_LCD_VGA'? There's *no* help I would send a patch for this to Tomi. for this configuration option so god only knows what it's right setting should be. Please give it some help text to explain what it is and what it does. I think it is because x_res and y_res of panel are set to QVGA (320 X 240) and the content sent is VGA (640 X 480) With CONFIG_FB_OMAP_LCD_VGA=y the resolution taken is VGA (640 X 480) You can check drivers/video/omap/lcd_ldp.c http://lxr.linux.no/#linux+v2.6.37/drivers/video/omap/lcd_ldp.c#L185 LCD works better with FB_OMAP_LCD_VGA set, but why is this necessary? This would set the resolution to VGA (640 X 480) 3430 SDP has a switch to toggle between VGA (640 X 480) and QQVGA (320 X 240). So this switch must also be toggled along with the when we are booting a kernel with CONFIG_FB_OMAP_LCD_VGA=y In LDP it is controlled by a GPIO: #define LCD_PANEL_QVGA_GPIO 56 Depending on value of this the resolution is selected. If LCD_PANEL_QVGA_GPIO is 1 then resolution is 320 X 240 Also, could you please share other CONFIG options which you are enabling over omap2plus_defconfig? (Otherwise please share .config) -Thanks, Mayuresh 2. Keyboard - numeric keys produce wrong ascii for their labelled function. This is from /dev/tty1 with X running: 1 gives nothing 2 gives 4 3 gives 7 4 gives 2 5 gives 5 6 gives 8 7 gives 3 8 gives nothing 9 gives 9 * gives nothing 0 gives E # gives nothing off-hook (green phone) gives 0 on-hook (red phone) gives 1b5b31397e Killing X and then running evtest on /dev/input/event1 doesn't return any events, neither does reading /dev/tty1 for the twl4030 keypad - the numeric keys are completely dead. /proc/interrupts shows no new interrupt counts when pressing the key for 'twl4030_keypad'. Unbinding/rebinding the twl4030 driver doesn't sort it out, neither does restarting X. 3. Touchscreen is dead, presumably because no devices are bound to ads7846 SPI driver. ls -al /sys/bus/spi/devices/ total 0 drwxr-xr-x 2 root root 0 Jan 1 01:02 . drwxr-xr-x 4 root root 0 Jan 1 01:02 .. lrwxrwxrwx 1 root root 0 Jan 1 01:02 spi1.0 - ../../../devices/platform/omap2_mcspi.1/spi1.0 is the only SPI device which appears, but is unbound. I'm sure this used to work at some point. Anybody from TI looking into these? 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 -- 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 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmodright before timer init
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Thursday, February 24, 2011 1:45 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Tony
Lindgren; Hilman, Kevin; Cousson, Benoit
Subject: RE: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent
hwmodright before timer init
Hello Santosh,
On Thu, 24 Feb 2011, Paul Walmsley wrote:
I propose the following change instead - please let me know what you
think.
Oops - the patch I sent you was not completely refreshed in the local
tree. Here is the correct one.
I have tested on OMAP3 and works fine.
On OMAP2, I guess there is different issue for which it does not work.
--
Tarun
From: Paul Walmsley p...@pwsan.com
Date: Wed, 23 Feb 2011 00:14:08 -0700
Subject: [PATCH] OMAP2+: clockevent: late-init GPTIMER clockevent hwmod
right before timer init
Late-initialize the GPTIMER hwmod used for the clockevent source
immediately
before it is used. This avoids the need to late-initialize all of the
hwmods
until the boot process is further along. (In general, we want to defer
as much as possible until late in the boot process.)
This second version fixes a bug pointed out by Santosh Shilimkar
santosh.shilim...@ti.com, that would cause the kernel to use an
incorrect timer hwmod name if the selected GPTIMER was not 1 or 12 -
thanks Santosh. Also, Tarun Kanti DebBarma tarun.ka...@ti.com
pointed out that the original patch did not apply cleanly; this has
now been fixed.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/timer-gp.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-
gp.c
index 7b7c268..b289d53 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -39,10 +39,11 @@
#include asm/mach/time.h
#include plat/dmtimer.h
#include asm/localtimer.h
+#include plat/common.h
+#include plat/omap_hwmod.h
#include timer-gp.h
-#include plat/common.h
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -132,9 +133,13 @@ static void __init omap2_gp_clockevent_init(void)
{
u32 tick_rate;
int src;
+ char clockevent_hwmod_name[8]; /* 8 = sizeof(timerXX0) */
inited = 1;
+ sprintf(clockevent_hwmod_name, timer%d, gptimer_id);
+ omap_hwmod_late_init_one(clockevent_hwmod_name);
+
gptimer = omap_dm_timer_request_specific(gptimer_id);
BUG_ON(gptimer == NULL);
gptimer_wakeup = gptimer;
--
1.7.2.3
--
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 06/19] omap3+: voltage: use volt_data pointer instead values
Hi,
On Thu, Feb 24, 2011 at 10:58 AM, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote:
Voltage values can get confusing in meaning with various Smartreflex
classes being active. Depending on the class used, the actual voltage
selected might be a variant. Hence pass the volt_data pointers through
the structure. Each voltage domain contains a set of volt_data structs.
Each of those volt_data struct represents a voltage point that is supported
for that domain. Hence, this is a more accurate representation of the
voltage point we are interested in going to, and the actual translation
of this voltage point to the voltage value is done inside the voltage layer
which allows the users of the voltage layer to be blissfully ignorant
of any complexity of the underneath layers.
Volt_data has efuse, Errgain and errminlimit other than nom_volt
How does this data differs in different SR Class implementation which
is why using volt_data is required?
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm.c | 3 +-
arch/arm/mach-omap2/smartreflex-class3.c | 3 +-
arch/arm/mach-omap2/voltage.c | 72
+++--
arch/arm/plat-omap/include/plat/voltage.h | 13 -
4 files changed, 53 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d5a102c..669998b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -209,7 +209,8 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
goto exit;
}
- omap_voltage_scale_vdd(voltdm, bootup_volt);
+ omap_voltage_scale_vdd(voltdm,
+ omap_voltage_get_voltdata(voltdm, bootup_volt));
return 0;
exit:
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 60e7055..2195668 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -15,7 +15,8 @@
static int sr_class3_enable(struct voltagedomain *voltdm)
{
- unsigned long volt = omap_voltage_get_nom_volt(voltdm);
+ unsigned long volt = omap_get_operation_voltage(
+ omap_voltage_get_nom_volt(voltdm));
if (!volt) {
pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3ee8a80..08f0abf 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -146,14 +146,14 @@ struct omap_vdd_info {
struct vc_reg_info vc_reg;
struct voltagedomain voltdm;
struct dentry *debug_dir;
- u32 curr_volt;
+ struct omap_volt_data *curr_volt;
u16 ocp_mod;
u8 prm_irqst_reg;
bool vp_enabled;
u32 (*read_reg) (u16 mod, u8 offset);
void (*write_reg) (u32 val, u16 mod, u8 offset);
int (*volt_scale) (struct omap_vdd_info *vdd,
- unsigned long target_volt);
+ struct omap_volt_data *target_volt);
};
static struct omap_vdd_info *vdd_info;
@@ -361,13 +361,15 @@ static int vp_volt_debug_get(void *data, u64 *val)
static int nom_volt_debug_get(void *data, u64 *val)
{
struct omap_vdd_info *vdd = (struct omap_vdd_info *) data;
+ struct omap_volt_data *volt_data;
if (!vdd) {
pr_warning(Wrong paramater passed\n);
return -EINVAL;
}
+ volt_data = omap_voltage_get_nom_volt(vdd-voltdm);
- *val = omap_voltage_get_nom_volt(vdd-voltdm);
+ *val = volt_data-volt_nominal;
return 0;
}
@@ -382,7 +384,8 @@ static void vp_latch_vsel(struct omap_vdd_info *vdd)
unsigned long uvdc;
char vsel;
- uvdc = omap_voltage_get_nom_volt(vdd-voltdm);
+ uvdc = omap_get_operation_voltage(
+ omap_voltage_get_nom_volt(vdd-voltdm));
if (!uvdc) {
pr_warning(%s: unable to find current voltage for vdd_%s\n,
__func__, vdd-voltdm.name);
@@ -505,12 +508,18 @@ static void __init vdd_debugfs_init(struct
omap_vdd_info *vdd)
/* Voltage scale and accessory APIs */
static int _pre_volt_scale(struct omap_vdd_info *vdd,
- unsigned long target_volt, u8 *target_vsel, u8 *current_vsel)
+ struct omap_volt_data *target_volt, u8 *target_vsel,
+ u8 *current_vsel)
{
- struct omap_volt_data *volt_data;
u32 vc_cmdval, vp_errgain_val;
u16 vp_mod, vc_mod;
+ if (IS_ERR_OR_NULL(target_volt) || IS_ERR_OR_NULL(vdd) ||
+ !target_vsel || !current_vsel) {
+ pr_err(%s: invalid parms!\n, __func__);
+ return -EINVAL;
+ }
+
/* Check if suffiecient pmic info is available for this vdd */
Re: [PATCH v6] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
On Thu, 2011-02-24 at 00:26 -0600, Nilofer, Samreen wrote: Enabling all the display interface options to be built as module And enabling all the display panels to be built as modules. Signed-off-by: Samreen samr...@ti.com This looks good to me. Tony, want to ack this? This enables all DSS features as modules. This should go through dss tree, as this doesn't work without a fix that is there. Tomi arch/arm/configs/omap2plus_defconfig | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index ae890ca..407ccf8 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -192,6 +192,17 @@ CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_OMAP_LCD_VGA=y +CONFIG_OMAP2_DSS=m +CONFIG_OMAP2_DSS_RFBI=y +CONFIG_OMAP2_DSS_SDI=y +CONFIG_OMAP2_DSS_DSI=y +CONFIG_FB_OMAP2=m +CONFIG_PANEL_GENERIC_DPI=m +CONFIG_PANEL_SHARP_LS037V7DW01=m +CONFIG_PANEL_NEC_NL8048HL11_01B=m +CONFIG_PANEL_TAAL=m +CONFIG_PANEL_TPO_TD043MTEA1=m +CONFIG_PANEL_ACX565AKM=m CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
Hi, On Wed, Feb 23, 2011 at 10:09:05PM +0200, Sakari Ailus wrote: In OMAP4 the cortex M3 is a double core processor and as each core is running they own version of the RTOS we threat them independently. So our driver which controls the remote processor sees two processor but both use the same iommu hw. When a iommu fault happens, at this moment, it is consider as a faltal error and it is no managed to recover and continue, instead a restart of the processor is needed, if the fault happens in core0 we need to reset core1 too and vice versa. if the iommu would support several user callbacks, we can register the callback which resets core0 and also the callback which resets core1 and treat them as totally independent processors. Also we have an error event notifier driver, which is only in charge of notifying error events to userspace, so we would have multiple callbacks we could do this The original purpose of the patch, as far as I understand, is to allow getting useful information for debugging purposes should an iommu fault happen. Also, I'm not sure it's necessarily a good idea to just go and reset the M3 cores in case an iommu fault happens --- this is very probably a grave bug in the software running on those M3s. It should be fixed instead of just hiding it. There will be consequences to host side as I have to agree here. Besides the fact that multiple callbacks is outside the scope of this patch. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of LDP3430 platform
On Thu, Feb 24, 2011 at 01:51:50PM +0530, Janorkar, Mayuresh wrote: Also, could you please share other CONFIG options which you are enabling over omap2plus_defconfig? (Otherwise please share .config) Attached. # # Automatically generated make config: don't edit # Linux/arm 2.6.38-rc4 Kernel Configuration # Sat Feb 12 16:43:38 2011 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_SCHED_CLOCK=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_HAVE_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_LZO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y # CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set CONFIG_HAVE_SPARSE_IRQ=y # CONFIG_GENERIC_PENDING_IRQ is not set # CONFIG_AUTO_IRQ_AFFINITY is not set # CONFIG_IRQ_PER_CPU is not set # CONFIG_SPARSE_IRQ is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set # CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y # # GCOV-based kernel profiling # CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_BLOCK=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set CONFIG_INLINE_SPIN_UNLOCK=y # CONFIG_INLINE_SPIN_UNLOCK_BH is not set CONFIG_INLINE_SPIN_UNLOCK_IRQ=y # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set CONFIG_INLINE_READ_UNLOCK=y # CONFIG_INLINE_READ_UNLOCK_BH is not set CONFIG_INLINE_READ_UNLOCK_IRQ=y # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set CONFIG_INLINE_WRITE_UNLOCK=y #
Re: [PATCH] omap: Move omap_hwmod_late_init() to mdesc-timer-init() code
Salut Benoît, On Wed, 23 Feb 2011, Cousson, Benoit wrote: This is indeed a little bit cleaner to init only the timer hwmod in the timer code, but I'm still wondering it it worth the extra complexity. As soon as we have one hwmod to initialize, why cannot we initialize the whole list like before? Tony has mentioned that he wishes to move any code unnecessary for early initialization to late in the boot process. This patch series was an attempt to do that with the current usage of the hwmod code. If tomorrow we want to handle PRCM and control module using hwmod, like I'd like to do, we will have to init these hwmods early as well. Even earlier that init_early for the control module at least. Yes, that makes sense to me. I'd suggest that the best time to deal with that is when the patches to handle PRCM and the SCM via hwmod are done. Then we would have a clear example of the need to move that code earlier. And then we will have a bunch of different init paths from different parts of the boot sequence that might become tricky to handle. If we're just initializing individual hwmods right before we use them in the early boot process, I hope this won't become too big of a problem. But perhaps you are foreseeing a problem which I am not? - Paul
RE: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmodright before timer init
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, February 24, 2011 1:45 PM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; Tony Lindgren; Kevin Hilman; Benoit
Cousson
Subject: RE: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER
clockevent hwmodright before timer init
Hello Santosh,
On Thu, 24 Feb 2011, Paul Walmsley wrote:
I propose the following change instead - please let me know what
you
think.
Oops - the patch I sent you was not completely refreshed in the
local
tree. Here is the correct one.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Wed, 23 Feb 2011 00:14:08 -0700
Subject: [PATCH] OMAP2+: clockevent: late-init GPTIMER clockevent
hwmod right before timer init
Late-initialize the GPTIMER hwmod used for the clockevent source
immediately
before it is used. This avoids the need to late-initialize all of
the hwmods
until the boot process is further along. (In general, we want to
defer
as much as possible until late in the boot process.)
This second version fixes a bug pointed out by Santosh Shilimkar
santosh.shilim...@ti.com, that would cause the kernel to use an
incorrect timer hwmod name if the selected GPTIMER was not 1 or 12 -
thanks Santosh. Also, Tarun Kanti DebBarma tarun.ka...@ti.com
pointed out that the original patch did not apply cleanly; this has
now been fixed.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoīt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
---
Looks good and thanks for fixing this one.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
arch/arm/mach-omap2/timer-gp.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-
omap2/timer-gp.c
index 7b7c268..b289d53 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -39,10 +39,11 @@
#include asm/mach/time.h
#include plat/dmtimer.h
#include asm/localtimer.h
+#include plat/common.h
+#include plat/omap_hwmod.h
#include timer-gp.h
-#include plat/common.h
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -132,9 +133,13 @@ static void __init
omap2_gp_clockevent_init(void)
{
u32 tick_rate;
int src;
+ char clockevent_hwmod_name[8]; /* 8 = sizeof(timerXX0) */
inited = 1;
+ sprintf(clockevent_hwmod_name, timer%d, gptimer_id);
+ omap_hwmod_late_init_one(clockevent_hwmod_name);
+
gptimer = omap_dm_timer_request_specific(gptimer_id);
BUG_ON(gptimer == NULL);
gptimer_wakeup = gptimer;
--
1.7.2.3
--
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: [024/115] USB: prevent buggy hubs from crashing the USB stack
Hi, On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? -- balbi From 65315c60a17f83e69d01888babe4445097c8ead0 Mon Sep 17 00:00:00 2001 From: Felipe Balbi ba...@ti.com Date: Thu, 24 Feb 2011 10:36:53 +0200 Subject: [PATCH] usb: musb: core: set has_tt flag Organization: Texas Instruments\n MUSB is a non-standard host implementation which can handle all speeds with the same core. We need to set has_tt flag after commit d199c96d41d80a567493e12b8e96ea056a1350c1 (USB: prevent buggy hubs from crashing the USB stack) in order for MUSB HCD to continue working. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/musb/musb_core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 54a8bd1..c292d5c 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1864,6 +1864,7 @@ allocate_instance(struct device *dev, INIT_LIST_HEAD(musb-out_bulk); hcd-uses_new_polling = 1; + hcd-has_tt = 1; musb-vbuserr_retry = VBUSERR_RETRY_COUNT; musb-a_wait_bcon = OTG_TIME_A_WAIT_BCON; -- 1.7.4.rc2
RE: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmodright before timer init
On Thu, 24 Feb 2011, DebBarma, Tarun Kanti wrote: I have tested on OMAP3 and works fine. On OMAP2, I guess there is different issue for which it does not work. Works fine for me on N800. Boot log below. - Paul Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.38-rc5-00065-g8a2f1db (paul@twilight) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #180 Thu Feb 24 01:56:43 MST1 [0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387f [0.00] CPU: VIPT aliasing data cache, unknown instruction cache [0.00] Machine: Nokia N800 [0.00] Ignoring unrecognised tag 0x414f4d50 [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP2420 [0.00] [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0xa [0.00] On node 0 totalpages: 32768 [0.00] free_area_init_node: node 0, pgdat c03c9850, node_mem_map c08ee000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32512 pages, LIFO batch:7 [0.00] Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz [0.00] GPMC revision 2.0 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=/dev/mmcblk0p1 rootwait console=ttyO2,115200 earlyprintk debug init=/bin/bash [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 128MB = 128MB total [0.00] Memory: 120756k/120756k available, 10316k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xc880 - 0xf800 ( 760 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc002c000 ( 144 kB) [0.00] .text : 0xc002c000 - 0xc0390bfc (3475 kB) [0.00] .data : 0xc0392000 - 0xc03c9f20 ( 224 kB) [0.00] [ cut here ] [0.00] WARNING: at arch/arm/kernel/hw_breakpoint.c:142 get_debug_arch+0x3c/0x68() [0.00] CPUID feature registers not supported. Assuming v6 debug is present. [0.00] Modules linked in: [0.00] [c003cbd8] (unwind_backtrace+0x0/0xec) from [c005bce4] (warn_slowpath_common+0x4c/0x64) [0.00] [c005bce4] (warn_slowpath_common+0x4c/0x64) from [c005bd7c] (warn_slowpath_fmt+0x2c/0x3c) [0.00] [c005bd7c] (warn_slowpath_fmt+0x2c/0x3c) from [c003d4c4] (get_debug_arch+0x3c/0x68) [0.00] [c003d4c4] (get_debug_arch+0x3c/0x68) from [c003d4f8] (debug_arch_supported+0x8/0x20) [0.00] [c003d4f8] (debug_arch_supported+0x8/0x20) from [c003d5b4] (hw_breakpoint_slots+0xc/0x50) [0.00] [c003d5b4] (hw_breakpoint_slots+0xc/0x50) from [c0013f50] (init_hw_breakpoint+0xc/0x98) [0.00] [c0013f50] (init_hw_breakpoint+0xc/0x98) from [c0013ee8] (perf_event_init+0xa8/0x104) [0.00] [c0013ee8] (perf_event_init+0xa8/0x104) from [c0008ad0] (start_kernel+0x150/0x2d4) [0.00] [c0008ad0] (start_kernel+0x150/0x2d4) from [80008034] (0x80008034) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- [0.00] NR_IRQS:402 [0.00] IRQ: Found an INTC at 0xfa0fe000 (revision 2.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32000 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.057922] Calibrating delay loop... 319.32 BogoMIPS (lpj=1249280) [0.246368] pid_max: default: 32768 minimum: 301 [0.252197] Security Framework initialized [0.257080] Mount-cache hash table entries: 512 [0.269104] CPU: Testing write buffer coherency: ok [0.276367] hw
Re: [PATCH v3 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
On Thu, Feb 24, 2011 at 11:51 AM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote: On Thu, Feb 24, 2011 at 3:04 AM, Tony Lindgren t...@atomide.com wrote: * ABRAHAM, KISHON VIJAY kis...@ti.com [110223 02:11]: Created on top of linux OMAP master (linux-omap-2.6 :master) Does not look like that's the case. This does not seem to compile because of .name usage in omap_hwmod_addr_space. Also contains omap_device idle calls that we don't have merged either. McBSP hwmod and runtime patches depends on http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134 to be compiled. Will you be merging this patch series? No yet. Please rebase on omap-for-linus at commit 7cab8713b1ed0dab08ad6458f92a40b7ff4be619 and make sure each patch compiles. I couldn't find that commit id on omap-for-linus :-(. Anyways, I did compile test applying my current patch series on top of HEAD (df7ffd317d36d36095c26bb57b3dd405274048e5) + API to modify SYSCONFIG patch series. Ok. I'll rebase on omap-for-linus at commit 7cab8713b1ed0dab08ad6458f92a40b7ff4be619 and send a new version. Regards Kishon 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 7/8] OMAP2+: hwmod: add ability to late-init individual hwmods
On Wed, 23 Feb 2011, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [110222 23:11]: --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c +int __init omap_hwmod_late_init_one(const char *oh_name) How about the following naming changes to avoid confusion: omap_hwmod_init - omap_hwmod_register omap_hwmod_late_init - omap_hwmod_init omap_hwmod_late_init_one - omap_hwmod_init_one This is because late_init gets actually called very early during the boot. Sounds good to me. Will write a patch to make this change, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Adding help for FB_OMAP_LCD_VGA option
CONFIG_FB_OMAP_LCD_VGA option is present in drivers/video/omap There is no explaination about what this flag does. Lets add information about it. FB_OMAP_LCD_VGA flag sets resolution of display to VGA (640 X 480). The default resolution of 3430 LDP is 320 X 240. Signed-off-by: Mayuresh Janorkar ma...@ti.com --- drivers/video/omap/Kconfig |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig index 083c8fe..ff7049b 100644 --- a/drivers/video/omap/Kconfig +++ b/drivers/video/omap/Kconfig @@ -11,7 +11,11 @@ config FB_OMAP config FB_OMAP_LCD_VGA bool Use LCD in VGA mode depends on MACH_OMAP_3430SDP || MACH_OMAP_LDP - + help + Set LCD resolution as VGA (640 X 480). + Default resolution without this option is QVGA(320 X 240). + Please take a look at drivers/video/omap/lcd_ldp.c file + for lcd driver code. choice depends on FB_OMAP MACH_OVERO prompt Screen resolution -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [024/115] USB: prevent buggy hubs from crashing the USB stack
Hello, Am 24.02.2011 09:57, schrieb Felipe Balbi: Hi, On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? I can do, I'm using exactly the same patch since yesterday. ;) Tested-by: Alexander Holler hol...@ahsoftware.de Regards, Alexander -- 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: [024/115] USB: prevent buggy hubs from crashing the USB stack
Hi, On Thu, Feb 24, 2011 at 10:15:23AM +0100, Alexander Holler wrote: On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? I can do, I'm using exactly the same patch since yesterday. ;) Tested-by: Alexander Holler hol...@ahsoftware.de Thanks a lot Alex, Greg, can you still take this to -rc ? Do you need a pull request or you can take this one patch ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] OMAP2+: hwmod: find MPU initiator hwmod during in _register()
Hello Benoît, On Wed, 23 Feb 2011, Cousson, Benoit wrote: On 2/23/2011 8:11 AM, Paul Walmsley wrote: + /* +* XXX Rather than doing a strcmp(), this should test a flag +* set in the hwmod data, inserted by the autogenerator code. What do you mean exactly? Something like a is_mpu field set to true for the mpu? Since we are enforcing a consistent naming for every hwmods, that looks like a duplication of the name. We will always named this hwmod mpu, so the strcmp() should be enough. But, maybe I'm missing your point. I had in mind adding a new flag bit for struct omap_hwmod.flags for this purpose, mostly for these reasons: 1. Russell indicated a preference to avoid strcmp() for this type of situation during the clock code merge a few years ago 2. Testing a single bit is much more efficient than calling strcmp(), which will hopefully make life a little easier when running on an FPGA emulator A separate field would of course work as well, but seems more heavyweight if there's only one special case. +*/ + if (!strcmp(oh-name, MPU_INITIATOR_NAME)) + mpu_oh = oh; - return ret; + return 0; } - Paul
Re: [PATCH v2 0/2] OMAP: omap_device: API to modify SYSCONFIG register
Hi Kevin, Paul, Benoit, Do you have any comments for this patch series? This series is necessary for McBSP hwmod and PM runtime patch series to be merged. Regards Kishon On Tue, Feb 15, 2011 at 12:08 PM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote: Kevin, Paul, Benoit, Do you have any comments for this patch series? -Kishon On Mon, Jan 31, 2011 at 6:04 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Certain peripherals require autoidle bits to be disabled before performing some operations. This patch series provides APIs in omap_device layer to modify the SYSCONFIG register. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these APIs will support the same. For e.g McBSP 2 and 3 in OMAP3 has sidetone feature which requires autoidle to be disabled before starting the sidetone. McBSP also requires the SYSCONFIG to be in NOIDLE when ELEMENTSYNCH mode is selected for DMA operation. Created on top of linux OMAP master (linux-omap-2.6 :master) Tested on OMAP4430, OMAP3430 and OMAP2430 SDP boards. Verified that this patch series does not break the OMAP1 build. V2: Mutex is replaced with spinlock. V1: * Creates 3 separate API's to change the idle mode to NOIDLE, SMARTIDLE and FORCEIDLE and one more API to change the idlemode to default value based on the hwmod flag. This change is done to align with the discussion on [3] * Added hwmod mutex in omap hwmod APIs that modifies SYSCONFIG register. * omap_hwmod_set_slave_idlemode() is not modified to take true/false kind-of argument since 3 states are associated with SIDLE bits (force, no and smart). These changes were made to align with Benoit's and Paul's comments for a similar patch written by Manjunath [1] for changing MSTANDBY bits. The discussions that happened for the RFC patch can be found at [2] [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39647.html [2]: https://patchwork.kernel.org/patch/134371/ [3]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39615.html Kishon Vijay Abraham I (2): OMAP: hwmod: API to handle autoidle mode OMAP: omap_device: API to modify AUTOIDLE and SMARTIDLE bits arch/arm/mach-omap2/omap_hwmod.c | 36 + arch/arm/plat-omap/include/plat/omap_device.h | 6 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 + arch/arm/plat-omap/omap_device.c | 176 + 4 files changed, 219 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display
Hi, On Mon, 2011-01-24 at 11:51 +0530, ext Sumit Semwal wrote: From: Senthilvadivu Guruswamy svad...@ti.com Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name. I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files. How does this sound: Let's leave the omapdss device name as it is. It represents a super device, containing the dss sysfs files and upper level dss management. Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, dsi block in some other HW component. Tomi -- 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 v4 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs. Created on top of linux OMAP (linux-omap-2.6 :omap-for-linus commit-id: 7cab8713b1ed0dab08ad6458f92a40b7ff4be619) + OMAP: omap_device: API to modify SYSCONFIG register patch series Did digital loopback testing on OMAP4430, OMAP3430, OMAP2430 and OMAP 1710 SDP boards. Tested audio on 3430 SDP board (by me) and N810 (by Jarkko Nikula). Tested PM with audio and verified the patch series does not cause regression. PM testing comprises of suspend/resume between consecutive audio playback. Support for suspend/resume in the middle of audio playback will be done by audio guys on top of this patch series. Patch series requires the following patch to be present http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134 V4: Rebased on omap-for-linus at commit 7cab8713b1ed0dab08ad6458f92a40b7ff4be619 V3: * Fixed a few minor comments related to patch subject and patch description. * Driver is adapted to handle the unique irq line (since this is the standard from OMAP4). * Removed duplication of memory address space entries in platform device model and hwmod database for OMAP1/2 and 3. * Put sysconfig in force idle when the mcbsp is freed (HW bug workaround for the device to hit retention). V2: * Added omap_hwmod_lookup() in the callback to omap_hwmod_for_each_by_class() to obtain hwmod data for sidetone. Previously this nesting of hwmod APIs was prevented by the use of mutex. * Added a revision member in hwmod database inorder to facilitate the driver to differentiate between different OMAP. * Created APIs to pass DMA params from McBSP driver to client drivers * Cleaned up sound soc by removing the use of macros to obtain base address and DMA channel number and instead use APIs exposed by the driver. * Removed macros defined in mcbsp driver for data that is obtained from hwmod database V1: * McBSP is designed to use multiple hwmods for a single device when the McBSP device has sidetone feature. * To avoid funcionality break of OMAP1 McBSP in between the series and to keep the patches readable, implementation was done in two steps: - First modify mcbsp driver to use platform_get* APIs - then convert it to use hwmod framework for OMAP2+. * API's like omap_device_noidle() and omap_device_default_idle() is used to change the SYCONFIG register bits. This change is done to align with the discussion on [2] * Use '.rev' of omap_hwmod class to identify OMAP3 specific settings * Use *ST_* macros for idlest_idle bit * Incorporate other general review comments provided for hwmod adpatation of other OMAP driver's (eg., do pdata free after a omap_device_build()) * Retain fclk even after pm_runtime adaptation to facilitate switching of functional clock from one source to another * Add member 'name' to omap_hwmod_addr_space struct so that the driver need not rely on the order to get the proper resource [3]. Discussions related to the first RFC patch can be found at [1] [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36743.html [2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39615.html [3]: https://patchwork.kernel.org/patch/233211/ Charulatha V (3): OMAP2420: hwmod data: Add McBSP OMAP2430: hwmod data: Add McBSP OMAP3: hwmod data: Add McBSP Kishon Vijay Abraham I (10): OMAP: hwmod: allow hwmod to provide address space accessible from SDMA OMAP: McBSP: Convert McBSP to platform device model OMAP4: hwmod: Naming of address space OMAP3: hwmod: add dev_attr for McBSP sidetone OMAP2+: McBSP: hwmod adaptation for McBSP OMAP: McBSP: use omap_device APIs to modify SYSCONFIG OMAP: McBSP: Add pm runtime support OMAP: McBSP: APIs to pass DMA params from McBSP driver to client drivers ASoC: McBSP: get hw params from McBSP driver OMAP: hwmod: Removal of macros for data that is obtained from hwmod database arch/arm/mach-omap1/mcbsp.c | 327 +++ arch/arm/mach-omap2/mcbsp.c | 231 +++-- arch/arm/mach-omap2/omap_hwmod.c |1 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 129 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 322 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 449 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8 + arch/arm/mach-omap2/prcm-common.h|4 + arch/arm/plat-omap/devices.c | 10 +- arch/arm/plat-omap/include/plat/mcbsp.h | 50 ++-- arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +- arch/arm/plat-omap/mcbsp.c | 210 +--- sound/soc/omap/omap-mcbsp.c | 126 +--- 13 files changed, 1419 insertions(+), 452 deletions(-) -- To unsubscribe from this list: send the line
[PATCH v4 01/13] OMAP: hwmod: allow hwmod to provide address space accessible from SDMA
Adds support for resource API to get address space info other than just MPU.
The drivers can now use platform_get_resource_byname() to get resource of
type 'IORESOURCE_MEM' by name.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d6b8d2e..d72ae5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1919,6 +1919,7 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
os = oh-slaves[i];
for (j = 0; j os-addr_cnt; j++) {
+ (res + r)-name = (os-addr + j)-name;
(res + r)-start = (os-addr + j)-pa_start;
(res + r)-end = (os-addr + j)-pa_end;
(res + r)-flags = IORESOURCE_MEM;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index e50a19a..2b54852 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -178,7 +178,8 @@ struct omap_hwmod_omap2_firewall {
#define ADDR_TYPE_RT (1 1)
/**
- * struct omap_hwmod_addr_space - MPU address space handled by the hwmod
+ * struct omap_hwmod_addr_space - address space handled by the hwmod
+ * @name: name of the address space
* @pa_start: starting physical address
* @pa_end: ending physical address
* @flags: (see omap_hwmod_addr_space.flags macros above)
@@ -187,6 +188,7 @@ struct omap_hwmod_omap2_firewall {
* structure. GPMC is one example.
*/
struct omap_hwmod_addr_space {
+ const char *name;
u32 pa_start;
u32 pa_end;
u8 flags;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/13] OMAP3: hwmod data: Add McBSP
From: Charulatha V ch...@ti.com
Add McBSP hwmod data for OMAP3.
Added a revision member inorder to facilitate the driver to
differentiate between mcbsp in different omap.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 439
arch/arm/plat-omap/include/plat/mcbsp.h|1 +
2 files changed, 440 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index e9d0012..b9dd727 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -23,6 +23,7 @@
#include plat/i2c.h
#include plat/gpio.h
#include plat/smartreflex.h
+#include plat/mcbsp.h
#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -72,6 +73,14 @@ static struct omap_hwmod am35xx_usbhsotg_hwmod;
static struct omap_hwmod omap3xxx_dma_system_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp1_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp2_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp3_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
.master = omap3xxx_l3_main_hwmod,
@@ -1729,6 +1738,427 @@ static struct omap_hwmod omap3xxx_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_mcbsp_sysc = {
+ .sysc_offs = 0x008c,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+ .clockact = 0x2,
+};
+
+static struct omap_hwmod_class omap3xxx_mcbsp_hwmod_class = {
+ .name = mcbsp,
+ .sysc = omap3xxx_mcbsp_sysc,
+ .rev = MCBSP_CONFIG_TYPE3,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap3xxx_mcbsp1_irqs[] = {
+ { .name = irq, .irq = 16 },
+ { .name = tx, .irq = 59 },
+ { .name = rx, .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_mcbsp1_sdma_chs[] = {
+ { .name = rx, .dma_req = 32 },
+ { .name = tx, .dma_req = 31 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mcbsp1_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp1 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mcbsp1 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap3xxx_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_mcbsp1_slaves[] = {
+ omap3xxx_l4_core__mcbsp1,
+};
+
+static struct omap_hwmod omap3xxx_mcbsp1_hwmod = {
+ .name = mcbsp1,
+ .class = omap3xxx_mcbsp_hwmod_class,
+ .mpu_irqs = omap3xxx_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_irqs),
+ .sdma_reqs = omap3xxx_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_sdma_chs),
+ .main_clk = mcbsp1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_ST_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap3xxx_mcbsp2_irqs[] = {
+ { .name = irq, .irq = 17 },
+ { .name = tx, .irq = 62 },
+ { .name = rx, .irq = 63 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_mcbsp2_sdma_chs[] = {
+ { .name = rx, .dma_req = 34 },
+ { .name = tx, .dma_req = 33 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mcbsp2_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x49022000,
+ .pa_end = 0x490220ff,
+ .flags = ADDR_TYPE_RT
+
[PATCH v4 03/13] OMAP2420: hwmod data: Add McBSP
From: Charulatha V ch...@ti.com
Add McBSP hwmod data for OMAP2420.
Also add macros in prcm-common.h for idlest bit of OMAP24XX McBSP devices
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 129
arch/arm/mach-omap2/prcm-common.h |4 +
2 files changed, 133 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index f323c6b..2503e1a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -109,6 +109,8 @@ static struct omap_hwmod omap2420_uart2_hwmod;
static struct omap_hwmod omap2420_uart3_hwmod;
static struct omap_hwmod omap2420_i2c1_hwmod;
static struct omap_hwmod omap2420_i2c2_hwmod;
+static struct omap_hwmod omap2420_mcbsp1_hwmod;
+static struct omap_hwmod omap2420_mcbsp2_hwmod;
/* l4 core - mcspi1 interface */
static struct omap_hwmod_addr_space omap2420_mcspi1_addr_space[] = {
@@ -1320,6 +1322,129 @@ static struct omap_hwmod omap2420_mcspi2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class omap2420_mcbsp_hwmod_class = {
+ .name = mcbsp,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap2420_mcbsp1_irqs[] = {
+ { .name = tx, .irq = 59 },
+ { .name = rx, .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp1_sdma_chs[] = {
+ { .name = rx, .dma_req = 32 },
+ { .name = tx, .dma_req = 31 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp1_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp1 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap2420_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcbsp1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp1_slaves[] = {
+ omap2420_l4_core__mcbsp1,
+};
+
+static struct omap_hwmod omap2420_mcbsp1_hwmod = {
+ .name = mcbsp1,
+ .class = omap2420_mcbsp_hwmod_class,
+ .mpu_irqs = omap2420_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcbsp1_irqs),
+ .sdma_reqs = omap2420_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_mcbsp1_sdma_chs),
+ .main_clk = mcbsp1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap2420_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap2420_mcbsp2_irqs[] = {
+ { .name = tx, .irq = 62 },
+ { .name = rx, .irq = 63 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp2_sdma_chs[] = {
+ { .name = rx, .dma_req = 34 },
+ { .name = tx, .dma_req = 33 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp2_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48076000,
+ .pa_end = 0x480760ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp2 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcbsp2_hwmod,
+ .clk= mcbsp2_ick,
+ .addr = omap2420_mcbsp2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcbsp2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp2 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp2_slaves[] = {
+ omap2420_l4_core__mcbsp2,
+};
+
+static struct omap_hwmod omap2420_mcbsp2_hwmod = {
+ .name = mcbsp2,
+ .class = omap2420_mcbsp_hwmod_class,
+ .mpu_irqs = omap2420_mcbsp2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcbsp2_irqs),
+ .sdma_reqs = omap2420_mcbsp2_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_mcbsp2_sdma_chs),
+ .main_clk = mcbsp2_fck,
+
[PATCH v4 04/13] OMAP2430: hwmod data: Add McBSP
From: Charulatha V ch...@ti.com
Add McBSP hwmod data for OMAP2430.
Added a revision member inorder to facilitate the driver to
differentiate between mcbsp in different omap.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 322
arch/arm/plat-omap/include/plat/mcbsp.h|2 +
2 files changed, 324 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index de0015d..8d1d252 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,6 +18,7 @@
#include plat/serial.h
#include plat/i2c.h
#include plat/gpio.h
+#include plat/mcbsp.h
#include plat/mcspi.h
#include plat/l3_2xxx.h
@@ -110,6 +111,11 @@ static struct omap_hwmod omap2430_uart2_hwmod;
static struct omap_hwmod omap2430_uart3_hwmod;
static struct omap_hwmod omap2430_i2c1_hwmod;
static struct omap_hwmod omap2430_i2c2_hwmod;
+static struct omap_hwmod omap2430_mcbsp1_hwmod;
+static struct omap_hwmod omap2430_mcbsp2_hwmod;
+static struct omap_hwmod omap2430_mcbsp3_hwmod;
+static struct omap_hwmod omap2430_mcbsp4_hwmod;
+static struct omap_hwmod omap2430_mcbsp5_hwmod;
static struct omap_hwmod omap2430_usbhsotg_hwmod;
@@ -1508,6 +1514,315 @@ static struct omap_hwmod omap2430_usbhsotg_hwmod = {
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_mcbsp_sysc = {
+ .rev_offs = 0x007C,
+ .sysc_offs = 0x008C,
+ .sysc_flags = (SYSC_HAS_SOFTRESET),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_mcbsp_hwmod_class = {
+ .name = mcbsp,
+ .sysc = omap2430_mcbsp_sysc,
+ .rev = MCBSP_CONFIG_TYPE2,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap2430_mcbsp1_irqs[] = {
+ { .name = tx, .irq = 59 },
+ { .name = rx, .irq = 60 },
+ { .name = ovr,.irq = 61 },
+ { .name = common, .irq = 64 },
+};
+
+static struct omap_hwmod_dma_info omap2430_mcbsp1_sdma_chs[] = {
+ { .name = rx, .dma_req = 32 },
+ { .name = tx, .dma_req = 31 },
+};
+
+static struct omap_hwmod_addr_space omap2430_mcbsp1_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp1 */
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcbsp1 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap2430_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcbsp1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap2430_mcbsp1_slaves[] = {
+ omap2430_l4_core__mcbsp1,
+};
+
+static struct omap_hwmod omap2430_mcbsp1_hwmod = {
+ .name = mcbsp1,
+ .class = omap2430_mcbsp_hwmod_class,
+ .mpu_irqs = omap2430_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_mcbsp1_irqs),
+ .sdma_reqs = omap2430_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2430_mcbsp1_sdma_chs),
+ .main_clk = mcbsp1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap2430_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap2430_mcbsp2_irqs[] = {
+ { .name = tx, .irq = 62 },
+ { .name = rx, .irq = 63 },
+ { .name = common, .irq = 16 },
+};
+
+static struct omap_hwmod_dma_info omap2430_mcbsp2_sdma_chs[] = {
+ { .name = rx, .dma_req = 34 },
+ { .name = tx, .dma_req = 33 },
+};
+
+static struct omap_hwmod_addr_space omap2430_mcbsp2_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48076000,
+ .pa_end = 0x480760ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp2 */
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcbsp2 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mcbsp2_hwmod,
+ .clk= mcbsp2_ick,
+
[PATCH v4 07/13] OMAP3: hwmod: add dev_attr for McBSP sidetone
Since the sidetone block is tightly coupled to the mcbsp, sidetone information
is directly added to mcbsp2 3 hwmod dev_attr.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 ++
arch/arm/plat-omap/include/plat/mcbsp.h|9 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b9dd727..4d77c1b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1852,6 +1852,10 @@ static struct omap_hwmod_ocp_if
*omap3xxx_mcbsp2_slaves[] = {
omap3xxx_l4_per__mcbsp2,
};
+static struct omap_mcbsp_dev_attr omap34xx_mcbsp2_dev_attr = {
+ .sidetone = mcbsp2_sidetone,
+};
+
static struct omap_hwmod omap3xxx_mcbsp2_hwmod = {
.name = mcbsp2,
.class = omap3xxx_mcbsp_hwmod_class,
@@ -1871,6 +1875,7 @@ static struct omap_hwmod omap3xxx_mcbsp2_hwmod = {
},
.slaves = omap3xxx_mcbsp2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_mcbsp2_slaves),
+ .dev_attr = omap34xx_mcbsp2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
@@ -1910,6 +1915,10 @@ static struct omap_hwmod_ocp_if
*omap3xxx_mcbsp3_slaves[] = {
omap3xxx_l4_per__mcbsp3,
};
+static struct omap_mcbsp_dev_attr omap34xx_mcbsp3_dev_attr = {
+ .sidetone = mcbsp3_sidetone,
+};
+
static struct omap_hwmod omap3xxx_mcbsp3_hwmod = {
.name = mcbsp3,
.class = omap3xxx_mcbsp_hwmod_class,
@@ -1929,6 +1938,7 @@ static struct omap_hwmod omap3xxx_mcbsp3_hwmod = {
},
.slaves = omap3xxx_mcbsp3_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_mcbsp3_slaves),
+ .dev_attr = omap34xx_mcbsp3_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index afcbb7b..1fe0637 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -475,6 +475,15 @@ struct omap_mcbsp {
#endif
void *reg_cache;
};
+
+/**
+ * omap_mcbsp_dev_attr - OMAP McBSP device attributes for omap_hwmod
+ * @sidetone: name of the sidetone device
+ */
+struct omap_mcbsp_dev_attr {
+ const char *sidetone;
+};
+
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count, omap_mcbsp_cache_size;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/13] OMAP: McBSP: Convert McBSP to platform device model
Implement McBSP as platform device and add support for
registering through platform device layer using resource
structures.
Later in this patch series, OMAP2+ McBSP driver would be modified to
use hwmod framework after populating the omap2+ hwmod database.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/mach-omap1/mcbsp.c | 327 +
arch/arm/mach-omap2/mcbsp.c | 613 +--
arch/arm/plat-omap/devices.c| 10 +-
arch/arm/plat-omap/include/plat/mcbsp.h | 14 +-
arch/arm/plat-omap/mcbsp.c | 59 +++-
5 files changed, 818 insertions(+), 205 deletions(-)
diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index 8209736..e68f6c0 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -10,6 +10,7 @@
*
* Multichannel mode not supported.
*/
+#include linux/ioport.h
#include linux/module.h
#include linux/init.h
#include linux/clk.h
@@ -78,100 +79,288 @@ static struct omap_mcbsp_ops omap1_mcbsp_ops = {
};
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+struct resource omap7xx_mcbsp_res[][6] = {
+ {
+ {
+ .start = OMAP7XX_MCBSP1_BASE,
+ .end = OMAP7XX_MCBSP1_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = rx,
+ .start = INT_7XX_McBSP1RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = tx,
+ .start = INT_7XX_McBSP1TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = rx,
+ .start = OMAP_DMA_MCBSP1_RX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .name = tx,
+ .start = OMAP_DMA_MCBSP1_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ },
+ {
+ {
+ .start = OMAP7XX_MCBSP2_BASE,
+ .end = OMAP7XX_MCBSP2_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = rx,
+ .start = INT_7XX_McBSP2RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = tx,
+ .start = INT_7XX_McBSP2TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = rx,
+ .start = OMAP_DMA_MCBSP3_RX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .name = tx,
+ .start = OMAP_DMA_MCBSP3_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ },
+};
+
static struct omap_mcbsp_platform_data omap7xx_mcbsp_pdata[] = {
{
- .phys_base = OMAP7XX_MCBSP1_BASE,
- .dma_rx_sync= OMAP_DMA_MCBSP1_RX,
- .dma_tx_sync= OMAP_DMA_MCBSP1_TX,
- .rx_irq = INT_7XX_McBSP1RX,
- .tx_irq = INT_7XX_McBSP1TX,
.ops= omap1_mcbsp_ops,
},
{
- .phys_base = OMAP7XX_MCBSP2_BASE,
- .dma_rx_sync= OMAP_DMA_MCBSP3_RX,
- .dma_tx_sync= OMAP_DMA_MCBSP3_TX,
- .rx_irq = INT_7XX_McBSP2RX,
- .tx_irq = INT_7XX_McBSP2TX,
.ops= omap1_mcbsp_ops,
},
};
-#define OMAP7XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap7xx_mcbsp_pdata)
-#define OMAP7XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+#define OMAP7XX_MCBSP_RES_SZ ARRAY_SIZE(omap7xx_mcbsp_res[1])
+#define OMAP7XX_MCBSP_COUNTARRAY_SIZE(omap7xx_mcbsp_res)
#else
+#define omap7xx_mcbsp_res NULL
#define omap7xx_mcbsp_pdataNULL
-#define OMAP7XX_MCBSP_PDATA_SZ 0
-#define OMAP7XX_MCBSP_REG_NUM 0
+#define OMAP7XX_MCBSP_RES_SZ 0
+#define OMAP7XX_MCBSP_COUNT0
#endif
#ifdef CONFIG_ARCH_OMAP15XX
+struct resource omap15xx_mcbsp_res[][6] = {
+ {
+ {
+ .start = OMAP1510_MCBSP1_BASE,
+ .end = OMAP1510_MCBSP1_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = rx,
+ .start = INT_McBSP1RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+
[PATCH v4 06/13] OMAP4: hwmod: Naming of address space
Added a name to address space belonging to SDMA and MPU facilitating
the driver to get the address space info by name. Added a revision
member inorder to facilitate the driver to differentiate between
mcbsp in different omap.
Also added a platform_get_irq in probe to get irq number by index since
from OMAP4, there will be a single irq line.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
arch/arm/plat-omap/include/plat/mcbsp.h|1 +
arch/arm/plat-omap/mcbsp.c |4
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..673b011 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
#include plat/gpio.h
#include plat/dma.h
#include plat/mcspi.h
+#include plat/mcbsp.h
#include omap_hwmod_common_data.h
@@ -2737,6 +2738,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_mcbsp_sysc = {
static struct omap_hwmod_class omap44xx_mcbsp_hwmod_class = {
.name = mcbsp,
.sysc = omap44xx_mcbsp_sysc,
+ .rev= MCBSP_CONFIG_TYPE4,
};
/* mcbsp1 */
@@ -2752,6 +2754,7 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp1_sdma_reqs[] = {
static struct omap_hwmod_addr_space omap44xx_mcbsp1_addrs[] = {
{
+ .name = mpu,
.pa_start = 0x40122000,
.pa_end = 0x401220ff,
.flags = ADDR_TYPE_RT
@@ -2770,6 +2773,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1 =
{
static struct omap_hwmod_addr_space omap44xx_mcbsp1_dma_addrs[] = {
{
+ .name = dma,
.pa_start = 0x49022000,
.pa_end = 0x490220ff,
.flags = ADDR_TYPE_RT
@@ -2823,6 +2827,7 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp2_sdma_reqs[] = {
static struct omap_hwmod_addr_space omap44xx_mcbsp2_addrs[] = {
{
+ .name = mpu,
.pa_start = 0x40124000,
.pa_end = 0x401240ff,
.flags = ADDR_TYPE_RT
@@ -2841,6 +2846,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp2 =
{
static struct omap_hwmod_addr_space omap44xx_mcbsp2_dma_addrs[] = {
{
+ .name = dma,
.pa_start = 0x49024000,
.pa_end = 0x490240ff,
.flags = ADDR_TYPE_RT
@@ -2894,6 +2900,7 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp3_sdma_reqs[] = {
static struct omap_hwmod_addr_space omap44xx_mcbsp3_addrs[] = {
{
+ .name = mpu,
.pa_start = 0x40126000,
.pa_end = 0x401260ff,
.flags = ADDR_TYPE_RT
@@ -2912,6 +2919,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp3 =
{
static struct omap_hwmod_addr_space omap44xx_mcbsp3_dma_addrs[] = {
{
+ .name = dma,
.pa_start = 0x49026000,
.pa_end = 0x490260ff,
.flags = ADDR_TYPE_RT
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index f084b6a..afcbb7b 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -39,6 +39,7 @@ static struct platform_device omap_mcbsp##port_nr = { \
#define MCBSP_CONFIG_TYPE2 0x2
#define MCBSP_CONFIG_TYPE3 0x3
+#define MCBSP_CONFIG_TYPE4 0x4
#define OMAP7XX_MCBSP1_BASE0xfffb1000
#define OMAP7XX_MCBSP2_BASE0xfffb1800
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 5f25ae5..62bd073 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1812,6 +1812,10 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
mcbsp-tx_irq = platform_get_irq_byname(pdev, tx);
mcbsp-rx_irq = platform_get_irq_byname(pdev, rx);
+ /* From OMAP4 there will be a single irq line */
+ if (mcbsp-tx_irq == -ENXIO)
+ mcbsp-tx_irq = platform_get_irq(pdev, 0);
+
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
if (!res) {
dev_err(pdev-dev, %s:mcbsp%d has invalid rx DMA channel\n,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
Modify OMAP2+ McBSP to use omap hwmod framework APIs
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/mach-omap2/mcbsp.c | 595 +++
arch/arm/plat-omap/include/plat/mcbsp.h |2 +-
2 files changed, 46 insertions(+), 551 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 765ebe7..275d6cf 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -22,10 +22,10 @@
#include plat/dma.h
#include plat/cpu.h
#include plat/mcbsp.h
+#include plat/omap_device.h
#include control.h
-
/* McBSP internal signal muxing functions */
void omap2_mcbsp1_mux_clkr_src(u8 mux)
@@ -101,573 +101,68 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
}
EXPORT_SYMBOL(omap2_mcbsp_set_clks_src);
-
-/* Platform data */
-
-#ifdef CONFIG_SOC_OMAP2420
-struct resource omap2420_mcbsp_res[][6] = {
+struct omap_device_pm_latency omap2_mcbsp_latency[] = {
{
- {
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP1_IRQ_RX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = tx,
- .start = INT_24XX_MCBSP1_IRQ_TX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = rx,
- .start = OMAP24XX_DMA_MCBSP1_RX,
- .flags = IORESOURCE_DMA,
- },
- {
- .name = tx,
- .start = OMAP24XX_DMA_MCBSP1_TX,
- .flags = IORESOURCE_DMA,
- },
- },
- {
- {
- .start = OMAP24XX_MCBSP2_BASE,
- .end = OMAP24XX_MCBSP2_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP2_IRQ_RX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = tx,
- .start = INT_24XX_MCBSP2_IRQ_TX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = rx,
- .start = OMAP24XX_DMA_MCBSP2_RX,
- .flags = IORESOURCE_DMA,
- },
- {
- .name = tx,
- .start = OMAP24XX_DMA_MCBSP2_TX,
- .flags = IORESOURCE_DMA,
- },
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
-#define OMAP2420_MCBSP_RES_SZ ARRAY_SIZE(omap2420_mcbsp_res[1])
-#define OMAP2420_MCBSP_COUNT ARRAY_SIZE(omap2420_mcbsp_res)
-#else
-#define omap2420_mcbsp_res NULL
-#define OMAP2420_MCBSP_RES_SZ 0
-#define OMAP2420_MCBSP_COUNT 0
-#endif
-#define omap2420_mcbsp_pdata NULL
+static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
+{
+ int id, count = 1;
+ char *name = omap-mcbsp;
+ struct omap_hwmod *oh_device[2];
+ struct omap_mcbsp_platform_data *pdata = NULL;
+ struct omap_device *od;
-#ifdef CONFIG_SOC_OMAP2430
-struct resource omap2430_mcbsp_res[][6] = {
- {
- {
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP1_IRQ_RX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = tx,
- .start = INT_24XX_MCBSP1_IRQ_TX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = rx,
- .start = OMAP24XX_DMA_MCBSP1_RX,
- .flags = IORESOURCE_DMA,
- },
- {
- .name = tx,
- .start = OMAP24XX_DMA_MCBSP1_TX,
- .flags = IORESOURCE_DMA,
- },
- },
- {
- {
- .start = OMAP24XX_MCBSP2_BASE,
-
[PATCH v4 09/13] OMAP: McBSP: use omap_device APIs to modify SYSCONFIG
McBSP2/3 in OMAP3 has sidetone feature which requires autoidle
to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, omap_device APIs are used to modify SYSCONFIG register.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/plat-omap/mcbsp.c | 66
1 files changed, 36 insertions(+), 30 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 62bd073..30683ce 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -27,6 +27,7 @@
#include plat/dma.h
#include plat/mcbsp.h
+#include plat/omap_device.h
/* XXX These sideways includes are a sign that something is wrong */
#include ../mach-omap2/cm2xxx_3xxx.h
@@ -228,9 +229,19 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
EXPORT_SYMBOL(omap_mcbsp_config);
#ifdef CONFIG_ARCH_OMAP3
+static struct omap_device *find_omap_device_by_dev(struct device *dev)
+{
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ return container_of(pdev, struct omap_device, pdev);
+}
+
static void omap_st_on(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
/*
* Sidetone uses McBSP ICLK - which must not idle when sidetones
@@ -244,8 +255,7 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w | SIDETONEEN);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w ~(ST_AUTOIDLE));
+ omap_device_disable_autoidle(od);
/* Enable Sidetone from Sidetone Core */
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -255,12 +265,14 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
static void omap_st_off(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
w = MCBSP_ST_READ(mcbsp, SSELCR);
MCBSP_ST_WRITE(mcbsp, SSELCR, w ~(ST_SIDETONEEN));
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w | ST_AUTOIDLE);
+ omap_device_enable_autoidle(od);
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w ~(SIDETONEEN));
@@ -273,9 +285,11 @@ static void omap_st_off(struct omap_mcbsp *mcbsp)
static void omap_st_fir_write(struct omap_mcbsp *mcbsp, s16 *fir)
{
u16 val, i;
+ struct omap_device *od;
- val = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, val ~(ST_AUTOIDLE));
+ od = find_omap_device_by_dev(mcbsp-dev);
+
+ omap_device_disable_autoidle(od);
val = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -303,9 +317,11 @@ static void omap_st_chgain(struct omap_mcbsp *mcbsp)
{
u16 w;
struct omap_mcbsp_st_data *st_data = mcbsp-st_data;
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w ~(ST_AUTOIDLE));
+ omap_device_disable_autoidle(od);
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -648,48 +664,38 @@ EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
{
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
/*
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
*/
if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- u16 syscon;
-
- syscon = MCBSP_READ(mcbsp, SYSCON);
- syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
-
- if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
- syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
- CLOCKACTIVITY(0x02));
+ if (mcbsp-dma_op_mode != MCBSP_DMA_MODE_THRESHOLD)
+ omap_device_noidle(od);
+ else
MCBSP_WRITE(mcbsp, WAKEUPEN, XRDYEN | RRDYEN);
- } else {
- syscon |= SIDLEMODE(0x01);
- }
-
- MCBSP_WRITE(mcbsp, SYSCON, syscon);
}
}
static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp)
{
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
+
/*
* Disable wakup behavior, smart idle and all wakeups
*/
[PATCH v4 11/13] OMAP: McBSP: APIs to pass DMA params from McBSP driver to client drivers
After McBSP driver is hwmod adapted, the information about the hw would be
obtained from the hwmod database by the mcbsp driver. Since DMA programming is
handled by the client driver, APIs are provided to pass the DMA channel number
and base address of data register required by the client driver for DMA
programming.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/mach-omap2/mcbsp.c |2 +
arch/arm/plat-omap/include/plat/mcbsp.h |7 +++
arch/arm/plat-omap/mcbsp.c | 64 +++
3 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 4ada6a9..565b906 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -126,6 +126,8 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
return -ENOMEM;
}
+ pdata-mcbsp_config_type = oh-class-rev;
+
if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
/* The FIFO has 1024 + 256 locations */
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 964a940..21c9b10 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -81,6 +81,8 @@ static struct platform_device omap_mcbsp##port_nr = { \
#define OMAP_MCBSP_REG_DRR10x02
#define OMAP_MCBSP_REG_DXR20x04
#define OMAP_MCBSP_REG_DXR10x06
+#define OMAP_MCBSP_REG_DRR 0x02
+#define OMAP_MCBSP_REG_DXR 0x06
#define OMAP_MCBSP_REG_SPCR2 0x08
#define OMAP_MCBSP_REG_SPCR1 0x0a
#define OMAP_MCBSP_REG_RCR20x0c
@@ -423,6 +425,7 @@ struct omap_mcbsp_platform_data {
unsigned long phys_base_st;
#endif
u16 buffer_size;
+ unsigned int mcbsp_config_type;
};
struct omap_mcbsp_st_data {
@@ -473,6 +476,7 @@ struct omap_mcbsp {
u16 max_rx_thres;
#endif
void *reg_cache;
+ unsigned int mcbsp_config_type;
};
/**
@@ -541,6 +545,9 @@ int omap_mcbsp_set_io_type(unsigned int id,
omap_mcbsp_io_type_t io_type);
void omap2_mcbsp1_mux_clkr_src(u8 mux);
void omap2_mcbsp1_mux_fsr_src(u8 mux);
+int omap_mcbsp_dma_ch_params(unsigned int id, unsigned int stream);
+int omap_mcbsp_dma_reg_params(unsigned int id, unsigned int stream);
+
#ifdef CONFIG_ARCH_OMAP3
/* Sidetone specific API */
int omap_st_set_chgain(unsigned int id, int channel, s16 chgain);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index b1b0a06..2fa96a6 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -229,6 +229,69 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
}
EXPORT_SYMBOL(omap_mcbsp_config);
+/**
+ * omap_mcbsp_dma_params - returns the dma channel number
+ * @id - mcbsp id
+ * @stream - indicates the direction of data flow (rx or tx)
+ *
+ * Returns the dma channel number for the rx channel or tx channel
+ * based on the value of @stream for the requested mcbsp given by @id
+ */
+int omap_mcbsp_dma_ch_params(unsigned int id, unsigned int stream)
+{
+ struct omap_mcbsp *mcbsp;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ if (stream)
+ return mcbsp-dma_rx_sync;
+ else
+ return mcbsp-dma_tx_sync;
+}
+EXPORT_SYMBOL(omap_mcbsp_dma_ch_params);
+
+/**
+ * omap_mcbsp_dma_reg_params - returns the address of mcbsp data register
+ * @id - mcbsp id
+ * @stream - indicates the direction of data flow (rx or tx)
+ *
+ * Returns the address of mcbsp data transmit register or data receive register
+ * to be used by DMA for transferring/receiving data based on the value of
+ * @stream for the requested mcbsp given by @id
+ */
+int omap_mcbsp_dma_reg_params(unsigned int id, unsigned int stream)
+{
+ struct omap_mcbsp *mcbsp;
+ int data_reg;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ data_reg = mcbsp-phys_dma_base;
+
+ if (mcbsp-mcbsp_config_type MCBSP_CONFIG_TYPE2) {
+ if (stream)
+ data_reg += OMAP_MCBSP_REG_DRR1;
+ else
+ data_reg += OMAP_MCBSP_REG_DXR1;
+ } else {
+ if (stream)
+ data_reg += OMAP_MCBSP_REG_DRR;
+ else
+ data_reg += OMAP_MCBSP_REG_DXR;
+ }
+
+ return data_reg;
+}
+EXPORT_SYMBOL(omap_mcbsp_dma_reg_params);
+
#ifdef
[PATCH v4 12/13] ASoC: McBSP: get hw params from McBSP driver
Removed the use of macros to obtain base address and DMA channel number.
Instead use the McBSP driver API's that passes base address and DMA
channel number to the client driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
sound/soc/omap/omap-mcbsp.c | 126 ++-
1 files changed, 4 insertions(+), 122 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index ede6afd..2175f09 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -69,110 +69,6 @@ static struct omap_mcbsp_data mcbsp_data[NUM_LINKS];
*/
static struct omap_pcm_dma_data omap_mcbsp_dai_dma_params[NUM_LINKS][2];
-#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-static const int omap1_dma_reqs[][2] = {
- { OMAP_DMA_MCBSP1_TX, OMAP_DMA_MCBSP1_RX },
- { OMAP_DMA_MCBSP2_TX, OMAP_DMA_MCBSP2_RX },
- { OMAP_DMA_MCBSP3_TX, OMAP_DMA_MCBSP3_RX },
-};
-static const unsigned long omap1_mcbsp_port[][2] = {
- { OMAP1510_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP1510_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
- { OMAP1510_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP1510_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
- { OMAP1510_MCBSP3_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP1510_MCBSP3_BASE + OMAP_MCBSP_REG_DRR1 },
-};
-#else
-static const int omap1_dma_reqs[][2] = {};
-static const unsigned long omap1_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
-static const int omap24xx_dma_reqs[][2] = {
- { OMAP24XX_DMA_MCBSP1_TX, OMAP24XX_DMA_MCBSP1_RX },
- { OMAP24XX_DMA_MCBSP2_TX, OMAP24XX_DMA_MCBSP2_RX },
-#if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
- { OMAP24XX_DMA_MCBSP3_TX, OMAP24XX_DMA_MCBSP3_RX },
- { OMAP24XX_DMA_MCBSP4_TX, OMAP24XX_DMA_MCBSP4_RX },
- { OMAP24XX_DMA_MCBSP5_TX, OMAP24XX_DMA_MCBSP5_RX },
-#endif
-};
-#else
-static const int omap24xx_dma_reqs[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP4)
-static const int omap44xx_dma_reqs[][2] = {
- { OMAP44XX_DMA_MCBSP1_TX, OMAP44XX_DMA_MCBSP1_RX },
- { OMAP44XX_DMA_MCBSP2_TX, OMAP44XX_DMA_MCBSP2_RX },
- { OMAP44XX_DMA_MCBSP3_TX, OMAP44XX_DMA_MCBSP3_RX },
- { OMAP44XX_DMA_MCBSP4_TX, OMAP44XX_DMA_MCBSP4_RX },
-};
-#else
-static const int omap44xx_dma_reqs[][2] = {};
-#endif
-
-#if defined(CONFIG_SOC_OMAP2420)
-static const unsigned long omap2420_mcbsp_port[][2] = {
- { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
- { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
-};
-#else
-static const unsigned long omap2420_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_SOC_OMAP2430)
-static const unsigned long omap2430_mcbsp_port[][2] = {
- { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
- OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
- OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
- OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
- OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
- OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
-};
-#else
-static const unsigned long omap2430_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP3)
-static const unsigned long omap34xx_mcbsp_port[][2] = {
- { OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
-};
-#else
-static const unsigned long omap34xx_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP4)
-static const unsigned long omap44xx_mcbsp_port[][2] = {
- { OMAP44XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP44XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP44XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP44XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
-};
-#else
-static const unsigned long omap44xx_mcbsp_port[][2] = {};
-#endif
-
static void
[PATCH v4 13/13] OMAP: hwmod: Removal of macros for data that is obtained from hwmod database
Information like base address and DMA channel nubers should no longer
be obtained using macros. These information should be obtained from
hwmod database. Hence the macros that define the base address are removed.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/plat-omap/include/plat/mcbsp.h | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 21c9b10..f8f690a 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -52,30 +52,7 @@ static struct platform_device omap_mcbsp##port_nr = {
\
#define OMAP1610_MCBSP2_BASE 0xfffb1000
#define OMAP1610_MCBSP3_BASE 0xe1017000
-#define OMAP24XX_MCBSP1_BASE 0x48074000
-#define OMAP24XX_MCBSP2_BASE 0x48076000
-#define OMAP2430_MCBSP3_BASE 0x4808c000
-#define OMAP2430_MCBSP4_BASE 0x4808e000
-#define OMAP2430_MCBSP5_BASE 0x48096000
-
-#define OMAP34XX_MCBSP1_BASE 0x48074000
-#define OMAP34XX_MCBSP2_BASE 0x49022000
-#define OMAP34XX_MCBSP2_ST_BASE0x49028000
-#define OMAP34XX_MCBSP3_BASE 0x49024000
-#define OMAP34XX_MCBSP3_ST_BASE0x4902A000
-#define OMAP34XX_MCBSP3_BASE 0x49024000
-#define OMAP34XX_MCBSP4_BASE 0x49026000
-#define OMAP34XX_MCBSP5_BASE 0x48096000
-
-#define OMAP44XX_MCBSP1_BASE 0x40122000
-#define OMAP44XX_MCBSP1_DMA_BASE 0x49022000
-#define OMAP44XX_MCBSP2_BASE 0x40124000
-#define OMAP44XX_MCBSP2_DMA_BASE 0x49024000
-#define OMAP44XX_MCBSP3_BASE 0x40126000
-#define OMAP44XX_MCBSP3_DMA_BASE 0x49026000
-#define OMAP44XX_MCBSP4_BASE 0x48096000
-
-#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX) ||
defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+#ifdef CONFIG_ARCH_OMAP1
#define OMAP_MCBSP_REG_DRR20x00
#define OMAP_MCBSP_REG_DRR10x02
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/13] OMAP: McBSP: Add pm runtime support
Add pm runtime support for McBSP driver.
Reference to fclk is not removed because it is required when the
functional clock is switched from one source to another.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/mach-omap2/mcbsp.c |5 +++--
arch/arm/plat-omap/include/plat/mcbsp.h |1 -
arch/arm/plat-omap/mcbsp.c | 23 ++-
3 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 275d6cf..4ada6a9 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -23,6 +23,7 @@
#include plat/cpu.h
#include plat/mcbsp.h
#include plat/omap_device.h
+#include linux/pm_runtime.h
#include control.h
@@ -83,7 +84,7 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
return -EINVAL;
}
- clk_disable(mcbsp-fclk);
+ pm_runtime_put_sync(mcbsp-dev);
r = clk_set_parent(mcbsp-fclk, fck_src);
if (IS_ERR_VALUE(r)) {
@@ -93,7 +94,7 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
return -EINVAL;
}
- clk_enable(mcbsp-fclk);
+ pm_runtime_get_sync(mcbsp-dev);
clk_put(fck_src);
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index c6cabfc..964a940 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -465,7 +465,6 @@ struct omap_mcbsp {
/* Protect the field .free, while checking if the mcbsp is in use */
spinlock_t lock;
struct omap_mcbsp_platform_data *pdata;
- struct clk *iclk;
struct clk *fclk;
#ifdef CONFIG_ARCH_OMAP3
struct omap_mcbsp_st_data *st_data;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 30683ce..b1b0a06 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -28,6 +28,7 @@
#include plat/dma.h
#include plat/mcbsp.h
#include plat/omap_device.h
+#include linux/pm_runtime.h
/* XXX These sideways includes are a sign that something is wrong */
#include ../mach-omap2/cm2xxx_3xxx.h
@@ -770,8 +771,7 @@ int omap_mcbsp_request(unsigned int id)
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-request)
mcbsp-pdata-ops-request(id);
- clk_enable(mcbsp-iclk);
- clk_enable(mcbsp-fclk);
+ pm_runtime_get_sync(mcbsp-dev);
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_request(mcbsp);
@@ -819,8 +819,7 @@ err_clk_disable:
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_free(mcbsp);
- clk_disable(mcbsp-fclk);
- clk_disable(mcbsp-iclk);
+ pm_runtime_put_sync(mcbsp-dev);
spin_lock(mcbsp-lock);
mcbsp-free = true;
@@ -850,8 +849,7 @@ void omap_mcbsp_free(unsigned int id)
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_free(mcbsp);
- clk_disable(mcbsp-fclk);
- clk_disable(mcbsp-iclk);
+ pm_runtime_put_sync(mcbsp-dev);
if (mcbsp-io_type == OMAP_MCBSP_IRQ_IO) {
/* Free IRQs */
@@ -1840,32 +1838,24 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
}
mcbsp-dma_tx_sync = res-start;
- mcbsp-iclk = clk_get(pdev-dev, ick);
- if (IS_ERR(mcbsp-iclk)) {
- ret = PTR_ERR(mcbsp-iclk);
- dev_err(pdev-dev, unable to get ick: %d\n, ret);
- goto err_res;
- }
-
mcbsp-fclk = clk_get(pdev-dev, fck);
if (IS_ERR(mcbsp-fclk)) {
ret = PTR_ERR(mcbsp-fclk);
dev_err(pdev-dev, unable to get fck: %d\n, ret);
- goto err_fclk;
+ goto err_res;
}
mcbsp-pdata = pdata;
mcbsp-dev = pdev-dev;
mcbsp_ptr[id] = mcbsp;
platform_set_drvdata(pdev, mcbsp);
+ pm_runtime_enable(mcbsp-dev);
/* Initialize mcbsp properties for OMAP34XX if needed / applicable */
omap34xx_device_init(mcbsp);
return 0;
-err_fclk:
- clk_put(mcbsp-iclk);
err_res:
iounmap(mcbsp-io_base);
err_ioremap:
@@ -1888,7 +1878,6 @@ static int __devexit omap_mcbsp_remove(struct
platform_device *pdev)
omap34xx_device_exit(mcbsp);
clk_put(mcbsp-fclk);
- clk_put(mcbsp-iclk);
iounmap(mcbsp-io_base);
kfree(mcbsp);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [024/115] USB: prevent buggy hubs from crashing the USB stack
On 02/24/2011 09:57 AM, Felipe Balbi wrote: Hi, On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? Alexander already did, but I can do now, too. Thanks for the fix. Tested-by: Michael Jones michael.jo...@matrix-vision.de MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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 3/3] am35xx: pm: Hook-up with TPS65023
Sanjeev,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sanjeev Premi
Sent: Wednesday, February 23, 2011 11:29 PM
To: linux-omap@vger.kernel.org
Cc: Sanjeev Premi
Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
Add glue logic to hook-up AM35x processors
with TPS65023.
It seems that you are not really using Voltage layer for any interaction
with TPS65023 as you are not using VP and VC. Then what is the purpose of
registering this PMIC with Voltage layer. I fail to understand the purpose
of this patch series.
Vishwa
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/am3517_tps.c | 96
++
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/am3517_tps.c
diff --git a/arch/arm/mach-omap2/am3517_tps.c b/arch/arm/mach-
omap2/am3517_tps.c
new file mode 100644
index 000..cddd7eb
--- /dev/null
+++ b/arch/arm/mach-omap2/am3517_tps.c
@@ -0,0 +1,96 @@
+/**
+ * Copyright (C) 2011 Texas Instruments Incorporated -
http://www.ti.com/
+ *
+ * Based on omap_twl.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/i2c/twl.h
+
+#include plat/voltage.h
+
+#include pm.h
+
+/*
+ * TODO: Copy of OMAP3 definitions to get thru compilation.
+ * May not be needed in final implementation. Need to
+ * relook at the the need again.
+ */
+#define OMAP3_SRI2C_SLAVE_ADDR 0x12
+#define OMAP3_VDD_MPU_SR_CONTROL_REG 0x00
+#define OMAP3_VDD_CORE_SR_CONTROL_REG0x01
+#define OMAP3_VP_CONFIG_ERROROFFSET 0x00
+#define OMAP3_VP_VSTEPMIN_VSTEPMIN 0x1
+#define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
+#define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
+
+#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
+#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
+
+/**
+ * TBD: Update the formula below.
+ * Needs to be derived from a table.
+ */
+static unsigned long tps65023_vsel_to_uv(const u8 vsel)
+{
+ return (((vsel * 250) + 6000)) * 100;
+}
+
+/**
+ * TBD: Update the formula below.
+ * Needs to be derived from a table.
+ */
+static u8 tps65023_uv_to_vsel(unsigned long uv)
+{
+ return DIV_ROUND_UP(uv - 60, 25000);
+}
+
+/**
+ * TBD: Just a copy of OMAP3 PMIC info.
+ * Many fields below don't make much sense for AM3517,
+ * but keeping them as is for now.
+ */
+static struct omap_volt_pmic_info am3517_volt_info = {
+ .slew_rate = 4000,
+ .step_size = 25000,
+ .on_volt= 120,
+ .onlp_volt = 100,
+ .ret_volt = 975000,
+ .off_volt = 60,
+ .volt_setup_time= 0xfff,
+ .vp_erroroffset =
OMAP3_VP_CONFIG_ERROROFFSET,
+ .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
+ .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
+ .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
+ .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vp_timeout_us =
OMAP3_VP_VLIMITTO_TIMEOUT_US,
+ .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
+ .pmic_reg = OMAP3_VDD_CORE_SR_CONTROL_REG,
+ .vsel_to_uv = tps65023_vsel_to_uv,
+ .uv_to_vsel = tps65023_uv_to_vsel,
+};
+
+int __init am3517_tps_init(void)
+{
+ struct voltagedomain *voltdm;
+
+ if (!cpu_is_omap3505() !cpu_is_omap3517())
+ return -ENODEV;
+
+ voltdm = omap_voltage_domain_lookup(mpu);
+ omap_voltage_register_pmic(voltdm, am3517_volt_info);
+
+ return 0;
+}
+
--
1.7.2.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
--
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
omap dss tft display connection
Hello, would be possible to configure dss on omap3530 which is connected to 18bit TFT display in such way: 8 88 | | | | | | | |-| | | | | | | |-| | | | | | | | 6 6 6 | | | | | |-| | | | | |-| | | | | | So no standard connection (2 bits in every color are skipped) but it's shifted so last 6 bits remain unused. When use generic panel it seems I have no red color (just combination of blue and green). It is anyway possible to drive such a connection? Or HW needs to ne changed? Thanks in advance, Marek Belisko -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite icq: 290551086 web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
Some of the omap2, omap3 peripherals support software reset. This
can be done through the softreset bit in sysconfig register.
The reset status can be checked through resetdone bit of
sysstatus register. syss_has_reset_status is added to the hwmod
database of peripherals which have resetdone bit in sysstatus register.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Reviewed-by: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
---
The patch is based on linux-omap tree, master branch on commit:
e10eed954a2525c5d0b6dc361cdcbb46fea69d50
Testing:
build testing : omap2plus_defconfig
boot testing: 2420h4, 2430sdp.
[ boot test was done on omap-fixes-for-linus branch, commit
1232a185ddd500b61b8dc389ad1a357e6b425548 , since master branch wasn't booting
on 2420 and 2430 ].
pm testing : tested core off in cpuidle patch in 3430sdp.
[ kevins 'i2c: OMAP: fix static suspend vs. runtime suspend' fix was needed to
have core off working. ]. core off works in cpuidle patch.
below configurations needed for core off in cpuidle:
echo 1 /debug/pm_debug/sleep_while_idle
echo 1 /debug/pm_debug/enable_off_mode
echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout
echo enabled /sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup
echo enabled /sys/devices/platform/omap/omap_uart.1/tty/ttyO1/power/wakeup
echo enabled /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 11 ++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 12 +++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 -
3 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b85c630..e8046b4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -308,7 +308,7 @@ static struct omap_hwmod_class_sysconfig
omap2420_wd_timer_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -349,7 +349,7 @@ static struct omap_hwmod_class_sysconfig uart_sysc = {
.syss_offs = 0x58,
.sysc_flags = (SYSC_HAS_SIDLEMODE |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -475,7 +475,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
.rev_offs = 0x00,
.sysc_offs = 0x20,
.syss_offs = 0x10,
- .sysc_flags = SYSC_HAS_SOFTRESET,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -647,7 +647,8 @@ static struct omap_hwmod_class_sysconfig omap242x_gpio_sysc
= {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -789,7 +790,7 @@ static struct omap_hwmod_class_sysconfig omap2420_dma_sysc
= {
.syss_offs = 0x0028,
.sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_MIDLEMODE |
SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_EMUFREE |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8ecfbcd..115eed5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -307,7 +307,7 @@ static struct omap_hwmod_class_sysconfig
omap2430_wd_timer_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -348,7 +348,7
[PATCH 1/3] OMAP2+: PM: omap device: API's for handling mstandby mode
Certain errata in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
release no standby mode and sets it to smart standby or no
standby? depending on HWMOD_SWSUP_MSTANDBY value.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
These API's are required for multiple DMA errata which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata:
1. Erratum ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Erratum ID: i541
sDMA FIFO draining does not finish. Applicable to all omap2+ except
omap4.
3. Erratum ID:i88
The sDMA to be put in no mstandby mode before disabling the channel
after completing the data transfer operation.
Applicable only for OMAP3430 ES1.0
Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 42
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +-
arch/arm/plat-omap/omap_device.c | 64 +
4 files changed, 111 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e282e35..27eb845 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1537,6 +1537,48 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ u8 sf;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ if (!oh-class-sysc)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+ sf = oh-class-sysc-sysc_flags;
+
+ if (sf SYSC_HAS_MIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
+ HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ }
+ retval = _set_master_standbymode(oh, idlemode, v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
+/**
* omap_hwmod_lookup - look up a registered omap_hwmod by name
* @name: name of the omap_hwmod to look up
*
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..42e0186 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -117,6 +117,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_require_no_mstandby(struct platform_device *pdev);
+int omap_device_release_no_mstandby(struct platform_device *pdev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1eee85a..8a37c6e 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -366,7 +366,7 @@ struct omap_hwmod_omap4_prcm {
*
* HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring module in and out
* of idle, rather than relying on module smart-idle
- * HWMOD_SWSUP_MSTDBY: omap_hwmod code should manually bring module in and out
+ * HWMOD_SWSUP_MSTANDBY: omap_hwmod code should manually bring module in and
out
* of standby, rather than relying on module smart-standby
* HWMOD_INIT_NO_RESET: don't reset this module at boot - important for
* SDRAM controller, etc. XXX probably belongs outside the main hwmod file
@@ -556,6 +556,8 @@ int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
int
[PATCH 0/3] OMAP: DMA: mstandby mode and runtime pm support
This patch series is remaining part of dma hwmod to support pm runtime and for handling mstandby mode for all applicable DMA mstandby mode errata. The alignment for pm runtime API's usage is at: http://thread.gmane.org/gmane.linux.ports.arm.omap/51588/focus=52493 http://thread.gmane.org/gmane.linux.ports.arm.omap/50762/focus=50840 The alignment for handling mstandby mode errata handling is at: http://thread.gmane.org/gmane.linux.ports.arm.omap/47398/focus=47426 http://thread.gmane.org/gmane.linux.ports.arm.omap/47479/focus=47537 Testing: Compile tested for - omap1_defconfig - omap2plus_defconfig Boot test on: - OMAP1710-H3 - OMAP2420-H4 - OMAP3430-LDP - OMAP3630-Zoom3 - OMAP4430-Blaze DMA memory to memory test cases(including chaining) are executed for all the above boards and for each test case, /sys/devices/platform/omap/omap_dma_system.0/power/runtime_status was verified and after completion of the tests, runtime_status will be always suspended. Apart from that, offmode testing is done for OMAP3430-LDP using the procedure: echo 1 /debug/pm_debug/sleep_while_idle echo 1 /debug/pm_debug/enable_off_mode echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout With the above steps, core off mode count gets increasing if the the board is idle for more than 5 seconds. Baseline: Applies cleanly on top of mainline 2.6.38-rc6: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git commit f5412be599602124d2bdd49947b231dd77c0bf99 Author: Linus Torvalds torva...@linux-foundation.org Date: Mon Feb 21 17:25:52 2011 -0800 Linux 2.6.38-rc6 Note: OMAP1 is tested on top of 2.6.38-rc5 since rc6 is broken for omap1 build Patch Summary: == G, Manjunath Kondaiah (2): OMAP2+: PM: omap device: API's for handling mstandby mode OMAP2+: DMA: prevent races while setting M idle mode to nostandby Manjunath G Kondaiah (1): OMAP: PM: DMA: Enable runtime pm arch/arm/mach-omap1/dma.c |1 + arch/arm/mach-omap2/dma.c | 16 ++ arch/arm/mach-omap2/omap_hwmod.c | 42 ++ arch/arm/plat-omap/dma.c | 190 + arch/arm/plat-omap/include/plat/dma.h |1 + arch/arm/plat-omap/include/plat/omap_device.h |2 + arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +- arch/arm/plat-omap/omap_device.c | 64 + 8 files changed, 293 insertions(+), 27 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP2+: DMA: prevent races while setting M idle mode to nostandby
If two DMA users tries to set no mstandby mode at the same time, a race
condition would arise. Prevent that by using a spin lock and counting
up/down the number of times nostandby is set/reset.
Initial patch is created by Adrian Hunter adrian.hun...@nokia.com
https://patchwork.kernel.org/patch/366831/
Patch reworked to use API implemented at hwmod layer.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/mach-omap1/dma.c |1 +
arch/arm/mach-omap2/dma.c | 16 +
arch/arm/plat-omap/dma.c | 40 +++--
arch/arm/plat-omap/include/plat/dma.h |1 +
4 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index d855934..fa2d1b0 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -351,6 +351,7 @@ static int __init omap1_system_dma_init(void)
p-dma_write= dma_write;
p-dma_read = dma_read;
p-disable_irq_lch = NULL;
+ p-midlemode= NULL;
p-errata = configure_dma_errata();
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 34922b2..6e12e71 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -36,7 +36,9 @@
static u32 errata;
static u8 dma_stride;
+static u32 midlemode_save_cnt;
+static struct platform_device *pdev;
static struct omap_dma_dev_attr *d;
static enum omap_reg_offsets dma_common_ch_start, dma_common_ch_end;
@@ -117,6 +119,18 @@ static inline u32 dma_read(int reg, int lch)
return val;
}
+static void midlemode_nostandby(bool nostandby)
+{
+ /* TODO: midlemode_save_cnt can be moved to hwmod layer? */
+ if (nostandby) {
+ omap_device_require_no_mstandby(pdev);
+ midlemode_save_cnt += 1;
+ } else {
+ omap_device_release_no_mstandby(pdev);
+ midlemode_save_cnt -= 1;
+ }
+}
+
static inline void omap2_disable_irq_lch(int lch)
{
u32 val;
@@ -253,6 +267,7 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
p-clear_dma= omap2_clear_dma;
p-dma_write= dma_write;
p-dma_read = dma_read;
+ p-midlemode= midlemode_nostandby;
p-clear_lch_regs = NULL;
@@ -286,6 +301,7 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
dev_err(od-pdev.dev, %s: kzalloc fail\n, __func__);
return -ENOMEM;
}
+ pdev = od-pdev;
return 0;
}
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 8536308..84879eb 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -38,8 +38,9 @@
#include asm/system.h
#include mach/hardware.h
-#include plat/dma.h
+#include plat/dma.h
+#include plat/omap_device.h
#include plat/tc.h
#undef DEBUG
@@ -924,6 +925,7 @@ EXPORT_SYMBOL(omap_start_dma);
void omap_stop_dma(int lch)
{
u32 l;
+ unsigned long flags;
/* Disable all interrupts on the channel */
if (cpu_class_is_omap1())
@@ -933,14 +935,13 @@ void omap_stop_dma(int lch)
if (IS_DMA_ERRATA(DMA_ERRATA_i541)
(l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
- u32 sys_cf;
/* Configure No-Standby */
- l = p-dma_read(OCP_SYSCONFIG, lch);
- sys_cf = l;
- l = ~DMA_SYSCONFIG_MIDLEMODE_MASK;
- l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
- p-dma_write(l , OCP_SYSCONFIG, 0);
+ if (p-midlemode) {
+ spin_lock_irqsave(dma_chan_lock, flags);
+ p-midlemode(true);
+ spin_unlock_irqrestore(dma_chan_lock, flags);
+ }
l = p-dma_read(CCR, lch);
l = ~OMAP_DMA_CCR_EN;
@@ -958,7 +959,11 @@ void omap_stop_dma(int lch)
printk(KERN_ERR DMA drain did not complete on
lch %d\n, lch);
/* Restore OCP_SYSCONFIG */
- p-dma_write(sys_cf, OCP_SYSCONFIG, lch);
+ if (p-midlemode) {
+ spin_lock_irqsave(dma_chan_lock, flags);
+ p-midlemode(false);
+ spin_unlock_irqrestore(dma_chan_lock, flags);
+ }
} else {
l = ~OMAP_DMA_CCR_EN;
p-dma_write(l, CCR, lch);
@@ -1610,7 +1615,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
{
int *channels;
u32 l, i;
- u32 sys_cf = 0;
+ unsigned long flags;
/* Check for input params */
if (unlikely((chain_id 0 || chain_id = dma_lch_count))) {
@@ -1625,12 +1630,10
[PATCH 3/3] OMAP: PM: DMA: Enable runtime pm
From: Manjunath G Kondaiah manj...@ti.com
Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put_autosuspend
for OMAP DMA driver.
The DMA driver uses auto suspend feature of runtime pm framework through
which the clock gets disabled automatically if there is no activity for
more than one second.
Testing:
Compile: omap1_defconfig and omap2plus_defconfig
Boot: OMAP1710(H3), OMAP2420(H4), OMAP3430LDP(Zoom2), OMAP3630(Zoom3),
OMAP4(Blaze)
The DMA tests(including chaining) are executed and tested for suspend state
after each test cases.
On zoom2 core retention is tested with following steps:
echo 1 /debug/pm_debug/sleep_while_idle
echo 1 /debug/pm_debug/enable_off_mode
echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/plat-omap/dma.c | 150 +++---
1 files changed, 141 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 84879eb..92e18e3 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -35,6 +35,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/delay.h
+#include linux/pm_runtime.h
#include asm/system.h
#include mach/hardware.h
@@ -60,6 +61,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
static struct omap_system_dma_plat_info *p;
static struct omap_dma_dev_attr *d;
+static struct device *dev;
static int enable_1510_mode;
static u32 errata;
@@ -172,6 +174,7 @@ void omap_set_dma_priority(int lch, int dst_port, int
priority)
unsigned long reg;
u32 l;
+ pm_runtime_get_sync(dev);
if (cpu_class_is_omap1()) {
switch (dst_port) {
case OMAP_DMA_PORT_OCP_T1: /* FFFECC00 */
@@ -188,6 +191,7 @@ void omap_set_dma_priority(int lch, int dst_port, int
priority)
break;
default:
BUG();
+ pm_runtime_put_autosuspend(dev);
return;
}
l = omap_readl(reg);
@@ -206,6 +210,7 @@ void omap_set_dma_priority(int lch, int dst_port, int
priority)
ccr = ~(1 6);
p-dma_write(ccr, CCR, lch);
}
+ pm_runtime_put_autosuspend(dev);
}
EXPORT_SYMBOL(omap_set_dma_priority);
@@ -215,6 +220,8 @@ void omap_set_dma_transfer_params(int lch, int data_type,
int elem_count,
{
u32 l;
+ pm_runtime_get_sync(dev);
+
l = p-dma_read(CSDP, lch);
l = ~0x03;
l |= data_type;
@@ -269,6 +276,7 @@ void omap_set_dma_transfer_params(int lch, int data_type,
int elem_count,
p-dma_write(elem_count, CEN, lch);
p-dma_write(frame_count, CFN, lch);
+ pm_runtime_put_autosuspend(dev);
}
EXPORT_SYMBOL(omap_set_dma_transfer_params);
@@ -276,6 +284,7 @@ void omap_set_dma_color_mode(int lch, enum
omap_dma_color_mode mode, u32 color)
{
BUG_ON(omap_dma_in_1510_mode());
+ pm_runtime_get_sync(dev);
if (cpu_class_is_omap1()) {
u16 w;
@@ -329,11 +338,13 @@ void omap_set_dma_color_mode(int lch, enum
omap_dma_color_mode mode, u32 color)
color = 0xff;
p-dma_write(color, COLOR, lch);
}
+ pm_runtime_put_autosuspend(dev);
}
EXPORT_SYMBOL(omap_set_dma_color_mode);
void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode)
{
+ pm_runtime_get_sync(dev);
if (cpu_class_is_omap2()) {
u32 csdp;
@@ -342,11 +353,13 @@ void omap_set_dma_write_mode(int lch, enum
omap_dma_write_mode mode)
csdp |= (mode 16);
p-dma_write(csdp, CSDP, lch);
}
+ pm_runtime_put_autosuspend(dev);
}
EXPORT_SYMBOL(omap_set_dma_write_mode);
void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode mode)
{
+ pm_runtime_get_sync(dev);
if (cpu_class_is_omap1() !cpu_is_omap15xx()) {
u32 l;
@@ -355,6 +368,7 @@ void omap_set_dma_channel_mode(int lch, enum
omap_dma_channel_mode mode)
l |= mode;
p-dma_write(l, LCH_CTRL, lch);
}
+ pm_runtime_put_autosuspend(dev);
}
EXPORT_SYMBOL(omap_set_dma_channel_mode);
@@ -365,6 +379,8 @@ void omap_set_dma_src_params(int lch, int src_port, int
src_amode,
{
u32 l;
+ pm_runtime_get_sync(dev);
+
if (cpu_class_is_omap1()) {
u16 w;
@@ -383,11 +399,13 @@ void omap_set_dma_src_params(int lch, int src_port, int
src_amode,
p-dma_write(src_ei, CSEI, lch);
p-dma_write(src_fi, CSFI, lch);
+ pm_runtime_put_autosuspend(dev);
}
EXPORT_SYMBOL(omap_set_dma_src_params);
void omap_set_dma_params(int lch, struct
Re: [PATCH v3 0/5] OMAP: HSMMC: hwmod adaptation
Hi Kishore, On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote: Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4. Adapting the omap_hsmmc driver to hwmod framework. The patch series is based on -rc6 and tested on OMAP2430, OMAP3430SDP OMAP4430SDP. Could you rebase it on top of omap-for-linus, it does apply for the moment. Thanks, Benoit V3: --- Omap2420 platform consists of mmc block as in omap1 and not the hsmmc block as present in omap2430, omap3, omap4 platforms. The series takes care of hwmod adaptation of hsmmc drivers and thus excluding the omap2420 platforms. The patch series has dependency on : 1)https://patchwork.kernel.org/patch/585281/ 2)https://patchwork.kernel.org/patch/538301/ V2: --- http://www.spinics.net/lists/linux-omap/msg45443.html V1: --- http://www.spinics.net/lists/linux-mmc/msg05689.html Anand Gadiyar (1): OMAP4: hwmod data: enable HSMMC Kishore Kadiyala (2): OMAP: hwmod data: Add dev_attr and use in the host driver OMAP: adapt hsmmc to hwmod framework Paul Walmsley (2): OMAP2430: hwmod data: Add HSMMC OMAP3: hwmod data: Add HSMMC arch/arm/mach-omap2/devices.c | 251 arch/arm/mach-omap2/hsmmc.c| 153 -- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 155 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 221 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 +++- arch/arm/mach-omap2/prcm-common.h |4 + arch/arm/plat-omap/include/plat/mmc.h | 24 +-- drivers/mmc/host/omap_hsmmc.c |4 +- 8 files changed, 554 insertions(+), 284 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/5] OMAP4: hwmod data: enable HSMMC
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
From: Anand Gadiyargadi...@ti.com
Enabling hsmmc hwmod for OMAP4
Signed-off-by: Anand Gadiyargadi...@ti.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
CC: Kevin Hilmankhil...@deeprootsystems.com
Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..dd39e75 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5077,11 +5077,11 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[]
= {
omap44xx_mcspi4_hwmod,
/* mmc class */
-/* omap44xx_mmc1_hwmod, */
-/* omap44xx_mmc2_hwmod, */
-/* omap44xx_mmc3_hwmod, */
-/* omap44xx_mmc4_hwmod, */
-/* omap44xx_mmc5_hwmod, */
+ omap44xx_mmc1_hwmod,
+ omap44xx_mmc2_hwmod,
+ omap44xx_mmc3_hwmod,
+ omap44xx_mmc4_hwmod,
+ omap44xx_mmc5_hwmod,
/* mpu class */
omap44xx_mpu_hwmod,
--
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 dss tft display connection
On Thu, 2011-02-24 at 04:05 -0600, Belisko Marek wrote: Hello, would be possible to configure dss on omap3530 which is connected to 18bit TFT display in such way: 8 88 | | | | | | | |-| | | | | | | |-| | | | | | | | 6 6 6 | | | | | |-| | | | | |-| | | | | | So no standard connection (2 bits in every color are skipped) but it's shifted so last 6 bits remain unused. When use generic panel it seems I have no red color (just combination of blue and green). It is anyway possible to drive such a connection? Or HW needs to ne changed? Can you explain a bit more what you are trying to do? At least I didn't quite understand =). Why don't you use the 18bit TFT with 18 datalines? Tomi -- 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 dss tft display connection
Hi Toomi, On Thu, Feb 24, 2011 at 11:39 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2011-02-24 at 04:05 -0600, Belisko Marek wrote: Hello, would be possible to configure dss on omap3530 which is connected to 18bit TFT display in such way: 8 8 8 | | | | | | | |-| | | | | | | |-| | | | | | | | 6 6 6 | | | | | |-| | | | | |-| | | | | | So no standard connection (2 bits in every color are skipped) but it's shifted so last 6 bits remain unused. When use generic panel it seems I have no red color (just combination of blue and green). It is anyway possible to drive such a connection? Or HW needs to ne changed? Can you explain a bit more what you are trying to do? At least I didn't quite understand =). Sorry maybe my question wasn't clear ;). I have mini8100 board connected to 18bit hitachi TX18D35 connected in way I described in first email (LCD datalines connected to lower 18 bits dss data lines). So my question was what to change (only .phy.dpi.data_lines = 18 is enought?) to keep driving my display correctly ;) I try that option but no visible change. Hopefully better description like before ;) Why don't you use the 18bit TFT with 18 datalines? Tomi thanks, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite icq: 290551086 web: http://open-nandra.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: [PATCH] omap4: hwmod: Enable the keypad
On 2/24/2011 6:42 AM, Datta, Shubhrajyoti wrote:
From: Shubhrajyoti Dshubhrajy...@ti.com
Enable the keypad in the hwmod database.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..5af80d6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5056,7 +5056,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_iva_seq1_hwmod,
/* kbd class */
-/* omap44xx_kbd_hwmod, */
+ omap44xx_kbd_hwmod,
/* mailbox class */
omap44xx_mailbox_hwmod,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] OMAP: hwmod data: Add dev_attr and use in the host driver
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
Add a device attribute to hwmod data of omap2430, omap3, omap4.
Currently the device attribute holds information regarding dual volt MMC card
support by the controller which will be later passed to the host driver via
platform data.
Signed-off-by: Kevin Hilmankhil...@deeprootsystems.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
There are few minor comments to fix hence the:
Almost-Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
arch/arm/plat-omap/include/plat/mmc.h | 10 ++
drivers/mmc/host/omap_hsmmc.c |4 ++--
5 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4d45b7d..e050355 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -19,6 +19,7 @@
#includeplat/i2c.h
#includeplat/gpio.h
#includeplat/mcspi.h
+#includeplat/mmc.h
#include omap_hwmod_common_data.h
@@ -1290,6 +1291,10 @@ static struct omap_hwmod_class mmc_class = {
/* MMC/SD/SDIO1 */
+static struct mmc_dev_attr mmc1_dev_attr = {
Could you rename the struct omap_mmc_dev_attr to stick to the convention?
The dev_attr should be just above static struct omap_hwmod. See the
OMAP4 example below.
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
{ .irq = 83 },
};
@@ -1328,11 +1333,14 @@ static struct omap_hwmod omap2430_mmc1_hwmod = {
.slaves = omap2430_mmc1_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_mmc1_slaves),
.class =mmc_class,
+ .dev_attr =mmc1_dev_attr,
dev_attr should be above .slaves.
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
/* MMC/SD/SDIO2 */
+static struct mmc_dev_attr mmc2_dev_attr;
If you do not have any dev_attr for that instance, do not add it here
and test for null pointer in your driver.
This comment applies for all instances in all OMAPs.
+
static struct omap_hwmod_irq_info mmc2_mpu_irqs[] = {
{ .irq = 86 },
};
@@ -1371,6 +1379,7 @@ static struct omap_hwmod omap2430_mmc2_hwmod = {
.slaves = omap2430_mmc2_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_mmc2_slaves),
.class =mmc_class,
+ .dev_attr =mmc2_dev_attr,
Not needed if there is not data in the structure.
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index dd39e75..6c4ccfd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
#includeplat/gpio.h
#includeplat/dma.h
#includeplat/mcspi.h
+#includeplat/mmc.h
#include omap_hwmod_common_data.h
@@ -3383,6 +3384,10 @@ static struct omap_hwmod_class omap44xx_mmc_hwmod_class
= {
};
/* mmc1 */
+static struct mmc_dev_attr omap_mmc1_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info omap44xx_mmc1_irqs[] = {
{ .irq = 83 + OMAP44XX_IRQ_GIC_START },
};
@@ -3437,10 +3442,14 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc1_slaves),
.masters= omap44xx_mmc1_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_mmc1_masters),
+ .dev_attr =omap_mmc1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc2 */
+static struct omap_hwmod omap44xx_mmc2_hwmod;
+static struct mmc_dev_attr omap_mmc2_dev_attr;
+
static struct omap_hwmod_irq_info omap44xx_mmc2_irqs[] = {
{ .irq = 86 + OMAP44XX_IRQ_GIC_START },
};
@@ -3495,11 +3504,13 @@ static struct omap_hwmod omap44xx_mmc2_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc2_slaves),
.masters= omap44xx_mmc2_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_mmc2_masters),
+ .dev_attr =omap_mmc2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc3 */
static struct omap_hwmod omap44xx_mmc3_hwmod;
+static struct mmc_dev_attr omap_mmc3_dev_attr;
static struct omap_hwmod_irq_info omap44xx_mmc3_irqs[] = {
{ .irq = 94 + OMAP44XX_IRQ_GIC_START },
};
@@ -3547,11 +3558,13 @@ static struct omap_hwmod omap44xx_mmc3_hwmod = {
},
.slaves = omap44xx_mmc3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc3_slaves),
+ .dev_attr =omap_mmc3_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc4 */
static struct omap_hwmod omap44xx_mmc4_hwmod;
+static struct mmc_dev_attr
[PATCH v11 0/8] dmtimer adaptation to platform_driver
dmtimer adaptation to platform_driver.
This patch series is adaptation of dmtimer code to platform driver
using omap_device and omap_hwmod abstraction.
NOTE:
This patch series should be applied on-top of Paul's following patch
series:
http://www.spinics.net/lists/linux-omap/msg46725.html
Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Branch: omap-for-linus
Test Info:
Tested on OMAP3, OMAP4. Bootup test on OMAP1710.
OMAP3 power test: Retention and Off mode.
OMAP2 platforms not tested because of existing issue in the branch.
v11:
(1) Removed early timer initialization call from omap2_init_common_devices()
in io.c. It is now called from omap2_gp_timer_init() in timer-gp.c as part
of following call sequence:
start_kernel()-time_init()-timer-init()-omap2_gp_timer_init()
(2) Basedlined on top of Paul's patch series mentioned above.
v10:
(1) Update PM runtime for active early timers so that PM runtime userspace
info is correct.
(2) Include code to configure timers to POSTED mode which got missed in
the previous version.
(3) Remove pm runtime_enable from OMAP1 specific code since this is not
applicable.
v9:
(1) In OMAP3 hwmod database, added entry for timer12 which was missing.
Beagle board uses timer12 as its millisecond timer.
(2) In OMAP3 hwmod database, rectified in-correct prcm configurations
for timer10 and timer11.
From:
.prcm = {
.module_bit = OMAP24XX_EN_GPT10_SHIFT,
.idlest_idle_bit = OMAP24XX_ST_GPT10_SHIFT,
},
To:
.prcm = {
.module_bit = OMAP3430_EN_GPT10_SHIFT,
.idlest_idle_bit = OMAP3430_ST_GPT10_SHIFT,
},
(3) In OMAP3 hwmod database, removed timer master port entry for all
timers because it is not supported.
static struct omap_hwmod_ocp_if *omap3xxx_timer7_masters[] = {
omap3xxx_l4_per__timer7,
};
(4) In OMAP4 hwmod database, added SIDLE_SMART_WKUP flag for
non-millisecond timers.
(5) In OMAP3 hwmod database, rectified sysconfig configuration for
non-millisecond timers.
From: omap_hwmod_sysc_type2 To: omap_hwmod_sysc_type1.
This was preventing system to go to RETENTION and OFF modes.
v8:
(1) Baselined on Tony's tree in omap-for-linus branch
(2) The last patch in v7 series has been removed because it is fixed
by following patch:
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
v7:
(1) In omap1_dm_timer_set_src(), the computation of shift value to respective
dmtimer clock source was corrected:
From:
int n = (pdev-id) 1;
To:
int n = (pdev-id - 1) 1;
This change is needed because dmtimer is indexed from 1 now instead of 0.
(2) In omap1_dm_timer_init(void) memory resource end address chnaged:
From:
res[0].end = base + 0xff;
To:
res[0].end = base + 0x46;
This was causing request_mem_region() failure in driver probe().
(3) In the export APIs there are some calls which are not applicable to OMAP1.
They have been made conditional now. They include following calls:
timer-fclk = clk_get(timer-pdev-dev, fck);
omap_dm_timer_enable()
omap_dm_timer_disable()
(4) Remove usage of cpu_is_omap16xx() and instead a flag has been added in
struct dmtimer_platform_data {
...
u32 is_omap16xx:1;
}
This flag is set to 1 in mach-omap1/dmtimer.c and set to 0 in
mach-omap2/dmtimer.c
This flag is used in plat-omap/dmtimer.c wherever it needs to distiguish
omap16xx.
(5) Remove #include plat/omap_device.h from mach-omap1/dmtimer.c
(6) Instead of using macros like INT_24XX_GPTIMERx, use the numbers
directly in OMAP2420, OMAP2430 and OMAP3xxx hwmod database.
(7) pm_runtime_get_sync() and pm_runtime_put_sync() return value check modified
from positive to negative value:
if (pm_runtime_get_sync(...) 0) {
...
}
v6:
(1) Removed reset functions to mach-omap1/dmtimer.c.
Access to reset function from plat-omap/dmtimer.c is provided by means
of function pointer.
(2) Remove multiple calls to omap_device_build() for registering timer devices
during early and regular initialization. Regular device registration is now done
by reading data from temporary list. This list is populated during early init
where timer data is read from hwmod database and corresponding memory allocated.
(3) kfree(pdata) under error condition since platform_device_unregister does
not free its pdata.
(4) Removed extra header inclusion in mach-omap2 and plat-omap
NOTE: omap_dm_timer.id field could not be removed because during regular boot
there is no mechanism to match the current pdev with corresponding entry in the
timer list which was partially initialized during early boot.
v5:
(1) In mach-omap2/dmtimer.c merged the merged two different init functions
into a single one, viz: omap_timer_init(*oh, *user). Now this function is
used both during early init and later. The distinction is between the two
is made thriugh the *user field.
(2) Added timeout to low-level access routines in place of infinite
[PATCH v11 1/8] OMAP2+: dmtimer: add device names to flck nodes
From: Thara Gopinath th...@ti.com
Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
NOTE: gpt1_fck is modified in patch-10 when we switch to platform device
driver. This is to make sure that each patch compiles and boots.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 58 +++--
arch/arm/mach-omap2/clock2430_data.c | 58 +++--
arch/arm/mach-omap2/clock3xxx_data.c | 46 --
arch/arm/mach-omap2/clock44xx_data.c | 42 ++--
4 files changed, 161 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 0a992bc..ee93d3c 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1803,27 +1803,27 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpt1_ick, gpt1_ick, CK_242X),
CLK(NULL, gpt1_fck, gpt1_fck, CK_242X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_242X),
- CLK(NULL, gpt2_fck, gpt2_fck, CK_242X),
+ CLK(omap_timer.2, fck, gpt2_fck, CK_242X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_242X),
- CLK(NULL, gpt3_fck, gpt3_fck, CK_242X),
+ CLK(omap_timer.3, fck, gpt3_fck, CK_242X),
CLK(NULL, gpt4_ick, gpt4_ick, CK_242X),
- CLK(NULL, gpt4_fck, gpt4_fck, CK_242X),
+ CLK(omap_timer.4, fck, gpt4_fck, CK_242X),
CLK(NULL, gpt5_ick, gpt5_ick, CK_242X),
- CLK(NULL, gpt5_fck, gpt5_fck, CK_242X),
+ CLK(omap_timer.5, fck, gpt5_fck, CK_242X),
CLK(NULL, gpt6_ick, gpt6_ick, CK_242X),
- CLK(NULL, gpt6_fck, gpt6_fck, CK_242X),
+ CLK(omap_timer.6, fck, gpt6_fck, CK_242X),
CLK(NULL, gpt7_ick, gpt7_ick, CK_242X),
- CLK(NULL, gpt7_fck, gpt7_fck, CK_242X),
+ CLK(omap_timer.7, fck, gpt7_fck, CK_242X),
CLK(NULL, gpt8_ick, gpt8_ick, CK_242X),
- CLK(NULL, gpt8_fck, gpt8_fck, CK_242X),
+ CLK(omap_timer.8, fck, gpt8_fck, CK_242X),
CLK(NULL, gpt9_ick, gpt9_ick, CK_242X),
- CLK(NULL, gpt9_fck, gpt9_fck, CK_242X),
+ CLK(omap_timer.9, fck, gpt9_fck, CK_242X),
CLK(NULL, gpt10_ick,gpt10_ick, CK_242X),
- CLK(NULL, gpt10_fck,gpt10_fck, CK_242X),
+ CLK(omap_timer.10,fck, gpt10_fck, CK_242X),
CLK(NULL, gpt11_ick,gpt11_ick, CK_242X),
- CLK(NULL, gpt11_fck,gpt11_fck, CK_242X),
+ CLK(omap_timer.11,fck, gpt11_fck, CK_242X),
CLK(NULL, gpt12_ick,gpt12_ick, CK_242X),
- CLK(NULL, gpt12_fck,gpt12_fck, CK_242X),
+ CLK(omap_timer.12,fck, gpt12_fck, CK_242X),
CLK(omap-mcbsp.1, ick, mcbsp1_ick,CK_242X),
CLK(omap-mcbsp.1, fck, mcbsp1_fck,CK_242X),
CLK(omap-mcbsp.2, ick, mcbsp2_ick,CK_242X),
@@ -1878,6 +1878,42 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_242X),
CLK(NULL, usb_fck, usb_fck, CK_242X),
CLK(musb-hdrc,fck, osc_ck,CK_242X),
+ CLK(omap_timer.1, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.2, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.3, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.4, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.5, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.6, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.7, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.8, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.9, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.10,32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.11,32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.12,32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.1, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.2, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.3, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.4, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.5, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.6, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.7,
[PATCH v11 8/8] OMAP: dmtimer: add timeout to low-level routines
The low-level read and write access routines wait on write-pending register
in posted mode to make sure that previous write is complete on respective
registers. This waiting is done in an infinite while loop. Now it is being
modified to use timeout instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index fcac422..a39d5ba 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -43,6 +43,7 @@
#include linux/err.h
#include linux/platform_device.h
#include plat/dmtimer.h
+#include plat/common.h
/* register offsets */
#define _OMAP_TIMER_ID_OFFSET 0x00
@@ -153,6 +154,8 @@
#define OMAP_TIMER_TICK_INT_MASK_COUNT_REG \
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR WPSHIFT))
+#define MAX_WRITE_PEND_WAIT1 /* 10ms timeout delay */
+
static LIST_HEAD(omap_timer_list);
static DEFINE_SPINLOCK(dm_timer_lock);
@@ -168,16 +171,23 @@ static DEFINE_SPINLOCK(dm_timer_lock);
static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer, u32 reg)
{
struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+ int i = 0;
if (reg = OMAP_TIMER_WAKEUP_EN_REG)
reg += pdata-func_offset;
else if (reg = OMAP_TIMER_STAT_REG)
reg += pdata-intr_offset;
- if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
-(reg WPSHIFT))
- cpu_relax();
+ if (timer-posted) {
+ omap_test_timeout(!(readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG +
+ pdata-func_offset) 0xff)) (reg WPSHIFT)),
+ MAX_WRITE_PEND_WAIT, i);
+
+ if (WARN_ON_ONCE(i == MAX_WRITE_PEND_WAIT))
+ pr_err(: read timeout\n);
+ }
+
return readl(timer-io_base + (reg 0xff));
}
@@ -195,16 +205,23 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
u32 value)
{
struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+ int i = 0;
if (reg = OMAP_TIMER_WAKEUP_EN_REG)
reg += pdata-func_offset;
else if (reg = OMAP_TIMER_STAT_REG)
reg += pdata-intr_offset;
- if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
-(reg WPSHIFT))
- cpu_relax();
+ if (timer-posted) {
+ omap_test_timeout(!(readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG +
+ pdata-func_offset) 0xff)) (reg WPSHIFT)),
+ MAX_WRITE_PEND_WAIT, i);
+
+ if (WARN_ON(i == MAX_WRITE_PEND_WAIT))
+ pr_err(: write timeout\n);
+ }
+
writel(value, timer-io_base + (reg 0xff));
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 4/8] OMAP2+: dmtimer: convert to platform devices
Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver. It also provides
provision to access timers during early boot when pm_runtime framework
is not completely up and running.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dmtimer.c | 199 +
2 files changed, 200 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1c3635d..7e5014b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
-common.o gpio.o dma.o wd_timer.o
+common.o gpio.o dma.o wd_timer.o dmtimer.o
omap-2-3-common= irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
new file mode 100644
index 000..00cebe9
--- /dev/null
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -0,0 +1,199 @@
+/**
+ * OMAP2+ Dual-Mode Timers - platform device registration
+ *
+ * Contains first level initialization routines which extracts timers
+ * information from hwmod database and registers with linux device model.
+ * It also has low level function to change the timer input clock source.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * Thara Gopinath th...@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 as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/dmtimer.h
+#include plat/omap_device.h
+#include plat/cpu.h
+
+/*
+ * OMAP4 IP revision has different register offsets
+ * for interrupt registers and functional registers.
+ */
+#define VERSION2_TIMER_WAKEUP_EN_REG_OFFSET0x14
+#define VERSION2_TIMER_STAT_REG_OFFSET 0x10
+
+static int early_timer_count __initdata = 1;
+
+struct dm_timer_data {
+ struct omap_device *od;
+ struct dmtimer_platform_data *pdata;
+ struct list_head node;
+};
+
+static __initdata LIST_HEAD(dm_timer_data_list);
+
+/**
+ * omap2_dm_timer_set_src - change the timer input clock source
+ * @pdev: timer platform device pointer
+ * @timer_clk: current clock source
+ * @source:array index of parent clock source
+ */
+static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
+{
+ int ret;
+ struct dmtimer_platform_data *pdata = pdev-dev.platform_data;
+ struct clk *fclk = clk_get(pdev-dev, fck);
+ struct clk *new_fclk;
+ char *fclk_name = 32k_ck; /* default name */
+
+ switch (source) {
+ case OMAP_TIMER_SRC_SYS_CLK:
+ fclk_name = sys_ck;
+ break;
+
+ case OMAP_TIMER_SRC_32_KHZ:
+ fclk_name = 32k_ck;
+ break;
+
+ case OMAP_TIMER_SRC_EXT_CLK:
+ if (pdata-timer_ip_type == OMAP_TIMER_IP_VERSION_1) {
+ fclk_name = alt_ck;
+ break;
+ }
+ dev_err(pdev-dev, %s: %d: invalid clk src.\n,
+ __func__, __LINE__);
+ return -EINVAL;
+ }
+
+ if (IS_ERR_OR_NULL(fclk)) {
+ dev_err(pdev-dev, %s: %d: clk_get() FAILED\n,
+ __func__, __LINE__);
+ return -EINVAL;
+ }
+
+ new_fclk = clk_get(pdev-dev, fclk_name);
+ if (IS_ERR_OR_NULL(new_fclk)) {
+ dev_err(pdev-dev, %s: %d: clk_get() %s FAILED\n,
+ __func__, __LINE__, fclk_name);
+ clk_put(fclk);
+ return -EINVAL;
+ }
+
+ ret = clk_set_parent(fclk, new_fclk);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(pdev-dev, %s: clk_set_parent() to %s FAILED\n,
+ __func__, fclk_name);
+ ret = -EINVAL;
+ }
+
+ clk_put(new_fclk);
+ clk_put(fclk);
+
+ return ret;
+}
+
+struct omap_device_pm_latency omap2_dmtimer_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags =
[PATCH v11 5/8] OMAP: dmtimer: platform driver
From: Thara Gopinath th...@ti.com
Add dmtimer platform driver functions which include:
(1) platform driver initialization
(2) driver probe function
(3) driver remove function
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 167 -
arch/arm/plat-omap/include/plat/dmtimer.h |2 +
2 files changed, 168 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 1bfaf09..bfe6fd3 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -43,6 +43,9 @@
#include linux/delay.h
#include linux/io.h
#include linux/module.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/platform_device.h
#include mach/hardware.h
#include plat/dmtimer.h
#include mach/irqs.h
@@ -257,7 +260,8 @@ static struct omap_dm_timer *dm_timers;
static const char **dm_source_names;
static struct clk **dm_source_clocks;
-static spinlock_t dm_timer_lock;
+static LIST_HEAD(omap_timer_list);
+static DEFINE_SPINLOCK(dm_timer_lock);
/*
* Reads timer registers in posted and non-posted mode. The posted mode bit
@@ -689,6 +693,167 @@ int omap_dm_timers_active(void)
}
EXPORT_SYMBOL_GPL(omap_dm_timers_active);
+/**
+ * omap_dm_timer_probe - probe function called for every registered device
+ * @pdev: pointer to current timer platform device
+ *
+ * Called by driver framework at the end of device registration for all
+ * timer devices.
+ */
+static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
+{
+ int ret;
+ unsigned long flags;
+ struct omap_dm_timer *timer;
+ struct resource *mem, *irq, *ioarea;
+ struct dmtimer_platform_data *pdata = pdev-dev.platform_data;
+
+ if (!pdata) {
+ dev_err(pdev-dev, %s: no platform data\n, __func__);
+ return -ENODEV;
+ }
+
+ spin_lock_irqsave(dm_timer_lock, flags);
+ list_for_each_entry(timer, omap_timer_list, node)
+ if (!pdata-is_early_init timer-id == pdev-id) {
+ timer-pdev = pdev;
+ spin_unlock_irqrestore(dm_timer_lock, flags);
+ dev_dbg(pdev-dev, Regular Probed\n);
+ return 0;
+ }
+ spin_unlock_irqrestore(dm_timer_lock, flags);
+
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (unlikely(!irq)) {
+ dev_err(pdev-dev, %s: no IRQ resource\n, __func__);
+ ret = -ENODEV;
+ goto err_free_pdev;
+ }
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (unlikely(!mem)) {
+ dev_err(pdev-dev, %s: no memory resource\n, __func__);
+ ret = -ENODEV;
+ goto err_free_pdev;
+ }
+
+ ioarea = request_mem_region(mem-start, resource_size(mem),
+ pdev-name);
+ if (!ioarea) {
+ dev_err(pdev-dev, %s: region already claimed\n, __func__);
+ ret = -EBUSY;
+ goto err_free_pdev;
+ }
+
+ timer = kzalloc(sizeof(struct omap_dm_timer), GFP_KERNEL);
+ if (!timer) {
+ dev_err(pdev-dev, %s: no memory for omap_dm_timer\n,
+ __func__);
+ ret = -ENOMEM;
+ goto err_release_ioregion;
+ }
+
+ timer-io_base = ioremap(mem-start, resource_size(mem));
+ if (!timer-io_base) {
+ dev_err(pdev-dev, %s: ioremap failed\n, __func__);
+ ret = -ENOMEM;
+ goto err_free_mem;
+ }
+
+ /*
+* Following func pointers are required by OMAP1's reset code
+* in mach-omap1/dmtimer.c to access to low level read/write.
+*/
+ if (pdata-is_omap16xx) {
+ pdata-dm_timer_read_reg = omap_dm_timer_read_reg;
+ pdata-dm_timer_write_reg = omap_dm_timer_write_reg;
+ pdata-is_early_init = 0;
+ }
+
+ timer-id = pdev-id;
+ timer-irq = irq-start;
+ timer-pdev = pdev;
+ timer-reserved = 0;
+
+ /* add the timer element to the list */
+ spin_lock_irqsave(dm_timer_lock, flags);
+ list_add_tail(timer-node, omap_timer_list);
+ spin_unlock_irqrestore(dm_timer_lock, flags);
+
+ dev_dbg(pdev-dev, Early Probed\n);
+
+ return 0;
+
+err_free_mem:
+ kfree(timer);
+
+err_release_ioregion:
+ release_mem_region(mem-start, resource_size(mem));
+
+err_free_pdev:
+ kfree(pdata);
+ platform_device_unregister(pdev);
+
+ return ret;
+}
+
+/**
+ * omap_dm_timer_remove - cleanup a registered timer device
+ * @pdev: pointer to current timer platform device
+ *
+ * Called by driver framework whenever a timer device is unregistered.
+ * In addition to freeing platform resources it also deletes the
[PATCH v11 3/8] OMAP1: dmtimer: conversion to platform devices
From: Thara Gopinath th...@ti.com
Convert OMAP1 dmtimers into a platform devices and then registers with
device model framework so that it can be bound to corresponding driver.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/dmtimer.c | 214 +
arch/arm/mach-omap1/timer32k.c|4 -
arch/arm/plat-omap/dmtimer.c | 64 +
arch/arm/plat-omap/include/plat/dmtimer.h | 24 +++-
5 files changed, 246 insertions(+), 62 deletions(-)
create mode 100644 arch/arm/mach-omap1/dmtimer.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index af98117..a0ae35f 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := io.o id.o sram.o time.o irq.o mux.o flash.o serial.o devices.o dma.o
-obj-y += clock.o clock_data.o opp_data.o reset.o
+obj-y += clock.o clock_data.o opp_data.o reset.o dmtimer.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/dmtimer.c b/arch/arm/mach-omap1/dmtimer.c
new file mode 100644
index 000..d1e17fe
--- /dev/null
+++ b/arch/arm/mach-omap1/dmtimer.c
@@ -0,0 +1,214 @@
+/**
+ * OMAP1 Dual-Mode Timers - platform device registration
+ *
+ * Contains first level initialization routines which internally
+ * generates timer device information and registers with linux
+ * device model. It also has low level function to chnage the timer
+ * input clock source.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * Thara Gopinath th...@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 as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/platform_device.h
+
+#include mach/irqs.h
+
+#include plat/dmtimer.h
+
+#define OMAP1610_GPTIMER1_BASE 0xfffb1400
+#define OMAP1610_GPTIMER2_BASE 0xfffb1c00
+#define OMAP1610_GPTIMER3_BASE 0xfffb2400
+#define OMAP1610_GPTIMER4_BASE 0xfffb2c00
+#define OMAP1610_GPTIMER5_BASE 0xfffb3400
+#define OMAP1610_GPTIMER6_BASE 0xfffb3c00
+#define OMAP1610_GPTIMER7_BASE 0xfffb7400
+#define OMAP1610_GPTIMER8_BASE 0xfffbd400
+
+#define OMAP1_DM_TIMER_COUNT 8
+
+#define OMAP_TIMER_OCP_CFG_REG 0x10
+#define OMAP_TIMER_SYS_STAT_REG0x14
+#define OMAP_TIMER_IF_CTRL_REG 0x40
+
+static int omap1_dm_timer_set_src(struct platform_device *pdev,
+ int source)
+{
+ int n = (pdev-id - 1) 1;
+ u32 l;
+
+ l = omap_readl(MOD_CONF_CTRL_1) ~(0x03 n);
+ l |= source n;
+ omap_writel(l, MOD_CONF_CTRL_1);
+
+ return 0;
+}
+
+static void omap1_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
+{
+ int c;
+ struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+
+ c = 0;
+ while (!(pdata-dm_timer_read_reg(timer, OMAP_TIMER_SYS_STAT_REG) 1))
{
+ c++;
+ if (c 10) {
+ printk(KERN_ERR Timer failed to reset.\n);
+ return;
+ }
+ }
+}
+
+static void omap1_dm_timer_reset(struct omap_dm_timer *timer)
+{
+ u32 l;
+ struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+
+ if (timer-pdev-id != 1) {
+ pdata-dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+ omap1_dm_timer_wait_for_reset(timer);
+ }
+
+ l = pdata-dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG);
+ l |= 0x02 3; /* Set to smart-idle mode */
+ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */
+ pdata-dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_REG, l);
+}
+
+int __init omap1_dm_timer_init(void)
+{
+ int i;
+ int ret;
+ struct dmtimer_platform_data *pdata;
+ struct platform_device *pdev;
+
+ if (!cpu_is_omap16xx())
+ return 0;
+
+ for (i = 1; i = OMAP1_DM_TIMER_COUNT; i++) {
+ struct resource res[2];
+ u32 base, irq;
+
+ switch (i) {
+ case 1:
+ base = OMAP1610_GPTIMER1_BASE;
+ irq = INT_1610_GPTIMER1;
+ break;
+ case 2:
+ base =
[PATCH v11 2/8] OMAP4: hwmod data: add dmtimer version information
OMAP4 has two groups of timers: version 1 timers are 1, 2, 10,
while the rest of the timers, 3-9, 11 are version 2 timers.
The version information is required by the driver so that they
could be handled correctly by it.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +++
arch/arm/plat-omap/include/plat/dmtimer.h |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..ee57742 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
#include plat/gpio.h
#include plat/dma.h
#include plat/mcspi.h
+#include plat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -3940,6 +3941,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_timer_1ms_sysc = {
static struct omap_hwmod_class omap44xx_timer_1ms_hwmod_class = {
.name = timer,
.sysc = omap44xx_timer_1ms_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
};
static struct omap_hwmod_class_sysconfig omap44xx_timer_sysc = {
@@ -3955,6 +3957,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_timer_sysc = {
static struct omap_hwmod_class omap44xx_timer_hwmod_class = {
.name = timer,
.sysc = omap44xx_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_2,
};
/* timer1 */
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index d6c70d2..05a967e 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,8 @@
* in OMAP4 can be distinguished.
*/
#define OMAP_TIMER_IP_VERSION_10x1
+#define OMAP_TIMER_IP_VERSION_20x2
+
struct omap_dm_timer;
extern struct omap_dm_timer *gptimer_wakeup;
extern struct sys_timer omap_timer;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 6/8] dmtimer: switch-over to platform device driver
switch-over to platform device driver through following changes:
(a) initiate dmtimer early initialization from omap2_gp_timer_init()
in timer-gp.c. This is equivalent of timer_init()-timer-init().
(b) modify plat-omap/dmtimer routines to use new register map and
platform data.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/clock44xx_data.c |2 +-
arch/arm/mach-omap2/dmtimer.c | 61 +
arch/arm/mach-omap2/dmtimer.h | 30 +++
arch/arm/mach-omap2/timer-gp.c|4 +-
arch/arm/plat-omap/dmtimer.c | 350 -
arch/arm/plat-omap/include/plat/dmtimer.h |5 +-
9 files changed, 190 insertions(+), 268 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.h
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index ee93d3c..390d6aa 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1801,7 +1801,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, virt_prcm_set, virt_prcm_set, CK_242X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL, gpt1_ick, gpt1_ick, CK_242X),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_242X),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_242X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_242X),
CLK(omap_timer.2, fck, gpt2_fck, CK_242X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 24553ce..7a3e5a4 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1905,7 +1905,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, virt_prcm_set, virt_prcm_set, CK_243X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL, gpt1_ick, gpt1_ick, CK_243X),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_243X),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_243X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_243X),
CLK(omap_timer.2, fck, gpt2_fck, CK_243X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 6a17982..506f59d 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3374,7 +3374,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(ehci-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
CLK(NULL, gpio1_dbck, gpio1_dbck,CK_3XXX),
CLK(omap_wdt, fck, wdt2_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 11997a3..8f8b010 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3181,7 +3181,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, smartreflex_core_fck, smartreflex_core_fck,
CK_443X),
CLK(NULL, smartreflex_iva_fck, smartreflex_iva_fck,
CK_443X),
CLK(NULL, smartreflex_mpu_fck, smartreflex_mpu_fck,
CK_443X),
- CLK(NULL, gpt1_fck, timer1_fck,
CK_443X),
+ CLK(omap_timer.1, fck, timer1_fck,
CK_443X),
CLK(omap_timer.10,fck, timer10_fck,
CK_443X),
CLK(omap_timer.11,fck, timer11_fck,
CK_443X),
CLK(omap_timer.2, fck, timer2_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
index 00cebe9..63d5ae7 100644
--- a/arch/arm/mach-omap2/dmtimer.c
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -197,3 +197,64 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
return ret;
}
+
+/**
+ * omap2_dm_timer_early_init - top level early timer initialization
+ * called in the last part of omap2_init_common_hw
+ *
+ * Uses dedicated hwmod api to parse through hwmod database for
+ * given class name and then build and register the timer device.
+ * At the end driver is registered and early probe initiated.
+ */
+void __init
Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
On Thu, Feb 24, 2011 at 10:35 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Feb 23, 2011 at 10:09:05PM +0200, Sakari Ailus wrote: In OMAP4 the cortex M3 is a double core processor and as each core is running they own version of the RTOS we threat them independently. So our driver which controls the remote processor sees two processor but both use the same iommu hw. When a iommu fault happens, at this moment, it is consider as a faltal error and it is no managed to recover and continue, instead a restart of the processor is needed, if the fault happens in core0 we need to reset core1 too and vice versa. if the iommu would support several user callbacks, we can register the callback which resets core0 and also the callback which resets core1 and treat them as totally independent processors. Also we have an error event notifier driver, which is only in charge of notifying error events to userspace, so we would have multiple callbacks we could do this The original purpose of the patch, as far as I understand, is to allow getting useful information for debugging purposes should an iommu fault happen. Also, I'm not sure it's necessarily a good idea to just go and reset the M3 cores in case an iommu fault happens --- this is very probably a grave bug in the software running on those M3s. It should be fixed instead of just hiding it. There will be consequences to host side as I have to agree here. Besides the fact that multiple callbacks is outside the scope of this patch. This patch is already acked. What about leave it as it is and discuss multiple callbacks before release a new patch to support it? Br, David -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
On Thu, Feb 24, 2011 at 01:26:05PM +0200, David Cohen wrote: On Thu, Feb 24, 2011 at 10:35 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Feb 23, 2011 at 10:09:05PM +0200, Sakari Ailus wrote: In OMAP4 the cortex M3 is a double core processor and as each core is running they own version of the RTOS we threat them independently. So our driver which controls the remote processor sees two processor but both use the same iommu hw. When a iommu fault happens, at this moment, it is consider as a faltal error and it is no managed to recover and continue, instead a restart of the processor is needed, if the fault happens in core0 we need to reset core1 too and vice versa. if the iommu would support several user callbacks, we can register the callback which resets core0 and also the callback which resets core1 and treat them as totally independent processors. Also we have an error event notifier driver, which is only in charge of notifying error events to userspace, so we would have multiple callbacks we could do this The original purpose of the patch, as far as I understand, is to allow getting useful information for debugging purposes should an iommu fault happen. Also, I'm not sure it's necessarily a good idea to just go and reset the M3 cores in case an iommu fault happens --- this is very probably a grave bug in the software running on those M3s. It should be fixed instead of just hiding it. There will be consequences to host side as I have to agree here. Besides the fact that multiple callbacks is outside the scope of this patch. This patch is already acked. What about leave it as it is and discuss multiple callbacks before release a new patch to support it? fine by me ;-) -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap dss tft display connection
On Thu, 2011-02-24 at 04:56 -0600, Belisko Marek wrote: Hi Toomi, On Thu, Feb 24, 2011 at 11:39 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2011-02-24 at 04:05 -0600, Belisko Marek wrote: Hello, would be possible to configure dss on omap3530 which is connected to 18bit TFT display in such way: 8 88 | | | | | | | |-| | | | | | | |-| | | | | | | | 6 6 6 | | | | | |-| | | | | |-| | | | | | So no standard connection (2 bits in every color are skipped) but it's shifted so last 6 bits remain unused. When use generic panel it seems I have no red color (just combination of blue and green). It is anyway possible to drive such a connection? Or HW needs to ne changed? Can you explain a bit more what you are trying to do? At least I didn't quite understand =). Sorry maybe my question wasn't clear ;). I have mini8100 board connected to 18bit hitachi TX18D35 connected in way I described in first email (LCD datalines connected to lower 18 bits dss data lines). So my question was what to change (only .phy.dpi.data_lines = 18 is enought?) to keep driving my display correctly ;) I try that option but no visible change. Yes, changing the data_lines should be enough. Are you sure you changed the correct board file? =) The highest bits are used for the red color, so if you get no red, it sounds to me like OMAP is trying to use 24bit output. Another thing that comes to my mind is pin-muxing. The DSS pins have to be muxed in mode0. But most likely they already are, if you get an image on the LCD. Tomi -- 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 5/5] OMAP: adapt hsmmc to hwmod framework
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
Changes involves:
1) Remove controller reset in devices.c which is taken care of
by hwmod framework.
2) Removing all base address macro defines except keeping one for OMAP2420.
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute.
Signed-off-by: Paul Walmsleyp...@pwsan.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
CC: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c | 251 -
arch/arm/mach-omap2/hsmmc.c | 153 ++--
arch/arm/plat-omap/include/plat/mmc.h | 14 --
3 files changed, 141 insertions(+), 277 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7b35c87..2d2deb6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -503,112 +503,6 @@ static inline void omap_init_aes(void) { }
/*-*/
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-#define MMCHS_SYSCONFIG0x0010
-#define MMCHS_SYSCONFIG_SWRESET(1 1)
-#define MMCHS_SYSSTATUS0x0014
-#define MMCHS_SYSSTATUS_RESETDONE (1 0)
-
-static struct platform_device dummy_pdev = {
- .dev = {
- .bus =platform_bus_type,
- },
-};
-
-/**
- * omap_hsmmc_reset() - Full reset of each HS-MMC controller
- *
- * Ensure that each MMC controller is fully reset. Controllers
- * left in an unknown state (by bootloader) may prevent retention
- * or OFF-mode. This is especially important in cases where the
- * MMC driver is not enabled, _or_ built as a module.
- *
- * In order for reset to work, interface, functional and debounce
- * clocks must be enabled. The debounce clock comes from func_32k_clk
- * and is not under SW control, so we only enable i- and f-clocks.
- **/
-static void __init omap_hsmmc_reset(void)
-{
- u32 i, nr_controllers;
- struct clk *iclk, *fclk;
-
- if (cpu_is_omap242x())
- return;
-
- nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
- (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
-
- for (i = 0; i nr_controllers; i++) {
- u32 v, base = 0;
- struct device *dev =dummy_pdev.dev;
-
- switch (i) {
- case 0:
- base = OMAP2_MMC1_BASE;
- break;
- case 1:
- base = OMAP2_MMC2_BASE;
- break;
- case 2:
- base = OMAP3_MMC3_BASE;
- break;
- case 3:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC4_BASE;
- break;
- case 4:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC5_BASE;
- break;
- }
-
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
- dummy_pdev.id = i;
- dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
- iclk = clk_get(dev, ick);
- if (IS_ERR(iclk))
- goto err1;
- if (clk_enable(iclk))
- goto err2;
-
- fclk = clk_get(dev, fck);
- if (IS_ERR(fclk))
- goto err3;
- if (clk_enable(fclk))
- goto err4;
-
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS)
-MMCHS_SYSSTATUS_RESETDONE))
- cpu_relax();
-
- clk_disable(fclk);
- clk_put(fclk);
- clk_disable(iclk);
- clk_put(iclk);
- }
- return;
-
-err4:
- clk_put(fclk);
-err3:
- clk_disable(iclk);
-err2:
- clk_put(iclk);
-err1:
- printk(KERN_WARNING %s: Unable to enable clocks for MMC%d,
- cannot reset.\n, __func__, i);
-}
-#else
-static inline void omap_hsmmc_reset(void) {}
-#endif
-
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
static inline void omap242x_mmc_mux(struct omap_mmc_platform_data
@@ -665,150 +559,6 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#endif
-#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
-
-static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
-
RE: [PATCH 0/3] OMAP2+: voltage: first pass at cleanup/reorganization
Hi Paul,
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org
[mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf
Of Paul Walmsley
Sent: Monday, February 21, 2011 7:39 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: khil...@ti.com; n...@ti.com; b-cous...@ti.com; mturque...@ti.com
Subject: [PATCH 0/3] OMAP2+: voltage: first pass at
cleanup/reorganization
Hello,
this patch set does an initial round of cleanup on the OMAP voltage
code
in arch/arm/mach-omap2/voltage.c. As part of this process, the header
files
for the voltage code and SmartReflex are moved into arch/arm/mach-omap2,
since
they are currently OMAP2+-specific.
There is still quite a bit of cleanup left to do; hopefully someone else
will
get to it before I do. More details are in the last patch.
This series was built-tested for an OSK5912-specific config,
omap1_defconfig,
a N800-specific config, omap2plus_defconfig, an OMAP3-specific config,
and
an OMAP4-specific config. It was boot-tested on an OMAP35xx
Beagleboard.
Further testing assistance is, of course, appreciated.
I found these abort on my 4430SDP. The below changes I found
are needed for it to bootup..
I tested the 'integration-2.6.39' branch of
git://git.pwsan.com/linux-integration and the patch is
based on this branch.
---
From e3d5e2bb09ecb7a958c1f79b86d1917f0becb8d2 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 24 Feb 2011 16:42:25 +0530
Subject: [PATCH] OMAP4: voltage: Populate missing .vp/.vc_common pointers
The common_data for vp and vc on OMAP4 is defined
but not hooked up with the corresponding
vp/vc_data.
This causes an abort at bootup on OMAP4, as the
framework api's assumes these to be present.
While here, also rename omap4_vp_data to
omap4_vp_common and omap4_vc_data to
omap4_vc_common to maintain consistency in
naming structs across all OMAPs.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/vc44xx_data.c |5 -
arch/arm/mach-omap2/vp44xx_data.c |5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/vc44xx_data.c
b/arch/arm/mach-omap2/vc44xx_data.c
index 548cb06..a98da8d 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -30,7 +30,7 @@
* VC data common to 44xx chips
* XXX This stuff presumably belongs in the vc3xxx.c or vc.c file.
*/
-static const struct omap_vc_common_data omap4_vc_data = {
+static const struct omap_vc_common_data omap4_vc_common = {
.smps_sa_reg = OMAP4_PRM_VC_SMPS_SA_OFFSET,
.smps_volra_reg = OMAP4_PRM_VC_VAL_SMPS_RA_VOL_OFFSET,
.bypass_val_reg = OMAP4_PRM_VC_VAL_BYPASS_OFFSET,
@@ -47,6 +47,7 @@ static const struct omap_vc_common_data omap4_vc_data =
{
/* VC instance data for each controllable voltage line */
struct omap_vc_instance_data omap4_vc_mpu_data = {
+ .vc_common = omap4_vc_common,
.cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_MPU_L_OFFSET,
.smps_sa_shift = OMAP4430_SA_VDD_MPU_L_PRM_VC_SMPS_SA_SHIFT,
.smps_sa_mask = OMAP4430_SA_VDD_MPU_L_PRM_VC_SMPS_SA_MASK,
@@ -55,6 +56,7 @@ struct omap_vc_instance_data omap4_vc_mpu_data = {
};
struct omap_vc_instance_data omap4_vc_iva_data = {
+ .vc_common = omap4_vc_common,
.cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_IVA_L_OFFSET,
.smps_sa_shift = OMAP4430_SA_VDD_IVA_L_PRM_VC_SMPS_SA_SHIFT,
.smps_sa_mask = OMAP4430_SA_VDD_IVA_L_PRM_VC_SMPS_SA_MASK,
@@ -63,6 +65,7 @@ struct omap_vc_instance_data omap4_vc_iva_data = {
};
struct omap_vc_instance_data omap4_vc_core_data = {
+ .vc_common = omap4_vc_common,
.cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_CORE_L_OFFSET,
.smps_sa_shift = OMAP4430_SA_VDD_CORE_L_0_6_SHIFT,
.smps_sa_mask = OMAP4430_SA_VDD_CORE_L_0_6_MASK,
diff --git a/arch/arm/mach-omap2/vp44xx_data.c
b/arch/arm/mach-omap2/vp44xx_data.c
index 7b26f75..65d1ad6 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -31,7 +31,7 @@
* VP data common to 44xx chips
* XXX This stuff presumably belongs in the vp44xx.c or vp.c file.
*/
-static const struct omap_vp_common_data omap4_vp_data = {
+static const struct omap_vp_common_data omap4_vp_common = {
.vpconfig_erroroffset_shift = OMAP4430_ERROROFFSET_SHIFT,
.vpconfig_errorgain_mask = OMAP4430_ERRORGAIN_MASK,
.vpconfig_errorgain_shift = OMAP4430_ERRORGAIN_SHIFT,
@@ -56,6 +56,7 @@ static const struct omap_vp_prm_irqst_data
omap4_vp_mpu_prm_irqst_data = {
};
struct omap_vp_instance_data omap4_vp_mpu_data = {
+ .vp_common = omap4_vp_common,
.vpconfig = OMAP4_PRM_VP_MPU_CONFIG_OFFSET,
.vstepmin = OMAP4_PRM_VP_MPU_VSTEPMIN_OFFSET,
.vstepmax = OMAP4_PRM_VP_MPU_VSTEPMAX_OFFSET,
@@ -71,6 +72,7 @@ static const struct omap_vp_prm_irqst_data
omap4_vp_iva_prm_irqst_data = {
};
struct omap_vp_instance_data omap4_vp_iva_data = {
+ .vp_common
[PATCH] ldp: Fix regulator mapping for ads7846 TS controller
On the OMAP3430LDP board, the ads7846 touchscreen controller
is powered by VAUX1 regulator (supplying 3.0v).
Fix this mapping in the board file, and hence prevent
the ads7846 driver init to fail with the below error..
ads7846 spi1.0: unable to get regulator: -19
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-ldp.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index a3fae56..9a99cad 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -329,6 +329,26 @@ static struct regulator_init_data ldp_vmmc1 = {
.consumer_supplies = ldp_vmmc1_supply,
};
+/* ads7846 on SPI */
+static struct regulator_consumer_supply ldp_vaux1_supplies[] = {
+ REGULATOR_SUPPLY(vcc, spi1.0),
+};
+
+/* VAUX1 */
+static struct regulator_init_data ldp_vaux1 = {
+ .constraints = {
+ .min_uV = 300,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(ldp_vaux1_supplies),
+ .consumer_supplies = ldp_vaux1_supplies,
+};
+
static struct twl4030_platform_data ldp_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -337,6 +357,7 @@ static struct twl4030_platform_data ldp_twldata = {
.madc = ldp_madc_data,
.usb= ldp_usb_data,
.vmmc1 = ldp_vmmc1,
+ .vaux1 = ldp_vaux1,
.gpio = ldp_gpio_data,
.keypad = ldp_kp_twl4030_data,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: State of LDP3430 platform
-Original Message- From: Rajendra Nayak [mailto:rna...@ti.com] Sent: Thursday, February 24, 2011 12:39 PM To: Richard Woodruff; Tony Lindgren; Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Paul Walmsley; Santosh Shilimkar Subject: RE: State of LDP3430 platform -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Woodruff, Richard Sent: Thursday, February 24, 2011 4:53 AM To: Tony Lindgren; Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Paul Walmsley; Shilimkar, Santosh Subject: RE: State of LDP3430 platform From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, February 23, 2011 4:50 PM Anybody from TI looking into these? I'll poke some folks and check. I've not booted my LDP for a while. There was a regulator mapping issue on 3430SDP because of which tocuhscreen was broken and is now fixed with this patch http://marc.info/?l=linux-arm-kernelm=129673276608954w=2 Looks like the same issue on LDP. Will check it up. This one should now have LDP TS working.. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg45306.html Regards, Rajendra As an older 3430 dev board its lost its shine compared to 3630 and 4430 dev boards. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
-Original Message-
From: Menon, Nishanth
Sent: Thursday, February 24, 2011 12:14 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi pr...@ti.com wrote:
Add glue logic to hook-up AM35x processors
with TPS65023.
Signed-off-by: Sanjeev Premi pr...@ti.com
[...]
+/**
+ * TBD: Just a copy of OMAP3 PMIC info.
+ * Many fields below don't make much sense for AM3517,
+ * but keeping them as is for now.
+ */
+static struct omap_volt_pmic_info am3517_volt_info = {
+ .slew_rate = 4000,
+ .step_size = 25000,
+ .on_volt = 120,
+ .onlp_volt = 100,
+ .ret_volt = 975000,
+ .off_volt = 60,
+ .volt_setup_time = 0xfff,
+ .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
+ .vp_vstepmin = OMAP3_VP_VSTEPMIN_VSTEPMIN,
+ .vp_vstepmax = OMAP3_VP_VSTEPMAX_VSTEPMAX,
+ .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
+ .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
+ .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
+ .pmic_reg = OMAP3_VDD_CORE_SR_CONTROL_REG,
+ .vsel_to_uv = tps65023_vsel_to_uv,
+ .uv_to_vsel = tps65023_uv_to_vsel,
+};
I see your point in http://marc.info/?l=linux-omapm=129847126805656w=2
Check the definition of omap_volt_pmic_info and omap_volt_data.
Just to hack support we can fill *don't care* values for the
fields not supported and wrap processing under if (cpu_is_())
checks; but this doesn't appear to be a good solution
PMIC specific data:
+ .slew_rate = 4000,
+ .step_size = 25000,
SoC specific data + PMIC limits:
+ .on_volt= 120,
+ .onlp_volt = 100,
+ .ret_volt = 975000,
+ .off_volt = 60,
I dont like the following at all!
+ .volt_setup_time= 0xfff,
SOC specific
+ .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
+ .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
+ .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
+ .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
+ .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
PMIC speciic
+ .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
+ .pmic_reg = OMAP3_VDD_CORE_SR_CONTROL_REG,
+ .vsel_to_uv = tps65023_vsel_to_uv,
+ .uv_to_vsel = tps65023_uv_to_vsel,
Yeah they ought to be split properly IMHO.
[sp] Gr8. Good abstraction of PMIC functions and SoC functions
related to VC/PC would be necessary. More importantly
keeping the interfaces pluggable for different PMICs.
~sanjeev
--
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/4] OMAP: DSS2: Clean up a switch-case
Support for the display interface was checked in a separate switch-case.
There's no reason for that, and this patch handles the fail code path in
the same switch-case where the display initialization is done.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/display.c | 27 +++
1 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 22dd7a4..3f4fa0b 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -396,29 +396,6 @@ void dss_init_device(struct platform_device *pdev,
switch (dssdev-type) {
#ifdef CONFIG_OMAP2_DSS_DPI
case OMAP_DISPLAY_TYPE_DPI:
-#endif
-#ifdef CONFIG_OMAP2_DSS_RFBI
- case OMAP_DISPLAY_TYPE_DBI:
-#endif
-#ifdef CONFIG_OMAP2_DSS_SDI
- case OMAP_DISPLAY_TYPE_SDI:
-#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
- case OMAP_DISPLAY_TYPE_DSI:
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
- case OMAP_DISPLAY_TYPE_VENC:
-#endif
- break;
- default:
- DSSERR(Support for display '%s' not compiled in.\n,
- dssdev-name);
- return;
- }
-
- switch (dssdev-type) {
-#ifdef CONFIG_OMAP2_DSS_DPI
- case OMAP_DISPLAY_TYPE_DPI:
r = dpi_init_display(dssdev);
break;
#endif
@@ -443,7 +420,9 @@ void dss_init_device(struct platform_device *pdev,
break;
#endif
default:
- BUG();
+ DSSERR(Support for display '%s' not compiled in.\n,
+ dssdev-name);
+ return;
}
if (r) {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] OMAP: DSS2: FEATURES: Remove SDI from 3630 displays
OMAP 3630 does not support SDI. Split omap3_dss_supported_displays into
3430 and 3630 entries, and remove the SDI from 3630 entry.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss_features.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index cf3ef69..f4367f6 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -73,7 +73,7 @@ static const enum omap_display_type
omap2_dss_supported_displays[] = {
OMAP_DISPLAY_TYPE_VENC,
};
-static const enum omap_display_type omap3_dss_supported_displays[] = {
+static const enum omap_display_type omap3430_dss_supported_displays[] = {
/* OMAP_DSS_CHANNEL_LCD */
OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
@@ -82,6 +82,15 @@ static const enum omap_display_type
omap3_dss_supported_displays[] = {
OMAP_DISPLAY_TYPE_VENC,
};
+static const enum omap_display_type omap3630_dss_supported_displays[] = {
+ /* OMAP_DSS_CHANNEL_LCD */
+ OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
+ OMAP_DISPLAY_TYPE_DSI,
+
+ /* OMAP_DSS_CHANNEL_DIGIT */
+ OMAP_DISPLAY_TYPE_VENC,
+};
+
static const enum omap_display_type omap4_dss_supported_displays[] = {
/* OMAP_DSS_CHANNEL_LCD */
OMAP_DISPLAY_TYPE_DBI | OMAP_DISPLAY_TYPE_DSI,
@@ -161,7 +170,7 @@ static struct omap_dss_features omap3430_dss_features = {
.num_mgrs = 2,
.num_ovls = 3,
- .supported_displays = omap3_dss_supported_displays,
+ .supported_displays = omap3430_dss_supported_displays,
.supported_color_modes = omap3_dss_supported_color_modes,
};
@@ -176,7 +185,7 @@ static struct omap_dss_features omap3630_dss_features = {
.num_mgrs = 2,
.num_ovls = 3,
- .supported_displays = omap3_dss_supported_displays,
+ .supported_displays = omap3630_dss_supported_displays,
.supported_color_modes = omap3_dss_supported_color_modes,
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] OMAP: DSS2: FEATURES: Remove DSI SDI from OMAP2
OMAP2 doesn't support SDI or DSI. Remove them from
omap2_dss_supported_displays.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss_features.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index f4367f6..fe22d11 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -66,8 +66,7 @@ static const struct dss_reg_field omap3_dss_reg_fields[] = {
static const enum omap_display_type omap2_dss_supported_displays[] = {
/* OMAP_DSS_CHANNEL_LCD */
- OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
- OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
+ OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI,
/* OMAP_DSS_CHANNEL_DIGIT */
OMAP_DISPLAY_TYPE_VENC,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] OMAP: DSS2: Check for SDI HW before accessing SDI registers
Only OMAP 3430 hardware has SDI support. The availability of SDI HW can
be found out by checking if the LCD channel supports SDI displays.
This patch checks for SDI HW support before accessing SDI registers,
which fixes a crash on OMAP4 when SDI SW support is compiled in.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/display.c | 10 ++
drivers/video/omap2/dss/dss.c | 29 ++---
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 3f4fa0b..58459f4 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -30,6 +30,7 @@
#include plat/display.h
#include dss.h
+#include dss_features.h
static LIST_HEAD(display_list);
@@ -392,6 +393,15 @@ void dss_init_device(struct platform_device *pdev,
struct device_attribute *attr;
int i;
int r;
+ enum omap_display_type supported;
+
+ supported = dss_feat_get_supported_displays(dssdev-channel);
+
+ if (!(supported dssdev-type)) {
+ DSSERR(Unsupported display interface for display '%s'.\n,
+ dssdev-name);
+ return;
+ }
switch (dssdev-type) {
#ifdef CONFIG_OMAP2_DSS_DPI
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 5a93e66..b3e9dd1 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -32,6 +32,7 @@
#include plat/display.h
#include plat/clock.h
#include dss.h
+#include dss_features.h
#define DSS_SZ_REGSSZ_512
@@ -110,10 +111,11 @@ void dss_save_context(void)
SR(SYSCONFIG);
SR(CONTROL);
-#ifdef CONFIG_OMAP2_DSS_SDI
- SR(SDI_CONTROL);
- SR(PLL_CONTROL);
-#endif
+ if (dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_LCD)
+ OMAP_DISPLAY_TYPE_SDI) {
+ SR(SDI_CONTROL);
+ SR(PLL_CONTROL);
+ }
}
void dss_restore_context(void)
@@ -124,10 +126,11 @@ void dss_restore_context(void)
RR(SYSCONFIG);
RR(CONTROL);
-#ifdef CONFIG_OMAP2_DSS_SDI
- RR(SDI_CONTROL);
- RR(PLL_CONTROL);
-#endif
+ if (dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_LCD)
+ OMAP_DISPLAY_TYPE_SDI) {
+ RR(SDI_CONTROL);
+ RR(PLL_CONTROL);
+ }
}
#undef SR
@@ -259,9 +262,13 @@ void dss_dump_regs(struct seq_file *s)
DUMPREG(DSS_SYSSTATUS);
DUMPREG(DSS_IRQSTATUS);
DUMPREG(DSS_CONTROL);
- DUMPREG(DSS_SDI_CONTROL);
- DUMPREG(DSS_PLL_CONTROL);
- DUMPREG(DSS_SDI_STATUS);
+
+ if (dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_LCD)
+ OMAP_DISPLAY_TYPE_SDI) {
+ DUMPREG(DSS_SDI_CONTROL);
+ DUMPREG(DSS_PLL_CONTROL);
+ DUMPREG(DSS_SDI_STATUS);
+ }
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
#undef DUMPREG
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] OMAP: adapt hsmmc to hwmod framework
On Thu, Feb 24, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
Changes involves:
1) Remove controller reset in devices.c which is taken care of
by hwmod framework.
2) Removing all base address macro defines except keeping one for
OMAP2420.
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute.
Signed-off-by: Paul Walmsleyp...@pwsan.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
CC: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c | 251
-
arch/arm/mach-omap2/hsmmc.c | 153 ++--
arch/arm/plat-omap/include/plat/mmc.h | 14 --
3 files changed, 141 insertions(+), 277 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7b35c87..2d2deb6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -503,112 +503,6 @@ static inline void omap_init_aes(void) { }
/*-*/
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-#define MMCHS_SYSCONFIG 0x0010
-#define MMCHS_SYSCONFIG_SWRESET (1 1)
-#define MMCHS_SYSSTATUS 0x0014
-#define MMCHS_SYSSTATUS_RESETDONE (1 0)
-
-static struct platform_device dummy_pdev = {
- .dev = {
- .bus =platform_bus_type,
- },
-};
-
-/**
- * omap_hsmmc_reset() - Full reset of each HS-MMC controller
- *
- * Ensure that each MMC controller is fully reset. Controllers
- * left in an unknown state (by bootloader) may prevent retention
- * or OFF-mode. This is especially important in cases where the
- * MMC driver is not enabled, _or_ built as a module.
- *
- * In order for reset to work, interface, functional and debounce
- * clocks must be enabled. The debounce clock comes from func_32k_clk
- * and is not under SW control, so we only enable i- and f-clocks.
- **/
-static void __init omap_hsmmc_reset(void)
-{
- u32 i, nr_controllers;
- struct clk *iclk, *fclk;
-
- if (cpu_is_omap242x())
- return;
-
- nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
- (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
-
- for (i = 0; i nr_controllers; i++) {
- u32 v, base = 0;
- struct device *dev =dummy_pdev.dev;
-
- switch (i) {
- case 0:
- base = OMAP2_MMC1_BASE;
- break;
- case 1:
- base = OMAP2_MMC2_BASE;
- break;
- case 2:
- base = OMAP3_MMC3_BASE;
- break;
- case 3:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC4_BASE;
- break;
- case 4:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC5_BASE;
- break;
- }
-
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
- dummy_pdev.id = i;
- dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
- iclk = clk_get(dev, ick);
- if (IS_ERR(iclk))
- goto err1;
- if (clk_enable(iclk))
- goto err2;
-
- fclk = clk_get(dev, fck);
- if (IS_ERR(fclk))
- goto err3;
- if (clk_enable(fclk))
- goto err4;
-
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base +
MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS)
- MMCHS_SYSSTATUS_RESETDONE))
- cpu_relax();
-
- clk_disable(fclk);
- clk_put(fclk);
- clk_disable(iclk);
- clk_put(iclk);
- }
- return;
-
-err4:
- clk_put(fclk);
-err3:
- clk_disable(iclk);
-err2:
- clk_put(iclk);
-err1:
- printk(KERN_WARNING %s: Unable to enable clocks for MMC%d,
- cannot reset.\n, __func__, i);
-}
-#else
-static inline void omap_hsmmc_reset(void) {}
-#endif
-
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
static inline void omap242x_mmc_mux(struct omap_mmc_platform_data
@@ -665,150 +559,6 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data
Re: [PATCH v3 4/5] OMAP: hwmod data: Add dev_attr and use in the host driver
On Thu, Feb 24, 2011 at 4:29 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
Add a device attribute to hwmod data of omap2430, omap3, omap4.
Currently the device attribute holds information regarding dual volt MMC
card
support by the controller which will be later passed to the host driver
via
platform data.
Signed-off-by: Kevin Hilmankhil...@deeprootsystems.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
There are few minor comments to fix hence the:
Almost-Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 9 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
arch/arm/plat-omap/include/plat/mmc.h | 10 ++
drivers/mmc/host/omap_hsmmc.c | 4 ++--
5 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4d45b7d..e050355 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -19,6 +19,7 @@
#includeplat/i2c.h
#includeplat/gpio.h
#includeplat/mcspi.h
+#includeplat/mmc.h
#include omap_hwmod_common_data.h
@@ -1290,6 +1291,10 @@ static struct omap_hwmod_class mmc_class = {
/* MMC/SD/SDIO1 */
+static struct mmc_dev_attr mmc1_dev_attr = {
Could you rename the struct omap_mmc_dev_attr to stick to the convention?
Ok
The dev_attr should be just above static struct omap_hwmod. See the OMAP4
example below.
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
{ .irq = 83 },
};
@@ -1328,11 +1333,14 @@ static struct omap_hwmod omap2430_mmc1_hwmod = {
.slaves = omap2430_mmc1_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_mmc1_slaves),
.class =mmc_class,
+ .dev_attr =mmc1_dev_attr,
dev_attr should be above .slaves.
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
/* MMC/SD/SDIO2 */
+static struct mmc_dev_attr mmc2_dev_attr;
If you do not have any dev_attr for that instance, do not add it here and
test for null pointer in your driver.
This comment applies for all instances in all OMAPs.
ok
+
static struct omap_hwmod_irq_info mmc2_mpu_irqs[] = {
{ .irq = 86 },
};
@@ -1371,6 +1379,7 @@ static struct omap_hwmod omap2430_mmc2_hwmod = {
.slaves = omap2430_mmc2_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_mmc2_slaves),
.class =mmc_class,
+ .dev_attr =mmc2_dev_attr,
Not needed if there is not data in the structure.
ok
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index dd39e75..6c4ccfd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
#includeplat/gpio.h
#includeplat/dma.h
#includeplat/mcspi.h
+#includeplat/mmc.h
#include omap_hwmod_common_data.h
@@ -3383,6 +3384,10 @@ static struct omap_hwmod_class
omap44xx_mmc_hwmod_class = {
};
/* mmc1 */
+static struct mmc_dev_attr omap_mmc1_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info omap44xx_mmc1_irqs[] = {
{ .irq = 83 + OMAP44XX_IRQ_GIC_START },
};
@@ -3437,10 +3442,14 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc1_slaves),
.masters = omap44xx_mmc1_masters,
.masters_cnt = ARRAY_SIZE(omap44xx_mmc1_masters),
+ .dev_attr =omap_mmc1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc2 */
+static struct omap_hwmod omap44xx_mmc2_hwmod;
+static struct mmc_dev_attr omap_mmc2_dev_attr;
+
static struct omap_hwmod_irq_info omap44xx_mmc2_irqs[] = {
{ .irq = 86 + OMAP44XX_IRQ_GIC_START },
};
@@ -3495,11 +3504,13 @@ static struct omap_hwmod omap44xx_mmc2_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc2_slaves),
.masters = omap44xx_mmc2_masters,
.masters_cnt = ARRAY_SIZE(omap44xx_mmc2_masters),
+ .dev_attr =omap_mmc2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc3 */
static struct omap_hwmod omap44xx_mmc3_hwmod;
+static struct mmc_dev_attr omap_mmc3_dev_attr;
static struct omap_hwmod_irq_info omap44xx_mmc3_irqs[] = {
{ .irq = 94 + OMAP44XX_IRQ_GIC_START },
};
@@ -3547,11 +3558,13 @@ static struct omap_hwmod omap44xx_mmc3_hwmod = {
},
.slaves = omap44xx_mmc3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc3_slaves),
+ .dev_attr =omap_mmc3_dev_attr,
.omap_chip =
Re: [PATCH v3 5/5] OMAP: adapt hsmmc to hwmod framework
On Thu, Feb 24, 2011 at 11:58 AM, Varadarajan, Charulatha ch...@ti.com wrote:
Kishore,
On Wed, Feb 23, 2011 at 23:17, Kishore Kadiyala kishore.kadiy...@ti.com
wrote:
Changes involves:
1) Remove controller reset in devices.c which is taken care of
by hwmod framework.
2) Removing all base address macro defines except keeping one for OMAP2420.
why?
Will mention the details in the log
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
CC: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c | 251
-
arch/arm/mach-omap2/hsmmc.c | 153 ++--
arch/arm/plat-omap/include/plat/mmc.h | 14 --
3 files changed, 141 insertions(+), 277 deletions(-)
snip
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 34272e4..b6e1eae 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -16,7 +16,11 @@
#include mach/hardware.h
#include plat/mmc.h
#include plat/omap-pm.h
+#include plat/mux.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include mux.h
#include hsmmc.h
#include control.h
@@ -30,7 +34,7 @@ static u16 control_mmc1;
static struct hsmmc_controller {
char name[HSMMC_NAME_LEN + 1];
-} hsmmc[OMAP34XX_NR_MMC];
+} hsmmc[OMAP44XX_NR_MMC];
Why do you have a dependency on OMAP44XX_NR_MMC? You should get
this kind of information using number of iterations in *_hwmod_each_by_class.
Ok , will remove
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
@@ -204,7 +208,141 @@ static int nop_mmc_set_power(struct device *dev, int
slot, int power_on,
return 0;
}
-static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC]
__initdata;
+static inline void omap2_mmc_mux(struct omap_mmc_platform_data
*mmc_controller,
+ int controller_nr)
+{
+ if ((mmc_controller-slots[0].switch_pin 0) \
+ (mmc_controller-slots[0].switch_pin OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].switch_pin,
+ OMAP_PIN_INPUT_PULLUP);
+ if ((mmc_controller-slots[0].gpio_wp 0) \
+ (mmc_controller-slots[0].gpio_wp OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
+ OMAP_PIN_INPUT_PULLUP);
+ if (cpu_is_omap34xx()) {
+ if (controller_nr == 0) {
+ omap_mux_init_signal(sdmmc1_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+ if (mmc_controller-slots[0].caps
+ (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+ omap_mux_init_signal(sdmmc1_dat1,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat2,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat3,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ if (mmc_controller-slots[0].caps
+ MMC_CAP_8_BIT_DATA) {
+ omap_mux_init_signal(sdmmc1_dat4,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat5,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat6,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat7,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ }
+ if (controller_nr == 1) {
+ /* MMC2 */
+ omap_mux_init_signal(sdmmc2_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc2_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc2_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+
+ /*
+ * For 8 wire configurations, Lines DAT4, 5, 6 and 7
+ * need to be muxed in the board-*.c
Re: [PATCH v3 4/5] OMAP: hwmod data: Add dev_attr and use in the host driver
On Thu, Feb 24, 2011 at 11:30 AM, Varadarajan, Charulatha ch...@ti.com wrote:
Kishore,
On Wed, Feb 23, 2011 at 23:17, Kishore Kadiyala kishore.kadiy...@ti.com
wrote:
Add a device attribute to hwmod data of omap2430, omap3, omap4.
Currently the device attribute holds information regarding dual volt MMC card
support by the controller which will be later passed to the host driver via
platform data.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 9 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
arch/arm/plat-omap/include/plat/mmc.h | 10 ++
drivers/mmc/host/omap_hsmmc.c | 4 ++--
5 files changed, 49 insertions(+), 2 deletions(-)
snip
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index e5de5d4..7853130 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -43,6 +43,13 @@
#define OMAP_MMC_MAX_SLOTS 2
+/* omap_hwmod integration data */
What is omap_hwmod integration data ? Pls clarify.
+#define OMAP_HSMMC_SUPPORTS_DUAL_VOLT BIT(1)
+
+struct mmc_dev_attr {
+ u8 flags;
+};
+
struct omap_mmc_platform_data {
/* back-link to device */
struct device *dev;
@@ -71,6 +78,9 @@ struct omap_mmc_platform_data {
u64 dma_mask;
+ /* Integrating attributes from the omap_hwmod layer */
+ u8 controller_dev_attr;
+
/* Register offset deviation */
u16 reg_offset;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 078fdf1..160cc95 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1555,7 +1555,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
break;
}
- if (host-id == OMAP_MMC1_DEVID) {
+ if (host-pdata-controller_dev_attr
OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
Where is pdata-controller_dev_attr getting populated? I don't see the
dev_attr from the
hwmod database used anywhere in this patch.
good catch ,
the changes in the driver should be part of last patch.
/* Only MMC1 can interface at 3V without some flavor
* of external transceiver; but they all handle 1.8V.
*/
@@ -1647,7 +1647,7 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
u32 hctl, capa, value;
/* Only MMC1 supports 3.0V */
- if (host-id == OMAP_MMC1_DEVID) {
+ if (host-pdata-controller_dev_attr
OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
Ditto.
hctl = SDVS30;
capa = VS30 | VS18;
} else {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] OMAP: McSPI: Off-by-one error in finding the right divisor
Off-by-one error, gave erroneous divisor value 16 if speed_hz is over zero but
less than OMAP2_MCSPI_MAX_FREQ / (1 15), that is, [1..1463].
Also few overly complex bit shifts in divisor fixed.
Also one dev_dgb line fixed, which indicated max speed exceeding transfer speed.
Introducing a new function omap2_mcspi_calc_divisor() for getting the right
divisor in omap2_mcspi_setup_transfer().
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
Signed-off-by: Hannu Heikkinen ext-hannu.m.heikki...@nokia.com
---
drivers/spi/omap2_mcspi.c | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 36501ad..845248c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -631,6 +631,17 @@ out:
return count - c;
}
+static u32 omap2_mcspi_calc_divisor(u32 speed_hz)
+{
+ u32 div;
+
+ for (div = 0; div 15; div++)
+ if (speed_hz = (OMAP2_MCSPI_MAX_FREQ div))
+ return div;
+
+ return 15;
+}
+
/* called only when no transfer is active to this device */
static int omap2_mcspi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
@@ -653,12 +664,8 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
if (t t-speed_hz)
speed_hz = t-speed_hz;
- if (speed_hz) {
- while (div = 15 (OMAP2_MCSPI_MAX_FREQ / (1 div))
-speed_hz)
- div++;
- } else
- div = 15;
+ speed_hz = min(speed_hz, OMAP2_MCSPI_MAX_FREQ);
+ div = omap2_mcspi_calc_divisor(speed_hz);
l = mcspi_cached_chconf0(spi);
@@ -695,7 +702,7 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
mcspi_write_chconf0(spi, l);
dev_dbg(spi-dev, setup: speed %d, sample %s edge, clk %s\n,
- OMAP2_MCSPI_MAX_FREQ / (1 div),
+ OMAP2_MCSPI_MAX_FREQ div,
(spi-mode SPI_CPHA) ? trailing : leading,
(spi-mode SPI_CPOL) ? inverted : normal);
@@ -996,10 +1003,10 @@ static int omap2_mcspi_transfer(struct spi_device *spi,
struct spi_message *m)
t-bits_per_word);
return -EINVAL;
}
- if (t-speed_hz t-speed_hz OMAP2_MCSPI_MAX_FREQ/(116)) {
- dev_dbg(spi-dev, %d Hz max exceeds %d\n,
- t-speed_hz,
- OMAP2_MCSPI_MAX_FREQ/(116));
+ if (t-speed_hz t-speed_hz (OMAP2_MCSPI_MAX_FREQ 15)) {
+ dev_dbg(spi-dev, speed_hz %d below minimum %d Hz\n,
+ t-speed_hz,
+ OMAP2_MCSPI_MAX_FREQ 15);
return -EINVAL;
}
--
1.7.3
--
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] OMAP4: clock: Support divider selection for auxclks
On OMAP4 the auxclk nodes (part of SCRM) support both
divider as well as parent selection.
Supporting this requires splitting the existing nodes
(which support only parent selection) into
two nodes, one for parent and another for
divider selection.
The nodes for parent selection are named
auxclk*_src_ck and the ones for divider
selection as auxclk*_ck
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Anand Gadiyar gadi...@ti.com
---
The only user of these auxclks' today is
USB PHY on panda board.
Thanks to Anand G for testing this works
fine with the patch,
Patch is based on 2.6.38-rc6 kernel.
arch/arm/mach-omap2/clock44xx_data.c | 179 +-
1 files changed, 154 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index de9ec8d..af1aa93 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2842,19 +2842,39 @@ static struct clk trace_clk_div_ck = {
/* SCRM aux clk nodes */
-static const struct clksel auxclk_sel[] = {
+static const struct clksel auxclk_src_sel[] = {
{ .parent = sys_clkin_ck, .rates = div_1_0_rates },
{ .parent = dpll_core_m3x2_ck, .rates = div_1_1_rates },
{ .parent = dpll_per_m3x2_ck, .rates = div_1_2_rates },
{ .parent = NULL },
};
-static struct clk auxclk0_ck = {
- .name = auxclk0_ck,
+static const struct clksel_rate div16_1to16_rates[] = {
+ { .div = 1, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 3, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 4, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 5, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 6, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 7, .val = 6, .flags = RATE_IN_4430 },
+ { .div = 8, .val = 7, .flags = RATE_IN_4430 },
+ { .div = 9, .val = 8, .flags = RATE_IN_4430 },
+ { .div = 10, .val = 9, .flags = RATE_IN_4430 },
+ { .div = 11, .val = 10, .flags = RATE_IN_4430 },
+ { .div = 12, .val = 11, .flags = RATE_IN_4430 },
+ { .div = 13, .val = 12, .flags = RATE_IN_4430 },
+ { .div = 14, .val = 13, .flags = RATE_IN_4430 },
+ { .div = 15, .val = 14, .flags = RATE_IN_4430 },
+ { .div = 16, .val = 15, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static struct clk auxclk0_src_ck = {
+ .name = auxclk0_src_ck,
.parent = sys_clkin_ck,
.init = omap2_init_clksel_parent,
.ops= clkops_omap2_dflt,
- .clksel = auxclk_sel,
+ .clksel = auxclk_src_sel,
.clksel_reg = OMAP4_SCRM_AUXCLK0,
.clksel_mask= OMAP4_SRCSELECT_MASK,
.recalc = omap2_clksel_recalc,
@@ -2862,12 +2882,29 @@ static struct clk auxclk0_ck = {
.enable_bit = OMAP4_ENABLE_SHIFT,
};
-static struct clk auxclk1_ck = {
- .name = auxclk1_ck,
+static const struct clksel auxclk0_sel[] = {
+ { .parent = auxclk0_src_ck, .rates = div16_1to16_rates },
+ { .parent = NULL },
+};
+
+static struct clk auxclk0_ck = {
+ .name = auxclk0_ck,
+ .parent = auxclk0_src_ck,
+ .clksel = auxclk0_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK0,
+ .clksel_mask= OMAP4_CLKDIV_MASK,
+ .ops= clkops_null,
+ .recalc = omap2_clksel_recalc,
+ .round_rate = omap2_clksel_round_rate,
+ .set_rate = omap2_clksel_set_rate,
+};
+
+static struct clk auxclk1_src_ck = {
+ .name = auxclk1_src_ck,
.parent = sys_clkin_ck,
.init = omap2_init_clksel_parent,
.ops= clkops_omap2_dflt,
- .clksel = auxclk_sel,
+ .clksel = auxclk_src_sel,
.clksel_reg = OMAP4_SCRM_AUXCLK1,
.clksel_mask= OMAP4_SRCSELECT_MASK,
.recalc = omap2_clksel_recalc,
@@ -2875,24 +2912,59 @@ static struct clk auxclk1_ck = {
.enable_bit = OMAP4_ENABLE_SHIFT,
};
-static struct clk auxclk2_ck = {
- .name = auxclk2_ck,
+static const struct clksel auxclk1_sel[] = {
+ { .parent = auxclk1_src_ck, .rates = div16_1to16_rates },
+ { .parent = NULL },
+};
+
+static struct clk auxclk1_ck = {
+ .name = auxclk1_ck,
+ .parent = auxclk1_src_ck,
+ .clksel = auxclk1_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK1,
+ .clksel_mask= OMAP4_CLKDIV_MASK,
+ .ops= clkops_null,
+ .recalc = omap2_clksel_recalc,
+ .round_rate = omap2_clksel_round_rate,
+ .set_rate = omap2_clksel_set_rate,
+};
+
+static struct clk auxclk2_src_ck = {
+ .name = auxclk2_src_ck,
.parent = sys_clkin_ck,
.init = omap2_init_clksel_parent,
.ops
Re: [PATCH v3 5/5] OMAP: adapt hsmmc to hwmod framework
On 2/24/2011 2:55 PM, Kadiyala, Kishore wrote:
On Thu, Feb 24, 2011 at 5:19 PM, Cousson, Benoitb-cous...@ti.com wrote:
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
[...]
static struct hsmmc_controller {
charname[HSMMC_NAME_LEN + 1];
-} hsmmc[OMAP34XX_NR_MMC];
+} hsmmc[OMAP44XX_NR_MMC];
I do not know the details of that driver, so this comment might be
completely irrelevant, but in theory, such static table should not be
necessary since the driver core already maintain a list of all instances
bound to it.
I agree, but this is used in slot data for the controller and is used
in the driver
to create a /sys entry.
I guess the sysfs should be able to use only the device instance.
I will try to avoid the OMAP44XX_NR_MMC dependency.
[...]
+static struct omap_mmc_platform_data *hsmmc_data[OMAP44XX_NR_MMC]
__initdata;
Same concern than for hsmmc, why do you need static table here?
Agree, will remove static declaration.
And why do you need another structure? The omap2_hsmmc_info should already
be in a pdata kind of structure.
The board file should just populate a table of pdata that you will use
during init.
No, omap2_hsmmc_info is intermediate structure used by the boards
files to update
some basic info of the controller, based on which the pdata is
populated in hsmmc.c.
This is the point, I guess you can potentially directly fill partially a
pdata with controller information in the board file to avoid that
intermediate structure.
[...]
+ name = mmci-omap-hs;
Could you please rename the device to have something in the form: omap_?
In that case omap_mmc should be good. The hs is just a indication of one
of the mmc instance capability and does not have to be in the device name
since there is no none-hs instance.
I understood your concern but omap1,omap2420 uses mmc driver while
omap2430, omap3 , omap4 has hsmmc driver.
OK, it makes sense then.
omap1, omap2420 boards have device name as mmci-omap currently, but
if they undergo
the similar change as proposed above then it looks like omap_mmc
Therefore for hsmmc driver, I will be happy to have something like omap_hsmmc
please let me know if this is fine.
Excellent, that's fine for me.
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adding help for FB_OMAP_LCD_VGA option
On Thu, 2011-02-24 at 03:39 -0600, Janorkar, Mayuresh wrote: CONFIG_FB_OMAP_LCD_VGA option is present in drivers/video/omap There is no explaination about what this flag does. Lets add information about it. FB_OMAP_LCD_VGA flag sets resolution of display to VGA (640 X 480). The default resolution of 3430 LDP is 320 X 240. Looks fine to me. I'll apply to my tree. In the long run let's try to port the LCD drivers to the new display subsystem driver, and remove hacky Kconfigs like this =). Tomi -- 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/2 v2] twl4030-madc driver
MADC(Monitoring ADC) driver enables monitoring analog signals using analog-to-digital conversion (ADC) on the input source. The previous discussion concluded in keeping the generic ADC functionality and the hwmon separate. The discussion can be found here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html Keerthy (2): mfd: twl4030: Driver for twl4030 madc module hwmon: twl4030: Hwmon Driver for TWL4030 MADC Documentation/hwmon/twl4030-madc-hwmon | 45 ++ drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/twl4030-madc-hwmon.c | 153 ++ drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile |1 + drivers/mfd/twl4030-madc.c | 815 include/linux/i2c/twl4030-madc.h | 142 ++ 8 files changed, 1177 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/twl4030-madc-hwmon create mode 100644 drivers/hwmon/twl4030-madc-hwmon.c create mode 100644 drivers/mfd/twl4030-madc.c create mode 100644 include/linux/i2c/twl4030-madc.h -- 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/2 v2] mfd: twl4030: Driver for twl4030 madc module
Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring
ADC. This driver monitors the real time conversion of analog signals like
battery temperature, battery cuurent etc.
Signed-off-by: Keerthy j-keer...@ti.com
---
V2:
Added functions to convert raw voltages to current and temperature.
V1:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg44543.html
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile |1 +
drivers/mfd/twl4030-madc.c | 815 ++
include/linux/i2c/twl4030-madc.h | 142 +++
4 files changed, 968 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/twl4030-madc.c
create mode 100644 include/linux/i2c/twl4030-madc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fd01836..029e078 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -167,6 +167,16 @@ config TWL4030_CORE
high speed USB OTG transceiver, an audio codec (on most
versions) and many other features.
+config TWL4030_MADC
+ tristate Texas Instruments TWL4030 MADC
+ depends on TWL4030_CORE
+ help
+ This driver provides support for triton TWL4030-MADC. The
+ driver supports both RT and SW conversion methods.
+
+ This driver can be built as a module. If so it will be
+ named twl4030-madc
+
config TWL4030_POWER
bool Support power resources on TWL4030 family chips
depends on TWL4030_CORE ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a54e2c7..2922cc2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_TPS6507X)+= tps6507x.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
+obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
obj-$(CONFIG_TWL6030_PWM) += twl6030-pwm.o
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
new file mode 100644
index 000..c30abf7
--- /dev/null
+++ b/drivers/mfd/twl4030-madc.c
@@ -0,0 +1,815 @@
+/*
+ *
+ * TWL4030 MADC module driver-This driver monitors the real time
+ * conversion of analog signals like battery temperature,
+ * battery type, battery level etc.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * J Keerthy j-keer...@ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen mikko.k.yli...@nokia.com
+ *
+ * Amit Kucheria amit.kuche...@canonical.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, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/i2c/twl.h
+#include linux/i2c/twl4030-madc.h
+
+/*
+ * struct twl4030_madc_data - a container for madc info
+ * @dev - pointer to device structure for madc
+ * @lock - mutex protecting this data structire
+ * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @imr - Interrupt mask register of MADC
+ * @isr - Interrupt status register of MADC
+ */
+struct twl4030_madc_data {
+ struct device *dev;
+ struct mutex lock; /* mutex protecting this data structire */
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ int imr;
+ int isr;
+};
+
+static struct twl4030_madc_data *twl4030_madc;
+
+struct twl4030_prescale_divider_ratios {
+ s16 numerator;
+ s16 denominator;
+};
+
+static const struct twl4030_prescale_divider_ratios
+twl4030_divider_ratios[16] = {
+ {1, 1}, /* CHANNEL 0 No Prescaler */
+ {1, 1}, /* CHANNEL 1 No Prescaler */
+ {6, 10},/* CHANNEL 2 */
+ {6, 10},/* CHANNEL 3 */
+ {6, 10},/* CHANNEL 4 */
+ {6, 10},/* CHANNEL 5 */
+ {6, 10},/* CHANNEL 6 */
+ {6, 10},/* CHANNEL 7 */
+ {3, 14},/* CHANNEL 8 */
+ {1, 3}, /* CHANNEL 9 */
+ {1, 1}, /* CHANNEL 10 NA */
+ {15, 100}, /* CHANNEL 11 */
+ {1, 4}, /* CHANNEL 12 */
+ {1, 1}, /* CHANNEL 13 NA */
+ {1, 1}, /* CHANNEL 14 NA */
+ {5, 11},/* CHANNEL 15 */
+};
+
+
+/*
+
[PATCH 2/2 v2] hwmon: twl4030: Hwmon Driver for TWL4030 MADC
This driver exposes the sysfs nodes of the TWL4030 MADC module. All the voltage channel values are expressed in terms of mV. Channel 13 and channel 14 are reserved. There are channels which represent temperature and current the output is represented by celcius and mA respectively. Signed-off-by: Keerthy j-keer...@ti.com --- V2: Changed the names of the sysfs attributes compliant to current, voltage and temperature attributes. V1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg44542.html Documentation/hwmon/twl4030-madc-hwmon | 45 + drivers/hwmon/Kconfig | 10 ++ drivers/hwmon/Makefile |1 + drivers/hwmon/twl4030-madc-hwmon.c | 153 4 files changed, 209 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/twl4030-madc-hwmon create mode 100644 drivers/hwmon/twl4030-madc-hwmon.c diff --git a/Documentation/hwmon/twl4030-madc-hwmon b/Documentation/hwmon/twl4030-madc-hwmon new file mode 100644 index 000..ef79843 --- /dev/null +++ b/Documentation/hwmon/twl4030-madc-hwmon @@ -0,0 +1,45 @@ +Kernel driver twl4030-madc += + +Supported chips: + * Texas Instruments TWL4030 + Prefix: 'twl4030-madc' + + +Authors: + J Keerthy j-keer...@ti.com + +Description +--- + +The Texas Instruments TWL4030 is a Power Management and Audio Circuit. Among +other things it contains a 10-bit A/D converter MADC. The converter has 16 +channels which can be used in different modes. + + +See this table for the meaning of the different channels + +Channel Signal +-- +0 Battery type(BTYPE) +1 BCI: Battery temperature (BTEMP) +2 GP analog input +3 GP analog input +4 GP analog input +5 GP analog input +6 GP analog input +7 GP analog input +8 BCI: VBUS voltage(VBUS) +9 Backup Battery voltage (VBKP) +10 BCI: Battery charger current (ICHG) +11 BCI: Battery charger voltage (VCHG) +12 BCI: Main battery voltage (VBAT) +13 Reserved +14 Reserved +15 VRUSB Supply/Speaker left/Speaker right polarization level + + +The Sysfs nodes will represent the voltage in the units of mV, +the temperature channel shows the converted temperature in +degree celcius. The Battery charging current channel represents +battery charging current in mA. diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 773e484..cc95dae 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -940,6 +940,16 @@ config SENSORS_TMP421 This driver can also be built as a module. If so, the module will be called tmp421. +config SENSORS_TWL4030_MADC + tristate Texas Instruments TWL4030 MADC Hwmon + depends on TWL4030_MADC + help + If you say yes here you get hwmon support for triton + TWL4030-MADC. + + This driver can also be built as a module. If so it will be called + twl4030-madc-hwmon. + config SENSORS_VIA_CPUTEMP tristate VIA CPU temperature sensor depends on X86 diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index dde02d9..bc7d740 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_SENSORS_THMC50)+= thmc50.o obj-$(CONFIG_SENSORS_TMP102) += tmp102.o obj-$(CONFIG_SENSORS_TMP401) += tmp401.o obj-$(CONFIG_SENSORS_TMP421) += tmp421.o +obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc-hwmon.o obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o obj-$(CONFIG_SENSORS_VIA686A) += via686a.o obj-$(CONFIG_SENSORS_VT1211) += vt1211.o diff --git a/drivers/hwmon/twl4030-madc-hwmon.c b/drivers/hwmon/twl4030-madc-hwmon.c new file mode 100644 index 000..24f6e2c --- /dev/null +++ b/drivers/hwmon/twl4030-madc-hwmon.c @@ -0,0 +1,153 @@ +/* + * + * TWL4030 MADC Hwmon driver-This driver monitors the real time + * conversion of analog signals like battery temperature, + * battery type, battery level etc. User can ask for the conversion on a + * particular channel using the sysfs nodes. + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * J Keerthy j-keer...@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, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/platform_device.h +#include linux/i2c/twl.h +#include
Re: [PATCH 8/8] OMAP2+: clockevent: late-init GPTIMER clockevent hwmodright before timer init
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110224 00:27]: I have tested on OMAP3 and works fine. On OMAP2, I guess there is different issue for which it does not work. That's because commit 15490ef8ff8fd22d677cb5d4f6a98e5a79118dba changed things to include CONFIG_CPU_32v6K. And this means that omap-for-linus won't boot on omap2 currently using omap2plus_defconfig. The master branch boots because of the patches in omap-testing. To boot test omap-for-linus, you can temporarily merge in the omap-testing branch that has the pending patches from Russell to make non-6K ARMv6 processors work with CONFIG_CPU_32v6K. 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 1/1] OMAP: McSPI: Off-by-one error in finding the right divisor
On Thu, Feb 24, 2011 at 04:13:31PM +0200, Hannu Heikkinen wrote: Off-by-one error, gave erroneous divisor value 16 if speed_hz is over zero but less than OMAP2_MCSPI_MAX_FREQ / (1 15), that is, [1..1463]. Also few overly complex bit shifts in divisor fixed. Also one dev_dgb line fixed, which indicated max speed exceeding transfer speed. Introducing a new function omap2_mcspi_calc_divisor() for getting the right divisor in omap2_mcspi_setup_transfer(). Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com Signed-off-by: Hannu Heikkinen ext-hannu.m.heikki...@nokia.com Applied, thanks 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 1/1] OMAP: McSPI: Off-by-one error in finding the right divisor
On Thu, Feb 24, 2011 at 9:00 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Thu, Feb 24, 2011 at 04:13:31PM +0200, Hannu Heikkinen wrote: Off-by-one error, gave erroneous divisor value 16 if speed_hz is over zero but less than OMAP2_MCSPI_MAX_FREQ / (1 15), that is, [1..1463]. Also few overly complex bit shifts in divisor fixed. Also one dev_dgb line fixed, which indicated max speed exceeding transfer speed. Introducing a new function omap2_mcspi_calc_divisor() for getting the right divisor in omap2_mcspi_setup_transfer(). Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com Signed-off-by: Hannu Heikkinen ext-hannu.m.heikki...@nokia.com Applied, thanks Patch adds a build warning: CC drivers/spi/omap2_mcspi.o linux-2.6/drivers/spi/omap2_mcspi.c: In function 'omap2_mcspi_setup_transfer': linux-2.6/drivers/spi/omap2_mcspi.c:687: warning: comparison of distinct pointer types lacks a cast I've dropped it, please fix up and resubmit. Thanks, 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] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
Hi paul, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Santosh Shilimkar Sent: Monday, January 17, 2011 10:09 PM To: Paul Walmsley Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 06, 2011 11:56 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM Hi Santosh, On Wed, 5 Jan 2011, Santosh Shilimkar wrote: Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism' introduced watchdog timer state state management using postsetup_state. This was done to allow some board files to support watchdog coverage throughout kernel initialization and it work as intended when RUNTIME_PM is enabled. With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog to remain enabled the omap_wdt_probe crashesh. This is because hwmod in absense of runtime PM unable to turn watchdog clocks because it's state is set to be disabled. For rest of the device, the state is set as enabled in absense of RUNTIME_PM [1.372558] Unhandled fault: imprecise external abort (0x1406) at 0xad733eeb [1.379913] Internal error: : 1406 [#1] SMP [1.384277] last sysfs file: [1.387359] Modules linked in: [1.390563] CPU: 0Tainted: GW(2.6.37-rc7-00265- g4298a4c-dirty #23) [1.398468] PC is at omap_wdt_disable+0x2c/0x3c [1.403198] LR is at omap_wdt_probe+0x124/0x1e0 [1.407928] pc : [c02f5bf4]lr : [c03be10c]psr: 6013 [1.407958] sp : df833f00 ip : fp : [1.419921] r10: c0ac57ac r9 : df959e00 r8 : [1.425384] r7 : df959e08 r6 : df8000c0 r5 : df95bebc r4 : df87dde0 [1.432189] r3 : fc314000 r2 : r1 : fc314034 r0 : df87dde0 This patch make the default watchdog state to be enabled in case of !CONFIG_RUNTIME_PM. This fixes the crash Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Paul, I am not too sure if it breaks your _shutdown idea of watchdog timer. Maybe. What happens in a case where the bootloader enables the watchdog, but the booting kernel is compiled with !CONFIG_OMAP_WATCHDOG and !CONFIG_PM_RUNTIME? Won't the watchdog reset the MPU unexpectedly in that case? Or am I missing something... I tried this scenario and some how the WDT isn't reseting MPU with my patch. Actually I was expecting it should reset but it didn't. Regards, Santosh In the case of !CONFIG_PM_RUNTIME and !CONFIG_OMAP_WATCHDOG, if the boot loader or hwmod enables the watchdog, then it generates an un wanted reset. So to avoid this in the case of !CONFIG_OMAP_WATCHDOG then the watchdog should always be disabled. So there are two cases: Case 1: (!CONFIG_OMAP_WATCHDOG and !CONFIG_PM_RUNTIME) Watchdog should be disabled. Case 2: (!CONFIG_PM_RUNTIME) and ( driver is present and board file enables it) Watchdog should run. Solution1: Introduce a new hwmod watchdog reset function, by populating the .reset entry of the hwmod. This function is called during the hwmod init. This function resets the watchdog always and also disables it if !CONFIG_OMAP_WATCHDOG. ( or ) Solution2: Introduce a state variable to differentiate if hwmod post_setup_state is set to enabled by by board file or io.c file. Use this state variable in the reset function as If it is enabled by io.c then disable watchdog Otherwise if it is set to enabled by board file then enable watchdog. The below is the patch for solution1, that I have mentioned. Please suggest which would be the right approach ? diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 657f3c8..2641d73 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -382,24 +382,6 @@ void __init omap2_init_common_infrastructure(void) #endif omap_hwmod_for_each(_set_hwmod_postsetup_state, postsetup_state); - /* -* Set the default postsetup state for unusual modules (like -* MPU WDT). -* -* The postsetup_state is not actually used until -* omap_hwmod_late_init(), so boards that desire full watchdog -* coverage of kernel initialization can reprogram the -* postsetup_state between the calls to -* omap2_init_common_infra() and omap2_init_common_devices(). -* -* XXX ideally we could detect whether the MPU WDT was currently -* enabled here and make this conditional -*/ -
Re: [024/115] USB: prevent buggy hubs from crashing the USB stack
On Thu, Feb 24, 2011 at 11:16:38AM +0200, Felipe Balbi wrote: Hi, On Thu, Feb 24, 2011 at 10:15:23AM +0100, Alexander Holler wrote: On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? I can do, I'm using exactly the same patch since yesterday. ;) Tested-by: Alexander Holler hol...@ahsoftware.de Thanks a lot Alex, Greg, can you still take this to -rc ? Do you need a pull request or you can take this one patch ? Wait, where does this need to go? For the final 2.6.38 release and then also for .37-stable? Or just .37-stable? confused. And no, I don't need a pull request, I can handle one patch through email :) thanks, greg k-h -- 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 06/19] omap3+: voltage: use volt_data pointer instead values
On Thu, Feb 24, 2011 at 10:58, Gulati, Shweta shweta.gul...@ti.com wrote: Hi, On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote: Voltage values can get confusing in meaning with various Smartreflex classes being active. Depending on the class used, the actual voltage selected might be a variant. Hence pass the volt_data pointers through the structure. Each voltage domain contains a set of volt_data structs. Each of those volt_data struct represents a voltage point that is supported for that domain. Hence, this is a more accurate representation of the voltage point we are interested in going to, and the actual translation of this voltage point to the voltage value is done inside the voltage layer which allows the users of the voltage layer to be blissfully ignorant of any complexity of the underneath layers. Volt_data has efuse, Errgain and errminlimit other than nom_volt How does this data differs in different SR Class implementation which is why using volt_data is required? fair question. let me try it this way. with smart reflex class 3: a) you dont have SR enabled, you will go to volt_nominal b) you have SR enabled, you go to volt_nominal, then enable SR and expect it to adjust voltage. we dont really care about the resultant voltage(until the next scale ofcourse). but when we ask voltage layer to scale to voltage x for OPP y, it always means x is the nominal voltage for OPP y. Now with class 1.5 as introduced in http://marc.info/?l=linux-omapm=129811707718325w=2, a) if you are booting for the first time OR if you never enable SR, you go to volt_nominal b) if you enable SR and the OPP is calibrated, you will not enable SR again when that OPP is accessed anymore, but when you set voltage, the voltage achieved will be volt_calibrated c) if recalibration timeout triggers, the calibrated values are nullified, and you set voltage, the voltage achieved will be volt_dynamic_nominal so, voltage for that OPP you are setting has not 1 single value anymore, but 3 possible valid values depending on which state the system is at. This is the motivation of decoupling values representing voltage in this patch and instead we use a voltage object represented by the pointer to volt_data to decide adequately the OPP voltage we go to. The decision as to what the voltage object means in uVolts is left to the voltage layer. upper layers (or users of voltage layer) are not aware of the system conditions relevant to voltage - only voltage.c has that view - hence we do the translation there. [...] Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [024/115] USB: prevent buggy hubs from crashing the USB stack
On Thu, Feb 24, 2011 at 09:18:14AM -0800, Greg KH wrote: On Thu, Feb 24, 2011 at 11:16:38AM +0200, Felipe Balbi wrote: Hi, On Thu, Feb 24, 2011 at 10:15:23AM +0100, Alexander Holler wrote: On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? I can do, I'm using exactly the same patch since yesterday. ;) Tested-by: Alexander Holler hol...@ahsoftware.de Thanks a lot Alex, Greg, can you still take this to -rc ? Do you need a pull request or you can take this one patch ? Wait, where does this need to go? For the final 2.6.38 release and then also for .37-stable? Or just .37-stable? confused. And no, I don't need a pull request, I can handle one patch through email :) final .38 and .37-stable :-) Thanks Greg :-) -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Santosh Shilimkar santosh.shilim...@ti.com [110212 00:45]: Tony, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Thursday, February 03, 2011 2:13 PM To: Tony Lindgren Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava Munegowda; Felipe Balbi Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure) -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, February 03, 2011 1:19 AM To: Santosh Shilimkar Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava Munegowda; Felipe Balbi Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure) * Santosh Shilimkar santosh.shilim...@ti.com [110201 22:04]: It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot. Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP. Yeah I do, it rarely makes it to the userspace. Works reliably if I disable omap_l2_cache_init. Ok. I shall try few experiments and try to reproduce it Not sure if it's the same issue but I managed to reproduce the issue on ES2.0 itself. And after some experiments, it boiled down to the V6 and V7 issue. By disabling OMAP2 from the build, everything was fine again. Was this with linux-omap master branch or mainline? The V6 vs V7 issues should be sorted out with Russell's patches that we also have now in linux-omap master branch. 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: [024/115] USB: prevent buggy hubs from crashing the USB stack
On Thu, 24 Feb 2011, Felipe Balbi wrote: On Thu, Feb 24, 2011 at 09:18:14AM -0800, Greg KH wrote: On Thu, Feb 24, 2011 at 11:16:38AM +0200, Felipe Balbi wrote: Hi, On Thu, Feb 24, 2011 at 10:15:23AM +0100, Alexander Holler wrote: On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? I can do, I'm using exactly the same patch since yesterday. ;) Tested-by: Alexander Holler hol...@ahsoftware.de Thanks a lot Alex, Greg, can you still take this to -rc ? Do you need a pull request or you can take this one patch ? Wait, where does this need to go? For the final 2.6.38 release and then also for .37-stable? Or just .37-stable? confused. And no, I don't need a pull request, I can handle one patch through email :) final .38 and .37-stable :-) Thanks Greg :-) It's important that this patch appear in .37-stable at the same time as the $SUBJECT patch. If that means delaying $SUBJECT for one release, so be it -- it was not a very important change. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
On Thu, Feb 24, 2011 at 5:29 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Feb 24, 2011 at 01:26:05PM +0200, David Cohen wrote: On Thu, Feb 24, 2011 at 10:35 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Feb 23, 2011 at 10:09:05PM +0200, Sakari Ailus wrote: In OMAP4 the cortex M3 is a double core processor and as each core is running they own version of the RTOS we threat them independently. So our driver which controls the remote processor sees two processor but both use the same iommu hw. When a iommu fault happens, at this moment, it is consider as a faltal error and it is no managed to recover and continue, instead a restart of the processor is needed, if the fault happens in core0 we need to reset core1 too and vice versa. if the iommu would support several user callbacks, we can register the callback which resets core0 and also the callback which resets core1 and treat them as totally independent processors. Also we have an error event notifier driver, which is only in charge of notifying error events to userspace, so we would have multiple callbacks we could do this The original purpose of the patch, as far as I understand, is to allow getting useful information for debugging purposes should an iommu fault happen. Also, I'm not sure it's necessarily a good idea to just go and reset the M3 cores in case an iommu fault happens --- this is very probably a grave bug in the software running on those M3s. It should be fixed instead of just hiding it. There will be consequences to host side as I have to agree here. Besides the fact that multiple callbacks is outside the scope of this patch. This patch is already acked. What about leave it as it is and discuss multiple callbacks before release a new patch to support it? fine by me ;-) Ok, maybe it was too late to change it, due to it is already acked, I just wanted to avoid change isr here and then change it on other patch. it is ok then. Regards, Fernando. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3 Touchbook: Fix MMC caps
MMC controller cannot handle MMC_CAP_4_BIT_DATA nor MMC_CAP_8_BIT_DATA
- the card won't be detected (tested with two SDHC cards, both Class6).
Thus disabling.
Signed-off-by: Radek Pilar mr...@mrkva.eu
---
arch/arm/mach-omap2/board-omap3touchbook.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 6a60f79..e65a32d 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -109,7 +109,6 @@ static struct omap_nand_platform_data
omap3touchbook_nand_data = {
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
- .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 29,
},
{} /* Terminator */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clock: Support divider selection for auxclks
Hi Rajendra, On Thu, 24 Feb 2011, Rajendra Nayak wrote: On OMAP4 the auxclk nodes (part of SCRM) support both divider as well as parent selection. Supporting this requires splitting the existing nodes (which support only parent selection) into two nodes, one for parent and another for divider selection. The nodes for parent selection are named auxclk*_src_ck and the ones for divider selection as auxclk*_ck Signed-off-by: Rajendra Nayak rna...@ti.com Tested-by: Anand Gadiyar gadi...@ti.com Thanks. Has the autogeneration script been updated? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP3 Touchbook: fix board initialization
init_early hook runs too early for omap3_mux_init(), so the board
won't boot. Moved to init_machine, then it works just fine.
Signed-off-by: Radek Pilar mr...@mrkva.eu
---
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index e65a32d..3b560d7 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -416,7 +416,6 @@ static struct omap_board_mux board_mux[]
__initdata = {
static void __init omap3_touchbook_init_early(void)
{
- omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_board_config = omap3_touchbook_config;
omap_board_config_size = ARRAY_SIZE(omap3_touchbook_config);
omap2_init_common_infrastructure();
@@ -513,6 +512,7 @@ static struct omap_musb_board_data musb_board_data
= {
static void __init omap3_touchbook_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
pm_power_off = omap3_touchbook_poweroff;
omap3_touchbook_i2c_init();
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
TWL4030 backup battery charging in 2.6.32
Hi, I have a TPS65920 (twl4030) power chip on an omap3530 board I would like to use to charge a small backup battery to keep the RTC happy. I've run across patches adding drivers/power/twl4030_bci_battery.c which seems to do what I want (sets the twl4030 BB_CFG register's BBCHEN bit), but the driver probe() complains after platform_get_irq() returns -6 (ENXIO). I assume that platform interrupt resources need to be added in my board code. I know this file has been removed, but is there an example of setting up interrupts for this driver or a description of how twl4030 interrupts should be set up in board code? It seems that newer code like board-omap3pandora.c just sets .bci = pandora_bci_data instead of explicit charger interrupts. Thanks, John -- 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 0/5] OMAP: HSMMC: hwmod adaptation
Hi Benoit, On Thu, Feb 24, 2011 at 3:49 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Kishore, On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote: Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4. Adapting the omap_hsmmc driver to hwmod framework. The patch series is based on -rc6 and tested on OMAP2430, OMAP3430SDP OMAP4430SDP. Could you rebase it on top of omap-for-linus, it does apply for the moment. Sure, I will repost new version based on omap-for-linus with comments fixed. snip Regards, Kishore -- 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: [024/115] USB: prevent buggy hubs from crashing the USB stack
Hello, Am 24.02.2011 18:57, schrieb Alan Stern: It's important that this patch appear in .37-stable at the same time as the $SUBJECT patch. If that means delaying $SUBJECT for one release, so be it -- it was not a very important change. Too late, 2.6.37.1 is already broken. But the patch could be still applied to 2.6.32-longterm, at least the message I've replied to asked about objections for that version. Regards, Alexander -- 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: [024/115] USB: prevent buggy hubs from crashing the USB stack
On Thu, Feb 24, 2011 at 12:57:20PM -0500, Alan Stern wrote: On Thu, 24 Feb 2011, Felipe Balbi wrote: On Thu, Feb 24, 2011 at 09:18:14AM -0800, Greg KH wrote: On Thu, Feb 24, 2011 at 11:16:38AM +0200, Felipe Balbi wrote: Hi, On Thu, Feb 24, 2011 at 10:15:23AM +0100, Alexander Holler wrote: On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? I can do, I'm using exactly the same patch since yesterday. ;) Tested-by: Alexander Holler hol...@ahsoftware.de Thanks a lot Alex, Greg, can you still take this to -rc ? Do you need a pull request or you can take this one patch ? Wait, where does this need to go? For the final 2.6.38 release and then also for .37-stable? Or just .37-stable? confused. And no, I don't need a pull request, I can handle one patch through email :) final .38 and .37-stable :-) Thanks Greg :-) It's important that this patch appear in .37-stable at the same time as the $SUBJECT patch. If that means delaying $SUBJECT for one release, so be it -- it was not a very important change. Ok, I'll drop this from the next .37-stable release until this happens. thanks for letting me know. greg k-h -- 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: [024/115] USB: prevent buggy hubs from crashing the USB stack
On Thu, Feb 24, 2011 at 10:12:46AM -0800, Greg KH wrote: On Thu, Feb 24, 2011 at 12:57:20PM -0500, Alan Stern wrote: On Thu, 24 Feb 2011, Felipe Balbi wrote: On Thu, Feb 24, 2011 at 09:18:14AM -0800, Greg KH wrote: On Thu, Feb 24, 2011 at 11:16:38AM +0200, Felipe Balbi wrote: Hi, On Thu, Feb 24, 2011 at 10:15:23AM +0100, Alexander Holler wrote: On Wed, Feb 23, 2011 at 10:26:20AM -0500, Alan Stern wrote: In both cases, it appears that the problem is caused by the fact that the musb host-controller driver doesn't set the hcd-has_tt flag. Felipe, you should know where it belongs. It should be easy enough to add. Sure Alan, it's attached to this mail. Compile tested only though. Michael, would you care to give your tested-by ? I can do, I'm using exactly the same patch since yesterday. ;) Tested-by: Alexander Holler hol...@ahsoftware.de Thanks a lot Alex, Greg, can you still take this to -rc ? Do you need a pull request or you can take this one patch ? Wait, where does this need to go? For the final 2.6.38 release and then also for .37-stable? Or just .37-stable? confused. And no, I don't need a pull request, I can handle one patch through email :) final .38 and .37-stable :-) Thanks Greg :-) It's important that this patch appear in .37-stable at the same time as the $SUBJECT patch. If that means delaying $SUBJECT for one release, so be it -- it was not a very important change. Ok, I'll drop this from the next .37-stable release until this happens. Oops, wait, that's going to be hard as it's already in 2.6.37.1. Oh, I guess I can revert it for the .2 release in a few hours, and then add it back in for .3... I'll go do that. thanks, greg k-h -- 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: [024/115] USB: prevent buggy hubs from crashing the USB stack
On Thu, Feb 24, 2011 at 07:11:34PM +0100, Alexander Holler wrote: Hello, Am 24.02.2011 18:57, schrieb Alan Stern: It's important that this patch appear in .37-stable at the same time as the $SUBJECT patch. If that means delaying $SUBJECT for one release, so be it -- it was not a very important change. Too late, 2.6.37.1 is already broken. But the patch could be still applied to 2.6.32-longterm, at least the message I've replied to asked about objections for that version. It's too late for that release as well, as it's already included in the last .32 stable release. I'll revert it there also for now. thanks, greg k-h -- 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 09/13] OMAP: McBSP: use omap_device APIs to modify SYSCONFIG
* Kishon Vijay Abraham I kis...@ti.com [110224 01:50]: McBSP2/3 in OMAP3 has sidetone feature which requires autoidle to be disabled before starting the sidetone. Also SYSCONFIG register has to be set with smart idle or no idle depending on the dma op mode (threshold or element sync). For doing these operations dynamically at runtime, omap_device APIs are used to modify SYSCONFIG register. I've modified this patch to compile by leaving out the omap_device idle calls. Please send those changes as a separate patch and coordinate it with Kevin's PM changes. 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
