Hi Tomi,
On Mon, Mar 7, 2011 at 2:10 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote:
Adding HDMI support on OMAP4.
HDMI is a driver that is similar to the VENC or the DSI driver to support
HDMI/DVI sink device.
snip
1. v10 of omap2,3
Salut Paul,
On 3/8/2011 12:25 AM, Paul Walmsley wrote:
Hi Rajendra, Santosh,
On Fri, 4 Mar 2011, Rajendra Nayak wrote:
On Thursday 03 March 2011 06:00 PM, Rajendra Nayak wrote:
Also some more testing showed up a lockup in suspend on OMAP4 which I
could narrow down to a similar case with
Hi Tomi,
On Mon, Mar 7, 2011 at 3:16 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote:
Adding the hdmi interface driver header file (hdmi.h) to the dss driver.
Register and timing declaration to be used by the corresponding c file
is added
On Tue, 2011-03-08 at 02:17 -0600, K, Mythri P wrote:
Hi Tomi,
On Mon, Mar 7, 2011 at 3:16 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote:
Adding the hdmi interface driver header file (hdmi.h) to the dss driver.
Register and timing
From: ext David Cohen daco...@gmail.com
Subject: Re: [PATCH] omap: iommu: disallow mapping NULL address
Date: Mon, 7 Mar 2011 21:41:21 +0200
On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote:
From: ext David Cohen daco...@gmail.com
Subject: Re: [PATCH] omap: iommu: disallow mapping NULL address
Date: Mon, 7 Mar 2011 23:35:31 +0200
On Mon, Mar 7, 2011 at 11:19 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi David,
Hi Laurent,
On Monday 07 March 2011 20:41:21
Guzman Lugo, Fernando wrote:
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote:
On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones
michael.jo...@matrix-vision.de wrote:
From
On Tue, Mar 8, 2011 at 07:45, Paul Walmsley p...@pwsan.com wrote:
Some drivers wish to know whether the device that they control can
ever lose context, for example, when the device's enclosing
powerdomain loses power. They can use this information to determine
whether it is necessary to save
Hi Fernando,
On Tue, Mar 8, 2011 at 11:13 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
Guzman Lugo, Fernando wrote:
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote:
On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On
On 3/7/2011 4:03 PM, Valkeinen, Tomi wrote:
On Mon, 2011-03-07 at 07:51 -0600, Cousson, Benoit wrote:
+ Rajendra
Hi Tomi,
On 3/7/2011 9:22 AM, Valkeinen, Tomi wrote:
Hi Kevin, Paul,
We currently have a small problem with OMAP4 DSS. When we enable the DSS
clocks, it seems that the DSS
The following series removes cpu_...() usage completely from the
omap-i2c driver by having decisions about functional implementation
choices in the SoC held in cpu-specific hwmod tables that are
already established, or for OMAP1 where there is no hwmod, set at
OMAP1-specific i2c bus addition time.
The OMAP I2C driver dynamically chooses between two register sets of
differing sizes depending on the cpu type it finds itself on.
It has been observed that the existing code references non-existing
registers on OMAP3530, because while it correctly chose the smaller
register layout based on cpu
These represent the two kinds of (incompatible) OMAP I2C
peripheral unit in use so far.
The constants are in linux/i2c-omap.h so the omap i2c driver can have
them too.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy
Since we cannot trust (or even reliably find) the OMAP I2C
peripheral unit's own revision register, we must inform the
OMAP i2c driver of which IP version it is running on. We
do this by tagging the omap_hwmod_class for i2c on all the
OMAP2+ platform / cpu specific hwmod init and passing it up
to
We need to pass the I2C IP revision from the hwmod class up
into the OMAP I2C driver, which does not have direct
access to it.
This adds a member to the platform data the OMAP I2C driver
does use already to hold the I2C IP revision.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
All OMAP1 are using IP revision 1 in terms of register
layout. We set this information in omap1_i2c_add_bus() so
we don't have to use cpu_is_xxx() any more in the omap i2c
driver.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Mark each OMAP I2C bus with the hwmod's knowledge of which I2C
IP version is in the chip we're running on.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/plat-omap/i2c.c |
Change the register map names to reflect the IP revision they
are representing, and use the platform_data IP revision index
to select between them at init time.
Eliminates 1 of 17 cpu_...() calls in the driver.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell
Peter Maydell noticed when running under QEMU he was getting
errors reporting 32-bit access to I2C peripheral unit registers
that are documented to be 8 or 16-bit only[1][2]
The I2C driver is blameless as it wraps its accesses in a
function using __raw_writew and __raw_readw, it turned out it
is
This solves the main problem the patch series is about. Prior
to this patch on OMAP3530 the driver wrongly interprets the I2C
peripheral unit's own reported revision as meaning it is running
on an IP V2 device and must use the extended registers.
In fact OMAP3530 is IP V1 with the smaller
OMAP I2C driver can access the configuration flags through
its platform data.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
include/linux/i2c-omap.h |1 +
1 files changed, 1
This is how the driver can find the flags for its implementation
functionality in its platform_data
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/plat-omap/i2c.c |7
These represent the 8 kinds of implementation functionality
that up until now were inferred by the 16 remaining cpu_...()
tests in the omap i2c driver.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green
This adds the new functionality flags for omap i2c unit to all OMAP2
hwmod definitions
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |
Most of the OMAP1 implementation flags are set statically, with the
exception that omap7xx has its data bus wired up differently.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
This patch eliminates all cpu_...() tests from the OMAP I2C driver.
Instead, it uses the functionality flags in the platform data to make
the decisions about product variations the driver needs to handle.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell
The IP version is prepended to the existing printed probed
version as an epoch version.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Thursday, March 03, 2011 6:53 AM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 0/6] omap3: pm: Fixes for low power code
Hi Santosh,
Santosh
On Sat, Mar 5, 2011 at 7:27 AM, Kevin Hilman khil...@ti.com wrote:
Kevin Hilman khil...@ti.com writes:
Govindraj.R govindraj.r...@ti.com writes:
[...]
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
@@ -342,6
There are clocks on OMAP4 within DSS2 which can have multiple clock sources.
This cleans up the existing way of selecting/getting the clock sources and add
some of the new clock sources for OMAP4.
Applies over:
http://gitorious.org/linux-omap-dss2/linux/commits/master
Archit Taneja (2):
Clean up some of the DSS functions which select/get clock sources, use switch
to select the clock source members since more clock sources will be introduced
later on.
Remove the use of macro CONFIG_OMAP2_DSS_DSI in dispc_fclk_rate, use a dummy
inline for function for
On OMAP3, the pixel clock for the LCD manager was derived through DISPC_FCLK as:
Lcd Pixel clock = DISPC_FCLK / lcd / pcd
Where lcd and pcd are divisors in the DISPC_DIVISOR register.
On OMAP4, the pixel clocks for LCD1 and LCD2 managers are derived from 2 new
clocks named LCD1_CLK and
On Sat, Mar 5, 2011 at 5:24 AM, Kevin Hilman khil...@ti.com wrote:
Hi Govindraj,
Govindraj.R govindraj.r...@ti.com writes:
For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
are wakeup capable) enable the IO-daisy wakeup capability.
During re-muxing avoid direct write
-Original Message-
From: Sripathy, Vishwanath
Sent: Monday, March 07, 2011 10:01 PM
To: Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
[snip]...[snip]
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
-Original Message-
From: Premi, Sanjeev [mailto:pr...@ti.com]
Sent: Tuesday, March 08, 2011 5:56 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
-Original Message-
From: Sripathy, Vishwanath
Sent: Monday,
IOVMM driver checks input 'da == 0' when mapping address to determine whether
user wants fixed 'da' or not. At the same time, it doesn't disallow address
0x0 to be used, what creates an ambiguous situation. This patch set moves
fixed 'da' check to the input flags.
It also fixes da_start value for
Premi, Sanjeev wrote, on 03/08/2011 05:56 PM:
[...]
Add glue logic to hook-up AM35x processors
with TPS65023.
It seems that you are not really using Voltage layer for any
interaction
with TPS65023 as you are not using VP and VC. Then what is the
purpose of
registering this PMIC with
ISP doesn't consider 0x0 as a valid address, so it should explicitly
exclude first page from allowed 'da' range.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
From: Michael Jones michael.jo...@matrix-vision.de
commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping
the NULL address if da_start==0, which would then not get unmapped.
Disallow this again. And spell variable 'alignment' correctly.
Signed-off-by: Michael Jones
Currently IOVMM driver sets IOVMF_DA_FIXED/IOVMF_DA_ANON flags according
to input 'da' address when mapping memory:
da == 0: IOVMF_DA_ANON
da != 0: IOVMF_DA_FIXED
It prevents IOMMU to map first page with fixed 'da'. To avoid such
issue, IOVMM will not automatically set IOVMF_DA_FIXED. It should
From: ext David Cohen daco...@gmail.com
Subject: [PATCH 0/3] omap: iovmm: Fix IOVMM check for fixed 'da'
Date: Tue, 8 Mar 2011 14:46:02 +0200
IOVMM driver checks input 'da == 0' when mapping address to determine whether
user wants fixed 'da' or not. At the same time, it doesn't disallow address
The runtime PM does not offer enough granularity to control
individual clocks separately as needed. Current pm implementation
of omap_wdt blocks the CORE power domain from idling in
OMAP SoC, as it keeps the interface clock of the watchdog always
on. This causes severe power leakage in devices
This reverts commit 7ec5ad0f3c1e28b693185c35f768953c5db32291.
The runtime PM APIs do not allow separate switching of watchdog
interface clock. Both functional clock and interface clock are
switched at the same time. This results in the CORE power domain
being unable to sleep due to the watchdog
Keeping the omap watchdog interface clock always enabled
blocks OMAP CORE power domain from sleeping. Introduce
fine grain clock control to fix the issue.
This patch is based on a patch created by Atal
Shargorodsky: http://lkml.org/lkml/2009/3/10/266.
Signed-off-by: Kalle Jokiniemi
minor comment - here and elsewhere - OMAP, PM is a good idea to be
caps even in $subject.
On Wed, Mar 2, 2011 at 19:00, Lesly A M lesl...@ti.com wrote:
Only configure sleep script when the flag is TWL4030_SLEEP_SCRIPT.
Adding the missing brackets for fixing the issue.
Signed-off-by: Lesly A
On Wed, Mar 2, 2011 at 19:00, Lesly A M lesl...@ti.com wrote:
Correcting the if condition check for printing the warning,
if wakeup script is not updated before updating the sleep script.
Since the flag 'order' is set to '1' while updating the wakeup script for
P1P2,
the condition checking
-Original Message-
From: Menon, Nishanth
Sent: Tuesday, March 08, 2011 6:16 PM
To: Premi, Sanjeev
Cc: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
Premi, Sanjeev wrote, on 03/08/2011 05:56 PM:
[...]
Add glue logic
-Original Message-
From: Sripathy, Vishwanath
Sent: Tuesday, March 08, 2011 6:16 PM
To: Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
-Original Message-
From: Premi, Sanjeev [mailto:pr...@ti.com]
Sent: Tuesday,
On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev pr...@ti.com wrote:
[...]
Thinking from a generic soln perspective, lets try and split this into
multiple issues:
a) OPP and Voltage layer voltages - these need to be PMIC aware as well.
See my comment on
-Original Message-
From: Menon, Nishanth
Sent: Tuesday, March 08, 2011 6:58 PM
To: Premi, Sanjeev
Cc: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev pr...@ti.com wrote:
[...]
On Sat, Mar 5, 2011 at 7:29 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Adapts omap-serial driver to use pm_runtime api's.
1.) Populate reg values to uart port which can be used for context restore.
2.) Moved Erratum handling func to driver from serial.c
David Cohen wrote:
ISP doesn't consider 0x0 as a valid address, so it should explicitly
exclude first page from allowed 'da' range.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On Mon, Mar 07, 2011 at 04:36:12PM +0530, G, Manjunath Kondaiah wrote:
On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote:
On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote:
G, Manjunath Kondaiah manj...@ti.com writes:
This patch series is remaining part
Kevin,
On Tue, Mar 8, 2011 at 00:25, Kevin Hilman khil...@ti.com wrote:
Varadarajan, Charulatha ch...@ti.com writes:
[...]
GPIO driver is modified to use dev_pm_ops instead of sysdev_class.
With this approach, gpio_bank_suspend() gpio_bank_resume()
are not part of sys_dev_class.
Usage
As per OMAP4430 TRM, the dynamic dependency between MEMIF and MPUSS
clockdomains is enable by default. Refer register CM_MPU_DYNAMICDEP
description for details.
But it doesn't seems to work as expected and MPUSS doesn't wakeup
from off-mode if the static dependency is not set between MPUSS and
From: Abhilash Vadakkepat Koyamangalath x0151...@psplinux051.india.ti.com
The i2c_board_info entry supporting AIC23 codec was added into
the i2c2 bus.
Signed-off-by: Abhilash K V abhilash...@ti.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/board-am3517evm.c |3 +++
Paul,
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Friday, March 04, 2011 10:14 PM
To: Rajendra Nayak
Cc: linux-omap@vger.kernel.org; Benoit Cousson; Paul Walmsley
Subject: RE: Integration branch base switchover to Tony's omap-for-
linus branch
The i2c client device name (.2-001a in this case, including
the separator period) for the AIC23 codec on the TI AM3517-EVM
was appended to the codec_name member of am3517evm_dai to
resolve the names mismatch happening in soc_bind_dai_link(),
due to which the card was not getting registered.
On Tue, Mar 08, 2011 at 09:02:43PM +0530, Abhilash K V wrote:
The i2c client device name (.2-001a in this case, including
the separator period) for the AIC23 codec on the TI AM3517-EVM
was appended to the codec_name member of am3517evm_dai to
resolve the names mismatch happening in
From: Ming Lei tom.leim...@gmail.com
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
about Oprofile on Pandaboard / Omap4 on pandabo...@googlegroups.com.
Acked-by: Jean Pihet j-pi...@ti.com
Acked-by: Tony
On Tue, Mar 8, 2011 at 3:15 AM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to
On Wed, Mar 2, 2011 at 19:00, Lesly A M lesl...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/twl4030.c b/arch/arm/mach-omap2/twl4030.c
new file mode 100644
index 000..ff344b3
--- /dev/null
+++ b/arch/arm/mach-omap2/twl4030.c
@@ -0,0 +1,145 @@
+/*
+ * OMAP power script for PMIC
Menon, Nishanth n...@ti.com writes:
On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev pr...@ti.com wrote:
[...]
Thinking from a generic soln perspective, lets try and split this into
multiple issues:
a) OPP and Voltage layer voltages - these need to be PMIC aware as well.
See my comment on
On Tue, 2011-03-08 at 05:50 -0600, Taneja, Archit wrote:
There are clocks on OMAP4 within DSS2 which can have multiple clock sources.
This cleans up the existing way of selecting/getting the clock sources and add
some of the new clock sources for OMAP4.
Applies over:
On 3/8/2011 4:16 PM, Shilimkar, Santosh wrote:
Paul,
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Friday, March 04, 2011 10:14 PM
To: Rajendra Nayak
Cc: linux-omap@vger.kernel.org; Benoit Cousson; Paul Walmsley
Subject: RE: Integration branch base
Kevin Hilman wrote, on 03/08/2011 02:32 AM:
Lesly A Mlesl...@ti.com writes:
Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset.
TWL4030 power scripts which can be used by different OMAP3 boards
with the power companion chip (TWL4030 series).
The twl4030 generic script
* sricharan r.sricha...@ti.com [110306 20:33]:
Currently OMAP_DEVICE_PAD_IDLE flag is used to mux pins
dynamically. This can be simplified by using the enabled
state variable of each pad. This also fixes the issue of
the static pads not getting muxed after idling and
disable/enable state
Kalle Jokiniemi kalle.jokini...@nokia.com writes:
The runtime PM does not offer enough granularity to control
individual clocks separately as needed. Current pm implementation
of omap_wdt blocks the CORE power domain from idling in
OMAP SoC, as it keeps the interface clock of the watchdog
Hi Sakari,
On Tue, Mar 8, 2011 at 4:06 PM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
David Cohen wrote:
ISP doesn't consider 0x0 as a valid address, so it should explicitly
exclude first page from allowed 'da' range.
Signed-off-by: David Cohen daco...@gmail.com
---
* Govindraj govindraj...@gmail.com [110308 03:43]:
I am not sure whether now we can control read/writes to pad_mux from any
driver
interface and I think we have to go through mux framework for any
read/writes to mux.
Sure, the drivers should not mess with those registers directly.
with
Jean Pihet jean.pi...@newoldbits.com writes:
On Tue, Mar 8, 2011 at 3:15 AM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating similar APIs at the omap_device and omap_hwmod levels. The
On Tue, Mar 8, 2011 at 3:13 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
Guzman Lugo, Fernando wrote:
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote:
On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Mon, Mar 7, 2011
On Tue, Mar 8, 2011 at 3:55 AM, David Cohen daco...@gmail.com wrote:
Hi Fernando,
On Tue, Mar 8, 2011 at 11:13 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
Guzman Lugo, Fernando wrote:
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote:
On Mon, Mar 7,
On Tue, Mar 8, 2011 at 6:46 AM, David Cohen daco...@gmail.com wrote:
Currently IOVMM driver sets IOVMF_DA_FIXED/IOVMF_DA_ANON flags according
to input 'da' address when mapping memory:
da == 0: IOVMF_DA_ANON
da != 0: IOVMF_DA_FIXED
It prevents IOMMU to map first page with fixed 'da'. To
On Tue, Mar 8, 2011 at 6:46 AM, David Cohen daco...@gmail.com wrote:
From: Michael Jones michael.jo...@matrix-vision.de
commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping
the NULL address if da_start==0, which would then not get unmapped.
Disallow this again. And spell variable
On Tue, 8 Mar 2011, Varadarajan, Charulatha wrote:
Do you really want to return 1 in case of invalid powerdomain pointer?
Sure, that's why I wrote it that way. It seems less risky than returning
0. Do you have a proposal that makes more sense, given that this is going
to be called
From: ext Guzman Lugo, Fernando fernando.l...@ti.com
Subject: Re: [PATCH 3/3] omap: iovmm: don't check 'da' to set
IOVMF_DA_FIXED/IOVMF_DA_ANON flags
Date: Tue, 8 Mar 2011 11:59:43 -0600
On Tue, Mar 8, 2011 at 6:46 AM, David Cohen daco...@gmail.com wrote:
Currently IOVMM driver sets
Tony Lindgren t...@atomide.com writes:
* Govindraj govindraj...@gmail.com [110308 03:43]:
I am not sure whether now we can control read/writes to pad_mux from any
driver
interface and I think we have to go through mux framework for any
read/writes to mux.
Sure, the drivers should not
On Tue, Mar 8, 2011 at 12:09 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Guzman Lugo, Fernando fernando.l...@ti.com
Subject: Re: [PATCH 3/3] omap: iovmm: don't check 'da' to set
IOVMF_DA_FIXED/IOVMF_DA_ANON flags
Date: Tue, 8 Mar 2011 11:59:43 -0600
On Tue, Mar 8, 2011 at 6:46
Hi Hiroshi, Fernando,
On Tue, Mar 8, 2011 at 8:53 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Tue, Mar 8, 2011 at 12:09 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Guzman Lugo, Fernando fernando.l...@ti.com
Subject: Re: [PATCH 3/3] omap: iovmm: don't check 'da' to set
On Tue, Mar 8, 2011 at 8:06 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Tue, Mar 8, 2011 at 6:46 AM, David Cohen daco...@gmail.com wrote:
From: Michael Jones michael.jo...@matrix-vision.de
commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping
the NULL address if
Hi
On Tue, 8 Mar 2011, Kevin Hilman wrote:
Tony Lindgren t...@atomide.com writes:
* Govindraj govindraj...@gmail.com [110308 03:43]:
I am not sure whether now we can control read/writes to pad_mux from any
driver
interface and I think we have to go through mux framework for any
By the way, if your patch relies on OMAP_DEVICE_PAD_IDLE, you should
probably sync up with Sricharan, who is apparently planning to remove that
flag:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg46296.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Mar 8, 2011 at 12:57 PM, David Cohen daco...@gmail.com wrote:
Hi Hiroshi, Fernando,
On Tue, Mar 8, 2011 at 8:53 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Tue, Mar 8, 2011 at 12:09 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Guzman Lugo, Fernando
[snip]
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
+ if (~flags IOVMF_DA_FIXED)
+ flags |= IOVMF_DA_ANON;
could we use only one? both are mutual exclusive, what happen if flag
is IOVMF_DA_FIXED | IOVMF_DA_ANON? so, I suggest to get rid of
IOVMF_DA_ANON.
On Tue, Mar 8, 2011 at 9:46 PM, David Cohen daco...@gmail.com wrote:
[snip]
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
+ if (~flags IOVMF_DA_FIXED)
+ flags |= IOVMF_DA_ANON;
could we use only one? both are mutual exclusive, what happen if flag
is
On Tue, Mar 8, 2011 at 1:06 PM, David Cohen daco...@gmail.com wrote:
On Tue, Mar 8, 2011 at 8:06 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Tue, Mar 8, 2011 at 6:46 AM, David Cohen daco...@gmail.com wrote:
From: Michael Jones michael.jo...@matrix-vision.de
commit
On Tue, Mar 8, 2011 at 9:53 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Tue, Mar 8, 2011 at 1:06 PM, David Cohen daco...@gmail.com wrote:
On Tue, Mar 8, 2011 at 8:06 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
On Tue, Mar 8, 2011 at 6:46 AM, David Cohen daco...@gmail.com
On Tue, Mar 8, 2011 at 10:04 PM, David Cohen daco...@gmail.com wrote:
*** BLURB HERE ***
Sorry for this garbage :/
Br,
David
David Cohen (2):
omap3: change ISP's IOMMU da_start address
omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag
Michael Jones (1):
omap: iovmm: disallow
IOVMM driver checks input 'da == 0' when mapping address to determine whether
user wants fixed 'da' or not. At the same time, it doesn't disallow address
0x0 to be used, what creates an ambiguous situation. This patch set moves
fixed 'da' check to the input flags.
It also fixes da_start value for
From: Michael Jones michael.jo...@matrix-vision.de
commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL
address if da_start==0, which would then not get unmapped. Disallow
this again if IOVMF_DA_ANON is set. And spell variable 'alignment'
correctly.
Signed-off-by: Michael
ISP doesn't consider 0x0 as a valid address, so it should explicitly
exclude first page from allowed 'da' range.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Currently IOVMM driver sets IOVMF_DA_FIXED/IOVMF_DA_ANON flags according
to input 'da' address when mapping memory:
da == 0: IOVMF_DA_ANON
da != 0: IOVMF_DA_FIXED
It prevents IOMMU to map first page with fixed 'da'. To avoid such
issue, IOVMM will not automatically set IOVMF_DA_FIXED. It should
Hi David,
On Monday 07 March 2011 22:35:31 David Cohen wrote:
On Mon, Mar 7, 2011 at 11:19 PM, Laurent Pinchart wrote:
On Monday 07 March 2011 20:41:21 David Cohen wrote:
On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando wrote:
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen wrote:
On
On Tue, Mar 8, 2011 at 2:15 PM, David Cohen daco...@gmail.com wrote:
From: Michael Jones michael.jo...@matrix-vision.de
commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL
address if da_start==0, which would then not get unmapped. Disallow
this again if IOVMF_DA_ANON is
On Tue, Mar 8, 2011 at 2:15 PM, David Cohen daco...@gmail.com wrote:
Currently IOVMM driver sets IOVMF_DA_FIXED/IOVMF_DA_ANON flags according
to input 'da' address when mapping memory:
da == 0: IOVMF_DA_ANON
da != 0: IOVMF_DA_FIXED
It prevents IOMMU to map first page with fixed 'da'. To
On Tue, Mar 8, 2011 at 10:31 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi David,
On Monday 07 March 2011 22:35:31 David Cohen wrote:
On Mon, Mar 7, 2011 at 11:19 PM, Laurent Pinchart wrote:
On Monday 07 March 2011 20:41:21 David Cohen wrote:
On Mon, Mar 7, 2011 at 9:25
Hi Sanjeev,
On Mon, 7 Mar 2011, Vishwanath Sripathy wrote:
As per OMAP3630 TRM Section 26.5, register CM_AUTOIDLE_PLL is supposed to
be restored by ROM code. The PM code should only store these registers
before entering off mode. So only thing that needs to be done in this
patch set is to
Hi Omar,
On 3/7/2011 8:01 PM, Ramirez Luna, Omar wrote:
Hi Benoit,
On Mon, Mar 7, 2011 at 6:55 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Omar,
I have some concern about the introduction of a hwmod that does not match
the actual HW capability. MMU does exist, but there is no SW control
Hi Andy,
Thanks for that really fast update. That looks pretty good at first
glance. I still have to review in details.
And we need to find some volunteers for OMAP1 2 testing.
Thanks,
Benoit
On 3/8/2011 12:07 PM, Andy Green wrote:
The following series removes cpu_...() usage completely
1 - 100 of 147 matches
Mail list logo
