In all these files, the .power field was never correctly initialized.
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
drivers/gpu/drm/i915/intel_panel.c |1 +
drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
drivers/platform/x86/toshiba_acpi.c |
For coupled cpuidle to work when both cpus are active, it needs a global timer
that can handle events for both cpus. This timer is used as the broadcast
clock-event when the per-cpu timer hardware stop in low power states.
Set the cpumask of clockevent_gpt to all cpus, set the rating correctly,
Kevin,
Now Colin's v3 [1] is apearing in Len Brown's next branch, I have rebased
OMAP4 support against it. I need to pick up couple of fixes [2] posted on
top of v3 [1] version and arm-soc 'omap/cpuidle-cleanup' branch lined up
for 3.5.
This series adds the coupled cpuidle support for OMAP4 and
OMAP4 idle driver uses CLOCK_EVT_NOTIFY_BROADCAST_[ENTER/EXIT]
for broadcast clock events. But _ENTER/_EXIT doesn't really open
broadcast clock events and to explicitly setup the broadcast device,
CLOCK_EVT_NOTIFY_BROADCAST_ON should be used.
Add the missing CLOCK_EVT_NOTIFY_BROADCAST_ON
From: Kevin Hilman khil...@ti.com
With coupled idle states, a failure for any CPU to hit a low power
state must be coordinated such that all CPUs abort.
On OMAP4, when entering a coupled state, CPU0 has to wait for CPU1 to
enter its low power state before it can enter its low power state.
This
OMAP4 CPUDILE driver is converted mainly based on notes from the
coupled cpuidle patch series.
The changes include :
- Register both CPUs and C-states to cpuidle driver.
- Set struct cpuidle_device.coupled_cpus
- Set struct cpuidle_device.safe_state to non coupled state.
- Set
On Friday 18 May 2012 07:09 PM, Tomi Valkeinen wrote:
Hi,
On Tue, 2012-05-15 at 11:32 +0530, Archit Taneja wrote:
DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
BLLP blanking intervals in a video mode stream. This is useful as a user may
want to read or change
On Wed, 2012-05-16 at 11:28 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Added in preparation for device off mode. SAR ROM contains the mapping
from SAR RAM to IO registers, and this will eventually be parsed during
init time to do the reverse before device off.
On Wed, 2012-05-16 at 15:36 -0700, Kevin Hilman wrote:
+Jean for functional power states
Tero Kristo t-kri...@ti.com writes:
This patch adds device off support to OMAP4 device type.
Description is rather thin for a patch that is doing so much.
OFF mode is disabled by default,
On Wed, 2012-05-16 at 15:42 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from OFF mode.
The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
are
On Thu, 2012-05-17 at 09:37 -0700, Kevin Hilman wrote:
Shilimkar, Santosh santosh.shilim...@ti.com writes:
On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman khil...@ti.com wrote:
Tero Kristo t-kri...@ti.com
On Fri, 2012-05-18 at 11:23 +0530, Shilimkar, Santosh wrote:
On Thu, May 17, 2012 at 10:12 PM, Kevin Hilman khil...@ti.com wrote:
Shilimkar, Santosh santosh.shilim...@ti.com writes:
On Thu, May 17, 2012 at 4:28 AM, Kevin Hilman khil...@ti.com wrote:
Tero Kristo t-kri...@ti.com writes:
On Wed, 2012-05-16 at 16:07 -0700, Kevin Hilman wrote:
On 05/16/2012 04:05 PM, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Santosh Shilimkarsantosh.shilim...@ti.com
The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
IVA and Tesla execution.
On Wed, 2012-05-16 at 17:33 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Without this, CPU0 will crash in the ROM code during wakeup from
device off. This patch also clears the GIC save area, to prevent
ROM code from writing garbage to the GIC registers during wakeup.
Here are some late fixes for omapdss. Mostly small things that were found
during testing.
One exception is the TILER support from Chandrabhanu, which adds support to
configure omapdss so that it can be used with TILER. While not a fix, it's safe
to add as the patch doesn't affect non-TILER
There is a problem related to DSS FIFO thresholds and power management
on OMAP3. It seems that when the full PM hits in, we get underflows. The
core reason is unknown, but after experiments it looks like only
particular FIFO thresholds work correctly.
This bug is related to an earlier patch,
Commit 05dd0f5308213e169b02458a7f3a61362e581e14 (OMAPDSS: DISPC: Update
Accumulator configuration for chroma plane) adds
dispc_ovl_set_accu_uv() function that sets the accu, but the function
only handles YUV and NV12 modes, and BUGs otherwise.
The patch also adds a call to the function, but
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.
This patch fixes the warnings by initializing the
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.
This patch fixes the warnings by initializing the
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.
This patch fixes the warnings by initializing the
From: Chandrabhanu Mahapatra cmahapa...@ti.com
TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
Physical memory can be mapped to a portion of OMAP's system address space called
TILER address space. The TILER address space is split into 8 views. Each view
represents
From: Archit Taneja arc...@ti.com
DSS2 driver uses the timings in manager's private data to check the validity of
overlay and manager infos written by the user. For VENC interface, we divide the
Y resolution by half when writing to the DISPC_DIGIT_SIZE register as the
content is interlaced.
From: Archit Taneja arc...@ti.com
The VENC interfaces uses it's venc_set_timing() function to take in a new set
of timings. If the panel is disabled, it does not disable and re-enable the
interface. Currently, the manager timings are applied in venc_power_on(), these
are not called by set_timings
On Wed, 2012-05-16 at 16:36 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Carlos Leija cile...@ti.com
At wakeup from OFF/OSWR CPU1 will call secure HAL service through a local
secure dispatcher with MMU off,
Reviewers who are uninitaited in this level of
On Wed, 2012-05-16 at 16:48 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Axel Haslam axelhas...@gmail.com
ROM code restores part of the GIC context during wakeup from device
off mode from the SAR RAM. If the PPI and SPI interrupts are not
marked as non-secure
On Wed, 2012-05-16 at 18:17 -0600, Paul Walmsley wrote:
Hi Tero
On Mon, 14 May 2012, Tero Kristo wrote:
save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
otherwise the secure ROM code will crash.
Do we know why the l3_main_3 interconnect has to be enabled? Is this
On Wed, 2012-05-16 at 17:06 -0700, Kevin Hilman wrote:
+Benoit
Tero Kristo t-kri...@ti.com writes:
save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
otherwise the secure ROM code will crash.
Signed-off-by: Tero Kristo t-kri...@ti.com
I think I mentioned this already
On Mon, May 21, 2012 at 3:05 PM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-05-16 at 18:17 -0600, Paul Walmsley wrote:
Hi Tero
On Mon, 14 May 2012, Tero Kristo wrote:
save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
otherwise the secure ROM code will crash.
Do we
Tony,
There is a bug in the for-l-o-3.5 branch I sent earlier, causing the DVI driver
to fail to request the power-down GPIO. This patch fixes it.
Tomi Valkeinen (1):
OMAP: Beagle: fix DVI GPIO request
arch/arm/mach-omap2/board-omap3beagle.c |3 +--
1 file changed, 1 insertion(+), 2
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO handling for DVI output) moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver. One
gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
the Beagle board
On Mon, May 21, 2012 at 3:08 PM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-05-16 at 17:06 -0700, Kevin Hilman wrote:
+Benoit
Tero Kristo t-kri...@ti.com writes:
save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
otherwise the secure ROM code will crash.
Hi Jon,
On 5/18/2012 11:09 PM, Jon Hunter wrote:
Hi Benoit,
On 05/10/2012 04:56 AM, Cousson, Benoit wrote:
Hi Jon Ming,
On 5/9/2012 11:35 PM, Jon Hunter wrote:
From: Ming Leiming@canonical.com
The following modules is required to be enabled before configuring
cross trigger interface
On Wed, 2012-05-16 at 17:31 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back
to off.
Why is it waking up then? (I know the answer, but will forget. The
changelog serves as my long-term memory.)
Tero,
On Mon, May 21, 2012 at 3:51 PM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-05-16 at 17:31 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back
to off.
Why is it waking up then? (I know the
Op 21 mei 2012, om 11:41 heeft Tomi Valkeinen het volgende geschreven:
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO handling for DVI output) moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver. One
On Mon, 2012-05-21 at 12:59 +0200, Koen Kooi wrote:
Op 21 mei 2012, om 11:41 heeft Tomi Valkeinen het volgende geschreven:
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO handling for DVI output) moved TFP410 chip's
powerdown-gpio handling from
Op 21 mei 2012, om 13:12 heeft Tomi Valkeinen het volgende geschreven:
On Mon, 2012-05-21 at 12:59 +0200, Koen Kooi wrote:
Op 21 mei 2012, om 11:41 heeft Tomi Valkeinen het volgende geschreven:
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO
On Mon, 2012-05-21 at 13:28 +0200, Koen Kooi wrote:
Op 21 mei 2012, om 13:12 heeft Tomi Valkeinen het volgende geschreven:
On Mon, 2012-05-21 at 12:59 +0200, Koen Kooi wrote:
Op 21 mei 2012, om 11:41 heeft Tomi Valkeinen het volgende geschreven:
Commit
Here's an updated patch with a fix for the GPIO direction:
From e74be66075d14f7ed55ba3aaa8a166eac6a3e60f Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon, 21 May 2012 11:28:57 +0300
Subject: [PATCH] OMAP: Beagle: fix TFP410 powerdown GPIO init
Commit
Sat, May 19, 2012 at 4:52 AM, Eduardo Valentin eduardo.valen...@ti.com
wrote:
I guess it is time to properly document this increasing busy loop delay..
As it is getting closer to ms scale..
Does the following sound good?
/* Maximum time for Voltage Processor to enter or exit idle */
Regards,
Hi Santosh,
On Thu, May 17, 2012 at 12:04 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Jean,
On Tuesday 08 May 2012 02:10 PM, Jean Pihet wrote:
Paul,
On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
Hi Michal,
On Mon, May 21, 2012 at 4:02 PM, Michal Simek mon...@monstr.eu wrote:
I have looked at it and tested on latest and greatest and the problem is
still there.
Ok, I see why this is happening.
We're now allocating the vrings' DMA in -find_vqs() just before we
boot the remote processor,
Hi Tero, Kevin, Santosh,
On Mon, May 21, 2012 at 10:48 AM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-05-16 at 15:36 -0700, Kevin Hilman wrote:
+Jean for functional power states
Tero Kristo t-kri...@ti.com writes:
This patch adds device off support to OMAP4 device type.
Description
Jean,
On Mon, May 21, 2012 at 7:23 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Hi Santosh,
On Thu, May 17, 2012 at 12:04 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Jean,
On Tuesday 08 May 2012 02:10 PM, Jean Pihet wrote:
Paul,
On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley
Hello,
On Mon, May 21, 2012 at 08:36:35AM -0500, ext Nishanth Menon wrote:
Sat, May 19, 2012 at 4:52 AM, Eduardo Valentin eduardo.valen...@ti.com
wrote:
I guess it is time to properly document this increasing busy loop delay..
As it is getting closer to ms scale..
Does the following
On Mon, May 21, 2012 at 9:51 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
On Mon, May 21, 2012 at 08:36:35AM -0500, ext Nishanth Menon wrote:
Sat, May 19, 2012 at 4:52 AM, Eduardo Valentin eduardo.valen...@ti.com
wrote:
I guess it is time to properly document this increasing
The correct patch for this was sent earlier:
http://www.spinics.net/lists/linux-omap/msg70042.html
[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset gpio
On Mon, May 21, 2012 at 2:41 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Tony,
There is a bug in the for-l-o-3.5 branch I sent
On Mon, 2012-05-21 at 08:52 -0700, Russ Dill wrote:
The correct patch for this was sent earlier:
http://www.spinics.net/lists/linux-omap/msg70042.html
[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset gpio
On Mon, May 21, 2012 at 2:41 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, May 21, 2012 at 8:55 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-05-21 at 08:52 -0700, Russ Dill wrote:
The correct patch for this was sent earlier:
http://www.spinics.net/lists/linux-omap/msg70042.html
[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset gpio
On
On Mon, 2012-05-21 at 09:01 -0700, Russ Dill wrote:
On Mon, May 21, 2012 at 8:55 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-05-21 at 08:52 -0700, Russ Dill wrote:
The correct patch for this was sent earlier:
http://www.spinics.net/lists/linux-omap/msg70042.html
[PATCH
On Wed, 2012-05-09 at 15:15 -0700, Russ Dill wrote:
This removes several boot warnings from board-omap3beagle.c:
- gpio_request: gpio--22 (DVI reset) status -22
- Unable to get DVI reset GPIO
There is a combination of leftover code and revision confusion.
Additionally, xM support is
Hi Pali,
* Tony Lindgren t...@atomide.com [120508 17:12]:
* Pali Rohár pali.ro...@gmail.com [120504 08:41]:
Hi!
Upstream linux kernel has already driver for lis3lv02d accelerometer
in drivers/misc/lis3lv02d. So now can be added also platform support
for nokia rx51. Patch exists for
* Tomi Valkeinen tomi.valkei...@ti.com [120521 04:40]:
On Mon, 2012-05-21 at 13:28 +0200, Koen Kooi wrote:
Op 21 mei 2012, om 13:12 heeft Tomi Valkeinen het volgende geschreven:
On Mon, 2012-05-21 at 12:59 +0200, Koen Kooi wrote:
Op 21 mei 2012, om 11:41 heeft Tomi Valkeinen het
On Mon, May 21, 2012 at 9:07 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-05-09 at 15:15 -0700, Russ Dill wrote:
This removes several boot warnings from board-omap3beagle.c:
- gpio_request: gpio--22 (DVI reset) status -22
- Unable to get DVI reset GPIO
There is a
Looks good to me.
Tested-by: Fernando Guzman Lugo fernando.l...@ti.com
Regards,
Fernando.
On Sun, May 20, 2012 at 7:00 AM, Ohad Ben-Cohen o...@wizery.com wrote:
Dynamically allocate the vrings' DMA when the remote processor
is about to be powered on (i.e. when -find_vqs() is invoked),
and
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP
Sometimes a single IOMMU user may have to deal with several
different IOMMU devices (e.g. remoteproc).
When an IOMMU fault happens, such users have to regain their
context in order to deal with the fault.
Users can't use the private fields of neither the iommu_domain nor
the IOMMU device,
On 05/19/2012 02:44 AM, Arnd Bergmann wrote:
On Friday 18 May 2012, Stephen Warren wrote:
On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
So if we do that, we might want to make the dma-names property mandatory
for every device, and document what the names are.
We could do that, but one more
Hi
This series implements low-level PRM/CM support for the AM33xx series
of chips. This support is a prerequisite for the kernel to reset,
enable, and disable on-chip IP blocks.
This series applies against Tony's devel-soc branch at commit
8a7289f52543cc89de73e174946edaa21a2d049d (ARM:
From: Vaibhav Hiremath hvaib...@ti.com
Define AM33XX control register, in order to allow access to
control register address space, also add CONTROL_SEC_CLK_CTRL
register offset; both are required in clock tree data,
for wdt0 and timer0 clock source select configuration.
CONTROL.SEC_CLK_CTRL
From: Vaibhav Hiremath hvaib...@ti.com
AM33XX PRCM module consist of, various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
- SW Sleep: sw forced sleep transition
- SW Wakeup: sw forced wakeup transition
This patch adds all available
From: Vaibhav Hiremath hvaib...@ti.com
As far as PRM/CM/PRCM modules are concerned, AM33XX device is
different than OMAP3 and OMAP4 architectures; so we need to handle it
separately. This patch adds support for the PRM APIs required for
AM33XX device.
Signed-off-by: Vaibhav Hiremath
From: Vaibhav Hiremath hvaib...@ti.com
Add offset mask fields to struct powerdomain
In case of AM33xx family of devices, there is no consistency between
PWRSTCTRL PWRSTST register offsers in PRM space, for example -
PRM_XXX PWRSTCTRL PWRSTST
From: Vaibhav Hiremath hvaib...@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).
Also, hook up the AM33XX voltage domain to OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Hi all,
This series removes the old legacy fulls speed support for
omap2 as it's pretty much only used for omap1 only.
For omap2, only n8x0 seems to have active development, and
that has the external high speed tusb chip instead.
This allows removes the last user of omap_read/write for omap2+,
We should not select ARCH_OMAP_OTG as the hardware does not
have the legacy FS (Full Speed) USB interface.
Cc: linux-...@vger.kernel.org
Cc: Felipe Balbi ba...@ti.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |1
The FS (Full Speed) USB controller is available on 2420 and 2430,
but not being used.
Out of the 2420 based boards only Nokia N8X0 are seeing active
development and they have external HS (High Speed) TUSB controller.
On omap 2430sdp there is MUSB HS controller, so there's no need
to use the
As the FS USB code is not being actively used for omap2+
there's no point keeping it around for omap2+.
Let's make the FS USB platform init code omap1 only so
we can remove the last user of omap_read/write for omap2+,
and simplify things for further USB, DMA, and device tree
related work.
While
There are no active users of this code for omap2 as
the boards in use have either TUSB or MUSB controller.
While at it, also fix warnings related to uninitialized
dc_clk and hhc_clk.
Cc: linux-...@vger.kernel.org
Cc: Felipe Balbi ba...@ti.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
On Monday 21 May 2012, Stephen Warren wrote:
The point with the direction was that it covers most cases and makes
them rather simple, while for the rare case where you need more than
two channels, you just use the otherwise optional named interface
rather than the numbered one. My
On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
On Monday 21 May 2012, Stephen Warren wrote:
The point with the direction was that it covers most cases and makes
them rather simple, while for the rare case where you need more than
two channels, you just use the otherwise optional named interface
On Mon, May 21, 2012 at 04:25 PM +, Corentin Chary wrote:
In all these files, the .power field was never correctly initialized.
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
It looks good.
Best regards,
Jingoo Han
---
drivers/gpu/drm/i915/intel_panel.c |1
genirq requires that the IRQ requests that do not provided a handler to
use the IRQF_ONESHOT flag. This is to prevent situations in which the irq line
is reenabled while the interrupt is still asserted. While this situation may
not happen in edge type interrupts, genirq still requires to use
Hi Tomi,
While validating HDMI audio on the linux-next tree I found that requesting
the threaded irq for HDMI HDP will fail due to an upcoming change in genirq[1].
This change requires to use the IRQF_ONESHOT flag even for edge type interrupts
if no handler is provided, otherwise the request will
Hi Ivan,
On Sat, May 19, 2012 at 18:20:18, Ivan Djelic wrote:
Hi Afzal,
I tried to take your series of patches, but I had issues with the
first [1] (I did not try the others): it depends on the following patch,
which is not in the l2-mtd-2.6 tree:
75 matches
Mail list logo
