Re: Problems while designing TPS65023 regulator driver
Hi David, On Fri, Apr 24, 2009 at 3:47 AM, David Brownell davi...@pacbell.net wrote: On Thursday 23 April 2009, Trilok Soni wrote: Any updates on tps65023 regulator driver? Could you please submit the WIP patches to the list? FWIW, here's the last version I saw ... it includes a build hack for the regulator_register() call. I haven't build-tested it since that API change went to mainline. From: Manikandan Pillai mani.pil...@ti.com Subject: regulator: add support for TPS6235x The patch has been fixed for comments given by David Brownell and Mark Brown for adding TPS6235x support on OMAP3 EVM. Comments fixed include moving Makefile changes to this patch dev_err used removed the extra configuration option from Kconfig Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :). -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- 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: Problems while designing TPS65023 regulator driver
Trilok, Since the new regulator_register API was not there in l-o, I have not submitted my patch for TPS65023. But since now it is available, I will submit my patch soon. Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated PSP Products RSS Feed -Original Message- From: Trilok Soni [mailto:soni.tri...@gmail.com] Sent: Friday, April 24, 2009 11:32 AM To: David Brownell Cc: Aggarwal, Anuj; Mark Brown; linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: Problems while designing TPS65023 regulator driver Hi David, On Fri, Apr 24, 2009 at 3:47 AM, David Brownell davi...@pacbell.net wrote: On Thursday 23 April 2009, Trilok Soni wrote: Any updates on tps65023 regulator driver? Could you please submit the WIP patches to the list? FWIW, here's the last version I saw ... it includes a build hack for the regulator_register() call. I haven't build-tested it since that API change went to mainline. From: Manikandan Pillai mani.pil...@ti.com Subject: regulator: add support for TPS6235x The patch has been fixed for comments given by David Brownell and Mark Brown for adding TPS6235x support on OMAP3 EVM. Comments fixed include moving Makefile changes to this patch dev_err used removed the extra configuration option from Kconfig Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :). -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] OMAP24xx/25xx clock: init osc_ck, sys_ck internal lists early
On Thu, 23 Apr 2009, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [090423 20:13]:
On Thu, 23 Apr 2009, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090423 15:26]:
On Thu, Apr 23, 2009 at 11:00:31AM -0700, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [090423 01:35]:
Hello Russell,
On Thu, 23 Apr 2009, Russell King - ARM Linux wrote:
On Wed, Apr 22, 2009 at 08:01:29PM -0600, Paul Walmsley wrote:
The patch also renames clk_init_one() to clk_preinit() to
distinguish its function from clk_init() and the individual
struct clk
init functions.
That's rather unnecessary. 'clk_init_one' is already unique. In
the
long run, it's clk_init that needs to go.
Even if clk_init() were to disappear, the struct clk .init function
pointer would still be present. clk-init() performs a very
different
kind of initialization than clk_init_one().
I'm OK doing the rename in this fix. The original naming can cause
confusion while reading the code.
Well I'm not, and I want to discuss it some more. And I'm sending Linus
a pull request tonight, so I'm dropping the OMAP stuff from that.
OK. Paul, can you please separate out the rename part into a separate
patch so we only have a minimal fix then repost it here?
That way we'll get the necessary fixes in and you guys can schedule
other changes for next merge window.
The omap-clock-fixes branch has been updated to remove the rename.
Not that this should stop the discussion, but at least this should no
longer prevent these needed fixes from going upstream.
Care to post the updated patch here too? Temporay git branches are
not too readable by most people..
Here you go:
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Wed, 22 Apr 2009 19:48:53 -0600
Subject: [PATCH] OMAP2xxx clock: pre-initialize struct clks early
Commit 3f0a820c4c0b4670fb5f164baa5582e23c2ef118 breaks OMAP2xxx boot
during initial propagate_rate() on osc_ck and sys_ck. Fix by
pre-initializing all struct clks before running any other clock init
code. Incorporates review comments from Russell King
rmk+ker...@arm.linux.org.uk.
Resolves
1Unable to handle kernel NULL pointer dereference at virtual address
1pgd = c0004000
1[] *pgd=
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.29-omap1 #37)
PC is at propagate_rate+0x10/0x60
LR is at omap2_clk_init+0x30/0x218
...
Signed-off-by: Paul Walmsley p...@pwsan.com
Tested-by: Jarkko Nikula jarkko.nik...@nokia.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-omap2/clock24xx.c |6 +++---
arch/arm/plat-omap/clock.c |7 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 1e839c5..984fb86 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -720,14 +720,14 @@ int __init omap2_clk_init(void)
clk_init(omap2_clk_functions);
+ for (c = omap24xx_clks; c omap24xx_clks + ARRAY_SIZE(omap24xx_clks);
c++)
+ clk_init_one(c-lk.clk);
+
osc_ck.rate = omap2_osc_clk_recalc(osc_ck);
propagate_rate(osc_ck);
sys_ck.rate = omap2_sys_clk_recalc(sys_ck);
propagate_rate(sys_ck);
- for (c = omap24xx_clks; c omap24xx_clks + ARRAY_SIZE(omap24xx_clks);
c++)
- clk_init_one(c-lk.clk);
-
cpu_mask = 0;
if (cpu_is_omap2420())
cpu_mask |= CK_242X;
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 2e06145..29efc27 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -239,6 +239,13 @@ void recalculate_root_clocks(void)
}
}
+/**
+ * clk_init_one - initialize any fields in the struct clk before clk init
+ * @clk: struct clk * to initialize
+ *
+ * Initialize any struct clk fields needed before normal clk initialization
+ * can run. No return value.
+ */
void clk_init_one(struct clk *clk)
{
INIT_LIST_HEAD(clk-children);
--
1.6.3.rc1.51.gea0b7
--
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: Problems while designing TPS65023 regulator driver
On Thursday 23 April 2009, Trilok Soni wrote: Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :). Sorry ... maybe they'll help some other time. :) I was wondering what happened to the tps6235x drivers, which seemed to have gotten lost. I don't recall having seen tps65023 code. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
ext Kevin Hilman wrote: Nayak, Rajendra rna...@ti.com writes: Re-sending this patch-set with some mailer issues resolved. They now apply cleanly with a git-am/git-apply. Hi, This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis instead of calls to SRF. Patches apply on top of the latest pm branch from Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Rajendra, This series seems to boot on SDP and Beagle but I recetly tried on RX51 and it hangs in omap3_sr_init(). Using Lauterbach, I tracked it to hang in sr_configure_vp() at this PRM write to the PRM_VP1_VLIMITTO register: prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX | PRM_VP1_VLIMITTO_VDDMIN | PRM_VP1_VLIMITTO_TIMEOUT, OMAP3430_GR_MOD, OMAP3_PRM_VP1_VLIMITTO_OFFSET); Should these min/max/timeout values be board specific? 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 It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of CONFIG_OMAP_PM_NOOP. Should Smartreflex option be dependent or independent of the CONFIG_OMAP_PM_??? setting? -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, April 23, 2009 1:35 AM To: Nayak, Rajendra Cc: linux-omap Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver Nayak, Rajendra rna...@ti.com writes: Re-sending this patch-set with some mailer issues resolved. They now apply cleanly with a git-am/git-apply. Hi, This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis instead of calls to SRF. Patches apply on top of the latest pm branch from Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git Rajendra, This series seems to boot on SDP and Beagle but I recetly tried on RX51 and it hangs in omap3_sr_init(). Using Lauterbach, I tracked it to hang in sr_configure_vp() at this PRM write to the PRM_VP1_VLIMITTO register: prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX | PRM_VP1_VLIMITTO_VDDMIN | PRM_VP1_VLIMITTO_TIMEOUT, OMAP3430_GR_MOD, OMAP3_PRM_VP1_VLIMITTO_OFFSET); Should these min/max/timeout values be board specific? Kevin, These values I remember we got from the SiVal team here at TI, I don't think they are board specific. I can check up more on that from them. Btw, does the hang happen only with my patchset applied, because the patchset does not change any of these values. I don't have access to the RX51 h/w this week, so I can debug more on this next week once I have access to it. regards, Rajendra 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: Problems while designing TPS65023 regulator driver
As you know, some regulator patches were required in linux-OMAP tree to submit the TPS65023 patch, in absence of which it won't have compiled. Since they are available now, I can submit them after doing a refresh. Moreover, we are working on some restructuring for the different TPS devices so that the board-dependent code can be separated from the rest of the stuff. It should be closed soon and then the new patches would be submitted for review, for both the TPS devices. Thanks and Regards, Anuj Aggarwal Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated PSP Products RSS Feed -Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Friday, April 24, 2009 12:03 PM To: Trilok Soni Cc: Aggarwal, Anuj; Mark Brown; linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: Problems while designing TPS65023 regulator driver On Thursday 23 April 2009, Trilok Soni wrote: Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :). Sorry ... maybe they'll help some other time. :) I was wondering what happened to the tps6235x drivers, which seemed to have gotten lost. I don't recall having seen tps65023 code. -- 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.6.29-rc3-git] input: twl4030_keypad driver
On Thursday 23 April 2009, Dmitry Torokhov wrote:
Dave,
It waqs sitting in my local queue, I had some concerns over the keymap
change as it was implemented in the version you sent me. The problem is
that you mangle key codes in your keymap table (encoding row/col data in
Well, not really *me* I didn't write any of this. I just
cleaned it up and sent it along to help get this stuff out
of the OMAP tree, into mainline where it belongs.
them) but input core is not aware of that and when you try using
EVIOCSETKEYCODE it will do wierd things. I was wondering what you would
think about the following patch that should rectify this issue.
It invalidates all the existing keypad tables, which have been
waiting for this driver to merge before they go upstream ... it'd
be simpler just to prevent EVIOCSETKEYCODE calls. Or provide
update methods that understand the structure of those entries;
conceptually they're a struct { scancode; keycode; } though
it's not coded that way
Needing to take 512 bytes per keytable -- vs the keypad-specific
sizes, typically much less even if using a qwerty -- is also a
minor issue. Keypads with 256 keys are *really* unusual! Most
current ones are smaller ... the biggest I've seen is 44.
Also, I don't think we need the special handling for persistant keys.
Just let these keys generate KEY_RESERVED and input core will not
propagate their events.
I was never sure what to make of that, it seemed like a hack.
Only the Labrador boards (since renamed Zoom1) seem to
need that mechanism.
So I'm not sure whether that would be appropriate. If it is,
then the keytable construction macros could just change. But
is the input core aware that it shouldn't remap such things?
- Dave
p.s. a few comments are below.
Thanks!
--
Dmitry
Input: twl4030_kepad fixups
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/input/keyboard/twl4030_keypad.c | 62
++-
include/linux/i2c/twl4030.h | 18 +++--
2 files changed, 32 insertions(+), 48 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 987f13c..b761cac 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -48,23 +48,18 @@
* See the TPS65950 documentation; that's the general availability
* version of the TWL5030 second generation part.
*/
-#define MAX_ROWS 8 /* TWL4030 hard limit */
struct twl4030_keypad {
- unsigned*keymap;
- unsigned intkeymapsize;
- u16 kp_state[MAX_ROWS];
- unsignedn_rows;
- unsignedn_cols;
+ unsigned short keymap[TWL4030_KEYMAP_SIZE];
The keypad size is board-specific; not all possible switch
settings are used.
+ u16 kp_state[TWL4030_MAX_ROWS];
TWL4030_MAX_ROWS makes sense, although the same keypad macros
are used in some other OMAP boards that don't use TWL4030 family
chips, so it's not really TWL-specific. (OMAP1 boards often use
the omap-keypad driver.)
+ u8 n_rows;
+ u8 n_cols;
Didn't really need to change those. This is one of the cases
where the code to read a byte then zero-extend it uses more
space than using a 32-bit unsigned value instead of 8-bit. :)
unsignedirq;
struct device *dbg_dev;
struct input_dev *input;
};
-#define ROWCOL_MASK KEY(0xf, 0xf, 0)
-#define KEYNUM_MASK ~PERSISTENT_KEY(0xf, 0xf)
This being a side-effect of changing the key table encoding...
-
/*--*/
/* arbitrary prescaler value 0..7 */
@@ -156,18 +151,6 @@ static int twl4030_kpwrite_u8(struct twl4030_keypad *kp,
u8 data, u32 reg)
return ret;
}
-static int twl4030_find_key(struct twl4030_keypad *kp, int col, int row)
-{
- int i, rc;
-
- rc = KEY(col, row, 0);
- for (i = 0; i kp-keymapsize; i++)
- if ((kp-keymap[i] ROWCOL_MASK) == rc)
- return kp-keymap[i] (KEYNUM_MASK | KEY_PERSISTENT);
-
- return -EINVAL;
-}
-
static inline u16 twl4030_col_xlate(struct twl4030_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
@@ -183,7 +166,7 @@ static inline u16 twl4030_col_xlate(struct twl4030_keypad
*kp, u8 col)
static int twl4030_read_kp_matrix_state(struct twl4030_keypad *kp, u16
*state)
{
- u8 new_state[MAX_ROWS];
+ u8 new_state[TWL4030_MAX_ROWS];
int row;
int ret = twl4030_kpread(kp,
new_state, KEYP_FULL_CODE_7_0, kp-n_rows);
@@ -213,7 +196,8 @@ static int twl4030_is_in_ghost_state(struct
twl4030_keypad *kp, u16 *key_state)
static void twl4030_kp_scan(struct twl4030_keypad *kp, int release_all)
{
- u16 new_state[MAX_ROWS];
+ struct input_dev *input =
[PATCH] enabled alpha blender for OMAP2/3 DSS2 driver.
- Added global alpha value for GFX and VIDEO2 layer.
- Modified dispc_alpha_blending_enabled function.
- for OMAP_DSS_CHANNEL_DIGIT, it has to get DISPC_CONFIG[19], not 18.
For alpha channel, dispc_enable_alpha_blending() is called by
omapfb_fb_init() in case of only XXX_ARGB16, RGBA32 or ARGB32
Signed-off-by: InKi Dae inki@samsung.com
--
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9bab6cf..c5335e5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1846,8 +1846,10 @@ void dispc_enable_trans_key(enum omap_channel
ch, bool enable)
enable_clocks(1);
if (ch == OMAP_DSS_CHANNEL_LCD)
REG_FLD_MOD(DISPC_CONFIG, enable, 10, 10);
- else /* OMAP_DSS_CHANNEL_DIGIT */
+ else if (ch == OMAP_DSS_CHANNEL_DIGIT)
REG_FLD_MOD(DISPC_CONFIG, enable, 12, 12);
+ else
+ BUG();
enable_clocks(0);
}
void dispc_enable_alpha_blending(enum omap_channel ch, bool enable)
@@ -1855,8 +1857,10 @@ void dispc_enable_alpha_blending(enum
omap_channel ch, bool enable)
enable_clocks(1);
if (ch == OMAP_DSS_CHANNEL_LCD)
REG_FLD_MOD(DISPC_CONFIG, enable, 18, 18);
- else /* OMAP_DSS_CHANNEL_DIGIT */
+ else if (ch == OMAP_DSS_CHANNEL_DIGIT)
REG_FLD_MOD(DISPC_CONFIG, enable, 19, 19);
+ else
+ BUG();
enable_clocks(0);
}
bool dispc_alpha_blending_enabled(enum omap_channel ch)
@@ -1867,7 +1871,7 @@ bool dispc_alpha_blending_enabled(enum omap_channel ch)
if (ch == OMAP_DSS_CHANNEL_LCD)
enabled = REG_GET(DISPC_CONFIG, 18, 18);
else if (ch == OMAP_DSS_CHANNEL_DIGIT)
-enabled = REG_GET(DISPC_CONFIG, 18, 18);
+ enabled = REG_GET(DISPC_CONFIG, 19, 19);
else
BUG();
enable_clocks(0);
@@ -1876,6 +1880,18 @@ bool dispc_alpha_blending_enabled(enum omap_channel ch)
}
+void dispc_set_global_alpha(int layer, int alpha)
+{
+ enable_clocks(1);
+ if (layer == 0)
+ REG_FLD_MOD(DISPC_GLOBAL_ALPHA, alpha, 7, 0);
+ else if (layer == 2)
+ REG_FLD_MOD(DISPC_GLOBAL_ALPHA, alpha, 23, 16);
+ else
+ BUG();
+
+ enable_clocks(0);
+}
bool dispc_trans_key_enabled(enum omap_channel ch)
{
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 76e7c6c..98cad35 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1583,6 +1583,17 @@ int omapfb_fb_init(struct omapfb2_device
*fbdev, struct fb_info *fbi)
r = mode;
goto err;
}
+
+ if (mode == OMAP_DSS_COLOR_ARGB16 ||
+ mode ==
OMAP_DSS_COLOR_RGBA32 ||
+ mode ==
OMAP_DSS_COLOR_ARGB32) {
+
+
dispc_enable_alpha_blending(OMAP_DSS_CHANNEL_LCD, 1);
+
+ /* Set global alpha value to
fully apaque */
+ dispc_set_global_alpha(id, 255);
+ }
+
r = dss_mode_to_fb_mode(mode, var);
if (r 0)
goto err;
diff --git a/drivers/video/omap2/omapfb/omapfb.h
b/drivers/video/omap2/omapfb/omapfb.h
index 43f6922..56c303e 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -147,4 +147,8 @@ static inline int omapfb_overlay_enable(struct
omap_overlay *ovl,
return ovl-set_overlay_info(ovl, info);
}
+extern void dispc_enable_alpha_blending(enum omap_channel ch,
+ int enable);
+extern void dispc_set_global_alpha(int layer, int alpha);
+
#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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
Nayak, Rajendra rna...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, April 23, 2009 1:35 AM To: Nayak, Rajendra Cc: linux-omap Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver Nayak, Rajendra rna...@ti.com writes: Re-sending this patch-set with some mailer issues resolved. They now apply cleanly with a git-am/git-apply. Hi, This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis instead of calls to SRF. Patches apply on top of the latest pm branch from Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git Rajendra, This series seems to boot on SDP and Beagle but I recetly tried on RX51 and it hangs in omap3_sr_init(). Using Lauterbach, I tracked it to hang in sr_configure_vp() at this PRM write to the PRM_VP1_VLIMITTO register: prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX | PRM_VP1_VLIMITTO_VDDMIN | PRM_VP1_VLIMITTO_TIMEOUT, OMAP3430_GR_MOD, OMAP3_PRM_VP1_VLIMITTO_OFFSET); Should these min/max/timeout values be board specific? Kevin, These values I remember we got from the SiVal team here at TI, I don't think they are board specific. I can check up more on that from them. Btw, does the hang happen only with my patchset applied, because the patchset does not change any of these values. Yes, backing out your latest series results in a booting kernel. 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: n800 high idle power consumption
Kalle Valo kalle.v...@iki.fi writes: Hello all, I was testing 2.6.30-rc3-omap1 on n800 and noticed that idle power consumption is very high, ten times compared to a 2.6.29 I tested few weeks back. I'm guessing that CPU doesn't sleep at all. Is this a regression? How should I debug this further? Between .29 and .30, the PM code in l-o was dropped and re-sync'd to kernel.org code. This is so that PM can be separated out into a separate branch and submitted upstream independently. The current PM branch is in the process of being re-based onto 2.6.30. When it's ready, I'd appreciate any testing on n800. 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] enabled alpha blender for OMAP2/3 DSS2 driver.
InKi Dae daei...@gmail.com writes:
- Added global alpha value for GFX and VIDEO2 layer.
- Modified dispc_alpha_blending_enabled function.
- for OMAP_DSS_CHANNEL_DIGIT, it has to get DISPC_CONFIG[19], not 18.
For alpha channel, dispc_enable_alpha_blending() is called by
omapfb_fb_init() in case of only XXX_ARGB16, RGBA32 or ARGB32
Signed-off-by: InKi Dae inki@samsung.com
--
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9bab6cf..c5335e5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1846,8 +1846,10 @@ void dispc_enable_trans_key(enum omap_channel
ch, bool enable)
enable_clocks(1);
if (ch == OMAP_DSS_CHANNEL_LCD)
REG_FLD_MOD(DISPC_CONFIG, enable, 10, 10);
- else /* OMAP_DSS_CHANNEL_DIGIT */
+ else if (ch == OMAP_DSS_CHANNEL_DIGIT)
REG_FLD_MOD(DISPC_CONFIG, enable, 12, 12);
+ else
+ BUG();
BUG() will halt the whole kernel. I don't think you want to do that
for this issue. I think WARN() is more appropriate here and the other
cases in this patch as well.
Kevin
enable_clocks(0);
}
void dispc_enable_alpha_blending(enum omap_channel ch, bool enable)
@@ -1855,8 +1857,10 @@ void dispc_enable_alpha_blending(enum
omap_channel ch, bool enable)
enable_clocks(1);
if (ch == OMAP_DSS_CHANNEL_LCD)
REG_FLD_MOD(DISPC_CONFIG, enable, 18, 18);
- else /* OMAP_DSS_CHANNEL_DIGIT */
+ else if (ch == OMAP_DSS_CHANNEL_DIGIT)
REG_FLD_MOD(DISPC_CONFIG, enable, 19, 19);
+ else
+ BUG();
enable_clocks(0);
}
bool dispc_alpha_blending_enabled(enum omap_channel ch)
@@ -1867,7 +1871,7 @@ bool dispc_alpha_blending_enabled(enum omap_channel ch)
if (ch == OMAP_DSS_CHANNEL_LCD)
enabled = REG_GET(DISPC_CONFIG, 18, 18);
else if (ch == OMAP_DSS_CHANNEL_DIGIT)
-enabled = REG_GET(DISPC_CONFIG, 18, 18);
+ enabled = REG_GET(DISPC_CONFIG, 19, 19);
else
BUG();
enable_clocks(0);
@@ -1876,6 +1880,18 @@ bool dispc_alpha_blending_enabled(enum omap_channel ch)
}
+void dispc_set_global_alpha(int layer, int alpha)
+{
+ enable_clocks(1);
+ if (layer == 0)
+ REG_FLD_MOD(DISPC_GLOBAL_ALPHA, alpha, 7, 0);
+ else if (layer == 2)
+ REG_FLD_MOD(DISPC_GLOBAL_ALPHA, alpha, 23, 16);
+ else
+ BUG();
+
+ enable_clocks(0);
+}
bool dispc_trans_key_enabled(enum omap_channel ch)
{
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 76e7c6c..98cad35 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1583,6 +1583,17 @@ int omapfb_fb_init(struct omapfb2_device
*fbdev, struct fb_info *fbi)
r = mode;
goto err;
}
+
+ if (mode == OMAP_DSS_COLOR_ARGB16 ||
+ mode ==
OMAP_DSS_COLOR_RGBA32 ||
+ mode ==
OMAP_DSS_COLOR_ARGB32) {
+
+
dispc_enable_alpha_blending(OMAP_DSS_CHANNEL_LCD, 1);
+
+ /* Set global alpha value to
fully apaque */
+ dispc_set_global_alpha(id, 255);
+ }
+
r = dss_mode_to_fb_mode(mode, var);
if (r 0)
goto err;
diff --git a/drivers/video/omap2/omapfb/omapfb.h
b/drivers/video/omap2/omapfb/omapfb.h
index 43f6922..56c303e 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -147,4 +147,8 @@ static inline int omapfb_overlay_enable(struct
omap_overlay *ovl,
return ovl-set_overlay_info(ovl, info);
}
+extern void dispc_enable_alpha_blending(enum omap_channel ch,
+ int enable);
+extern void dispc_set_global_alpha(int layer, int alpha);
+
#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
--
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
Re: n800 high idle power consumption
Kevin Hilman khil...@deeprootsystems.com writes: Kalle Valo kalle.v...@iki.fi writes: Hello all, I was testing 2.6.30-rc3-omap1 on n800 and noticed that idle power consumption is very high, ten times compared to a 2.6.29 I tested few weeks back. I'm guessing that CPU doesn't sleep at all. Is this a regression? How should I debug this further? Between .29 and .30, the PM code in l-o was dropped and re-sync'd to kernel.org code. This is so that PM can be separated out into a separate branch and submitted upstream independently. Ah, of course. I read about this but didn't understand the implications :) Thanks for pointing this out to me. The current PM branch is in the process of being re-based onto 2.6.30. When it's ready, I'd appreciate any testing on n800. Ok. Please let me know when it's ready. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] OMAP24xx/25xx clock: init osc_ck, sys_ck internal lists early
* Paul Walmsley p...@pwsan.com [090423 23:29]:
On Thu, 23 Apr 2009, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [090423 20:13]:
On Thu, 23 Apr 2009, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090423 15:26]:
On Thu, Apr 23, 2009 at 11:00:31AM -0700, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [090423 01:35]:
Hello Russell,
On Thu, 23 Apr 2009, Russell King - ARM Linux wrote:
On Wed, Apr 22, 2009 at 08:01:29PM -0600, Paul Walmsley wrote:
The patch also renames clk_init_one() to clk_preinit() to
distinguish its function from clk_init() and the individual
struct clk
init functions.
That's rather unnecessary. 'clk_init_one' is already unique.
In the
long run, it's clk_init that needs to go.
Even if clk_init() were to disappear, the struct clk .init
function
pointer would still be present. clk-init() performs a very
different
kind of initialization than clk_init_one().
I'm OK doing the rename in this fix. The original naming can cause
confusion while reading the code.
Well I'm not, and I want to discuss it some more. And I'm sending
Linus
a pull request tonight, so I'm dropping the OMAP stuff from that.
OK. Paul, can you please separate out the rename part into a separate
patch so we only have a minimal fix then repost it here?
That way we'll get the necessary fixes in and you guys can schedule
other changes for next merge window.
The omap-clock-fixes branch has been updated to remove the rename.
Not that this should stop the discussion, but at least this should no
longer prevent these needed fixes from going upstream.
Care to post the updated patch here too? Temporay git branches are
not too readable by most people..
Here you go:
Thanks, I've updated omap-fixes again and will post a new pull request.
Tony
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Wed, 22 Apr 2009 19:48:53 -0600
Subject: [PATCH] OMAP2xxx clock: pre-initialize struct clks early
Commit 3f0a820c4c0b4670fb5f164baa5582e23c2ef118 breaks OMAP2xxx boot
during initial propagate_rate() on osc_ck and sys_ck. Fix by
pre-initializing all struct clks before running any other clock init
code. Incorporates review comments from Russell King
rmk+ker...@arm.linux.org.uk.
Resolves
1Unable to handle kernel NULL pointer dereference at virtual address
1pgd = c0004000
1[] *pgd=
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.29-omap1 #37)
PC is at propagate_rate+0x10/0x60
LR is at omap2_clk_init+0x30/0x218
...
Signed-off-by: Paul Walmsley p...@pwsan.com
Tested-by: Jarkko Nikula jarkko.nik...@nokia.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-omap2/clock24xx.c |6 +++---
arch/arm/plat-omap/clock.c |7 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 1e839c5..984fb86 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -720,14 +720,14 @@ int __init omap2_clk_init(void)
clk_init(omap2_clk_functions);
+ for (c = omap24xx_clks; c omap24xx_clks + ARRAY_SIZE(omap24xx_clks);
c++)
+ clk_init_one(c-lk.clk);
+
osc_ck.rate = omap2_osc_clk_recalc(osc_ck);
propagate_rate(osc_ck);
sys_ck.rate = omap2_sys_clk_recalc(sys_ck);
propagate_rate(sys_ck);
- for (c = omap24xx_clks; c omap24xx_clks + ARRAY_SIZE(omap24xx_clks);
c++)
- clk_init_one(c-lk.clk);
-
cpu_mask = 0;
if (cpu_is_omap2420())
cpu_mask |= CK_242X;
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 2e06145..29efc27 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -239,6 +239,13 @@ void recalculate_root_clocks(void)
}
}
+/**
+ * clk_init_one - initialize any fields in the struct clk before clk init
+ * @clk: struct clk * to initialize
+ *
+ * Initialize any struct clk fields needed before normal clk initialization
+ * can run. No return value.
+ */
void clk_init_one(struct clk *clk)
{
INIT_LIST_HEAD(clk-children);
--
1.6.3.rc1.51.gea0b7
--
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: git pull request for omap fixes, v4 (Re: [PATCH 00/11] Omap fixes for 2.6.30-rc1)
* Tony Lindgren t...@atomide.com [090423 11:21]: * Tony Lindgren t...@atomide.com [090421 08:55]: * Tony Lindgren t...@atomide.com [090420 21:58]: * Tony Lindgren t...@atomide.com [090416 18:23]: * Tony Lindgren t...@atomide.com [090414 14:48]: Hi all, Here are some omap fixes for review. Also merged in Paul's clock fixes posted here earlier. Russell, here's the pull request for you. I merged in Paul's updated patch OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files. The diff to earlier series and the updated pull request are attached. I've updated the omap-fixes branch again with Paul's change to OMAP2xxx clock: pre-initialize struct clks early patch as posted on this mailing list. Updated pull request below. Updated the same patch again. Updated pull request below. Tony The following changes since commit 091069740304c979f957ceacec39c461d0192158: Linus Torvalds (1): Linux 2.6.30-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes Arun KS (1): OMAP1: clock: Typo fix for clock in omap1 Huang Weiyi (1): ARM: OMAP3: remove duplicated #include Jarkko Nikula (1): ARM: OMAP2: Remove defines and resource init for OMAP24XX EAC Kevin Hilman (2): ARM: OMAP2/3: GPIO: do not attempt to wake-enable OMAP: dmtimer: enable all timers to be wakeup events Ladislav Michl (3): ARM: OMAP: MMC: Remove unused power_pin ARM: OMAP1: Simplify board-h2 MMC setup ARM: OMAP1: Fix mmc_set_power GPIO usage Paul Walmsley (4): OMAP2xxx clock: pre-initialize struct clks early OMAP2xxx clock: fix broken cpu_mask code OMAP3 GPTIMER: fix GPTIMER12 IRQ OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files Roel Kluin (1): ARM: OMAP2: possible division by 0 Roger Quadros (2): ARM: OMAP3: Fixed spurious IRQ issue for GPIO interrupts ARM: OMAP3: Clean up spurious interrupt check logic Santosh Shilimkar (1): ARM: OMAP: Fix for possible race condition in omap_free_dma() Sergio Aguirre (1): OMAP3: clock: Camera module doesn't have IDLEST bit Tony Lindgren (2): ARM: OMAP: Remove old dead gpio expander code Merge branch 'omap-clock-fixes' into omap-fixes arch/arm/mach-omap1/board-h2-mmc.c | 14 +--- arch/arm/mach-omap1/board-h3-mmc.c |6 +- arch/arm/mach-omap1/board-h3.c | 101 arch/arm/mach-omap1/board-nokia770.c |6 +- arch/arm/mach-omap1/mcbsp.c|4 +- arch/arm/mach-omap2/board-h4.c | 95 -- arch/arm/mach-omap2/board-omap3beagle.c|4 + arch/arm/mach-omap2/board-rx51.c |1 - arch/arm/mach-omap2/clock24xx.c| 19 ++--- arch/arm/mach-omap2/clock24xx.h| 10 ++- arch/arm/mach-omap2/clock34xx.h|7 +- arch/arm/mach-omap2/devices.c | 33 arch/arm/mach-omap2/irq.c |4 +- arch/arm/mach-omap2/timer-gp.c | 48 +++- arch/arm/mach-omap2/usb-tusb6010.c |2 +- arch/arm/plat-omap/clock.c |7 ++ arch/arm/plat-omap/dma.c | 13 ++-- arch/arm/plat-omap/dmtimer.c | 28 --- arch/arm/plat-omap/gpio.c | 20 ++--- arch/arm/plat-omap/include/mach/dmtimer.h |2 +- arch/arm/plat-omap/include/mach/eac.h | 100 --- arch/arm/plat-omap/include/mach/gpioexpander.h | 35 arch/arm/plat-omap/include/mach/irda.h |4 - arch/arm/plat-omap/include/mach/mmc.h |1 - arch/arm/plat-omap/include/mach/timer-gp.h | 17 drivers/mmc/host/omap.c|2 - 26 files changed, 136 insertions(+), 447 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/eac.h delete mode 100644 arch/arm/plat-omap/include/mach/gpioexpander.h create mode 100644 arch/arm/plat-omap/include/mach/timer-gp.h
Re: git pull request for omap fixes, v4 (Re: [PATCH 00/11] Omap fixes for 2.6.30-rc1)
On Fri, Apr 24, 2009 at 10:53:08AM -0700, Tony Lindgren wrote: Updated the same patch again. Updated pull request below. Pulled. Will probably go upstream in about 6 days time. -- 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: git pull request for omap fixes, v4 (Re: [PATCH 00/11] Omap fixes for 2.6.30-rc1)
* Russell King - ARM Linux li...@arm.linux.org.uk [090424 14:16]: On Fri, Apr 24, 2009 at 10:53:08AM -0700, Tony Lindgren wrote: Updated the same patch again. Updated pull request below. Pulled. Will probably go upstream in about 6 days time. OK thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
Roger Quadros ext-roger.quad...@nokia.com writes: ext Kevin Hilman wrote: [...] Rajendra, This series seems to boot on SDP and Beagle but I recetly tried on RX51 and it hangs in omap3_sr_init(). Using Lauterbach, I tracked it to hang in sr_configure_vp() at this PRM write to the PRM_VP1_VLIMITTO register: prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX | PRM_VP1_VLIMITTO_VDDMIN | PRM_VP1_VLIMITTO_TIMEOUT, OMAP3430_GR_MOD, OMAP3_PRM_VP1_VLIMITTO_OFFSET); Should these min/max/timeout values be board specific? [...] It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of CONFIG_OMAP_PM_NOOP. Should Smartreflex option be dependent or independent of the CONFIG_OMAP_PM_??? setting? I see the same thing on SDP as well as RX51. It looks like the new SR code assumes a range of OPPs, but when OMAP_PM_NONE is enabled, the omap_pm_vddX_get_opp() calls always return zero. In the mpu_opps array, the first entry is all zeros, resulting in a zero VSEL which is then used to (re)program the VP. The SR code should probably be a bit smarter about checking for valid values. 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
