Hi Grant,
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 6, 2012, at 12:14 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
For
On Tue, Nov 06, 2012 at 20:26:48, Cousson, Benoit wrote:
Hi Anil,
On 11/06/2012 02:48 PM, AnilKumar Ch wrote:
Add device tree date for GPIO based various drivers matrix keypad,
volume keys, push buttons and use leds accross three AM33XX devices
viz EVM, BeagleBone and Starter Kit.
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the versioning
provision seems to stand, I hope we address how much the
Hi Stephen,
On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
+ Tony, Daniel
Hi,
On Wed, Nov 07, 2012 at 02:04:03, Hunter, Jon wrote:
On 11/06/2012 12:00 PM, Matthieu CASTET wrote:
I will post another patch, unless this is already done in Afzal patch (Is
there
a tree where I can get Afzal pending patches ?)
Afzal keeps his kernel tree on
This series resolves a few minor issues with APPLY. Tested on a 4430sdp, checked
switching overlays between DSI command mode and HDMI displays for any unexpected
behavior.
Reference tree:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git
3.8/apply_fixes
Archit Taneja (3):
An overlay's channel out field isn't a shadow register. The TRM says that it's
taken into effect immediately. This understanding was missing and channel out
was treated as a shadow parameter, and in overlay's private data as extra info.
Program channel out bits directly in dss_ovl_set_manager().
The bool was_updating is never really used for anything. It is set to the
current value of mp-updating, but not used anywhere. Remove this variable.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c |2 --
1 file changed, 2 deletions(-)
diff --git
When doing a manual update in dss_mgr_start_update, we clear the shadow dirty
flags. Although there isn't any harm in clearing them. The need to clear them
out here should never arrive.
When applying configurations for a manual update manager, we never do any
register writes, i.e, calls to
On 05.11.2012 14:29, Philip, Avinash wrote:
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from
On 16.10.2012 16:09, Felipe Balbi wrote:
This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
(serial: omap: fix software flow control).
As Russell has pointed out, that commit isn't fixing
Software Flow Control at all, and it actually makes
it even more broken.
It was agreed to
On 2012-11-06 16:40, Rob Clark wrote:
I mean, similar to how we handle the subdev for dmm.. the
omap_drm_init() does the platform_driver_register() for the dmm device
before the platform_driver_register() for omapdrm itself, so we know
if there is a dmm device, the driver gets probed first
On Tue, 2012-11-06 at 13:52 -0800, Kevin Hilman wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Tero Kristo t-kri...@ti.com writes:
Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Hi Kevin,
On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
Hi Tero,
Tero Kristo t-kri...@ti.com writes:
Hi,
Changes compared to previous version:
- rebased on top of
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the
Hi Tomi,
On 11/05/2012 02:14 PM, Tomi Valkeinen wrote:
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi
On 11/05/2012 02:14 PM, Tomi Valkeinen wrote:
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi Valkeinen
On 11/07/2012 02:04 AM, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [121105 05:16]:
Hi,
OMAPDSS device tree support is still some way in the future. Tony has
requested
to get DSS working for Panda SDP boards with DT kernel, so that we'll have
fully working boards with DT.
Hi Benoit,
On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Hi Felipe,
On 11/06/2012 07:22 PM, Felipe Balbi wrote:
Hi,
On Tue, Nov 06, 2012 at 05:58:57PM +0100, Benoit Cousson wrote:
On 11/06/2012 05:44 PM, Felipe Balbi wrote:
Hi,
On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote:
OMAP2+ family of devices are now obtaining resources
On 11/07/2012 12:02 PM, Pantelis Antoniou wrote:
Hi Benoit,
On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
Hi Benoit,
On Nov 7, 2012, at 12:12 PM, Benoit Cousson wrote:
On 11/07/2012 12:02 PM, Pantelis Antoniou wrote:
Hi Benoit,
[snip]
I don't know if this breaks any conventions but seems to work fine for our
case.
Yeah, my main concern with that approach is that you change the
structure
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Remove duplicated include.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
arch/arm/mach-omap2/board-overo.c | 1 -
1 file changed, 1 deletion(-)
On Tuesday 06 November 2012 10:22 PM, Venkatraman S wrote:
Define the most frequently used bitmasks of the Interrupt Enable /
Interrupt Status register with consistent naming ( with _EN suffix).
Use meaningful concatenation of bitfields for INT_EN_MASK, which shows
which interrupts are enabled
Hi Kevin,
On Wed, Nov 07, 2012 at 06:36:06, Kevin Hilman wrote:
Bedia, Vaibhav vaibhav.be...@ti.com writes:
On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
[...]
Also, if there are drivers for these devices, won't this interfere?
Hmm, I can think of the following
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2012-11-06 16:40, Rob Clark wrote:
I mean, similar to how we handle the subdev for dmm.. the
omap_drm_init() does the platform_driver_register() for the dmm device
before the platform_driver_register() for omapdrm
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the platform
name
Hi,
On Tuesday 06 November 2012 07:47 PM, Joshua Emele wrote:
The iva coprocessor, available on some omap platforms, shares a voltage domain
with the mpu. If cpufreq is active and the mpu processor is scaled down, the iva
coprocessor should also be scaled. The goal is to make sure we do not
This series adds a writeback output driver and makes changes in APPLY to get
mem to mem mode working when writeback is connected to an overlay manager.
A user of writeback is supposed to use the fuctions exported by the writeback
output driver to configure writeback and start a mem to mem
Hello,
The currently available pwm-twl6030.c driver only supports TWL6030's Charging
indication LED.
Remove this driver and add two new ones which implements support for all PWM
driven outputs:
pwm-twl driver supports twl4030 (PWM 0/1) and twl6030 (PWM 1/2) instances
pwm-twl-led driver supports
The driver supports the following PWM outputs:
TWL4030 PWM0 and PWM1
TWL6030 PWM1 and PWM2
On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
will select the correct mux so the PWM can be used. When the PWM has been
freed the original configuration going to be restored.
Add changes in apply to let a user apply writeback configurations. This
basically involves a writeback user to commit the writeback_info it has set
previously.
Only memory to memory mode is supported for now in APPLY. Actual register
writes would only happen when a mem to mem update is initiated.
The input to the writeback piepline comes from an overlay manager or an overlay
in mem to mem mode. In both cases the input size configured for writeback should
be the size of the overlay or overlay manager output.
We ignore the case of direct connections between an overlay and writeback for
now.
Add dss_wb_enable/dss_wb_disable funcs in APPLY similar to that of manager's
enable/disable functions. Since, these functions support only writeback in
memory to memory mode, their job is reduced to just setting the private enable
parameter correctly.
Writeback can't be enabled if the manager it
writeback's input is configured by the CHANNELIN field in DISPC_WB_ATTRIBUTES.
It's an immediate write register field. We need to change writeback's channel
in whenever the manager to which it is connected changes.
When changing managers for overlays, we needed to be certain that the overlay
was
writeback in mem to mem mode works like an overlay manager connected to a
display in stallmode. When we set ENABLE in DISPC_WB_ATTRIBUTES writeback, it
starts a mem to mem transfer. On completion, we get a FRAMEDONEWB interrupt and
the ENABLE bit is cleared by HW.
In APPLY, we add
When a manager is connected to writeback in mem to mem mode, all the connected
fetch and process data at rate suitable for the scalar to perform the required
downscaling. This is because there isn't any display connected here, and hence
no real time constraints. When calling dispc_ovl_setup, pass
The writeback pipeline can connect to any of the OMAP4 overlay managers. Add it
as a supported output in dss features.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss_features.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
writeback is a like DPI in the sense that it's completelty a part of DISPC.
Hence it doesn't have it's own resource, or a hwmod entity tied to it.
Create a simple platfrom device for writeback in omap_display_init. Set the
parent to the omapdss_dss platform device like done for other DSS
This is an example to demonstrate how writeback is used to clear framebuffers.
The function omapfb_clear_fb_writeback is added as an alternative to the MPU
intensive function cfb_fillrect.
The writeback is attached to a free manager which has no overlays connected to
it, the manager's default
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
Writeback contains overlay-like parameters which need to be applied by a user
of writeback.
Create functions in APPLY which get and set user_info of type
omap_dss_writeback_info, these are similar to overlay's dss_ovl_get_info and
dss_ovl_set_info ops. The writeback output driver provides
Writeback is implemented as an output driver. This lets writeback to connect
to overlay managers, and configure writeback's manager like properties the same
way other output drivers do.
This driver can be considered something similar to the DPI output driver. It
provides functions which configure
This driver only supported the Charging indicator LED.
New set of drivers going to provide support for both PWMs and LEDs for twl4030
and twl6030 series of PMICs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 9 ---
drivers/pwm/Makefile | 1 -
On 17:47-20121106, Joshua Emele wrote:
+static int __cpuinit omap_iva_init(struct cpufreq_policy *policy)
+{
+ int result;
+ if (!iva_clk_name) {
+ pr_info(%s: iva unavailable\n, __func__);
+ return 0;
+ }
+ iva_dev =
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hotplugging is not some abstract future scenario, we already have
hardware that could use it. For example, omap3 SDP board has a
switchable output to DVI or LCD panel. In this
Hi Sricharan,
R Sricharan r.sricha...@ti.com writes:
In the latest, pad mux and clocks for all
non-essential modules at U-BOOT were removed.
This might also cause the problem.
We can bring this back in u-boot by adding the following macros
and check if it works fine again.
On Tue, Nov 06, 2012 at 12:16:13, Bedia, Vaibhav wrote:
On Mon, Nov 05, 2012 at 14:42:27, Philip, Avinash wrote:
[...]
+ /* Some platforms require explicit tbclk gating */
+ if (of_property_read_bool(pdev-dev.of_node, tbclkgating)) {
+ pc-tbclk = clk_get(pdev-dev, tbclk);
On Tue, Nov 06, 2012 at 12:16:13, Bedia, Vaibhav wrote:
On Mon, Nov 05, 2012 at 14:42:26, Philip, Avinash wrote:
[...]
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
Pinctrl changes should be separate patch. Morevoer, you don't mention
that you making this change.
On Tue, Nov 06, 2012 at 12:05:24, Bedia, Vaibhav wrote:
On Mon, Nov 05, 2012 at 14:42:22, Philip, Avinash wrote:
[...]
+pwmss0: pwmss@4830 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x4830 0x10
+ 0x48300100 0x80
+ 0x48300180 0x80
+ 0x48300200
On 11/6/2012 11:02 PM, Mugunthan V N wrote:
This patch-series adds support for,
[1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
[2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw
driver, as in case of AM33XX, the resources are shared and common
On Wed, 2012-11-07 at 09:06 +0100, Pantelis Antoniou wrote:
Hi Grant,
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 6, 2012, at 12:14 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 10:30
On Wed, Nov 07, 2012 at 15:18:37, Daniel Mack wrote:
On 05.11.2012 14:29, Philip, Avinash wrote:
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP
Hi Mugunthan,
On 11/07/2012 04:24 PM, Mugunthan V N wrote:
On 11/6/2012 11:02 PM, Mugunthan V N wrote:
This patch-series adds support for,
[1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
[2/7]: Adds parent-child relation between CPSW MDIO module inside
cpsw
On Wed, 7 Nov 2012, Paul Walmsley wrote:
On Tue, 6 Nov 2012, Tony Lindgren wrote:
I'm getting errors with the allnoconfig ones, there are total four
omap defconfigs there not counting the randconfigs.
That might indeed explain the discrepancy; so far only have been building
his
* Paul Walmsley p...@pwsan.com [121107 08:57]:
On Wed, 7 Nov 2012, Paul Walmsley wrote:
On Tue, 6 Nov 2012, Tony Lindgren wrote:
I'm getting errors with the allnoconfig ones, there are total four
omap defconfigs there not counting the randconfigs.
That might indeed explain the
On 11/04/2012 08:46 PM, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc4/20121104142910/
Passing tests
-
Boot to userspace: 2420n800, 3517evm, 3530es3beagle,
Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi Kevin,
On Wed, Nov 07, 2012 at 06:36:06, Kevin Hilman wrote:
Bedia, Vaibhav vaibhav.be...@ti.com writes:
On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
[...]
Also, if there are drivers for these devices, won't this interfere?
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.7-rc4/fixes-signed
for you to fetch changes up to
On 11/07/2012 01:47 AM, Pantelis Antoniou wrote:
Hi Stephen,
On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there.
On 11/07/2012 03:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started
On Wed, 7 Nov 2012, Jon Hunter wrote:
On 11/04/2012 08:46 PM, Paul Walmsley wrote:
* 4460pandaes: boot fails early
- Appears to be due to X-loader problems here
- Need to note the X-loader version so we know it's broken
Are you still planning to investigate this further or migrate
* Igor Grinberg grinb...@compulab.co.il [121107 06:44]:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures
On Wed, Nov 7, 2012 at 4:44 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
The driver supports the following PWM outputs:
TWL4030 PWM0 and PWM1
TWL6030 PWM1 and PWM2
On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
will select the correct mux so the PWM can be used.
On 11/07/2012 11:32 AM, Paul Walmsley wrote:
On Wed, 7 Nov 2012, Jon Hunter wrote:
On 11/04/2012 08:46 PM, Paul Walmsley wrote:
* 4460pandaes: boot fails early
- Appears to be due to X-loader problems here
- Need to note the X-loader version so we know it's broken
Are you still
On Wed, Nov 7, 2012 at 4:44 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled
On Wed, 7 Nov 2012, Paul Walmsley wrote:
If you're asking for a test build of the base commit,
7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33, I just kicked off a test build
of that; will post when done.
Just confirmed that this one passes all build tests here.
- Paul
--
To unsubscribe from
* Paul Walmsley p...@pwsan.com [121107 10:21]:
On Wed, 7 Nov 2012, Paul Walmsley wrote:
If you're asking for a test build of the base commit,
7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33, I just kicked off a test build
of that; will post when done.
Just confirmed that this one passes all
* Kishon Vijay Abraham I kis...@ti.com [121102 01:16]:
This patch series allows ocp2scp driver to create its child devices
from the platform data.
In omap platforms, usb phy is connected to ocp2scp and usb phy is needed
for MUSB to be functional. When ocp2scp driver was added, it had only dt
The following changes since commit a0212796b58061a9716178d261f318925c246643:
Merge tag 'omap-cleanup-fixes-a-for-3.8' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
omap-for-v3.8/cleanup-headers (2012-10-26 13:18:19 -0700)
are available in the git repository at:
Hi,
On Mon, 5 Nov 2012, Kevin Hilman wrote:
# echo mem /sys/power/state
[ 102.271087] PM: Syncing filesystems ... done.
[ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
done.
[
With the latest mainline u-boot bootloader (v2012.10), timers (5-8) in
the ABE power domain are failing to turn-on. The timers never come out
of the disabled state when setting the module-mode field to enable.
The problem was exposed when u-boot was updated to NOT configure and
lock the ABE DPLL
Commit ARM: dts: OMAP4: Update timer addresses updated the device-tree
names of the OMAP4 timers 5-7 because the default address for the timers
was changed from the L3 address to the MPU private address. When booting
with device-tree, this introduces a regression when attempting to set
the parent
Fixes included, fixing up timer clock aliases for v3.8 and working
around ABE DPLL issue seen with latest u-boot bootloader (v2012.10).
Testing includes:
- Boot testing on OMAP3430 Beagle, OMAP4430 Panda and OMAP4460 Panda
- Boot tested with device-tree on OMAP4430 Panda and OMAP4460 Panda
and
On OMAP4 devices, the ABE DPLL has an internal 4X multiplier that can
be enabled or disabled in addition to the standard configurable
multiplier (M) for OMAP DPLLs. When configuring the ABE DPLL the 4X
multiplier is accounted for by checking to see whether it is enabled or
not. However, when
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To
This series includes several fixes for the OMAP DMTIMER driver. This is
based upon 3.7-rc4 with the two series adding device-tree support for
DMTIMERs [1] and the 32kHz Counter [2]
Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda.
Testing includes ...
1. Booting kernel on
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode
When using a DMTIMER as the clock-source timer, posted mode configuration of
the DMTIMER is used. Posted mode is only benefical when configuring timers as
it allows writes to be posted and does not stall the CPU until the write is
complete. The clock-source timer is only configured once on boot
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the
For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer registers
after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1),
due
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
a fix was added to prevent timer1 being reset in the function
omap_dm_timer_reset() because timer1 was being used as the system timer for
OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
Restoring the timer interrupt status is not possible because writing a 1 to any
bit in the register clears that bit if set and writing a 0 has no affect.
Furthermore, if an interrupt is pending when someone attempts to disable a
timer, the timer will fail to transition to the idle state and hence
The OMAP DMTIMERs can generate an interrupt when the timer counter value
matches the value stored in the timer's match register. When using this
feature spurious interrupts were seen, because the compare logic is being
enabled before the match value is loaded and according to the documentation
the
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.
For OMAP2+
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because the same interrupt
enable register is used to disable interrupts. However, some timer instances
Whenever we call the function omap_dm_timer_set_source() to set the clock
source of a dmtimer we look-up the dmtimer functional clock source by
calling clk_get(). This is not necessary because on requesting a dmtimer
we look-up the functional clock source and store it in the omap_dm_timer
The __omap_dm_timer_set_source() function is only used by the system timer
(clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
remove this code from the dmtimer driver and move it to the system timer
code for OMAP2+ devices.
The current __omap_dm_timer_set_source() function
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hotplugging is not some abstract future scenario, we already have
hardware that could use it. For
Another update on this one to fix a build break that Tony spotted.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Mon, 29 Oct 2012 20:56:07 -0600
Subject: [PATCH] ARM: OMAP2+: PRCM: create SoC-specific chip restart
functions
Split omap_prcm_restart() from mach-omap2/prcm.c into
On 11/07/2012 11:32 AM, Paul Walmsley wrote:
On Wed, 7 Nov 2012, Jon Hunter wrote:
On 11/04/2012 08:46 PM, Paul Walmsley wrote:
* 4460pandaes: boot fails early
- Appears to be due to X-loader problems here
- Need to note the X-loader version so we know it's broken
Are you still
On 11:16-20121107, Joshua Emele wrote:
On Wed, Nov 7, 2012 at 6:53 AM, Nishanth Menon n...@ti.com wrote:
On 17:47-20121106, Joshua Emele wrote:
+static int __cpuinit omap_iva_init(struct cpufreq_policy *policy)
+{
+ int result;
+ if (!iva_clk_name
Hi all,
* Jon Hunter jon-hun...@ti.com [121107 11:03]:
This series includes several fixes for the OMAP DMTIMER driver. This is
based upon 3.7-rc4 with the two series adding device-tree support for
DMTIMERs [1] and the 32kHz Counter [2]
These look OK to me, I'm assuming you'll do a pull request
* Benoit Cousson b-cous...@ti.com [121107 03:00]:
On 11/07/2012 02:04 AM, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [121105 05:16]:
Hi,
OMAPDSS device tree support is still some way in the future. Tony has
requested
to get DSS working for Panda SDP boards with DT
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and
* Mohammed, Afzal af...@ti.com [121107 01:00]:
+ Tony, Daniel
Hi,
On Wed, Nov 07, 2012 at 02:04:03, Hunter, Jon wrote:
On 11/06/2012 12:00 PM, Matthieu CASTET wrote:
I will post another patch, unless this is already done in Afzal patch
(Is there
a tree where I can get Afzal
On 11/07/2012 03:22 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121107 11:03]:
This series includes several fixes for the OMAP DMTIMER driver. This is
based upon 3.7-rc4 with the two series adding device-tree support for
DMTIMERs [1] and the 32kHz Counter [2]
These look OK to
1 - 100 of 157 matches
Mail list logo
