---
Can you refresh this against Tony's 'fixes' branch and re-test.
I tested this on OMAP3430/n900 and noticed that it no longer
hit
off
mode from idle.
IOW, If I enable UART timeouts and then enable off mode, I
don't
actually ever hit off during idle. However, if I do a
On Tue, 2011-11-29 at 12:30 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
Both startup and shutdown take 500us at maximum, value taken from
TWL6030 data manual.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
Hi Tero,
On Fri, Nov 25, 2011 at 4:49 PM, Tero Kristo t-kri...@ti.com wrote:
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each
Hi Tero,
On Fri, Nov 25, 2011 at 4:49 PM, Tero Kristo t-kri...@ti.com wrote:
Hi,
Changes compared to previous version:
- merged most of the voltagedomain cleanup fixes to patch 2
- moved pmic latencies to omap_voltdm_pmic struct
- renamed omap_lp_params to omap2_oscillator as it only
Hi,
Removed part of patch for easier readability of comments.
On Tue, 2011-11-29 at 12:26 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
clip
@@ -227,11 +207,6 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
static struct
On Wed, 2011-11-30 at 10:52 +0100, Jean Pihet wrote:
Hi Tero,
On Fri, Nov 25, 2011 at 4:49 PM, Tero Kristo t-kri...@ti.com wrote:
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount
Tero,
On Fri, Nov 25, 2011 at 4:49 PM, Tero Kristo t-kri...@ti.com wrote:
-static void __init omap3_vfsm_init(struct voltagedomain *voltdm)
+static void omap3_set_i2c_timings(struct voltagedomain *voltdm, int off_mode)
{
+ unsigned long voltsetup1;
+ u32 tgt_volt;
+
+ if
On Wed, 2011-11-30 at 11:06 +0100, Jean Pihet wrote:
Hi Tero,
On Fri, Nov 25, 2011 at 4:49 PM, Tero Kristo t-kri...@ti.com wrote:
Hi,
Changes compared to previous version:
- merged most of the voltagedomain cleanup fixes to patch 2
- moved pmic latencies to omap_voltdm_pmic struct
on linux-next 2030.
This patch is against linux-next 2030.
Axel
arch/arm/mach-omap2/display.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index dce9905..fe44cc2 100644
--- a/arch/arm/mach-omap2
On Wed, Nov 30, 2011 at 03:45, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-11-29 at 12:30 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
Both startup and shutdown take 500us at maximum, value taken from
TWL6030 data manual.
Might be
On Wed, Nov 30, 2011 at 04:07, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-11-29 at 12:26 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
more snip
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
On Wed, 2011-11-30 at 06:31 -0600, Menon, Nishanth wrote:
On Wed, Nov 30, 2011 at 04:07, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-11-29 at 12:26 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
more snip
diff --git
On Wed, 2011-11-30 at 06:20 -0600, Menon, Nishanth wrote:
On Wed, Nov 30, 2011 at 03:45, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-11-29 at 12:30 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
Both startup and shutdown take 500us
On Tue, Nov 29, 2011 at 8:45 PM, Kevin Hilman khil...@ti.com wrote:
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Fri, Nov 4, 2011 at 2:57 PM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Fri, Nov 4, 2011 at 3:14 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma
Hi Paul,
On 11/29/2011 7:11 PM, Paul Walmsley wrote:
On Tue, 29 Nov 2011, Cousson, Benoit wrote:
On 11/27/2011 3:07 AM, Paul Walmsley wrote:
So just out of curiosity, do those SYSCONFIG registers in the STM address
space apply to the entire DEBUGSS, or just the STM IP block?
The STM IP is
On Tue, Nov 29, 2011 at 1:00 AM, Jan Weitzel j.weit...@phytec.de wrote:
Options from struct omap_nand_platform_data are not used.
Apply options after nand_scan_ident to avoid overwrite due to
NAND_CHIPOPTIONS_MSK.
So you can pass options from platformcode
Just to clarify, were the
DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(), resulting in the defalut rate of 60 MHz
always used instead of the one selected in .config. OTOH, in
omap1_defconfig we currently rely on Kconfig options for the supported
MHz rates in case of boards
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [30 12:23]:
DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(), resulting in the defalut rate of 60 MHz
always used instead of the one selected in .config. OTOH, in
omap1_defconfig we currently rely on
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [28 13:26]:
I'm not sure which of the patches you meant not ready for 3.2-rc. From
your comment I would conclude that only patch 3/5, which would really
break omap1_defconfig booting on some boards, is questionable, while you
posted this comment
Hi Vaibhav,
Vaibhav Hiremath hvaib...@ti.com writes:
From: Afzal Mohammed af...@ti.com
Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.
Signed-off-by: Afzal Mohammed af...@ti.com
Vaibhav Hiremath hvaib...@ti.com writes:
From: Afzal Mohammed af...@ti.com
Currently dummy voltage domain data is being created
in order to succeed boot process.
Nothing has been done w.r.t actual hardware (voltage control).
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by:
Vaibhav Hiremath hvaib...@ti.com writes:
From: Afzal Mohammed af...@ti.com
Hook up AM33XX voltage domain info to OMAP framework.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Should be part of previous patch.
Kevin
--
To unsubscribe from this
Hi everyone,
This is the second version of the OMAP4 ISS driver,
now ported to the Media Controller framework AND supporting
videobuf2 framework.
This patchset should apply cleanly on top of v3.2-rc3 kernel tag.
This driver attempts to provide an fully open source solution to
control the OMAP4
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/mfd/twl-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index bfbd660..e26b564 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -323,7
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig | 27
arch/arm/mach-omap2/Makefile |1 +
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile|1 +
drivers/media/video/ov5650.c| 524 +++
include/media/ov5650.h | 10 +
include/media/v4l2-chip-ident.h |1 +
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/devices.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b48aeea..e411c4e 100644
--- a/arch/arm/mach-omap2/devices.c
+++
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig| 27
arch/arm/mach-omap2/Makefile |2 +
From: Stanimir Varbanov svarba...@mm-sol.com
Introduce g_interface_parms sensor operation for getting sensor
interface parameters. These parameters are needed from the host side
to determine it's own configuration.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
---
The define should be the result of 1 Bit number.
Bit number for GPOCTL.GPO3 field is 2, which results
in 0x4 value.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
include/linux/mfd/twl6040.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
NOTE: This isn't the whole list of features that the
ISS supports, but the only ones supported at the moment.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/devices.c | 32
arch/arm/plat-omap/include/plat/omap44xx.h |9
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..1b59e2f
Vaibhav Hiremath hvaib...@ti.com writes:
From: Afzal Mohammed af...@ti.com
This patch adds AM33XX power domain data,
corresponding API's to access PRM module and
PRM register offsets bit fields.
Signed-off-by: Rachna Patil rac...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Vaibhav Hiremath hvaib...@ti.com writes:
From: Afzal Mohammed af...@ti.com
Hook up AM33XX power domain to OMAP framework.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Should be combined with previous patch.
Kevin
--
To unsubscribe from this
Hello,
Here are some initial comments on clk_get_rate().
On Mon, 21 Nov 2011, Mike Turquette wrote:
+/**
+ * clk_get_rate - return the rate of clk
+ * @clk: the clk whose rate is being returned
+ *
+ * Simply returns the cached rate of the clk. Does not query the hardware.
If
+ * clk
Vaibhav Hiremath hvaib...@ti.com writes:
This patch series adds support for AM335X basic voltage, power,
clock and HWMOD data to existing OMAP framework.
This series is missing patch 05/11.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
Vaibhav Hiremath hvaib...@ti.com writes:
This patch creats seperate irq and dma defination header file
and updates the module base addresses required for HWMOD data.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
These headers/defines should no
Hi
a few initial comments on clk_get_parent().
On Mon, 21 Nov 2011, Mike Turquette wrote:
+/**
+ * clk_get_parent - return the parent of a clk
+ * @clk: the clk whose parent gets returned
+ *
+ * Simply returns clk-parent. It is up to the caller to hold the
+ * prepare_lock, if desired.
Hi again,
On Wed, Nov 30, 2011 at 6:14 PM, Sergio Aguirre saagui...@ti.com wrote:
Hi everyone,
This is the second version of the OMAP4 ISS driver,
now ported to the Media Controller framework AND supporting
videobuf2 framework.
This patchset should apply cleanly on top of v3.2-rc3 kernel
On Wed, Nov 30, 2011 at 5:20 PM, Paul Walmsley p...@pwsan.com wrote:
This implementation of clk_get_rate() is racy, and is, in general, unsafe.
The problem is that, in many cases, the clock's rate may change between
the time that clk_get_rate() is called and the time that the returned
rate is
Hi,
I am using ZOOM OMAP 3530 SOM-LV board. Board successfully bootup and i got
the /dev/spidev3.0 . When i use the test program to send the data on the spi
device, and the wave form in the oscilloscope shows the the data drops after 5
bits.. i.e if i try to send the data 0xff, the first five
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Thursday, December 01, 2011 5:45 AM
To: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; laurent.pinch...@ideasonboard.com;
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Thursday, December 01, 2011 5:45 AM
To: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; laurent.pinch...@ideasonboard.com;
Hi Mike
a few brief comments.
On Wed, 30 Nov 2011, Turquette, Mike wrote:
Likewise when a clk is requested to transition to a new frequency it
will have to clear it with all of the clks below it, so there is still
a need to propagate a request throughout the clk tree whenever
clk_set_rate
45 matches
Mail list logo
