Re: [PATCH] Fix IGEPv2 second MMC channel power supply
Hi, 2010/11/14 Marc Zyngier m...@misterjones.org: On Sun, 14 Nov 2010 19:11:46 +0100 Enric Balletbò i Serra eballe...@gmail.com wrote: Why we need to define an unexistent regulator in board file ? This should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel configuration ? I'm not adding another regulator, but instead simply exposing the fact (or rather my guess) that the same regulator (vmmc1) is powering the two MMC channels. Not having access to the board schematics, I can't tell if that reflects the reality or not. But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's just papering over the issue. We should be exposing what's really on the board (a fixed regulator if that's the case). So the DUMMY_REGULATOR is only a workaround when a regulator is not defined and shouldn't be used ? Sorry if this is a stupid question but regulator interface is not too clear for me. The reality is this : --- | 3V3 | | 1V8 | --- | | - | WIFI/BT | - | ( MMC2 at 1V8 ) | OMAP | --- 3V3 is a fixed regulator 1V8 is a fixed regulator (VIO from TWL4030) So, which you think is the right solution ? Cheers, Enric -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
Hi, Bryan Wu wrote: On Mon, Nov 15, 2010 at 12:05 PM, Taneja, Archit arc...@ti.com wrote: Hi, bryan...@canonical.com wrote: On Wed, Nov 10, 2010 at 10:35 PM, Tomi Valkeinen [snip] For both panel power on and off some panels require some sleep times: when powering on, the video interface has to be enabled for some time before the panel can be enabled, and similarly when powering off the video interface needs to be on for some time after the panel has been disabled. Actually, in my previous version patches, I introduced .power_on_delay and .power_off_delay in panel_configs, which contains the sleep value for msleep(). But Archit told me this is not necessary, so I removed that. I had asked you to remove it from omap_dss_device to a more specific struct for the generic dpi driver :) Yeah, no problem. It should be in the 'panel_generic_dpi_data' struct now. I think the delay value is related to panel, which can be found in sharp_ls and sharp_lq drivers. So it might be in the panel_configs struct? Yes, I think that makes more sense. Thanks, Archit-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap4: hsmmc: Fix improper card detection while booting
While booting OMAP4 ES2.0 boards, cards on MMC1 and MMC2 controllers
are not getting detected some times.
During reset of command/data line, wrong pointer to base address
was passed while read operation to SYSCTL register, thus impacting
the updated reset logic.
Passing correct base address fixes the issue.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Felipie Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Chris Ball c...@laptop.org
Cc: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82a1079..5d46021 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1002,7 +1002,7 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host
*host,
* Monitor a 0-1 transition first
*/
if (mmc_slot(host).features HSMMC_HAS_UPDATED_RESET) {
- while ((!(OMAP_HSMMC_READ(host, SYSCTL) bit))
+ while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
(i++ limit))
cpu_relax();
}
--
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: omap4: hsmmc: Fix improper card detection while booting
On Mon, Nov 15, 2010 at 03:08:59AM -0600, Kadiyala, Kishore wrote:
While booting OMAP4 ES2.0 boards, cards on MMC1 and MMC2 controllers
are not getting detected some times.
During reset of command/data line, wrong pointer to base address
was passed while read operation to SYSCTL register, thus impacting
the updated reset logic.
Passing correct base address fixes the issue.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Felipie Balbi ba...@ti.com
you got it wrong, here's the correct one :-)
Acked-by: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Chris Ball c...@laptop.org
Cc: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82a1079..5d46021 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1002,7 +1002,7 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host
*host,
* Monitor a 0-1 transition first
*/
if (mmc_slot(host).features HSMMC_HAS_UPDATED_RESET) {
- while ((!(OMAP_HSMMC_READ(host, SYSCTL) bit))
+ while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
(i++ limit))
cpu_relax();
}
--
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
--
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 1/3] OMAP: DSS2: Add generic DPI panel display driver
On Sun, 2010-11-14 at 02:42 +0100, ext Bryan Wu wrote: On Wed, Nov 10, 2010 at 10:35 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Tue, 2010-11-09 at 18:12 +0100, ext Bryan Wu wrote: Generic DPI panel driver includes the driver and 4 similar panel configurations. It will match the panel name which is passed from platform data and setup the right configurations. With generic DPI panel driver, we can remove those 4 duplicated panel display drivers. In the future, it is simple for us just add new panel configuration date in panel-generic-dpi.c to support new display panel. This is looking good, but still a couple of comments inline: snip I think otherwise the patches look good. At some point we should add backlight support also, so that we can remove a few drivers more (and get rid of the extra backlight stuff in omap_dss_device struct). Yeah, I plan to do that. But IMHO, how about just move those backlight support as backlight drivers and only remain display control in this directory. Hmm, yes, perhaps that would work for these DPI panels. The reason I originally put the backlight driver inside the panel driver is that there are many panels for which the backlight is a part of the panel, in the sense that the backlight is controlled by sending messages to the panel. For these the backlight needs to be somewhat integrated into the panel driver. 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 v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, November 11, 2010 12:30 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for
OMAP3
[resend with thinned out response, since original reply was determined
to be spam by vger.kernel.org. wondering that tells me about my review
style... ]
Thara Gopinath th...@ti.com writes:
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
All comments below are cut-and-paste from v3 review, and were not
addressed in this update.
Hello Kevin,
Thanks for the review. I thought I had fixed most of the v3 comments
except the ones about the n-target values. Sorry if I had missed some.
[...]
--- /dev/null
+++ b/arch/arm/mach-omap2/voltage.c
@@ -0,0 +1,1158 @@
+/*
+ * OMAP3/OMAP4 Voltage Management Routines
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ * Lesly A M x0080...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/debugfs.h
+#include linux/slab.h
+
+#include plat/common.h
+#include plat/voltage.h
+
+#include prm-regbits-34xx.h
+
+#define VP_IDLE_TIMEOUT200
+#define VP_TRANXDONE_TIMEOUT 300
+#define VOLTAGE_DIR_SIZE 16
+
+static struct dentry *voltage_dir;
+/* PRM voltage module */
+static u32 volt_mod;
There's no need for this to be a global, this should be a member of
vdd_info (or the voltage domain.) That means the read/write functions
will have to take an additional argument (vdd or voltdm) but that's
cleaner to me.
Ok.
[...]
+/* OMAP3 specific voltage init functions */
+/*
+ * Intializes the voltage controller registers with the PMIC and board
+ * specific parameters and voltage setup times for OMAP3. If the board
+ * file does not populate the voltage controller parameters through
+ * omap3_pm_init_vc, default values specified in vc_config is used.
+ */
+static void __init omap3_init_voltagecontroller(void)
I'd like to see consistent naming. Elsewhere in the code, things are
named with either a vdd, vc or vp prefix. Let's keep that here and call
this omap3_vc_init(), and for VP below, s/init_voltagecontroller/vp_init/
Will rename
[...]
+ /*
+* Sys clk rate is require to calculate vp timeout value and
+* smpswaittimemin and smpswaittimemax.
+*/
+ sys_ck = clk_get(NULL, sys_ck);
+ if (IS_ERR(sys_ck)) {
+ pr_warning(%s: Could not get the sys clk to calculate
+ various vdd_%s params\n, __func__, vdd-voltdm.name);
+ return;
+ }
+ sys_clk_speed = clk_get_rate(sys_ck);
+ clk_put(sys_ck);
+ /* Divide to avoid overflow */
+ sys_clk_speed /= 1000;
+
+ /* Nominal/Reset voltage of the VDD */
+ vdd-nominal_volt = vdd-curr_volt = 120;
This should be a #define someplace, something like OMAP3_VDDx_RESET_VOL
or similar. Ideally with a TRM/doc reference to where it comes from.
I'm a little confused. Is this a hardware reset value? or a software
reset value which is part of this layer.
It's a little confusing, since if this is a hardware reset voltage why
does init_voltageprocessor() have to write it to the VP during init?
Even better, rather than hard code this, it would be even better if it
just picked one of the nominal voltages from the volt_data table.
Yes this is the default voltage at which the hardware will boot up.
I had to add this since some errata workarounds requires the vdd to be put to
this level even though this level might not correspond to any opp. The voltage
scaling
Re: BeagleBoard not resuming from uart with latest pm-core ?
Hello, On Wed, 10 Nov 2010 09:32:53 -0800 Kevin Hilman khil...@deeprootsystems.com wrote: The other problem that I'm aware of so far I've only seen on boards with UART2 console (beagle, Overo, n900.) The printk messages that warn of 'new worst case [de]activate latency seem to be racing with UART disable code. This makes sense, since this printk is printed to the UART immediately after the UART is disabled, which is going to cause problems with the current approach to UART pm we have in mach-omap2/serial.c. I have not yet fully debugged this and found a workaround. Even if I comment the new worst case deactivate latency message, my BeagleBoard still doesn't wake-up from suspend. Here's what I do: # echo enabled /sys/class/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 227.685028] PM: Syncing filesystems ... done. [ 227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 227.880706] PM: suspend of devices complete after 117.767 msecs [ 227.889160] PM: late suspend of devices complete after 2.136 msecs [ 227.895782] Disabling non-boot CPUs ... Any idea ? Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, November 11, 2010 12:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Thara Gopinath th...@ti.com writes: This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. The voltage parameters can be viewed at /debug/voltage/vdd_x/parameter and the smartreflex parameters can be viewed at /debug/vdd_x/smartreflex/parameter To enable overriding of these parameters from user side, write 1 into /debug/voltage/vdd_x/override_volt_params Please just git rid of any sort of override parameter from sysfs. Instead, you can detect in the sysfs code itself if any parameters were changed and then set the vdd-user_override flag. But when will I unset this flag?? Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/6] OMAP4: Adding voltage driver support
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, November 11, 2010 12:52 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 2/6] OMAP4: Adding voltage driver support
Thara Gopinath th...@ti.com writes:
OMAP4 has three scalable voltage domains vdd_mpu, vdd_iva
and vdd_core. This patch adds the voltage tables and other
configurable voltage processor and voltage controller
settings to control these three scalable domains in OMAP4.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+/*
+ * Structures containing OMAP4430 voltage supported and various
+ * data associated with it per voltage domain basis. Smartreflex Ntarget
+ * values are left as 0 as they have to be populated by smartreflex
+ * driver after reading the efuse.
+ */
+static struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
+ {.volt_nominal = 93, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
+ {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain = 0x16},
+ {.volt_nominal = 126, .sr_errminlimit = 0xFA, .vp_errgain = 0x23},
+ {.volt_nominal = 135, .sr_errminlimit = 0xFA, .vp_errgain = 0x27},
+};
+
+static struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
+ {.volt_nominal = 93, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
+ {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain = 0x16},
+ {.volt_nominal = 126, .sr_errminlimit = 0xFA, .vp_errgain = 0x23},
+};
+
+static struct omap_volt_data omap44xx_vdd_core_volt_data[] = {
+ {.volt_nominal = 93, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
+ {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain = 0x16},
+};
As mentioned in previous reviews, the standard is to write hex value
using lower case letters. Please fix this up in the both OMAP3 4 series.
Ok. Sorry for missing this.
[...]
+/* Sets up all the VDD related info for OMAP4 */
+static void __init omap4_vdd_data_configure(struct omap_vdd_info *vdd)
+{
+ struct clk *sys_ck;
+ u32 sys_clk_speed, timeout_val, waittime;
+
+ if (!strcmp(vdd-voltdm.name, mpu)) {
+ vdd-vp_reg.vlimitto_vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN;
+ vdd-vp_reg.vlimitto_vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX;
+ vdd-volt_data = omap44xx_vdd_mpu_volt_data;
+ vdd-volt_data_count = ARRAY_SIZE(omap44xx_vdd_mpu_volt_data);
+ vdd-vp_reg.tranxdone_status =
+ OMAP4430_VP_MPU_TRANXDONE_ST_MASK;
+ vdd-cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_MPU_L_OFFSET;
+ vdd-vdd_sr_reg = OMAP4_VDD_MPU_SR_VOLT_REG;
+ } else if (!strcmp(vdd-voltdm.name, core)) {
+ vdd-vp_reg.vlimitto_vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN;
+ vdd-vp_reg.vlimitto_vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX;
+ vdd-volt_data = omap44xx_vdd_core_volt_data;
+ vdd-volt_data_count = ARRAY_SIZE(omap44xx_vdd_core_volt_data);
+ vdd-vp_reg.tranxdone_status =
+ OMAP4430_VP_CORE_TRANXDONE_ST_MASK;
+ vdd-cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_CORE_L_OFFSET;
+ vdd-vdd_sr_reg = OMAP4_VDD_CORE_SR_VOLT_REG;
+ } else if (!strcmp(vdd-voltdm.name, iva)) {
+ vdd-vp_reg.vlimitto_vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN;
+ vdd-vp_reg.vlimitto_vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX;
+ vdd-volt_data = omap44xx_vdd_iva_volt_data;
+ vdd-volt_data_count = ARRAY_SIZE(omap44xx_vdd_iva_volt_data);
+ vdd-vp_reg.tranxdone_status =
+ OMAP4430_VP_IVA_TRANXDONE_ST_MASK;
+ vdd-cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_IVA_L_OFFSET;
+ vdd-vdd_sr_reg = OMAP4_VDD_IVA_SR_VOLT_REG;
+ } else {
+ pr_warning(%s: vdd_%s does not exisit in OMAP4\n,
+ __func__, vdd-voltdm.name);
+ return;
+ }
+
+ /*
+* Sys clk rate is require to calculate vp timeout value and
+* smpswaittimemin and smpswaittimemax.
+*/
+ sys_ck = clk_get(NULL, sys_clkin_ck);
+ if (IS_ERR(sys_ck)) {
+ pr_warning(%s: Could not get the sys clk to calculate
+ various vdd_%s params\n, __func__, vdd-voltdm.name);
+ return;
+ }
+ sys_clk_speed = clk_get_rate(sys_ck);
+ clk_put(sys_ck);
+
+ /* Divide to avoid overflow */
+ sys_clk_speed /= 1000;
+
+ /* Nominal/Reset voltage of the VDD */
+ vdd-nominal_volt = vdd-curr_volt = 120;
same comment as from OMAP3 series.
Will take care
[...]
/* Generic voltage init functions */
static void __init init_voltageprocessor(struct omap_vdd_info *vdd)
{
@@ -753,6 +945,14 @@ static int vp_forceupdate_scale_voltage(struct
omap_vdd_info *vdd,
vc_cmd_on_mask = OMAP3430_VC_CMD_ON_MASK;
prm_irqst_reg_offs = OMAP3_PRM_IRQSTATUS_MPU_OFFSET;
RE: [PATCH v2 04/14] OMAP: Introduce API to register a device with a voltagedomain
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, November 11, 2010 6:19 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v2 04/14] OMAP: Introduce API to register a device with a
voltagedomain
Thara Gopinath th...@ti.com writes:
This patch adds an API in the voltage layer that
can be used during omap_device_build to register the built
device with the voltage domain. This API is to be typically called
only once per device during the device registeration. This approach
makes it easy during dvfs to scale all the devices associated with
a voltage domain and then scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
/* Generic voltage init functions */
@@ -1240,6 +1251,40 @@ int omap_voltage_add_request(struct voltagedomain
*voltdm, struct device *dev,
return 0;
}
+int omap_voltage_add_dev(struct voltagedomain *voltdm, struct device *dev)
minor nit: I prefer this be a 'register' function,
e.g. omap_voltage_register (or _register_dev)
_register_dev. Will rename.
[...]
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
omap/omap_device.c
index abe933c..7c902a6 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -86,6 +86,7 @@
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/voltage.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -453,6 +454,17 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
for (i = 0; i oh_cnt; i++) {
hwmods[i]-od = od;
_add_optional_clock_alias(od, hwmods[i]);
+ if (hwmods[i]-vdd_name) {
Use:
if (!is_early_device hwmods[i]-vdd_name)
+ struct omap_hwmod *oh = hwmods[i];
+ struct voltagedomain *voltdm;
+
+ if (is_early_device)
+ continue;
and drop this check
Ok
+ voltdm = omap_voltage_domain_lookup(oh-vdd_name);
+ if (!omap_voltage_add_dev(voltdm, od-pdev.dev))
+ oh-voltdm = voltdm;
+ }
}
if (ret)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 05/14] OMAP: Introduce device specific set rate and get rate in omap_device structure
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, November 12, 2010 4:29 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v2 05/14] OMAP: Introduce device specific set rate and
get rate in omap_device structure
Thara Gopinath th...@ti.com writes:
This patch extends the omap_device structure to contain
pointers to scale the operating rate of the
device and to retrieve the operating rate of the device.
This patch also adds the three new APIs in the omap device layer
namely omap_device_set_rate that can be called to set a new operating
rate for a device, omap_device_get_rate that can be called to retrieve
the operating frequency for a device and omap_device_populate_rate_fns
to populte the device specific set_rate and get_rate API's.
The omap_device_set_rate and omap_device_get_rate does some routine error
checks and finally calls into the device specific set_rate
and get_rate APIs populated through omap_device_populate_rate_fns.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |9 +
arch/arm/plat-omap/omap_device.c | 49
+
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-
omap/include/plat/omap_device.h
index 28e2d1a..2a37345 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -50,6 +50,8 @@ extern struct device omap_device_parent;
* @hwmods: (one .. many per omap_device)
* @hwmods_cnt: ARRAY_SIZE() of @hwmods
* @pm_lats: ptr to an omap_device_pm_latency table
+ * @set_rate: fn ptr to change the operating rate.
+ * @get_rate: fn ptr to retrieve the current operating rate.
* @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats
* @pm_lat_level: array index of the last odpl entry executed - -1 if
never
* @dev_wakeup_lat: dev wakeup latency in nanoseconds
@@ -67,6 +69,8 @@ struct omap_device {
struct platform_device pdev;
struct omap_hwmod **hwmods;
struct omap_device_pm_latency *pm_lats;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
minor nit, but I prefer the function pointers at the end.
Ok
u32 dev_wakeup_lat;
u32 _dev_wakeup_lat_limit;
u8 pm_lats_cnt;
@@ -107,6 +111,11 @@ void __iomem *omap_device_get_rt_va(struct omap_device
*od);
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
+int omap_device_set_rate(struct device *dev, unsigned long freq);
+unsigned long omap_device_get_rate(struct device *dev);
+void omap_device_populate_rate_fns(struct device *dev,
+ int (*set_rate)(struct device *dev, unsigned long rate),
+ unsigned long (*get_rate) (struct device *dev));
how about omap_device_register_callbacks()
I am ok. But then the name will not specify what kind of
callbacks.
/* Other */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
omap/omap_device.c
index 7c902a6..ffe06eb 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -785,6 +785,55 @@ int omap_device_enable_clocks(struct omap_device *od)
return 0;
}
+int omap_device_set_rate(struct device *dev, unsigned long freq)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
pdev = to_platform_device(dev)
This helper is already defined in platform_device.h.
Ok
+ od = _find_by_pdev(pdev);
+
+ if (!od-set_rate) {
+ dev_err(dev, %s: No set_rate API for scaling device\n,
+ __func__);
+ return -ENODATA;
+ }
+
+ return od-set_rate(dev, freq);
+}
+
+unsigned long omap_device_get_rate(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
pdev = to_platform_device(dev)
+ od = _find_by_pdev(pdev);
+
+
+ if (!od-get_rate) {
+ dev_err(dev, %s: No get rate API for the device\n,
+ __func__);
+ return 0;
+ }
+
+ return od-get_rate(dev);
+}
+
+void omap_device_populate_rate_fns(struct device *dev,
+ int (*set_rate)(struct device *dev, unsigned long rate),
+ unsigned long (*get_rate) (struct device *dev))
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
pdev = to_platform_device(dev)
Ok
+ od =
RE: [PATCH] OMAP: DSS2: OMAPFB: Fix null pointer check
Belisko Marek wrote: On Fri, Nov 12, 2010 at 12:47 PM, Samreen samr...@ti.com wrote: A null pointer check added. Signed-off-by: Samreen samr...@ti.com --- drivers/video/omap2/omapfb/omapfb-main.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index 6a704f1..55bed89 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -2133,6 +2133,8 @@ static int omapfb_parse_def_modes(struct omapfb2_device *fbdev) int r = 0; str = kmalloc(strlen(def_mode) + 1, GFP_KERNEL); + if (str == NULL) + return -EINVAL; Shouldn't be rerutn _ENNOMEM; instead to get correct error code? [Samreen] Will fix this. strcpy(str, def_mode); options = str; -- 1.5.6.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 thank, marek-- 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: DSS2: OMAPFB: Fix null pointer check
Ville Syrjälä wrote: On Fri, Nov 12, 2010 at 12:47:15PM +0100, ext Samreen wrote: A null pointer check added. Signed-off-by: Samreen samr...@ti.com --- drivers/video/omap2/omapfb/omapfb-main.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index 6a704f1..55bed89 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -2133,6 +2133,8 @@ static int omapfb_parse_def_modes(struct omapfb2_device *fbdev) int r = 0; str = kmalloc(strlen(def_mode) + 1, GFP_KERNEL); +if (str == NULL) +return -EINVAL; strcpy(str, def_mode); While you're at it you could change the code to use kstrdup(). [Samreen] Will use kstrdup() and post the patch soon. Warm Regards, Samreen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
On Mon, 15 Nov 2010 11:50:05 +0100 Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: # echo enabled /sys/class/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 227.685028] PM: Syncing filesystems ... done. [ 227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 227.880706] PM: suspend of devices complete after 117.767 msecs [ 227.889160] PM: late suspend of devices complete after 2.136 msecs [ 227.895782] Disabling non-boot CPUs ... Any idea ? Removing no_console_suspend from my bootargs made it work. However, it was previously working with no_console_suspend, and that was very useful since I need to debug things happening fairly early in the resume procedure. Any clue on how to make no_console_suspend work again ? Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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
linux-next 20101115 fails to boot on zoom3
Hi all, Linux-next as of 20101115 fails to boot up on a zoom3. earlyprintk throws the following crash. [0.00] MUX: Add partition: #1: core, flags: 0 [0.00] Unable to handle kernel paging request at virtual address 01000268 [0.00] pgd = c0004000 [0.00] [01000268] *pgd= [0.00] Internal error: Oops: 805 [#1] [0.00] last sysfs file: [0.00] Modules linked in: [0.00] CPU: 0Tainted: GW(2.6.37-rc1-mode1-debug+ #8) [0.00] PC is at omap_mux_write+0x1c/0x28 [0.00] LR is at omap_mux_write_array+0x30/0x44 [0.00] pc : [c04a9798]lr : [c04a97d4]psr: 4013 [0.00] sp : c7819ee0 ip : c7819ef0 fp : c7819eec [0.00] r10: 0002 r9 : c786b9c8 r8 : c048e078 [0.00] r7 : c782a480 r6 : fa002030 r5 : c048ec14 r4 : 0004 [0.00] r3 : 01000100 r2 : 0168 r1 : 011c r0 : fa002030 [0.00] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387f Table: 80004019 DAC: 0017 [0.00] Process swapper (pid: 1, stack limit = 0xc78182f0) [0.00] Stack: (0xc7819ee0 to 0xc781a000) [0.00] 9ee0: c7819f0c c7819ef0 c04a97d4 c04a9788 c782a480 c786b9c0 c097b3a8 [0.00] 9f00: c7819f64 c7819f10 c000f1a4 c04a97b0 c07f3b48 c07f3a50 c09708b0 [0.00] 9f20: c08d0300 c782a494 c7819f44 c7819f38 c09708b0 c7819f6c c002f600 [0.00] 9f40: c000ba2c c04c7434 c7819f84 c7819f68 [0.00] 9f60: c0010364 c000ed38 c048b7c8 c048aad8 c048ec14 c048a160 c7819f94 c7819f88 [0.00] 9f80: c0013224 c00102d8 c7819fa4 c7819f98 c000ba4c c0013218 c7819fdc c7819fa8 [0.00] 9fa0: c04943d4 c000ba38 0191 c0008644 c04c7434 0013 c002f600 c0008644 [0.00] 9fc0: c04c7434 0013 c7819ff4 c7819fe0 c00086e0 c049430c [0.00] 9fe0: c7819ff8 c04c7434 c0008650 fdff fffe [0.00] Backtrace: [0.00] [c04a977c] (omap_mux_write+0x0/0x28) from [c04a97d4] (omap_mux_write_array+0x30/0x44) [0.00] [c04a97a4] (omap_mux_write_array+0x0/0x44) from [c000f1a4] (omap_mux_init+0x478/0x4e4) [0.00] r6:c097b3a8 r5:c786b9c0 r4:c782a480 r3: [0.00] [c000ed2c] (omap_mux_init+0x0/0x4e4) from [c0010364] (omap3_mux_init+0x98/0xc4) [0.00] [c00102cc] (omap3_mux_init+0x0/0xc4) from [c0013224] (omap_zoom_init+0x18/0x54) [0.00] [c001320c] (omap_zoom_init+0x0/0x54) from [c000ba4c] (customize_machine+0x20/0x2c) [0.00] [c000ba2c] (customize_machine+0x0/0x2c) from [c04943d4] (do_one_initcall+0xd4/0x1a8) [0.00] [c0494300] (do_one_initcall+0x0/0x1a8) from [c00086e0] (kernel_init+0x9c/0x154) [0.00] [c0008644] (kernel_init+0x0/0x154) from [c04c7434] (do_exit+0x0/0x5f0) [0.00] r4: r3: [0.00] Code: e5903004 e3130001 e5903010 16ef1071 (018210b3) [0.00] ---[ end trace 1b75b31a2719ed1e ]--- [0.00] Kernel panic - not syncing: Attempted to kill init! I've bisected it down to this commit: commit 78b017cab9338a015d8c20d6b1e35f276073a35a Author: Benoit Cousson b-cous...@ti.com Date: Thu Nov 11 22:35:16 2010 +0100 OMAP: mux: Add support for control module split in several partitions Just reporting for now. I'll take a stab at fixing this tomorrow, unless someone beats me to it. - Anand -- 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: BeagleBoard not resuming from uart with latest pm-core ?
On Mon, Nov 15, 2010 at 6:43 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Mon, 15 Nov 2010 11:50:05 +0100 Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: # echo enabled /sys/class/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 227.685028] PM: Syncing filesystems ... done. [ 227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 227.880706] PM: suspend of devices complete after 117.767 msecs [ 227.889160] PM: late suspend of devices complete after 2.136 msecs [ 227.895782] Disabling non-boot CPUs ... Any idea ? Removing no_console_suspend from my bootargs made it work. However, it was previously working with no_console_suspend, and that was very useful since I need to debug things happening fairly early in the resume procedure. Any clue on how to make no_console_suspend work again ? Can you check if you have below two patches in the kernel you have? http://www.spinics.net/lists/linux-serial/msg02684.html http://www.spinics.net/lists/linux-serial/msg02683.html If not there can you check applying these two patch -- Regards, Govindraj.R Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 06/14] OMAP: Voltage layer changes to support DVFS.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, November 12, 2010 5:04 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v2 06/14] OMAP: Voltage layer changes to support DVFS.
Thara Gopinath th...@ti.com writes:
This patch introduces an API to take in the voltage domain and the
new voltage as parameter and to scale all the scalable devices
associated with the the voltage domain to the rate corresponding to the
new voltage and scale the voltage domain to the new voltage.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 72
+
arch/arm/plat-omap/include/plat/voltage.h |7 +++
2 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6c2e4ef..458f8c1 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -27,9 +27,11 @@
#include linux/spinlock.h
#include linux/plist.h
#include linux/slab.h
+#include linux/opp.h
#include plat/common.h
#include plat/voltage.h
+#include plat/omap_device.h
#include prm-regbits-34xx.h
#include prm44xx.h
@@ -1678,6 +1680,76 @@ struct voltagedomain
*omap_voltage_domain_lookup(char *name)
}
/**
+ * omap_voltage_scale : API to scale the devices associated with a
+ * voltage domain vdd voltage.
+ * @volt_domain : the voltage domain to be scaled
+ * @volt : the new voltage for the voltage domain
+ *
+ * This API runs through the list of devices associated with the
+ * voltage domain and scales the device rates to those corresponding
+ * to the new voltage of the voltage domain. This API also scales
+ * the voltage domain voltage to the new value. Returns 0 on success
+ * else the error value.
+ */
+int omap_voltage_scale(struct voltagedomain *voltdm, unsigned long volt)
+{
+ unsigned long curr_volt;
+ int is_volt_scaled = 0;
+ struct omap_vdd_info *vdd;
+ struct omap_vdd_dev_list *temp_dev;
+
+ if (!voltdm || IS_ERR(voltdm)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return -EINVAL;
+ }
+
+ vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
+
+ mutex_lock(vdd-scaling_mutex);
+
+ curr_volt = omap_voltage_get_nom_volt(voltdm);
+
+ if (curr_volt == volt) {
+ is_volt_scaled = 1;
+ } else if (curr_volt volt) {
+ omap_voltage_scale_vdd(voltdm, volt);
+ is_volt_scaled = 1;
+ }
+
+ list_for_each_entry(temp_dev, vdd-dev_list, node) {
+ struct device *dev;
+ struct opp *opp;
+ unsigned long freq;
+
+ dev = temp_dev-dev;
+
+ opp = opp_find_voltage(dev, volt);
+ if (IS_ERR(opp)) {
+ dev_err(dev, %s: Unable to find OPP for
+ volt%ld\n, __func__, volt);
+ continue;
+ }
+
+ freq = opp_get_freq(opp);
+
+ if (freq == omap_device_get_rate(dev)) {
+ dev_warn(dev, %s: Already at the requested
+ rate %ld\n, __func__, freq);
Does this need to be a warning? This happens relatively often and is normal.
This should probably just be removed in favor of
if (freq != omap_device_get_rate(dev))
omap_device_set_rate(dev, freq);
Yes. There are other warnings also in the dvfs code
which could be removed. Will remove them all in the next
version
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
Hello Govindraj, On Mon, 15 Nov 2010 19:24:05 +0530 Govindraj govindraj...@gmail.com wrote: Can you check if you have below two patches in the kernel you have? http://www.spinics.net/lists/linux-serial/msg02684.html http://www.spinics.net/lists/linux-serial/msg02683.html If not there can you check applying these two patch I have both of these patches in my kernel (I'm running the latest pm-core from Kevin's repository). See http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=history;f=drivers/serial/serial_core.c;h=c4ea14670d4486fc142df31d806c528d2752c238;hb=pm-core. Thanks for the hint, anyway. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 v3 0/2] OMAP3: Display Support
On Mon, 2010-11-15 at 07:09 +0100, ext Samreen wrote: This patch series adds the Display Support for OMAP3 platforms and the corresponding changes in the board files. Version3: - Rebase to the latest LO Version2: - Optimised to configure INTBR from gpio to PWM1 mode setting and enabling of the PWM1 mode only when its not in PWM1 mode. Kishore Y (2): OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3 OMAP3: Enable display on ZOOM2/3/3630SDP arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-display.c | 168 + arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++- arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + arch/arm/mach-omap2/include/mach/board-zoom.h |3 + 7 files changed, 224 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-display.c Thanks, applied. 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 1/6] OMAP4: Add the new voltage to vsel calculation formula
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, November 04, 2010 10:54 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; khil...@deeprootsystems.com;
Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 1/6] OMAP4: Add the new voltage to vsel calculation
formula
* Thara Gopinath th...@ti.com [101027 09:07]:
TWL6030 the power IC used along with OMAP4 in OMAP4 SDPs,
blaze boards and panda boards has a different formula
from that of TWL4030 for voltage to vsel and
vsel to voltage calculation. This patch implements the new
formula depending on the PMIC type.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp_twl_tps.c | 71
++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/opp_twl_tps.c b/arch/arm/plat-
omap/opp_twl_tps.c
index 4448fc5..358b67b 100644
--- a/arch/arm/plat-omap/opp_twl_tps.c
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -15,9 +15,16 @@
#include linux/module.h
+#include linux/i2c/twl.h
+
#include plat/opp_twl_tps.h
#include plat/voltage.h
+static bool is_offset_valid;
+static u8 smps_offset;
+
+#define REG_SMPS_OFFSET 0xE0
+
/**
* omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
* @vsel: TWL/TPS VSEL value to convert
@@ -27,6 +34,38 @@
*/
unsigned long omap_twl_vsel_to_uv(const u8 vsel)
{
+ if (twl_class_is_6030()) {
+ /*
+* In TWL6030 depending on the value of SMPS_OFFSET
+* efuse register the voltage range supported in
+* standard mode can be either between 0.6V - 1.3V or
+* 0.7V - 1.4V. In TWL6030 ES1.0 SMPS_OFFSET efuse
+* is programmed to all 0's where as starting from
+* TWL6030 ES1.1 the efuse is programmed to 1
+*/
+ if (!is_offset_valid) {
+ twl_i2c_read_u8(TWL6030_MODULE_ID0, smps_offset, 0xE0);
+ is_offset_valid = true;
+ }
+
+ if (smps_offset 0x8) {
+ return vsel - 1) * 125) + 7000)) * 100;
+ } else {
+ /*
+* In case of the supported voltage range being
+* between 0.6V - 1.3V, there is not specific
+* formula for voltage to vsel conversion above
+* 1.3V. There are special hardcoded values for
+* voltages above 1.3V. Currently we are hardcodig
+* only for 1.35 V which is used for 1GH OPP for
+* OMAP4430.
+*/
+ if (vsel == 0x3A)
+ return 135;
+ return vsel - 1) * 125) + 6000)) * 100;
+ }
+ }
+
return (((vsel * 125) + 6000)) * 100;
}
Here too you will want to restructure things a bit so you can avoid
adding the if twl_class_is_whatever else if tests. Usually the best
way is to set separate functions for different chips during the init.
Hello Tony,
Thanks for the review.
There is another comment for this patch to drop this file all-together
and move this code to drivers/mfd/twl-core.c. Will take care of your
comment in the new location
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 3/6] OMAP4: PM: Program correct init voltages for scalable VDDs
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, November 04, 2010 10:50 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; khil...@deeprootsystems.com;
Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 3/6] OMAP4: PM: Program correct init voltages for
scalable VDDs
Hi Thara,
* Thara Gopinath th...@ti.com [101027 09:08]:
By default the system boots up at nominal voltage for every
voltage domain in the system. This patch puts vdd_mpu, vdd_iva
and vdd_core to the correct boot up voltage as per the opp tables
specified. This patch implements this by matching the rate of
the main clock of the voltage domain with the opp table and
picking up the correct voltage.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 353e155..0651667 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -211,6 +211,10 @@ static int __init omap2_common_pm_init(void)
if (cpu_is_omap34xx()) {
omap2_set_init_voltage(mpu, dpll1_ck, mpu_dev);
omap2_set_init_voltage(core, l3_ick, l3_dev);
+ } else if (cpu_is_omap44xx()) {
+ omap2_set_init_voltage(mpu, dpll_mpu_ck, mpu_dev);
+ omap2_set_init_voltage(core, l3_div_ck, l3_dev);
+ omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva_dev);
}
omap_pm_if_init();
In general, we want to avoid adding these if cpu_is_ompa34xx else if
things all over the place. That makes the code hard to maintain and
requires patching all over the place to add support for new omaps.
Instead, please do something like this:
static int __init omap_common_whatever_init(struct whatever_data *d)
{
...
return 0;
}
static int __init omap3_whatever_init(void)
{
struct whatever_data *d;
if (!cpu_is_omap34xx())
return -ENODEV;
/* Initialize omap3 specific things */
...
return omap_common_whatever_init(d);
}
device_initcall(omap3_whatever_init);
static int __init omap4_whatever_init(void)
{
struct whatever_data *d;
if (!cpu_is_omap44xx())
return -ENODEV;
/* Initialize omap4 specific things */
...
return omap_common_whatever_init(d);
}
device_initcall(omap4_whatever_init);
...
This way the common code stays readable and does not need
to be patched when support for new omaps is added. Also the
code for unselected omaps gets optimized out and an extra
level of code indentation is left out.
Yes. Will take care of this in the next version
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message-
From: Sripathy, Vishwanath
Sent: Thursday, November 11, 2010 11:30 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sawant,
Anand
Subject: RE: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for
OMAP3
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for
OMAP3
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/voltage.c | 1158
+
arch/arm/plat-omap/include/plat/voltage.h | 141
3 files changed, 1301 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/voltage.c
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-
omap2/Makefile
index 0b6d9af..bfdabcc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -51,7 +51,8 @@ obj-$(CONFIG_ARCH_OMAP2) +=
sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
cpuidle34xx.o pm_bus.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
voltage.o \
+ cpuidle34xx.o pm_bus.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
omap2/voltage.c
new file mode 100644
index 000..5aa5109
--- /dev/null
+++ b/arch/arm/mach-omap2/voltage.c
@@ -0,0 +1,1158 @@
+/*
+ * OMAP3/OMAP4 Voltage Management Routines
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ * Lesly A M x0080...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/debugfs.h
+#include linux/slab.h
+
+#include plat/common.h
+#include plat/voltage.h
+
+#include prm-regbits-34xx.h
+
+#define VP_IDLE_TIMEOUT200
+#define VP_TRANXDONE_TIMEOUT 300
+#define VOLTAGE_DIR_SIZE 16
+
+static struct dentry *voltage_dir;
+/* PRM voltage module */
+static u32 volt_mod;
+
+/* Voltage processor register offsets */
+struct vp_reg_offs {
+ u8 vpconfig;
+ u8 vstepmin;
+ u8 vstepmax;
+ u8 vlimitto;
+ u8 vstatus;
+ u8 voltage;
+};
+
+/* Voltage Processor bit field values, shifts and masks */
+struct vp_reg_val {
+ /* VPx_VPCONFIG */
+ u32 vpconfig_erroroffset;
+ u16 vpconfig_errorgain;
+ u32 vpconfig_errorgain_mask;
+ u8 vpconfig_errorgain_shift;
+ u32 vpconfig_initvoltage_mask;
+ u8 vpconfig_initvoltage_shift;
+ u32 vpconfig_timeouten;
+ u32 vpconfig_initvdd;
+ u32 vpconfig_forceupdate;
+ u32 vpconfig_vpenable;
+ /* VPx_VSTEPMIN */
+ u8 vstepmin_stepmin;
+ u16 vstepmin_smpswaittimemin;
+ u8 vstepmin_stepmin_shift;
+ u8 vstepmin_smpswaittimemin_shift;
+ /* VPx_VSTEPMAX */
+ u8 vstepmax_stepmax;
+ u16 vstepmax_smpswaittimemax;
+ u8 vstepmax_stepmax_shift;
+ u8 vstepmax_smpswaittimemax_shift;
+ /* VPx_VLIMITTO */
+ u16 vlimitto_vddmin;
+ u16 vlimitto_vddmax;
+ u16 vlimitto_timeout;
+ u16 vlimitto_vddmin_shift;
+ u16 vlimitto_vddmax_shift;
+ u16 vlimitto_timeout_shift;
+ /* PRM_IRQSTATUS*/
+ u32
Re: [PATCH v4 2/7] OMAP: DSS2: Represent DISPC register defines with channel as parameter
Hi,
On Mon, 2010-11-08 at 13:24 +0100, ext Archit Taneja wrote:
From: Sumit Semwal sumit.sem...@ti.com
Introduce new enum members for LCD2 Channel and corresponding Overlay Manager.
Represent some of the DISPC register defines with channel as a parameter
to differentiate between LCD, DIGIT and LCD2 channels. Replace the existing
reads/writes to these registers in this new way.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Samreen samr...@ti.com
snip
@@ -1843,9 +1847,9 @@ static void dispc_enable_digit_out(bool enable)
bool dispc_is_channel_enabled(enum omap_channel channel)
{
if (channel == OMAP_DSS_CHANNEL_LCD)
- return !!REG_GET(DISPC_CONTROL, 0, 0);
+ return !!REG_GET(DISPC_CONTROL(channel), 0, 0);
else if (channel == OMAP_DSS_CHANNEL_DIGIT)
- return !!REG_GET(DISPC_CONTROL, 1, 1);
+ return !!REG_GET(DISPC_CONTROL(channel), 1, 1);
else
BUG();
}
I don't think this is good.
Looking at the code here, it looks like we're accessing different
DISPC_CONTROL registers for LCD and DIGIT out. But we're not.
For some registers it's good to have DISPC_XXX(ch) style, when the
registers are accessed identically for different channels. Then you can
just modify the same bits in DISPC_REG(ch) register, and you don't have
to mind what the channel actually is.
But this is not the case in the function above.
The DISPC_CONTROL(ch) is defined as:
DISPC_REG(ch != 2 ? 0x0040 : 0x0238)
I don't think this is actually right. DISPC_CONTROL is not a register
defined per channel. The register at 0x40 contains bits for both
channels 0 and 1. Perhaps leave DISPC_CONTROL as it was, and add
DISPC_CONTROL2, because the registers are not used similarly for all
channels. Or you can come up with some other solution, but using channel
as argument for the macro doesn't look right.
The same comments apply to other functions using DISPC_CONTROL(channel).
(And possibly to some other registers which are similar).
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: omap4: hsmmc: Fix improper card detection while booting
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of kishore kadiyala
Sent: Monday, November 15, 2010 3:09 AM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: omap4: hsmmc: Fix improper card detection while booting
While booting OMAP4 ES2.0 boards, cards on MMC1 and MMC2 controllers
are not getting detected some times.
During reset of command/data line, wrong pointer to base address
was passed while read operation to SYSCTL register, thus impacting
the updated reset logic.
Passing correct base address fixes the issue.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Felipie Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Chris Ball c...@laptop.org
Cc: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82a1079..5d46021 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1002,7 +1002,7 @@ static inline void
omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host
*host,
* Monitor a 0-1 transition first
*/
if (mmc_slot(host).features HSMMC_HAS_UPDATED_RESET) {
- while ((!(OMAP_HSMMC_READ(host, SYSCTL) bit))
+ while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
(i++ limit))
cpu_relax();
}
--
1.7.1
Ack.
Acked-by: Madhusudhan Chikkature madhu...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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
[PATCH] omap4: enable L2 prefetching
From: Mans Rullgard m...@mansr.com Enabling L2 prefetching improves performance as shown on Panda ES2.1 board with mem test, and it has measurable impact on performances. I think we should consider it, even though it damages writes a bit. (rebased to k.org) Usually the prefetch is used at both levels together L1 + L2, however, to enable the CP15 prefetch engines, these are under security, and on GP devices, we cannot enable it(e.g. on PandaBoard). However, just enabling PL310 prefetch seems to provide performance improvement, as shown in the data below (from Ubuntu) and would be a great thing to pull in. Measurement Data: == STOCK 10.10 WITHOUT PATCH ~# ./memspeed size8388608 8192k 8M offset 8388608, 0 buffers 0x2aaad000 0x2b2ad000 copy libc 133 MB/s copy Android v5273 MB/s copy Android NEON 235 MB/s copy INT32 116 MB/s copy ASM ARM 187 MB/s copy ASM VLDM 64 204 MB/s copy ASM VLDM 128 173 MB/s copy ASM VLD1 216 MB/s read ASM ARM 286 MB/s read ASM VLDM 242 MB/s read ASM VLD1 286 MB/s write libc 1947 MB/s write ASM ARM 1943 MB/s write ASM VSTM 1942 MB/s write ASM VST1 1935 MB/s 10.10 + PATCH = ~# ./memspeed size8388608 8192k 8M offset 8388608, 0 buffers 0x2ab17000 0x2b317000 copy libc 129 MB/s copy Android v5256 MB/s copy Android NEON 356 MB/s copy INT32 127 MB/s copy ASM ARM 321 MB/s copy ASM VLDM 64 337 MB/s copy ASM VLDM 128 321 MB/s copy ASM VLD1 350 MB/s read ASM ARM 496 MB/s read ASM VLDM 470 MB/s read ASM VLD1 488 MB/s write libc 1701 MB/s write ASM ARM 1682 MB/s write ASM VSTM 1693 MB/s write ASM VST1 1681 MB/s Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Mans Rullgard m...@mansr.com --- Original: http://git.mansr.com/?p=linux-panda;a=commit;h=450b17993ba7c36cea3f2c746ae26c268563ee59 http://git.tif.ti.com/vstehle/kernel-ubuntu.git?a=shortlog;h=refs/heads/vincent/mans-patches arch/arm/mach-omap2/omap4-common.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 2f89555..a5e6126 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -64,6 +64,10 @@ static int __init omap_l2_cache_init(void) l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K); BUG_ON(!l2cache_base); + if (omap_rev() != OMAP4430_REV_ES1_0) + omap_smc1(0x109, 0x7e47); + + /* Enable PL310 L2 Cache controller */ omap_smc1(0x102, 0x1); @@ -75,7 +79,7 @@ static int __init omap_l2_cache_init(void) if (omap_rev() == OMAP4430_REV_ES1_0) l2x0_init(l2cache_base, 0x0e05, 0xcfff); else - l2x0_init(l2cache_base, 0x0e07, 0xcfff); + l2x0_init(l2cache_base, 0x7e47, 0xcfff); /* * Override default outer_cache.disable with a OMAP4 -- 1.6.3.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] omap4: enable L2 prefetching
Nishanth Menon n...@ti.com writes: From: Mans Rullgard m...@mansr.com Enabling L2 prefetching improves performance as shown on Panda ES2.1 board with mem test, and it has measurable impact on performances. I think we should consider it, even though it damages writes a bit. (rebased to k.org) Usually the prefetch is used at both levels together L1 + L2, however, to enable the CP15 prefetch engines, these are under security, and on GP devices, we cannot enable it(e.g. on PandaBoard). However, just enabling PL310 prefetch seems to provide performance improvement, as shown in the data below (from Ubuntu) and would be a great thing to pull in. What this does is enable automatic next line prefetching. With this enabled, whenever the PL310 receives a cachable read request, it automatically prefetches the following cache line as well. A larger offset can be programmed in secure mode, but the TI ROM authors neglected to include this. Testing with FFmpeg showed a speedup of 10% with this patch in some cases. -- Måns Rullgård m...@mansr.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 v2] OMAP4: Extend clock database.
Hi Thara, On Mon, 15 Nov 2010, Gopinath, Thara wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Saturday, October 30, 2010 3:07 PM Please don't remove this comment unless you're also adding the ES1 clocks back. I did not remove this. The script did :-). But I will manually add it back and post v3. The best thing to do is probably to change the script to add the comment in... - 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: linux-next 20101115 fails to boot on zoom3
* Anand Gadiyar gadi...@ti.com [101115 05:19]:
Hi all,
Linux-next as of 20101115 fails to boot up on a zoom3. earlyprintk throws
the following crash.
[0.00] MUX: Add partition: #1: core, flags: 0
[0.00] Unable to handle kernel paging request at virtual address
01000268
I'll merge the following fix into Benoit's patch. Looks like hese patches
need still a bit more testing :)
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 15 Nov 2010 09:30:11 -0800
Subject: [PATCH] omap: mux: Fix omap_mux_write_array
Otherwise we can get:
MUX: Add partition: #1: core, flags: 0
Unable to handle kernel paging request at virtual address 01000268
Also fix a cosmetic issue in omap_mux_init while.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -796,7 +796,7 @@ static void omap_mux_init_signals(struct omap_mux_partition
*partition,
struct omap_board_mux *board_mux)
{
omap_mux_set_cmdline_signals();
- omap_mux_write_array(partition-base, board_mux);
+ omap_mux_write_array(partition, board_mux);
}
#else
@@ -816,7 +816,7 @@ static void omap_mux_init_signals(struct omap_mux_partition
*partition,
static u32 mux_partitions_cnt;
-int __init omap_mux_init(const char * name, u32 flags,
+int __init omap_mux_init(const char *name, u32 flags,
u32 mux_pbase, u32 mux_size,
struct omap_mux *superset,
struct omap_mux *package_subset,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] omap4: opp: add OPP table data
This patch adds OPP tables for OMAP4. New file has been added to keep
the OMAP4 opp tables and the registration of these tables with the
generic opp framework by OMAP SoC OPP interface.
Based on:
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP4 in Kconfig
v3:
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266921/
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/opp.c | 18 +
arch/arm/mach-omap2/opp4xxx_data.h | 37
arch/arm/mach-omap2/pm.h |5
4 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp4xxx_data.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 93a91ff..0f1855a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -45,6 +45,7 @@ config ARCH_OMAP4
select ARM_GIC
select PL310_ERRATA_588369
select ARM_ERRATA_720789
+ select PM_OPP if PM
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 79c711c..d1012bd 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -152,3 +152,21 @@ int __init omap3_opp_init(void)
}
device_initcall(omap3_opp_init);
+/* omap4 opps */
+#include opp4xxx_data.h
+/**
+ * omap4_opp_init() - initialize omap4 opp table
+ */
+int __init omap4_opp_init(void)
+{
+ int r = -ENODEV;
+
+ if (!cpu_is_omap44xx())
+ return r;
+
+ r = omap_init_opp_table(omap44xx_opp_def_list,
+ ARRAY_SIZE(omap44xx_opp_def_list));
+
+ return r;
+}
+device_initcall(omap4_opp_init);
diff --git a/arch/arm/mach-omap2/opp4xxx_data.h
b/arch/arm/mach-omap2/opp4xxx_data.h
new file mode 100644
index 000..2e5fe67
--- /dev/null
+++ b/arch/arm/mach-omap2/opp4xxx_data.h
@@ -0,0 +1,37 @@
+/*
+ * OMAP4 OPP table definitions.
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ * Copyright (C) 2010 Texas Instruments Incorporated.
+ * Thara Gopinath
+ *
+ * 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.
+ */
+
+#ifndef __ASM_PLAT_OPP_OMAP4XXX_H__
+#define __ASM_PLAT_OPP_OMAP4XXX_H__
+
+static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
+ /* MPU OPP1 - OPP50 */
+ OPP_INITIALIZER(mpu, true, 3, 110),
+ /* MPU OPP2 - OPP100 */
+ OPP_INITIALIZER(mpu, true, 6, 120),
+ /* MPU OPP3 - OPP-Turbo */
+ OPP_INITIALIZER(mpu, false, 8, 126),
+ /* MPU OPP4 - OPP-SB */
+ OPP_INITIALIZER(mpu, false, 100800, 135),
+ /* L3 OPP1 - OPP50 */
+ OPP_INITIALIZER(l3_main_1, true, 1, 93),
+ /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OPP_INITIALIZER(l3_main_1, true, 2, 110),
+ /* TODO: add IVA, DSP, aess, fdif, gpu */
+};
+
+#endif /* __ASM_PLAT_OPP_OMAP4XXX_H__ */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2031f15..a43e069 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,11 +22,16 @@ extern int omap3_idle_init(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
+extern int omap4_opp_init(void);
#else
static inline int omap3_opp_init(void)
{
return -EINVAL;
}
+static inline int omap4_opp_init(void)
+{
+ return -EINVAL;
+}
#endif
struct cpuidle_params {
--
1.6.3.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 v3 0/3] OMAP: Add opp data
Series version 3 incorporating changes for the comments for using device_initcall to initialize the opp layer patches based on kernel.org 2.6.37-rc1 V2: http://marc.info/?t=12875366533r=1w=2 Kevin Hilman (1): OMAP3: remove OPP interfaces from OMAP PM layer Nishanth Menon (2): omap: opp: add OMAP3 OPP table data and common init omap4: opp: add OPP table data Documentation/arm/OMAP/omap_pm| 26 + arch/arm/mach-omap2/Kconfig |2 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/io.c |3 +- arch/arm/mach-omap2/opp.c | 172 + arch/arm/mach-omap2/opp3xxx_data.h| 82 ++ arch/arm/mach-omap2/opp4xxx_data.h| 37 ++ arch/arm/mach-omap2/pm.h | 14 +++ arch/arm/plat-omap/include/plat/omap-pm.h | 31 ++ arch/arm/plat-omap/omap-pm-noop.c | 11 +-- 10 files changed, 347 insertions(+), 33 deletions(-) create mode 100644 arch/arm/mach-omap2/opp.c create mode 100644 arch/arm/mach-omap2/opp3xxx_data.h create mode 100644 arch/arm/mach-omap2/opp4xxx_data.h 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
[PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP3 in the Kconfig
v3:
* added documentation for custom opp modification
by board files
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266911/
Documentation/arm/OMAP/omap_pm | 26 ++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/opp.c | 154
arch/arm/mach-omap2/opp3xxx_data.h | 82 +++
arch/arm/mach-omap2/pm.h |9 ++
6 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp.c
create mode 100644 arch/arm/mach-omap2/opp3xxx_data.h
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..88341f0 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,29 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+Customizing OPP for platform
+
+Defining CONFIG_PM should enable OPP layer for the silicon
+and the registration of OPP table should take place automatically.
+However, in special cases, the default OPP table may need to be
+tweaked, for e.g.:
+ * enable default OPPs which are disabled by default, but which
+ could be enabled on a platform
+ * Disable an unsupported OPP on the platform
+ * Define and add a custom opp table entry
+in these cases, the board file needs to do additional steps as follows:
+arch/arm/mach-omapx/board-xyz.c
+ #include pm.h
+
+ static void __init omap_xyz_init_irq(void)
+ {
+
+ /* Initialize the default table */
+ omapx_opp_init();
+ /* Do customization to the defaults */
+
+ }
+NOTE: omapx_opp_init will be omap3_opp_init or as required
+based on the omap family.
+
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..93a91ff 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -35,6 +35,7 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI
select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
+ select PM_OPP if PM
config ARCH_OMAP4
bool TI OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..1650a62 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,6 +64,8 @@ endif
endif
+obj-$(CONFIG_PM_OPP) += opp.o
+
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
obj-$(CONFIG_ARCH_OMAP3) += cm.o
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
new file mode 100644
index 000..79c711c
--- /dev/null
+++ b/arch/arm/mach-omap2/opp.c
@@ -0,0 +1,154 @@
+/*
+ * OMAP SoC specific OPP wrapper function
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/err.h
+#include linux/opp.h
+
+#include plat/cpu.h
+#include plat/omap_device.h
+
+#include pm.h
+
+/**
+ * struct omap_opp_def - OMAP OPP Definition
+ * @hwmod_name:Name of the hwmod for this domain
+ * @freq: Frequency in hertz corresponding to this OPP
+ * @u_volt:Nominal voltage in microvolts corresponding to this OPP
+ * @enabled: True/false - is this OPP enabled/disabled by default
+ *
+ * OMAP SOCs have a standard set of tuples consisting of frequency and voltage
+ * pairs that the device will support per voltage domain. This is called
+ * Operating Points or OPP. The actual definitions of OMAP Operating Points
+ * varies over silicon within the same family of devices. For a specific
+ * domain, you can have a set of {frequency, voltage} pairs and this is denoted
+ * by an array of omap_opp_def. As the kernel boots and more information is
+ * available, a set of these are activated based on the precise nature of
+ * device the kernel boots up on. It is interesting to remember that each IP
+ * which belongs to a voltage domain may define their own set of OPPs on top
+ * of this - but this is
[PATCH v3 3/3] OMAP3: remove OPP interfaces from OMAP PM layer
From: Kevin Hilman khil...@deeprootsystems.com
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
v3: no longer explicitly calling the init_table, instead
depending on the device_initcall to initialize as needed
v2: https://patchwork.kernel.org/patch/266931/
arch/arm/mach-omap2/io.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 31 +---
arch/arm/plat-omap/omap-pm-noop.c | 11 +-
3 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..2fe4e02 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -327,8 +327,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
else if (cpu_is_omap44xx())
omap44xx_hwmod_init();
- /* The OPP tables have to be registered before a clk init */
- omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+ omap_pm_if_early_init();
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..62c3fe9 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -17,27 +17,10 @@
#include linux/device.h
#include linux/cpufreq.h
#include linux/clk.h
+#include linux/opp.h
#include powerdomain.h
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data. Can vary by OMAP chip and board.
- */
-struct omap_opp {
- unsigned long rate;
- u8 opp_id;
- u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
-
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
*
@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
* framework starts. The _if_ is to avoid name collisions with the
* PM idle-loop code.
*/
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
/**
* omap_pm_if_init - OMAP PM init code called after clock fw init
@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp
*mpu_opp_table,
* The main initialization code. OPP tables are passed in here. The
* _if_ is to avoid name collisions with the PM idle-loop code.
*/
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
int __init omap_pm_if_init(void);
+#endif
/**
* omap_pm_if_exit - OMAP PM exit code
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..ca75abb 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -26,10 +26,6 @@
#include plat/powerdomain.h
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
/*
* Device-driver-originated constraints (via board-*.c files)
*/
@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
/* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
{
- mpu_opps = mpu_opp_table;
- dsp_opps = dsp_opp_table;
- l3_opps = l3_opp_table;
return 0;
}
--
1.6.3.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: BeagleBoard not resuming from uart with latest pm-core ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Mon, 15 Nov 2010 11:50:05 +0100 Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: # echo enabled /sys/class/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 227.685028] PM: Syncing filesystems ... done. [ 227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 227.880706] PM: suspend of devices complete after 117.767 msecs [ 227.889160] PM: late suspend of devices complete after 2.136 msecs [ 227.895782] Disabling non-boot CPUs ... Any idea ? Removing no_console_suspend from my bootargs made it work. However, it was previously working with no_console_suspend, and that was very useful since I need to debug things happening fairly early in the resume procedure. Any clue on how to make no_console_suspend work again ? Until we convert the omap-serial driver to use runtime PM (currently under development), no_console_suspend is going to be unpredictable at best. Until then, there will be races with the current UART PM code. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3
Gopinath, Thara th...@ti.com writes:
[...]
cpu_is_* checks are only acceptable at init time. This one happens
during every scale. These VC settings should be set at init time only.
Same issue with forceupdate_scale.
These masks are needed only in vc bypass voltage scaling API. I was
thinking that for using in just one API I need not maintain these
variables in the generic vdd structure. But yes this will add a
cpu_is_* check in this API. Is it preferred to have these variables
defined in the common vdd structures and populated during init even if
used only in one API?
Yes.
[...]
+void omap_vp_enable(struct voltagedomain *voltdm)
+{
+ struct omap_vdd_info *vdd;
+ u32 vpconfig;
+
+ if (!voltdm || IS_ERR(voltdm)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return;
+ }
+
+ vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
+
+ /* If VP is already enabled, do nothing. Return */
+ if (voltage_read_reg(vdd-vp_offs.vpconfig)
+ vdd-vp_reg.vpconfig_vpenable)
+ return;
Minor: is a register access here required? Why not just keep an
'vp_enabled' flag as part of the vdd struct?
I do not want to have the complications of maintaining a flag and
ensuring exclusivity.
Whether you use a flag or a register access, the ability to ensure
exclusivity does not change.
But do you think having a register read here is bad?
Yes.
s/bad/unnecessary/
Latency cannot be much as it is a single register read. If you really
think we should have a flag, I can change it.
The PRCM is on L4, so accesses to PRCM registers are all slow and should
be avoided if possible. This is an easy case where a register access
can be prevented simply by caching.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions
* Benoit Cousson b-cous...@ti.com [10 13:26]:
Starting on OMAP4, the pin mux configuration is located in two
different partitions of the control module (CODE_PAD and WKUP_PAD).
The first one is inside the core power domain whereas the second
one is inside the wakeup.
- Add the capability to add any number of partition during board init
time depending of Soc partitioning.
- Add some init flags as well in order to avoid explicit Soc version
check inside the mux core code.
- Add a comment with mux0 mode on top of omap_mux/board/partition
if the current mux mode is not the default one.
Here's one more patch that I'd like to merge into this patch to avoid
repeating the partition for each mux entry.
Assuming no more comments, I'll queue these for 2.6.38 merge window.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 15 Nov 2010 11:52:20 -0800
Subject: [PATCH] omap: mux: Save memory for struct omap_mux
There's no need to repeat the partition for each mux entry.
We can look up the partition for debugfs.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -348,14 +348,37 @@ static const struct file_operations
omap_mux_dbg_board_fops = {
.release= single_release,
};
+static struct omap_mux_partition * omap_mux_get_partition(struct omap_mux *mux)
+{
+ struct omap_mux_partition *partition;
+
+ list_for_each_entry(partition, mux_partitions, node) {
+ struct list_head *muxmodes = partition-muxmodes;
+ struct omap_mux_entry *e;
+
+ list_for_each_entry(e, muxmodes, node) {
+ struct omap_mux *m = e-mux;
+
+ if (m == mux)
+ return partition;
+ }
+ }
+
+ return NULL;
+}
+
static int omap_mux_dbg_signal_show(struct seq_file *s, void *unused)
{
struct omap_mux *m = s-private;
- struct omap_mux_partition *partition = m-partition;
+ struct omap_mux_partition *partition;
const char *none = NA;
u16 val;
int mode;
+ partition = omap_mux_get_partition(m);
+ if (!partition)
+ return 0;
+
val = omap_mux_read(partition, m-reg_offset);
mode = val OMAP_MUX_MODE7;
@@ -391,6 +414,7 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
struct omap_mux *m;
unsigned long val;
int buf_size, ret;
+ struct omap_mux_partition *partition;
if (count OMAP_MUX_MAX_ARG_CHAR)
return -EINVAL;
@@ -411,7 +435,11 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
seqf = file-private_data;
m = seqf-private;
- omap_mux_write(m-partition, (u16)val, m-reg_offset);
+ partition = omap_mux_get_partition(m);
+ if (!partition)
+ return -ENODEV;
+
+ omap_mux_write(partition, (u16)val, m-reg_offset);
*ppos += count;
return count;
@@ -440,7 +468,6 @@ static void __init omap_mux_dbg_create_entry(
list_for_each_entry(e, partition-muxmodes, node) {
struct omap_mux *m = e-mux;
- m-partition = partition;
(void)debugfs_create_file(m-muxnames[0], S_IWUGO, mux_dbg_dir,
m, omap_mux_dbg_signal_fops);
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -121,7 +121,6 @@ struct omap_mux {
char*muxnames[OMAP_MUX_NR_MODES];
#ifdef CONFIG_DEBUG_FS
char*balls[OMAP_MUX_NR_SIDES];
- struct omap_mux_partition *partition;
#endif
#endif
};
--
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/2] OMAP3: Display Support
* Tomi Valkeinen tomi.valkei...@nokia.com [101115 06:32]: On Mon, 2010-11-15 at 07:09 +0100, ext Samreen wrote: This patch series adds the Display Support for OMAP3 platforms and the corresponding changes in the board files. Version3: - Rebase to the latest LO Version2: - Optimised to configure INTBR from gpio to PWM1 mode setting and enabling of the PWM1 mode only when its not in PWM1 mode. Kishore Y (2): OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3 OMAP3: Enable display on ZOOM2/3/3630SDP arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-display.c | 168 + arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++- arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + arch/arm/mach-omap2/include/mach/board-zoom.h |3 + 7 files changed, 224 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-display.c Thanks, applied. This series needs to be posted to linux-arm-kernel list also for review. Samreen, can you please repost? 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
[GIT PULL] omap fixes for 2.6.37-rc1
Hi Linus, Please pull some trivial omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Regards, Tony The following changes since commit c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4: Linux 2.6.37-rc1 (2010-11-01 07:54:12 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Felipe Balbi (1): arm: omap1: devices: need to return with a value Janusz Krzysztofik (1): OMAP1: camera.h: add missing include Mathias Nyman (1): omap: dma: Add read-back to DMA interrupt handler to avoid spuriousinterrupts Thomas Weber (1): OMAP2: Devkit8000: Fix mmc regulator failure arch/arm/mach-omap1/devices.c |5 ++--- arch/arm/mach-omap1/include/mach/camera.h |2 ++ arch/arm/mach-omap2/board-devkit8000.c|3 --- arch/arm/plat-omap/dma.c |2 ++ 4 files changed, 6 insertions(+), 6 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 2/7] OMAP: mux: Add support for control module split in several partitions
Hi Tony,
On 11/15/2010 9:03 PM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [10 13:26]:
Starting on OMAP4, the pin mux configuration is located in two
different partitions of the control module (CODE_PAD and WKUP_PAD).
The first one is inside the core power domain whereas the second
one is inside the wakeup.
- Add the capability to add any number of partition during board init
time depending of Soc partitioning.
- Add some init flags as well in order to avoid explicit Soc version
check inside the mux core code.
- Add a comment with mux0 mode on top of omap_mux/board/partition
if the current mux mode is not the default one.
Here's one more patch that I'd like to merge into this patch to avoid
repeating the partition for each mux entry.
The memory vendors will not like you ;-)
Assuming no more comments, I'll queue these for 2.6.38 merge window.
I'll update the series and re-post tomorrow.
Thanks,
Benoit
Regards,
Tony
From: Tony Lindgrent...@atomide.com
Date: Mon, 15 Nov 2010 11:52:20 -0800
Subject: [PATCH] omap: mux: Save memory for struct omap_mux
There's no need to repeat the partition for each mux entry.
We can look up the partition for debugfs.
Signed-off-by: Tony Lindgrent...@atomide.com
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -348,14 +348,37 @@ static const struct file_operations
omap_mux_dbg_board_fops = {
.release= single_release,
};
+static struct omap_mux_partition * omap_mux_get_partition(struct omap_mux *mux)
+{
+ struct omap_mux_partition *partition;
+
+ list_for_each_entry(partition,mux_partitions, node) {
+ struct list_head *muxmodes =partition-muxmodes;
+ struct omap_mux_entry *e;
+
+ list_for_each_entry(e, muxmodes, node) {
+ struct omap_mux *m =e-mux;
+
+ if (m == mux)
+ return partition;
+ }
+ }
+
+ return NULL;
+}
+
static int omap_mux_dbg_signal_show(struct seq_file *s, void *unused)
{
struct omap_mux *m = s-private;
- struct omap_mux_partition *partition = m-partition;
+ struct omap_mux_partition *partition;
const char *none = NA;
u16 val;
int mode;
+ partition = omap_mux_get_partition(m);
+ if (!partition)
+ return 0;
+
val = omap_mux_read(partition, m-reg_offset);
mode = val OMAP_MUX_MODE7;
@@ -391,6 +414,7 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
struct omap_mux *m;
unsigned long val;
int buf_size, ret;
+ struct omap_mux_partition *partition;
if (count OMAP_MUX_MAX_ARG_CHAR)
return -EINVAL;
@@ -411,7 +435,11 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
seqf = file-private_data;
m = seqf-private;
- omap_mux_write(m-partition, (u16)val, m-reg_offset);
+ partition = omap_mux_get_partition(m);
+ if (!partition)
+ return -ENODEV;
+
+ omap_mux_write(partition, (u16)val, m-reg_offset);
*ppos += count;
return count;
@@ -440,7 +468,6 @@ static void __init omap_mux_dbg_create_entry(
list_for_each_entry(e,partition-muxmodes, node) {
struct omap_mux *m =e-mux;
- m-partition = partition;
(void)debugfs_create_file(m-muxnames[0], S_IWUGO, mux_dbg_dir,
m,omap_mux_dbg_signal_fops);
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -121,7 +121,6 @@ struct omap_mux {
char*muxnames[OMAP_MUX_NR_MODES];
#ifdef CONFIG_DEBUG_FS
char*balls[OMAP_MUX_NR_SIDES];
- struct omap_mux_partition *partition;
#endif
#endif
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, November 11, 2010 12:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Thara Gopinath th...@ti.com writes: This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. The voltage parameters can be viewed at /debug/voltage/vdd_x/parameter and the smartreflex parameters can be viewed at /debug/vdd_x/smartreflex/parameter To enable overriding of these parameters from user side, write 1 into /debug/voltage/vdd_x/override_volt_params Please just git rid of any sort of override parameter from sysfs. Instead, you can detect in the sysfs code itself if any parameters were changed and then set the vdd-user_override flag. But when will I unset this flag?? You can't. And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
Hi Sricharan, On 11/15/2010 8:38 AM, R, Sricharan wrote: This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. http://www.spinics.net/lists/linux-omap/msg38995.html I've just realized that this is not the latest one, here it is: http://www.spinics.net/lists/linux-omap/msg40039.html Regards, Benoit sricharan (5): OMAP4: hsmmc: Initialise the mmc mux pins OMAP4: usb-musb: Initialise the usb mux pins. OMAP4: mcbsp: Initialise the mcbsp mux pins OMAP4: board-4430sdp: Initialise the mcspi mux pins OMAP4: serial: Initialise the uart mux pins arch/arm/mach-omap2/board-4430sdp.c | 20 arch/arm/mach-omap2/devices.c | 83 +++ arch/arm/mach-omap2/mcbsp.c | 33 +- arch/arm/mach-omap2/serial.c| 38 arch/arm/mach-omap2/usb-musb.c | 41 + 5 files changed, 214 insertions(+), 1 deletions(-) While doing some internal reviews, there were few debates about existing mux framework usage. I am summarising that discussion here and would like to hear more on this from the community. 1. PAD configuration for all pins should be done in a central place(board file) Pros: a. All pins configured in a central place. Easy to ensure coverage and maintenance. Single place to look for all mux related settings b. Drivers, unless they have run time pad configuration requirements need not worry about muxing. Cons: a. Adds a lot of duplicate data in different board files assuming most of the pins will be connected the same way across different boards. 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon n...@ti.com wrote:
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ?
Unless I'm wrong, this means that if the opp3xxx_data.h file is
included in two different C files, the structures will be present twice.
As far as I could see, most of the kernel instantiate structure in C
files instead.
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following:
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon n...@ti.com wrote:
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ?
Unless I'm wrong, this means that if the opp3xxx_data.h file is
included in two different C files, the structures will be present twice.
The intent here - DONT DO precisely THAT!
As far as I could see, most of the kernel instantiate structure in C
files instead.
The intent here though was that opp3xx.h and opp4xx.h are private to
just opp.c to prevent misuse elsewhere. hmm.. thinking a bit,
find drivers/ -iname *.c|xargs grep #include| grep -v \.h
shows numerous examples of .c files being included in c files. I dont
have an issue of renaming these headers as .c file instead (I had
carried them over as .h from old implementation, but we can change it),
main point being, I just dont want folks mucking around and hacking
stuff with the defines.
--
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: [PATCH v3 0/2] OMAP3: Display Support
Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@nokia.com [101115 06:32]: On Mon, 2010-11-15 at 07:09 +0100, ext Samreen wrote: This patch series adds the Display Support for OMAP3 platforms and the corresponding changes in the board files. Version3: - Rebase to the latest LO Version2: - Optimised to configure INTBR from gpio to PWM1 mode setting and enabling of the PWM1 mode only when its not in PWM1 mode. Kishore Y (2): OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3 OMAP3: Enable display on ZOOM2/3/3630SDP arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-display.c | 168 + arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++- arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + arch/arm/mach-omap2/include/mach/board-zoom.h |3 + 7 files changed, 224 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-display.c Thanks, applied. This series needs to be posted to linux-arm-kernel list also for review. Samreen, can you please repost? Tony [Samreen] Sure Tony, Will post it right away. Warm Regards, Samreen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Repost][PATCH v3 0/2] OMAP3: Display Support
This patch series adds the Display Support for OMAP3 platforms and the corresponding changes in the board files. Version3: - Rebase to the latest LO Version2: - Optimised to configure INTBR from gpio to PWM1 mode setting and enabling of the PWM1 mode only when its not in PWM1 mode. Kishore Y (2): OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3 OMAP3: Enable display on ZOOM2/3/3630SDP arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-display.c | 168 + arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++- arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + arch/arm/mach-omap2/include/mach/board-zoom.h |3 + 7 files changed, 224 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-display.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Repost][PATCH v3 1/2] OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
From: Kishore Y kishor...@ti.com
Board-zoom-display.c added as a common file for display functionality
on boards zoom2, zoom3 and 3630sdp.
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/board-zoom-display.c | 168 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++-
arch/arm/mach-omap2/include/mach/board-zoom.h |3 +
4 files changed, 221 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..7b20341 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -146,16 +146,19 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
new file mode 100644
index 000..6bcd436
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-zoom-peripherals.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c/twl.h
+#include linux/spi/spi.h
+#include plat/mcspi.h
+#include plat/display.h
+
+#define LCD_PANEL_RESET_GPIO_PROD 96
+#define LCD_PANEL_RESET_GPIO_PILOT 55
+#define LCD_PANEL_QVGA_GPIO56
+
+static void zoom_lcd_panel_init(void)
+{
+ int ret;
+ unsigned char lcd_panel_reset_gpio;
+
+ lcd_panel_reset_gpio = (omap_rev() OMAP3430_REV_ES3_0) ?
+ LCD_PANEL_RESET_GPIO_PROD :
+ LCD_PANEL_RESET_GPIO_PILOT;
+
+ ret = gpio_request(lcd_panel_reset_gpio, lcd reset);
+ if (ret) {
+ pr_err(Failed to get LCD reset GPIO (gpio%d).\n,
+ lcd_panel_reset_gpio);
+ return;
+ }
+ gpio_direction_output(lcd_panel_reset_gpio, 1);
+
+ ret = gpio_request(LCD_PANEL_QVGA_GPIO, lcd qvga);
+ if (ret) {
+ pr_err(Failed to get LCD_PANEL_QVGA_GPIO (gpio%d).\n,
+ LCD_PANEL_QVGA_GPIO);
+ goto err0;
+ }
+ gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
+
+ return;
+err0:
+ gpio_free(lcd_panel_reset_gpio);
+}
+
+static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+}
+
+/*
+ * PWMA/B register offsets (TWL4030_MODULE_PWMA)
+ */
+#define TWL_INTBR_PMBR10xD
+#define TWL_INTBR_GPBR10xC
+#define TWL_LED_PWMON 0x0
+#define TWL_LED_PWMOFF 0x1
+
+static int zoom_set_bl_intensity(struct omap_dss_device *dssdev, int level)
+{
+ unsigned char c;
+ u8 mux_pwm, enb_pwm;
+
+ if (level 100)
+ return -1;
+
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, mux_pwm, TWL_INTBR_PMBR1);
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, enb_pwm, TWL_INTBR_GPBR1);
+
+ if (level == 0) {
+ /* disable pwm1 output and clock */
+ enb_pwm = enb_pwm 0xF5;
+ /* change pwm1 pin to gpio pin */
+ mux_pwm = mux_pwm 0xCF;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR,
+ enb_pwm, TWL_INTBR_GPBR1);
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR,
+
[Repost][PATCH v3 2/2] OMAP3: Enable display on ZOOM2/3/3630SDP
From: Kishore Y kishor...@ti.com
Enable Display on zoom2, zoom3 and 3630sdp boards.
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |1 +
arch/arm/mach-omap2/board-zoom2.c |1 +
arch/arm/mach-omap2/board-zoom3.c |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index bbcf580..bf990b6 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -209,6 +209,7 @@ static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
+ zoom_display_init();
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_sdp);
enable_board_wakeup_source();
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 2992a9f..1cd6414 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -105,6 +105,7 @@ static void __init omap_zoom2_init(void)
board_nand_init(zoom_nand_partitions,
ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
+ zoom_display_init();
}
MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board)
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 5adde12..1523369 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -118,6 +118,7 @@ static void __init omap_zoom_init(void)
board_nand_init(zoom_nand_partitions,
ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
+ zoom_display_init();
omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
usb_ehci_init(ehci_pdata);
--
1.5.6.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 0/3] OMAP: DSS2: introduce generic panel display driver (try #6)
There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset introduces a generic panel DPI driver, remove 3 panel drivers and enable generic panel DPI driver in board files. And it is based on 2.6.37-rc1. Building with omap2plus_defconfig is successful. Keep sharp_ls_panel, since it contains blacklight control code which will be moved out later. Bryan Wu (3): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers arch/arm/mach-omap2/board-3430sdp.c| 12 +- arch/arm/mach-omap2/board-am3517evm.c | 23 +- arch/arm/mach-omap2/board-cm-t35.c | 23 +- arch/arm/mach-omap2/board-devkit8000.c | 26 +- arch/arm/mach-omap2/board-igep0020.c | 12 +- arch/arm/mach-omap2/board-omap3beagle.c| 12 +- arch/arm/mach-omap2/board-omap3evm.c | 12 +- arch/arm/mach-omap2/board-omap3stalker.c | 23 +- .../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 +++ drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile |4 +- drivers/video/omap2/displays/panel-generic-dpi.c | 333 drivers/video/omap2/displays/panel-generic.c | 174 -- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -- .../video/omap2/displays/panel-toppoly-tdo35s.c| 164 -- 15 files changed, 482 insertions(+), 560 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c delete mode 100644 drivers/video/omap2/displays/panel-generic.c delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 +++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 333
4 files changed, 379 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@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, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include display.h
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC_DPI
+tristate Generic DPI Panel
+help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
config PANEL_GENERIC
tristate Generic Panel
help
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..c3fff9e
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,333 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include plat/panel-generic-dpi.h
+
+struct panel_config {
+ struct omap_video_timings timings;
+
+ int acbi; /* ac-bias pin transitions per interrupt */
+ /* Unit: line clocks */
+ int acb;/* ac-bias pin frequency */
+
+ enum omap_panel_config
[PATCH 2/3] OMAP: use generic DPI panel driver in board files
Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight
control driver code which will be moved out later. Then we can use generic DPI
driver for sharp_ls_panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-omap2/board-3430sdp.c | 12 +---
arch/arm/mach-omap2/board-am3517evm.c| 23 +--
arch/arm/mach-omap2/board-cm-t35.c | 23 +--
arch/arm/mach-omap2/board-devkit8000.c | 26 ++
arch/arm/mach-omap2/board-igep0020.c | 12 +---
arch/arm/mach-omap2/board-omap3beagle.c | 12 +---
arch/arm/mach-omap2/board-omap3evm.c | 12 +---
arch/arm/mach-omap2/board-omap3stalker.c | 23 +--
8 files changed, 105 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..1ca0156 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -38,6 +38,7 @@
#include plat/dma.h
#include plat/gpmc.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/gpmc-smc91x.h
@@ -270,13 +271,18 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable = sdp3430_panel_disable_lcd,
};
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= sdp3430_panel_enable_dvi,
+ .platform_disable = sdp3430_panel_disable_dvi,
+};
+
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= sdp3430_panel_enable_dvi,
- .platform_disable = sdp3430_panel_disable_dvi,
};
static struct omap_dss_device sdp3430_tv_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..851683f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
#include plat/common.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include mux.h
#include control.h
@@ -303,13 +304,18 @@ static void am3517_evm_panel_disable_lcd(struct
omap_dss_device *dssdev)
lcd_enabled = 0;
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= am3517_evm_panel_enable_lcd,
+ .platform_disable = am3517_evm_panel_disable_lcd,
+};
+
static struct omap_dss_device am3517_evm_lcd_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = lcd,
- .driver_name= sharp_lq_panel,
+ .driver_name= generic_dpi_panel,
+ .data = lcd_panel,
.phy.dpi.data_lines = 16,
- .platform_enable= am3517_evm_panel_enable_lcd,
- .platform_disable = am3517_evm_panel_disable_lcd,
};
static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -346,13 +352,18 @@ static void am3517_evm_panel_disable_dvi(struct
omap_dss_device *dssdev)
dvi_enabled = 0;
}
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= am3517_evm_panel_enable_dvi,
+ .platform_disable = am3517_evm_panel_disable_dvi,
+};
+
static struct omap_dss_device am3517_evm_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= am3517_evm_panel_enable_dvi,
- .platform_disable = am3517_evm_panel_disable_dvi,
};
static struct omap_dss_device *am3517_evm_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..e91c986 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -46,6 +46,7 @@
#include plat/gpmc.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/mcspi.h
#include mach/hardware.h
@@ -351,22 +352,32 @@ static void cm_t35_panel_disable_tv(struct
omap_dss_device *dssdev)
{
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = toppoly_tdo35s,
+ .platform_enable= cm_t35_panel_enable_lcd,
+ .platform_disable = cm_t35_panel_disable_lcd,
+};
+
static struct omap_dss_device cm_t35_lcd_device = {
.name
[PATCH 3/3] OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
Still keep sharp_ls_panel driver, because it contains blacklight control driver.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/omap2/displays/Kconfig | 18 --
drivers/video/omap2/displays/Makefile |3 -
drivers/video/omap2/displays/panel-generic.c | 174
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 ---
.../video/omap2/displays/panel-toppoly-tdo35s.c| 164 --
5 files changed, 0 insertions(+), 524 deletions(-)
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index cb3e339..9c09afd 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -9,12 +9,6 @@ config PANEL_GENERIC_DPI
Supports LCD Panel used in TI SDP3430 and EVM boards,
OMAP3517 EVM boards and CM-T35.
-config PANEL_GENERIC
-tristate Generic Panel
-help
- Generic panel driver.
- Used for DVI output for Beagle and OMAP3 SDP.
-
config PANEL_SHARP_LS037V7DW01
tristate Sharp LS037V7DW01 LCD Panel
depends on OMAP2_DSS
@@ -22,24 +16,12 @@ config PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
-config PANEL_SHARP_LQ043T1DG01
-tristate Sharp LQ043T1DG01 LCD Panel
-depends on OMAP2_DSS
-help
- LCD Panel used in TI's OMAP3517 EVM boards
-
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
help
Taal DSI command mode panel from TPO.
-config PANEL_TOPPOLY_TDO35S
-tristate Toppoly TDO35S LCD Panel support
-depends on OMAP2_DSS
-help
- LCD Panel used in CM-T35
-
config PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on OMAP2_DSS SPI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 022058c..3bebe4d 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,9 +1,6 @@
obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
-obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
-obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
-obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
deleted file mode 100644
index 395a68d..000
--- a/drivers/video/omap2/displays/panel-generic.c
+++ /dev/null
@@ -1,174 +0,0 @@
-/*
- * Generic panel support
- *
- * Copyright (C) 2008 Nokia Corporation
- * Author: Tomi Valkeinen tomi.valkei...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see http://www.gnu.org/licenses/.
- */
-
-#include linux/module.h
-#include linux/delay.h
-
-#include plat/display.h
-
-static struct omap_video_timings generic_panel_timings = {
- /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
- .x_res = 640,
- .y_res = 480,
- .pixel_clock= 23500,
- .hfp= 48,
- .hsw= 32,
- .hbp= 80,
- .vfp= 3,
- .vsw= 4,
- .vbp= 7,
-};
-
-static int generic_panel_power_on(struct omap_dss_device *dssdev)
-{
- int r;
-
- if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
- return 0;
-
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
-
- if (dssdev-platform_enable) {
- r = dssdev-platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
- return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
-err0:
- return r;
-}
-
-static void generic_panel_power_off(struct omap_dss_device *dssdev)
-{
- if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
- return;
-
- if (dssdev-platform_disable)
- dssdev-platform_disable(dssdev);
-
-
RE: [PATCH v4 2/7] OMAP: DSS2: Represent DISPC register defines with channel as parameter
Hi,
Tomi Valkeinen wrote:
Hi,
On Mon, 2010-11-08 at 13:24 +0100, ext Archit Taneja wrote:
From: Sumit Semwal sumit.sem...@ti.com
Introduce new enum members for LCD2 Channel and corresponding Overlay
Manager.
Represent some of the DISPC register defines with channel as a
parameter to differentiate between LCD, DIGIT and LCD2 channels.
Replace the existing reads/writes to these registers in this new way.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Samreen samr...@ti.com
snip
@@ -1843,9 +1847,9 @@ static void
dispc_enable_digit_out(bool enable)
bool dispc_is_channel_enabled(enum omap_channel channel) {
if (channel == OMAP_DSS_CHANNEL_LCD)
- return !!REG_GET(DISPC_CONTROL, 0, 0);
+ return !!REG_GET(DISPC_CONTROL(channel), 0, 0);
else if (channel == OMAP_DSS_CHANNEL_DIGIT)
- return !!REG_GET(DISPC_CONTROL, 1, 1);
+ return !!REG_GET(DISPC_CONTROL(channel), 1, 1); else
BUG();
}
I don't think this is good.
Looking at the code here, it looks like we're accessing
different DISPC_CONTROL registers for LCD and DIGIT out. But we're not.
For some registers it's good to have DISPC_XXX(ch) style,
when the registers are accessed identically for different
channels. Then you can just modify the same bits in
DISPC_REG(ch) register, and you don't have to mind what the channel actually
is.
But this is not the case in the function above.
The DISPC_CONTROL(ch) is defined as:
DISPC_REG(ch != 2 ? 0x0040 : 0x0238)
I don't think this is actually right. DISPC_CONTROL is not a
register defined per channel. The register at 0x40 contains
bits for both channels 0 and 1. Perhaps leave DISPC_CONTROL
as it was, and add DISPC_CONTROL2, because the registers are
not used similarly for all channels. Or you can come up with
some other solution, but using channel as argument for the macro doesn't look
right.
Yes, this holds for DISPC_CONTROL and DISPC_CONFIG registers, I didn't
think it would be wrong if 2 channels point to the same register field.
But apart from that, there are some bits in these registers which are
not specific to any channel and doing something like this would be misleading,
For setting fifiomerge:
REG_FLD_MOD(DISPC_CONFIG(OMAP_DSS_CHANNEL_LCD), enable ? 1 : 0, 14, 14);
Since the above bit is not specific to LCD channel.
I'll keep these 2 registers the way they are.
Thanks,
Archit--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
Adding people in CC. This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. http://www.spinics.net/lists/linux-omap/msg40039.html sricharan (5): OMAP4: hsmmc: Initialise the mmc mux pins OMAP4: usb-musb: Initialise the usb mux pins. OMAP4: mcbsp: Initialise the mcbsp mux pins OMAP4: board-4430sdp: Initialise the mcspi mux pins OMAP4: serial: Initialise the uart mux pins arch/arm/mach-omap2/board-4430sdp.c | 20 arch/arm/mach-omap2/devices.c | 83 +++ arch/arm/mach-omap2/mcbsp.c | 33 +- arch/arm/mach-omap2/serial.c| 38 arch/arm/mach-omap2/usb-musb.c | 41 + 5 files changed, 214 insertions(+), 1 deletions(-) While doing some internal reviews, there were few debates about existing mux framework usage. I am summarising that discussion here and would like to hear more on this from the community. 1. PAD configuration for all pins should be done in a central place(board file) Pros: a. All pins configured in a central place. Easy to ensure coverage and maintenance. Single place to look for all mux related settings b. Drivers, unless they have run time pad configuration requirements need not worry about muxing. Cons: a. Adds a lot of duplicate data in different board files assuming most of the pins will be connected the same way across different boards. 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On Sat, Nov 13, 2010 at 12:44:42AM +0100, Gregory CLEMENT wrote:
When SPI wake up from OFF mode, CS is in the wrong state: force it
to the inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable
the clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode
activated that on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Looks okay to me, but I'd like to get an ack from other users before I
merge it. Also some minor comments below.
---
drivers/spi/omap2_mcspi.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..43d92fc 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,46 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to
unactive state at
Patch is line-wrap damaged. Check your mailer configuration.
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+ struct spi_master *master;
+ struct omap2_mcspi_cs *cs;
+ struct omap2_mcspi *mcspi;
+
+ master = dev_get_drvdata(pdev-dev);
+ mcspi = spi_master_get_devdata(master);
These 5 lines can be collapsed a bit:
struct spi_master *master = dev_get_drvdata(pdev-dev);
struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
struct omap2_mcspi_cs *cs;
+ omap2_mcspi_enable_clocks(mcspi);
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node) {
+ if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+ /* We need to togle CS state for OMAP take this
spelling. s/togle/toggle
+ * change in account.
+ */
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ }
+ }
+ omap2_mcspi_disable_clocks(mcspi);
+ return 0;
+}
+#else
+#define omap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+ .resume = omap2_mcspi_resume,
.remove = __exit_p(omap2_mcspi_remove),
};
-- 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
