On Fri, 20 Feb 2009, Jouni Hogander wrote:
dpllx_m2x2_ck parent is dpllx_m2_ck. So remove few useless clocks and
and use right parent for dpllx_m2x2_ck.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Acked-by: Paul Walmsley p...@pwsan.com
Thanks Jouni.
- Paul
--
To unsubscribe
Hello,
ext Nishanth Menon wrote:
Oops.. copy-paste typo.. :(
tLow = (scll+3) * iclk
tHigh = (sclh+9) * iclk
Vs:
TRM:
tHigh = ( sclh +5 )*iclk period
tLow = ( scll +7 )*iclk period
But my question is this: why are we trying to a different equation
here compared to the equation in the TRM?
On Sun, Feb 22, 2009 at 04:37:31PM -0700, Paul Walmsley wrote:
Hello Russell,
On Sat, 14 Feb 2009, Russell King - ARM Linux wrote:
However, looking a little deeper, there's more issues in the reparenting
area. I don't think this code has been tested at all... In
The problem with Eero's patch is that it changes the internal clock
(again thanks to that confusing table). You should be able to use same
for all modes. Also note that the noise filter is one internel clock
period. Currently the driver uses 19.2 MHz which exceeds the I2C spec
max. So 24 MHz
On Mon, Feb 23, 2009 at 07:24:24PM +0100, ext Kevin Hilman wrote:
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes:
This patch introduces a new C state C0 which keeps both core and mpu
powerdomains in ON state. This gives us low latency at a cost of higher
power consumption.
Aaro Koskinen said the following on 02/24/2009 11:09 AM:
ext Nishanth Menon wrote:
Oops.. copy-paste typo.. :(
tLow = (scll+3) * iclk
tHigh = (sclh+9) * iclk
Vs:
TRM:
tHigh = ( sclh +5 )*iclk period
tLow = ( scll +7 )*iclk period
But my question is this: why are we trying to a
David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
Resolve longstanding issue noted by Adrian Hunter: confusion
between settting VSEL=0 (which is 1.8V on MMC1) and poweroff.
Also, leave VSEL alone if we're just powering the regulator off.
Signed-off-by: David Brownell
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Monday, February 23, 2009 10:04 AM
To: Woodruff, Richard
Ack?
Ack.
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 08baa18..b2d9e1f 100644
--- a/arch/arm/plat-omap/clock.c
+++
On Mon, Feb 23, 2009 at 06:03:49PM -0800, David Brownell wrote:
On Monday 23 February 2009, Mark Brown wrote:
The change to add voltage range constraints if none were supplied is a
noticable policy change from the existing framework standard - it allows
machines to enable voltage changes
Hello,
ext Nishanth Menon wrote:
Aaro Koskinen said the following on 02/24/2009 11:09 AM:
TRM:
tHigh = ( sclh +5 )*iclk period
tLow = ( scll +7 )*iclk period
But my question is this: why are we trying to a different equation
here compared to the equation in the TRM?
The problem with TRM
David Brownell wrote:
On Monday 23 February 2009, Adrian Hunter wrote:
Also, you will need the following patch if you actually want the power
to go off.
Current GIT already has a patch supporting power-off for
MMC2; tested on SDP and some custom hardware. So this
patch won't apply.
Sorry,
Well, it's implicite... Check the i2c spec table 7 for speeds 3400 and
1700. If you use TRM calculcations so that tLow == tHigh you get too
tLow that's below the minimum in both cases. So you must increase tLow,
and when you do that you must make tHigh shorter, otherwise you don't
match
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Woodruff, Richard
Sent: Tuesday, February 24, 2009 6:47 PM
To: Aaro Koskinen; ext Nishanth Menon
Cc: Nurkkala Eero.An (EXT-Offcode/Oulu); linux-omap@vger.kernel.org
Hello.
David Brownell wrote:
Ajay Kumar Gupta wrote:
urb-transfer_buffer_length and urb-transfer_buffer should be
updated based on urb-actual_length.For a fresh and first time urb,
actual_length will be zero but for urbs which has been stopped and
restarted (as bulk nak scheme does)
Paul Walmsley p...@pwsan.com writes:
On Fri, 20 Feb 2009, Jouni Hogander wrote:
dpllx_m2x2_ck parent is dpllx_m2_ck. So remove few useless clocks and
and use right parent for dpllx_m2x2_ck.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Acked-by: Paul Walmsley p...@pwsan.com
If these are CPU side GPIOs that you're talking about you'll
also want to write the standard utility for using gpiolib for
jack detection that I've not got round to doing yet :)
The GPIOs belong to a submodule of TWL4030, but they are configured
using standard gpiolib.
About adding GPIO
On Tue, Feb 24, 2009 at 11:37:47AM -0600, Lopez Cruz, Misael wrote:
About adding GPIO functionality to jack detection, if the right
place to request GPIOs and set its data direction is in board files
(arch/*/mach-*/board-*.c), then there won't be much to do in jack
code, only the irq request.
Hi all,
Just FYI, I've switched over to apply the omap patches from
patchwork.kernel.org [1]. So now we'll have some state tracking of the
patches, and I can keep my omap inbox relatively empty without
worrying about losing patches ;)
I'll be marking all the patches that should go via other
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Commit: cc7e090769a453fde37650f0ee768643b6423de8
PatchWorks
http://patchwork.kernel.org/patch/8199/
Git
Hi,
This patches do the needed changes to manage the address resources as
void __iomem * instead of u32.
Regards,
Fernando
Guzman
Lugo.
--
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
From: Fernando Guzman Lugo x0095...@ti.com
Date: Mon, 23 Feb 2009 17:38:15 -0600
Subject: [PATCH] DSPBRIDGE: Removes wrappers funtions of readl and writel
This patch change the call to RD_MEM_32_VOLATILE and
WR_MEM_32_VOLATILE with __raw_readl and __raw_writel
Signed-off-by: Guzman Lugo Fernando
From 708b2a4a434408e2d5325aa360ffb2cd57bc6bd1 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Mon, 23 Feb 2009 18:12:27 -0600
Subject: [PATCH] DSPBRIDGE: Change address resources to void __iomem *
This patch changes address resources to void __iomem *
Signed-off-by:
On Tuesday 24 February 2009, Adrian Hunter wrote:
I agree that code removed by this patch is ugly and worth
removing if it's not actually needed for MMC1.
Here is a patch against current OMAP tree.
From: Adrian Hunter ext-adrian.hun...@nokia.com
Date: Tue, 24 Feb 2009 14:48:16 +0200
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Commit: 2bf450019410d15dbce63893d3f91e076a5a70c0
PatchWorks
http://patchwork.kernel.org/patch/6808/
Git
On Tuesday 24 February 2009, Adrian Hunter wrote:
I would still like the other two issues I raised considered.
They were:
1. 'host' can be NULL in omap_mmc_suspend() / omap_mmc_resume()
2. wait for SDBP bit
Someone from Nokia was going to be shepherding HSMMC patches,
as I
hi,
On Mon, Feb 23, 2009 at 8:52 PM, Felipe Balbi m...@felipebalbi.com wrote:
Hi all,
Please give the following patches a good test. I don't have
hw to test them so any comments will be really welcome.
We still have lots to do before getting this driver upstream,
let's try to keep track of
On Tue, Feb 24, 2009 at 11:50 PM, Guzman Lugo, Fernando x0095...@ti.com wrote:
From 708b2a4a434408e2d5325aa360ffb2cd57bc6bd1 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Mon, 23 Feb 2009 18:12:27 -0600
Subject: [PATCH] DSPBRIDGE: Change address resources to void
On Fri, Feb 20, 2009 at 7:49 AM, Tony Lindgren t...@atomide.com wrote:
* Steve Sakoman sako...@gmail.com [090219 22:38]:
Overo has a wifi chip on mmc2 that uses the libertas_sdio driver.
I've had my head down working in other areas and failed to noticed
that at some point in the 2.6.29 rc
On Mon, Feb 23, 2009 at 12:52:01PM -0800, David Brownell wrote:
Use those methods to force machine-level constraints into bounds.
(Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board
constraints for that rail are 2.0V to 3.6V ... so the range of
voltages is then 2.4V to 3.3V on
Why wasn't dwMemBase updated too?
snip/
A step in the right direction. Thanks.
Hi Felipe,
In this moment the array dwMemBase is used to store iomem addresses but
also the element two stores a kernel address.
MEM_FreePhysMem((void *)pResources-dwMemBase[1], pResources-dwMemPhys[1],
On Mon, Feb 23, 2009 at 8:55 PM, Felipe Balbi m...@felipebalbi.com wrote:
Adding a platform_data to the driver allow us
to remove some of the ifdeferry in the code.
snip
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index b8a78c0..08215c0
On Wed, Feb 25, 2009 at 12:35:05AM +0200, Grazvydas Ignotas wrote:
On Mon, Feb 23, 2009 at 8:55 PM, Felipe Balbi m...@felipebalbi.com wrote:
Adding a platform_data to the driver allow us
to remove some of the ifdeferry in the code.
snip
diff --git
On Wed, Feb 25, 2009 at 12:28 AM, Guzman Lugo, Fernando x0095...@ti.com wrote:
Why wasn't dwMemBase updated too?
snip/
A step in the right direction. Thanks.
Hi Felipe,
In this moment the array dwMemBase is used to store iomem addresses
but also the element two stores a kernel
On Mon, Feb 23, 2009 at 8:55 PM, Felipe Balbi m...@felipebalbi.com wrote:
Make the register definitions in ehci-omap.c more sane.
Also change the parameter passed omap_start/stop_ehc().
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 219
Then I guess you should leave the '=0' instead of changing
'=(u32)NULL', that can wait for the next patch.
What about dwDipiBase?
dwDipiBase is not used it should have removed, I will update the patch with
your comments. Please let me know if you have more comments about the patch.
Regards,
From 708b2a4a434408e2d5325aa360ffb2cd57bc6bd1 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Mon, 23 Feb 2009 18:12:27 -0600
Subject: [PATCH] DSPBRIDGE: Change address resources to void __iomem *
This patch changes address resources to void __iomem *
Signed-off-by:
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:
big snip
Theodore,
You're considering just one subset of the V4L usages: notebook webcams.
Actually, the sq905 cameras are not notebook webcams. They are cheap,
consumer
On Tue, 24 Feb 2009, kilg...@banach.math.auburn.edu wrote:
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:
big snip
Theodore,
You're considering just one subset of the V4L usages: notebook webcams.
Actually, the sq905
On Tuesday 24 February 2009, Mark Brown wrote:
On Mon, Feb 23, 2009 at 12:52:01PM -0800, David Brownell wrote:
Use those methods to force machine-level constraints into bounds.
(Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board
constraints for that rail are 2.0V to 3.6V ...
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Tue, 24 Feb 2009, kilg...@banach.math.auburn.edu wrote:
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:
big snip
Theodore,
You're considering just one subset of
Also an overview is often very helpful. Also trying to visualize what
might be needed in the future is helpful. All of this can be extremely
helpful. But not everyone can see or imagine every possible thing. For
example, it seems that some of the best minds in the business are
stunned when
On Wed, 25 Feb 2009, Thomas Kaiser wrote:
Also an overview is often very helpful. Also trying to visualize what
might be needed in the future is helpful. All of this can be extremely
helpful. But not everyone can see or imagine every possible thing. For
example, it seems that some of the
On Wed, 25 Feb 2009, Mauro Carvalho Chehab wrote:
On Tue, 24 Feb 2009 20:12:00 -0600 (CST)
kilg...@banach.math.auburn.edu wrote:
For sure we need to have a way for retrieving this information for devices
like the sq905 cameras, where the information can't be currently be
determined by
really big snip
So, what do these two deep questions, which confound the assembled
wisdom of an entire list of Linux video developers, have to do with
tables in userspace? None that I can see, unless someone wants to
provide a mechanism for the information, having been collected in the
44 matches
Mail list logo
