ext Kevin Hilman [EMAIL PROTECTED] writes:
Högander Jouni wrote:
ext Paul Walmsley [EMAIL PROTECTED] writes:
Hi Jouni,
On Fri, 7 Nov 2008, Högander Jouni wrote:
What do you Paul think about patch below:
I'm okay with it, but one potential problem: won't this prevent the
chip from
Any other comments ?
Stanley.
On Tue, 2008-11-11 at 19:50 +0800, Stanley.Miao wrote:
Changes since v1:
1, fix all the patch format problem.
2, split the defconfig patch from code patches.
3, put a twl4030keypad bug fix into a single patch.
4, Add a persistent bit in the keypad map,
There are already various drivers having bigger label than 10 bytes. Most
of them fit well under 20 bytes but make column width exact so that
oversized labels don't mess up output alignment.
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
---
arch/arm/plat-omap/gpio.c |2 +-
1 files changed,
On Tue, Nov 11, 2008 at 04:36:38PM -0800, Tony Lindgren wrote:
* Jonathan McDowell [EMAIL PROTECTED] [08 15:43]:
I got some section mismatch warnings when compiling latest git for
MACH_AMS_DELTA this evening; this seems to be due to a missing
__initdata on the omap_board_config_kernel.
Hi,
I just tried to find the source of the problem with PM-20081106 branch.
Am trying to debug this issue now.
I tried to do a check to find which commit caused the problem.
I find that it is something to do with uart pm support.
The patch commit
This patch causes _omap3_noncore_dpll_lock to wait for clocks marked as
WAIT_READY to be ready before continuing. This is necessary for MPU/DSP
DVFS to work correctly.
Cheers,
Peter.
---
arch/arm/mach-omap2/clock34xx.c | 19 ---
arch/arm/mach-omap2/clock34xx.h |2 +-
2
On Wed, 12 Nov 2008, Peter 'p2' De Schrijver wrote:
This patch causes _omap3_noncore_dpll_lock to wait for clocks marked as
WAIT_READY to be ready before continuing. This is necessary for MPU/DSP
DVFS to work correctly.
Acked-by: Paul Walmsley [EMAIL PROTECTED]
but it is missing your
ext Jouni Hogander [EMAIL PROTECTED] writes:
Current implementation makes it possible that printouts are
written into UART while its clocks are disabled. This causes freeze.
Now I got how this new uart clock handling works. Event thought this
fix is not too sensible it actually does what is
I forgot the signoff. Fixed now.
This patch causes _omap3_noncore_dpll_lock to wait for clocks marked as
WAIT_READY to be ready before continuing. This is necessary for MPU/DSP
DVFS to work correctly.
Cheers,
Peter.
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
---
Sriram V [EMAIL PROTECTED] writes:
Hi,
I just tried to find the source of the problem with PM-20081106 branch.
Am trying to debug this issue now.
I tried to do a check to find which commit caused the problem.
I find that it is something to do with uart pm support.
The
ext Kevin Hilman [EMAIL PROTECTED] writes:
Rajendra Nayak [EMAIL PROTECTED] writes:
I am seeing a couple of issues on the 3430sdp with this latest pm
branch. With the omap_3430sdp_min_defconfig I see a system freeze
after bootup after the debug UART inactivity. Also system wide
suspend
Hi jouni,
Does the branch PM-20081106 work for you?
When i try to do a echo mem /sys/power/state on omap3evm.
the system hangs. Does Suspend-Resume work on this branch?
[EMAIL PROTECTED] /proc]# echo mem /sys/power/state
6PM: Syncing filesystems ... PM: Syncing filesystems ... done.
On Tue, Nov 11, 2008 at 10:20:33PM -0800, David Brownell wrote:
On Friday 24 October 2008, Felipe Balbi wrote:
--- a/arch/arm/plat-omap/include/mach/usb.h
+++ b/arch/arm/plat-omap/include/mach/usb.h
@@ -29,6 +29,7 @@
void __init usb_musb_init(void);
void __init
The SDK 1.0.0 kernel for OMAP35x EVM from TI included DVI support
(480P and 720P) in the display driver. Is there a patch that was
submitted to the l-o git that includes that support? I'm looking to
add DVI support into the kernel I'm currently using, which is
linux-omap-2.6 (tag =
On Wed, Nov 12, 2008 at 12:17:24PM +0200, ext Sudipta GHOSH wrote:
Hi,
I am having some problem with i2c.
In my env I cant make i2c working.
During boot, Twl4030 tries to send few i2c data, but it didnt going ok.
static void twl_init_irq(void), issues many i2c write but fails with
Remove the unused devconf_loopback_clock field from twl_mmc_controller.
control_devconf_offset only changes for DEVCONF1, so move it out.
Signed-off-by: Grazvydas Ignotas [EMAIL PROTECTED]
---
arch/arm/mach-omap2/mmc-twl4030.c | 19 +++
1 files changed, 7 insertions(+), 12
If you are using git-send-email, please provide the --no-chain-reply-to
option to avoid creating exceptionally deep nesting.
Stanley.
On Wed, 2008-11-12 at 00:56 +0200, Felipe Balbi wrote:
From: Felipe Balbi [EMAIL PROTECTED]
Get rid of omap_{read,write}[bsl] defines.
Virtual and physical
Hi,
I am having some problem with i2c.
In my env I cant make i2c working.
During boot, Twl4030 tries to send few i2c data, but it didnt going ok.
static void twl_init_irq(void), issues many i2c write but fails with
error -121 (EREMOTEIO).
I tries to some twl4030 i2c read and write from video
Current implementation will disable clocks in the order defined in clock34xx.h,
at least DPLL4_M2X2 will hang in certain cases (and prevent retention / off)
if clocks are not disabled in correct order. This patch makes sure the parent
clocks will be active when disabling a clock.
Signed-off-by:
Current implementation makes it possible that printouts are
written into UART while its clocks are disabled. This causes freeze.
This patch contains possible fix for this.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c |6 ++
Hello,
this series fixes a bug in the OMAP3 DPLL rate rounding code that will
attempt to program the DPLL to use an internal clock frequency that
does not exist in the FREQSEL table in 34xx TRM 4.7.6.2. This mostly
seems to generate warnings, but can potentially hang the system.
As part of this
Remove some clutter from omap2_dpll_round_rate().
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index
The previous DPLL rate rounding algorithm counted the divider (N) down
from the maximum to 1. Since we currently use a broad DPLL rate
tolerance, and lower N values are more power-efficient, we can often
bypass several iterations through the loop by counting N upwards from
1.
Peter de Schrijver
The DPLL FREQSEL jitter correction bits are set based on a table in
the 34xx TRM, Table 4-38, according to the DPLL's internal clock
frequency Fint. Several Fint frequency ranges are missing from this
table. Previously, we allowed these Fint frequency ranges to be
selected in the rate rounding
Fixes a bug in TWL4030 keypad where too many columns were being checked.
Code originally submitted by Stanley Miao to linux-omap tree.
Signed-off-by: Dominic Curran [EMAIL PROTECTED]
cc: Stanley.Miao [EMAIL PROTECTED]
---
drivers/input/keyboard/omap-twl4030keypad.c |2 +-
1 files changed, 1
Removes ZOOM specific code from TWL4030 keypad driver.
Adds generic code to deal with persistent TWL4030 keypress.
Code originally submitted by Stanley Miao to linux-omap tree.
Signed-off-by: Dominic Curran [EMAIL PROTECTED]
cc: Stanley.Miao [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-ldp.c
On Wednesday 12 November 2008, Dominic Curran wrote:
Lower i2c bus 1 speed to 400KHz for LDP.
Does something go wrong if it's faster, then?
If so, the failure needs to be in the patch comment.
If not ...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
ext Sriram V [EMAIL PROTECTED] writes:
Hi jouni,
Does the branch PM-20081106 work for you?
When i try to do a echo mem /sys/power/state on omap3evm.
the system hangs. Does Suspend-Resume work on this branch?
Yes, but you need to apply this patch (or something similiar). Have
you
Resending patch with more descriptive comment.
Lower i2c bus 1 speed to 400KHz for LDP.
At 2600KHz i2c reads from twl4030 keypad driver are returning
incorrect data. Reason unknown. Lowering bus speed as temporary
fix to get LDP keypad working.
Signed-off-by: Dominic Curran [EMAIL PROTECTED]
Jouni Hogander [EMAIL PROTECTED] writes:
Current implementation makes it possible that printouts are
written into UART while its clocks are disabled. This causes freeze.
This patch contains possible fix for this.
Thanks, pulling into PM branch until final solution can be found.
Kevin
Hi Jouni, Kevin,
On Tue, 11 Nov 2008, Högander Jouni wrote:
I wouldn't add any flags for this. The goal is finally to set all
next_states as OFF until someone has set some constraint which
prevents OFF usage. For now we need to use RET as default, because
drivers are not supporting OFF mode.
* Grazvydas Ignotas [EMAIL PROTECTED] [081110 02:37]:
+static int hsmmc2_set_power(struct device *dev, int slot, int power_on,
int vdd)
+{
+ int ret;
+
+ struct hsmmc_controller *c = hsmmc[1];
+
+ if (power_on) {
+ u32 reg;
+
+ reg =
On Wed, 12 Nov 2008, Paul Walmsley wrote:
On Wed, 12 Nov 2008, Peter 'p2' De Schrijver wrote:
This patch causes _omap3_noncore_dpll_lock to wait for clocks marked as
WAIT_READY to be ready before continuing. This is necessary for MPU/DSP
DVFS to work correctly.
Acked-by: Paul Walmsley
- Original Message -
From: Dominic Curran [EMAIL PROTECTED]
To: linux-omap@vger.kernel.org
Sent: Thursday, November 13, 2008 1:51 AM
Subject: [PATCH 1/3] [OMAPZOOM] Lower i2c speed on bus 1 for LDP.
Resending patch with more descriptive comment.
Lower i2c bus 1 speed to 400KHz for
I noticed that l-o updated divisors the other day.
It might be some sync'ing pulled in bad dividers?
Regards,
Richard W.
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of shekhar, chandra
Sent: Wednesday, November 12, 2008 8:50 PM
To:
Thanks,
Vaibhav
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of twebb
Sent: Wednesday, November 12, 2008 11:06 PM
To: linux-omap@vger.kernel.org Mailing List
Subject: DVI output support for OMAP35x EVM
The SDK 1.0.0 kernel for
36 matches
Mail list logo
