[PATCH] media: omap3isp: fix format string warning
Trivially fix this:
drivers/media/video/omap3isp/isp.c: In function 'isp_isr_dbg':
drivers/media/video/omap3isp/isp.c:394: warning: zero-length gnu_printf format
string
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 472a693..a0d5e69 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -391,7 +391,7 @@ static inline void isp_isr_dbg(struct isp_device *isp, u32
irqstatus)
};
int i;
- dev_dbg(isp-dev, );
+ dev_dbg(isp-dev, %s\n, __func__);
for (i = 0; i ARRAY_SIZE(name); i++) {
if ((1 i) irqstatus)
--
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: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@ti.com writes: [...] In general we do not want to reset nor idle an IP that was potentially already properly configured by bootloader or early Linux boot code. Actually, the opposite is true. The kernel should not make any assumptions about what the bootloader has or has not done. We need to have a kernel that can boot from any bootloader (or none, like using kexec) and be able to start from a known hardware state. YES. Bootloaders should only do what is necessary (set clocks, enable memories etc) to load the next stage. Pushing stuff that should be in the kernel into the bootloader (like iniiting gpios and other things) bloats it and makes a developer deal with two entirely different source trees (kernel and booterx) to enable a new feature or to fix bugs. Uboot tends to lag the kernel in capabilities too, probably because fewer developers or something. For instance Beagleboard xm uboot cannot access the ethernet because it is usb based, and uboot cannot access its own environment in flash - because it is running from a new microsd based flash system. U-boot will eventually catch up with these, but by then other new hardware will be available. Does anyone know if 2.6.39 has kexec working again for the kernel? NFS boot is a dream development environment but with both u-boot and kexec not working with nfs, it is slightly more work and less automated. Regards, Steve -- 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
[pm_wip/voltdm_nm][PATCH v2 0/4] OMAP4: PM: Voltage cleanups
The following patches are on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm-wip/voltdm_nm Tested on: SDP4430 This is v2 of the series (of which most of the patches were incorporated) Dropped patches: http://marc.info/?l=linux-omapm=130570864519114w=2 - Agree that we should wait for regulators Pending: http://marc.info/?l=linux-omapm=130569587107997w=2 - I have a bunch of scope pictures and xls from which this data was created, so no equation yet available. Updated patches: http://marc.info/?l=linux-omapm=130569587007994w=2 - review comments v1: http://marc.info/?l=linux-omapm=130569586007964w=2 Nishanth Menon (3): OMAP4: PM: VC: fix channel bit offset for MPU OMAP4: PM: VC: introduce concept of default channel OMAP4: PM: VC: make omap_vc_i2c_init static arch/arm/mach-omap2/vc.c | 82 ++--- arch/arm/mach-omap2/vc.h | 37 +++- arch/arm/mach-omap2/vc3xxx_data.c | 11 + arch/arm/mach-omap2/vc44xx_data.c | 22 ++ arch/arm/mach-omap2/voltage.h |9 5 files changed, 125 insertions(+), 36 deletions(-) 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
[pm_wip/voltdm_nm][PATCH v2 1/3] OMAP4: PM: VC: fix channel bit offset for MPU
Patch OMAP3+: VC: abstract out channel configuration abstracts out
VC channel configuration. However, TRM has it's little surprises such
as the following for channel_cfg:
CFG_CHANNEL_SABIT(0)
CFG_CHANNEL_RAV BIT(1)
CFG_CHANNEL_RAC BIT(2)
CFG_CHANNEL_RACEN BIT(3)
CFG_CHANNEL_CMD BIT(4)
is valid for core and iva, *but* for mpu, the channel offsets are as follows:
CFG_CHANNEL_SABIT(0)
CFG_CHANNEL_CMD BIT(1)
CFG_CHANNEL_RAV BIT(2)
CFG_CHANNEL_RAC BIT(3)
CFG_CHANNEL_RACEN BIT(4)
To handle this on the fly, add a structure to describe this and use the
structure for vc definition.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vc.c | 30 ++
arch/arm/mach-omap2/vc.h | 29 +
arch/arm/mach-omap2/vc3xxx_data.c | 11 +++
arch/arm/mach-omap2/vc44xx_data.c | 21 +
4 files changed, 75 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index fba352d..6437460 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -10,18 +10,6 @@
#include prm-regbits-44xx.h
#include prm44xx.h
-/*
- * Channel configuration bits, common for OMAP3 4
- * OMAP3 register: PRM_VC_CH_CONF
- * OMAP4 register: PRM_VC_CFG_CHANNEL
- */
-#define CFG_CHANNEL_SABIT(0)
-#define CFG_CHANNEL_RAV BIT(1)
-#define CFG_CHANNEL_RAC BIT(2)
-#define CFG_CHANNEL_RACEN BIT(3)
-#define CFG_CHANNEL_CMD BIT(4)
-#define CFG_CHANNEL_MASK 0x3f
-
/**
* omap_vc_config_channel - configure VC channel to PMIC mappings
* @voltdm: pointer to voltagdomain defining the desired VC channel
@@ -249,6 +237,7 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
{
struct omap_vc_channel *vc = voltdm-vc;
u8 on_vsel, onlp_vsel, ret_vsel, off_vsel;
+ struct omap_vc_channel_cfg *cfg_channel_data;
u32 val;
if (!voltdm-pmic || !voltdm-pmic-uv_to_vsel) {
@@ -264,6 +253,14 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
return;
}
+ /* Ensure we have VC channel data */
+ if (!vc-cfg_ch_bits) {
+ pr_err(%s: No CFG Channel data for vdd_%s regs\n,
+ __func__, voltdm-name);
+ return;
+ }
+ cfg_channel_data = vc-cfg_ch_bits;
+
vc-cfg_channel = 0;
/* get PMIC/board specific settings */
@@ -276,7 +273,7 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
voltdm-rmw(vc-smps_sa_mask,
vc-i2c_slave_addr __ffs(vc-smps_sa_mask),
vc-common-smps_sa_reg);
- vc-cfg_channel |= CFG_CHANNEL_SA;
+ vc-cfg_channel |= cfg_channel_data-sa;
/*
* Configure the PMIC register addresses.
@@ -284,13 +281,14 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
voltdm-rmw(vc-smps_volra_mask,
vc-volt_reg_addr __ffs(vc-smps_volra_mask),
vc-common-smps_volra_reg);
- vc-cfg_channel |= CFG_CHANNEL_RAV;
+ vc-cfg_channel |= cfg_channel_data-rav;
if (vc-cmd_reg_addr) {
voltdm-rmw(vc-smps_cmdra_mask,
vc-cmd_reg_addr __ffs(vc-smps_cmdra_mask),
vc-common-smps_cmdra_reg);
- vc-cfg_channel |= CFG_CHANNEL_RAC | CFG_CHANNEL_RACEN;
+ vc-cfg_channel |= cfg_channel_data-rac |
+ cfg_channel_data-racen;
}
/* Set up the on, inactive, retention and off voltage */
@@ -303,7 +301,7 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
(ret_vsel vc-common-cmd_ret_shift) |
(off_vsel vc-common-cmd_off_shift));
voltdm-write(val, vc-cmdval_reg);
- vc-cfg_channel |= CFG_CHANNEL_CMD;
+ vc-cfg_channel |= cfg_channel_data-cmd;
/* Channel configuration */
omap_vc_config_channel(voltdm);
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index f0fb61f..2538089 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -62,11 +62,39 @@ struct omap_vc_common {
u8 i2c_mcode_mask;
};
+/*
+ * Channel configuration bits, common for OMAP3 4
+ * OMAP3 register: PRM_VC_CH_CONF
+ * OMAP4 register: PRM_VC_CFG_CHANNEL
+ */
+#define CFG_CHANNEL_SABIT(0)
+#define CFG_CHANNEL_RAV BIT(1)
+#define CFG_CHANNEL_RAC BIT(2)
+#define CFG_CHANNEL_RACEN BIT(3)
+#define CFG_CHANNEL_CMD BIT(4)
+#define CFG_CHANNEL_MASK 0x3f
+/**
+ * struct omap_vc_channel_cfg - describe the cfg_channel bitfield
+ * @sa:SA_VDD_xxx_L
+ * @rav: RAV_VDD_xxx_L
+ * @rac: RAC_VDD_xxx_L
+ * @racen: RACEN_VDD_xxx_L
+ * @cmd: CMD_VDD_xxx_L
+ */
+struct omap_vc_channel_cfg {
+ u8 sa;
+ u8 rav;
+ u8 rac;
+ u8 racen;
+ u8 cmd;
+};
+
/**
* struct omap_vc_channel - VC
[pm_wip/voltdm_nm][PATCH v2 2/3] OMAP4: PM: VC: introduce concept of default channel
Due to a TRM bug, the current code assumes that channel0(core) is the default
channel. With the additional explanation provided by the hardware team, it is
clear that PRM_VC_CFG_CHANNEL register allows for flexibility of configuring
for various PMIC configurations. For example, the I2C slave address on TWL6030
when using 4430 configuration could potentially use the same slave address for
all domains, while in 4460 configuration, we drive MPU using TPS; Core and IVA
using TWL6030. To allow this flexibility, we state in existing parameters using
a flag to indicate usage of default channel.
In addition, the TRM update clears up the confusion on the fact that MPU is
infact the default channel on OMAP4.
We update the same here.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vc.c | 58 -
arch/arm/mach-omap2/vc.h |8 +++--
arch/arm/mach-omap2/vc44xx_data.c |1 +
arch/arm/mach-omap2/voltage.h |9 ++
4 files changed, 53 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 6437460..42c77a8 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -22,20 +22,20 @@
* - command values for ON, ONLP, RET and OFF (CMD)
*
* This function currently only allows flexible configuration of
- * the non-default channel (e.g. non-zero channels.) Starting with
- * OMAP4, only the non-zero channels can be configured. Channel zero
- * always uses the channel zero register values. Therefore, the
- * same limitation is imposed on OMAP3 for consistency.
+ * the non-default channels. Introduced in OMAP4, is a concept of a default
+ * channel - in OMAP4, this channel is MPU, all other domains could optionally
+ * link their i2c regs to use MPU channel's configuration if required.
*/
static int omap_vc_config_channel(struct voltagedomain *voltdm)
{
struct omap_vc_channel *vc = voltdm-vc;
/*
-* For channel zero, the only configurable bit is RACEN.
-* All others must stay at zero (see function comment above.)
+* For default channel, the only configurable bit is RACEN.
+* All others default channel bits stays at zero
+* (see function comment above.)
*/
- if (!vc-cfg_channel_sa_shift)
+ if (vc-is_default_channel)
vc-cfg_channel = CFG_CHANNEL_RACEN;
voltdm-rmw(CFG_CHANNEL_MASK vc-cfg_channel_sa_shift,
@@ -261,6 +261,18 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
}
cfg_channel_data = vc-cfg_ch_bits;
+ /* Dont proceed if channel configurations are messed up */
+ if (vc-is_default_channel
+ (vc-i2c_slave_addr == USE_DEFAULT_CHANNEL_I2C_PARAM ||
+vc-cmd_reg_addr == USE_DEFAULT_CHANNEL_I2C_PARAM ||
+vc-volt_reg_addr == USE_DEFAULT_CHANNEL_I2C_PARAM)) {
+ pr_err(%s: Voltage Domain %s is default.INVALID CONFIGURATION:
+ slave_add = %04x cmd=%04x vol=%04x!\n,
+ __func__, voltdm-name, vc-i2c_slave_addr,
+ vc-cmd_reg_addr, vc-volt_reg_addr);
+ return;
+ }
+
vc-cfg_channel = 0;
/* get PMIC/board specific settings */
@@ -269,26 +281,32 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
vc-cmd_reg_addr = voltdm-pmic-cmd_reg_addr;
vc-setup_time = voltdm-pmic-volt_setup_time;
- /* Configure the i2c slave address for this VC */
- voltdm-rmw(vc-smps_sa_mask,
- vc-i2c_slave_addr __ffs(vc-smps_sa_mask),
- vc-common-smps_sa_reg);
- vc-cfg_channel |= cfg_channel_data-sa;
+ /* Configure the I2C slave address for this VC */
+ if (vc-i2c_slave_addr != USE_DEFAULT_CHANNEL_I2C_PARAM) {
+ voltdm-rmw(vc-smps_sa_mask,
+ vc-i2c_slave_addr __ffs(vc-smps_sa_mask),
+ vc-common-smps_sa_reg);
+ vc-cfg_channel |= cfg_channel_data-sa;
+ }
/*
* Configure the PMIC register addresses.
*/
- voltdm-rmw(vc-smps_volra_mask,
- vc-volt_reg_addr __ffs(vc-smps_volra_mask),
- vc-common-smps_volra_reg);
- vc-cfg_channel |= cfg_channel_data-rav;
-
- if (vc-cmd_reg_addr) {
+ if (vc-cmd_reg_addr != USE_DEFAULT_CHANNEL_I2C_PARAM) {
voltdm-rmw(vc-smps_cmdra_mask,
vc-cmd_reg_addr __ffs(vc-smps_cmdra_mask),
vc-common-smps_cmdra_reg);
- vc-cfg_channel |= cfg_channel_data-rac |
- cfg_channel_data-racen;
+ vc-cfg_channel |= cfg_channel_data-rac;
+ }
+
+ /* if voltage and cmd regs are same, we can use cmdra register */
+ if (vc-volt_reg_addr == vc-cmd_reg_addr) {
+
[pm_wip/voltdm_nm][PATCH v2 3/3] OMAP4: PM: VC: make omap_vc_i2c_init static
The only user of omap_vc_i2c_init is vc.c itself, makes
no reason for us to expose it out.
This also fixes the sparse warning:
arch/arm/mach-omap2/vc.c:207:13: warning: symbol 'omap_vc_i2c_init' was not
declared. Should it be static?
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 42c77a8..d0b52cc 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -204,7 +204,7 @@ static void __init omap4_vc_init_channel(struct
voltagedomain *voltdm)
* channel registers. All other VC channels will use the
* same configuration.
*/
-void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
+static void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
{
struct omap_vc_channel *vc = voltdm-vc;
static bool initialized;
--
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: [PATCHv2 2/2] OMAP: add omap_device_reset()
On Fri, 27 May 2011, Tomi Valkeinen wrote: However, VENC doesn't use the standard syscontrol mechanism, so that cannot be done via omap_device interface anyway. struct omap_hwmod_class has a .reset function pointer for this purpose. It's already been necessary to deal with the I2C IP block: https://patchwork.kernel.org/patch/804072/ If all that's needed are the steps in 4430 TRM Rev. T Section 10.6.5.1.2.3 Subsequence--Video Encoder Software Reset, then it should be possible to handle this internal reset with hwmod code. - 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: [PATCHv2 2/2] OMAP: add omap_device_reset()
Hi Tomi, On Fri, 27 May 2011, Tomi Valkeinen wrote: DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. One thing that I don't quite understand about this thread is that the hwmod code should be resetting the DSS hwmods when the system boots. Is something not working with this process? That is a separate case from the error recovery case. Sounds like we may need to expose a reset function for that purpose as well. Tomi, I don't think your proposed patch is enough for this, though: we'd also need to reset the hwmod internal state for that module, and reprogram the SYSCONFIG bits, etc. as mach-omap2/omap_hwmod.c:_setup() does. - 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
[pm_wip/voltdm_nm][PATCH] OMAP3+: PM: VC: support configuring PMIC over I2C_SR
Many simpler PMICs such as TPS65023 as discussed in:
http://marc.info/?t=129848405600010r=1w=2
With a single I2C interface do still have configuration registers that
may need population. Typical being slew rate, thermal shutdown
configuration etc. These devices are typically hooked on Application
Processor's(AP) standard I2C busses. Unfortunately, when hooked on
I2C_SR, unlike the standard I2C framework, we cannot read using
Voltage controller, but we can definitely write to them. Hence
for using PMICs such as these and others such as those used with
OMAP4460, it is imperative that we provide a hook to support the
device configuration.
To reuse code, we split the existing vc_bypass command into a reusable
subfunction which we use from both vc_bypass and the new function.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vc.c | 91 --
arch/arm/mach-omap2/vc.h |2 +
2 files changed, 81 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 0b4d533..6f445e8 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -102,30 +102,29 @@ void omap_vc_post_scale(struct voltagedomain *voltdm,
voltdm-curr_volt = target_volt;
}
-/* vc_bypass_scale_voltage - VC bypass method of voltage scaling */
-int omap_vc_bypass_scale_voltage(struct voltagedomain *voltdm,
-unsigned long target_volt)
+static int omap_vc_bypass_send_value(struct voltagedomain *voltdm,
+ struct omap_vc_channel *vc, u8 sa, u8 reg, u32 data)
{
- struct omap_vc_channel *vc = voltdm-vc;
u32 loop_cnt = 0, retries_cnt = 0;
u32 vc_valid, vc_bypass_val_reg, vc_bypass_value;
- u8 target_vsel, current_vsel;
- int ret;
- ret = omap_vc_pre_scale(voltdm, target_volt, target_vsel,
current_vsel);
- if (ret)
- return ret;
+ if (IS_ERR_OR_NULL(vc-common)) {
+ pr_err(%s voldm=%s bad value for vc-common\n,
+ __func__, voltdm-name);
+ return -EINVAL;
+ }
vc_valid = vc-common-valid;
vc_bypass_val_reg = vc-common-bypass_val_reg;
- vc_bypass_value = (target_vsel vc-common-data_shift) |
- (vc-volt_reg_addr vc-common-regaddr_shift) |
- (vc-i2c_slave_addr vc-common-slaveaddr_shift);
+ vc_bypass_value = (data vc-common-data_shift) |
+ (reg vc-common-regaddr_shift) |
+ (sa vc-common-slaveaddr_shift);
voltdm-write(vc_bypass_value, vc_bypass_val_reg);
voltdm-write(vc_bypass_value | vc_valid, vc_bypass_val_reg);
vc_bypass_value = voltdm-read(vc_bypass_val_reg);
+
/*
* Loop till the bypass command is acknowledged from the SMPS.
* NOTE: This is legacy code. The loop count and retry count needs
@@ -147,10 +146,78 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain
*voltdm,
vc_bypass_value = voltdm-read(vc_bypass_val_reg);
}
+ return 0;
+
+}
+
+/* vc_bypass_scale_voltage - VC bypass method of voltage scaling */
+int omap_vc_bypass_scale_voltage(struct voltagedomain *voltdm,
+unsigned long target_volt)
+{
+ struct omap_vc_channel *vc;
+ u8 target_vsel, current_vsel;
+ int ret;
+
+ if (IS_ERR_OR_NULL(voltdm)) {
+ pr_err(%s bad voldm\n, __func__);
+ return -EINVAL;
+ }
+
+ vc = voltdm-vc;
+ if (IS_ERR_OR_NULL(vc)) {
+ pr_err(%s voldm=%s bad vc\n, __func__, voltdm-name);
+ return -EINVAL;
+ }
+
+ ret = omap_vc_pre_scale(voltdm, target_volt, target_vsel,
current_vsel);
+ if (ret)
+ return ret;
+
+ ret = omap_vc_bypass_send_value(voltdm, vc, vc-i2c_slave_addr,
+ vc-volt_reg_addr, target_vsel);
+ if (ret)
+ return ret;
+
omap_vc_post_scale(voltdm, target_volt, target_vsel, current_vsel);
return 0;
}
+/**
+ * omap_vc_bypass_send_i2c_msg() - Function to control PMIC registers over
SRI2C
+ * @voltdm:voltage domain
+ * @slave_addr:slave address of the device.
+ * @reg_addr: register address to access
+ * @data: what do we want to write there
+ *
+ * Many simpler PMICs with a single I2C interface still have configuration
+ * registers that may need population. Typical being slew rate configurations
+ * thermal shutdown configuration etc. When these PMICs are hooked on I2C_SR,
+ * this function allows these configuration registers to be accessed.
+ *
+ * WARNING: Though this could be used for voltage register configurations over
+ * I2C_SR, DONOT use it for that purpose, all the Voltage controller's internal
+ * information is bypassed using this function and must be used judiciously.
+ */
+int omap_vc_bypass_send_i2c_msg(struct
Re: [PATCHv2 2/2] OMAP: add omap_device_reset()
On Sun, 2011-05-29 at 20:24 -0600, Paul Walmsley wrote: Hi Tomi, On Fri, 27 May 2011, Tomi Valkeinen wrote: DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. One thing that I don't quite understand about this thread is that the hwmod code should be resetting the DSS hwmods when the system boots. Is something not working with this process? I believe that is working fine. The problem appears when DSS is turned off (i.e. the screen is blanked) and then started again. The driver has been written so that it will reset the DSS HW before starting to use that particular DSS HW block, to get a clean state. Remove that reset, and we've got all the old register values lying around, causing the device to malfunction. This should be fixable in the driver, of course, although my experience with DSI (and DSS in general) shows that it's not always very easy to stop and restart the HW without a reset. However, I'd still argue that a driver is more robust if it does do a reset when starting up the HW. Perhaps the driver should be developed without that reset, but in the production device the reset should give us extra protection for unexpected situations. That is a separate case from the error recovery case. Sounds like we may need to expose a reset function for that purpose as well. Tomi, I don't think your proposed patch is enough for this, though: we'd also need to reset the hwmod internal state for that module, and reprogram the SYSCONFIG bits, etc. as mach-omap2/omap_hwmod.c:_setup() does. Ah, ok, sounds right. It worked for me, but I probably wouldn't notice if the PM bits in SYSCONFIG are wrong, as I didn't do any PM testing. 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
