On Wed, Mar 9, 2011 at 9:43 AM, 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
---
-Original Message-
From: ext Paul Walmsley [mailto:p...@pwsan.com]
Sent: 9. maaliskuuta 2011 1:11
To: Jokiniemi Kalle (Nokia-MS/Tampere)
Cc: Kevin Hilman; linux-omap@vger.kernel.org; t...@atomide.com; b-
cous...@ti.com; Koskinen Ilkka (Nokia-MS/Tampere); Charulatha
Varadarajan;
Hi,
Previous patch 2/3 was dropped in this new version. Patch 1 was updated
according to a comment it got.
---
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
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
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 Kalle,
On 3/9/2011 10:02 AM, kalle.jokini...@nokia.com wrote:
[mailto:p...@pwsan.com] Sent: 9. maaliskuuta 2011 1:11 To:
Jokiniemi Kalle (Nokia-MS/Tampere) Cc: Kevin Hilman;
linux-omap@vger.kernel.org; t...@atomide.com; b- cous...@ti.com;
Koskinen Ilkka (Nokia-MS/Tampere); Charulatha
Kevin,
On Wed, Mar 9, 2011 at 06:54, Varadarajan, Charulatha ch...@ti.com wrote:
On Tue, Mar 8, 2011 at 13:23, Kevin Hilman khil...@ti.com wrote:
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
Hi Paul,
On Wednesday 09 March 2011 09:20 AM, Paul Walmsley wrote:
Hi Rajendra,
A few questions...
On Fri, 4 Mar 2011, Rajendra Nayak wrote:
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is
-1- Force clkdm to SW_WKUP
-2- Configure desired module mode to
-Original Message-
From: ext Cousson, Benoit [mailto:b-cous...@ti.com]
In theory, you should not have to disable the interface clock at all.
Assuming that the smartidle is working properly, the iclk should be gated
during clock domain transition automagically.
The only thing that
-Original Message-
From: Jokiniemi Kalle (Nokia-MS/Tampere)
-Original Message-
From: ext Cousson, Benoit [mailto:b-cous...@ti.com]
In theory, you should not have to disable the interface clock at all.
Assuming that the smartidle is working properly, the iclk should be
Tony,
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Wednesday, March 09, 2011 1:19 PM
To: 'Tony Lindgren'
Cc: 'linux-omap@vger.kernel.org'; Benoit Cousson; Santosh Shilimkar;
'p...@pswan.com'; 'linux-arm-ker...@lists.infradead.org'
Subject: RE: [PATCH] omap2+: mux:
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.
The current design adheres to the DSS2 architecture.
It is split into the HDMI DSS driver and HDMI panel driver.
HDMI DSS driver (hdmi.c) is responsible for
1.OMAP
Adding HDMI type in dss_features , overlay and
the manager so that HDMI type of display will be recognized.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |1 +
drivers/video/omap2/dss/display.c |2 ++
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.c |5 +
drivers/video/omap2/dss/dss.h |6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 2be4d03..1d91b0a 100644
---
Adding changes to set gamma table bit for TV interface to make sure it is
disabled
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dispc.c | 10 ++
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git
The panel driver(hdmi_omap4_panel.c) in omap2/dss acts as a controller
to manage the enable and disable requests and synchronize audio and video.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Kconfig|8 +
drivers/video/omap2/dss/Makefile |1 +
Adding the hdmi interface driver(hdmi.c) to the dss driver.
It configures the audio and video portion of HDMI based on
functionality called by the panel driver.
Signed-off-by: Mythri P K mythr...@ti.com
Yong Zhi y-...@ti.com
---
drivers/video/omap2/dss/Kconfig |8 +
Adding board file structure for display which adds the display
structure with HDMI as the default driver when the display init
is called.
HDMI GPIO configurations are also done in this file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 75
Adding board file structure for display which adds the display
structure with HDMI as the default driver when the display init
is called.
HDMI GPIO configurations are also done in this file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 74
calling the platform registration of HDMI driver from core
during initialization.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/core.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c
Adding the hdmi interface driver header file (hdmi.h) to the dss driver.
Register and structure declaration done here.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.h | 415
1 files changed, 415 insertions(+), 0 deletions(-)
On Tue, 2011-03-08 at 21:02 +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
Hi Tony,
Here is the pull-request for OMAP3 and OMAP4 L3 error handling driver.
It's based on the latest omap-for-linus branch of yours.
The following changes since commit 0640b436e410290193f554dcfd777bcdeee59697:
Abhilash Vadakkepat Koyamangalath (1):
audio : AM3517 : Adding i2c info
On Wed, Mar 9, 2011 at 12:51 AM, Paul Walmsley p...@pwsan.com wrote:
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:
currently I am dependent on OMAP_DEVICE_PAD_WAKEUP flag.
I am not using
On Wed, Mar 9, 2011 at 7:32 AM, Paul Walmsley p...@pwsan.com wrote:
Hi Govindraj,
what also would be good to find out is why the UART is apparently sending
asynchronous wakeups even when the driver doesn't set
SCR_REG.RX_CTS_WU_EN. This seems contrary to the expectation that 34xx
TRM vZH
Hi Andy,
On 3/8/2011 12:09 PM, Andy Green wrote:
This adds the new functionality flags for omap i2c unit to all OMAP2
hwmod definitions
Cc: patc...@linaro.org
Cc: Ben Dooksben-li...@fluff.org
Reported-by: Peter Maydellpeter.mayd...@linaro.org
Signed-off-by: Andy Greenandy.gr...@linaro.org
On Wednesday 09 March 2011 12:51 PM, Valkeinen, Tomi wrote:
Hi,
In the future we will have more features using the DSI interrupts, like ULPS
handling, and making use-case specific hooks into the main IRQ handler would
become burdensome.
This patch set cleans up the DSI IRQ handling a bit by
Hi Tony,
On 3/9/2011 12:38 AM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110308 13:34]:
Hi Andy,
Thanks for that really fast update. That looks pretty good at first
glance. I still have to review in details.
Yes nice job!
And we need to find some volunteers for OMAP1 2
On 03/09/2011 01:49 PM, Somebody in the thread at some point said:
Hi -
I have one minor comment about the OMAP4 dev_attr position in the
structure. The point here is just to be aligned with the template
used by the generator.
Acked-by: Benoit Coussonb-cous...@ti.com
The generator is
-Original Message-
From: Jokiniemi Kalle (Nokia-MS/Tampere)
Sent: 9. maaliskuuta 2011 13:33
-Original Message-
From: Jokiniemi Kalle (Nokia-MS/Tampere)
-Original Message-
From: ext Cousson, Benoit [mailto:b-cous...@ti.com]
In theory, you should not have
On Wed, 2011-03-09 at 05:45 -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.
The current design adheres to the DSS2 architecture.
It is split into the HDMI DSS driver and HDMI panel
On Wed, 2011-03-09 at 05:45 -0600, K, Mythri P wrote:
The panel driver(hdmi_omap4_panel.c) in omap2/dss acts as a controller
to manage the enable and disable requests and synchronize audio and video.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Kconfig|
On Tue, Mar 8, 2011 at 4:39 PM, Andy Green a...@warmcat.com wrote:
+/* struct omap_i2c_bus_platform_data .flags meanings */
+
+#define OMAP_I2C_FLAG_NO_FIFO 1
Hi,
Minor comment, Can you use
BIT(0) for 1, BIT(1) for 2 ... BIT (8) for 0x100
+#define OMAP_I2C_FLAG_SIMPLE_CLOCK 2
+#define
On Wed, 2011-03-09 at 07:54 -0600, Taneja, Archit wrote:
On Wednesday 09 March 2011 12:51 PM, Valkeinen, Tomi wrote:
Hi,
In the future we will have more features using the DSI interrupts, like ULPS
handling, and making use-case specific hooks into the main IRQ handler would
become
On Wed, Mar 9, 2011 at 6:44 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj govindraj...@gmail.com writes:
Module level wakeup doesn't seem to work and only
way it seem to wakeup is through using resume_idle
from sram_idle.
Have you verified if the module wakeups themselves are not
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH v4 3/9] OMAP4 : DSS2 : HDMI: HDMI
On Wed, Mar 9, 2011 at 7:18 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj govindraj...@gmail.com writes:
[...]
This function should not be needed.
The timer should be replaced by the auto-suspend feature of runtime PM.
If I use autosuspend based on timer runtime framework
will disable
On 03/09/2011 02:31 PM, Somebody in the thread at some point said:
Hi -
Minor comment, Can you use
BIT(0) for 1, BIT(1) for 2 ... BIT (8) for 0x100
OK, I agree it will be nicer. Thanks for the comment.
I guess I can just change this and issue just this guy as try 3 rather
than sending the
On 3/9/2011 3:04 PM, Andy Green wrote:
On 03/09/2011 01:49 PM, Somebody in the thread at some point said:
Hi -
I have one minor comment about the OMAP4 dev_attr position in the
structure. The point here is just to be aligned with the template
used by the generator.
Acked-by: Benoit
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH v4 5/9] OMAP4 : DSS2 : HDMI: HDMI
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH v4 7/9] OMAP4 : DSS : HDMI: Call to
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH v4 4/9] OMAP4 : DSS2 : HDMI: HDMI
On 3/9/2011 4:18 PM, Andy Green wrote:
On 03/09/2011 02:31 PM, Somebody in the thread at some point said:
Hi -
Minor comment, Can you use
BIT(0) for 1, BIT(1) for 2 ... BIT (8) for 0x100
OK, I agree it will be nicer. Thanks for the comment.
I guess I can just change this and issue just
Rajendra Nayak rna...@ti.com writes:
In terms of triage, does this patch fix something that currently doesn't
work (meaning that we should try to merge it for 2.6.39)? Or can we plan
to merge this during the 2.6.40 time frame? It would be ideal, of course,
if we could wait until 2.6.40,
Here is the first version of the proposal to export SoC related information to
user-space through sysFS interface.
This serie is to continue what has been discussed on the socinfo thread
created by Eduardo Valentin:
https://lkml.org/lkml/2010/5/11/364
The first patch introduces the common
Common base to export System-on-Chip related informations through sysfs.
Creation of a soc directory under /sys/devices/system/.
Creation of a common mach_name entry to export machine name.
Creation of platform-defined SoC information entries.
Signed-off-by: Maxime COQUELIN
ST-Ericsson's U8500 implementation.
Register sysfs SoC interface, and export SoC ID, process and silicon revision
number.
Signed-off-by: Maxime COQUELIN maxime.coquelin-no...@stericsson.com
---
arch/arm/mach-ux500/id.c | 96 ++
1 files changed, 96
On Tue, 2011-03-08 at 15:02 -0800, Tony Lindgren wrote:
* Michael Büsch m...@bu3sch.de [110303 06:16]:
On Thu, 2011-03-03 at 11:42 +0200, Felipe Balbi wrote:
On Wed, Mar 02, 2011 at 05:11:58PM +0100, Michael Buesch wrote:
@@ -175,9 +124,9 @@ static int retu_wdt_release(struct inode
The static tahvo_usb_device is uninitialized, but used
in the otg interrupt handler. This results in a NULL pointer
dereference on interrupt.
Fix this by storing a struct tahvo_usb pointer instead of
a platform device.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
The global tahvo_usb_device
The struct tahvo_usb must be free'd on remove.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: linux-2.6.38-rc7/drivers/cbus/tahvo-usb.c
===
--- linux-2.6.38-rc7.orig/drivers/cbus/tahvo-usb.c 2011-03-09
usb_l4_ick is used by the USB. Request and enable it.
Without this, all register accesses just return garbage
due to the device not being clocked.
This also cleans up the error path of the probe function
while we're at it.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index:
The omap_otg platform device has to be registered in order
to get USB working on the n810.
I currently do this by calling the USB-FS init, which in turn
registers the omap_otg platform device.
The omap_usb_config structure values were copied from n770 code, so
I have no idea whether this is
* Cousson, Benoit b-cous...@ti.com [110309 06:00]:
Hi Tony,
On 3/9/2011 12:38 AM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110308 13:34]:
Hi Andy,
Thanks for that really fast update. That looks pretty good at first
glance. I still have to review in details.
Yes nice
* Steve Sakoman st...@sakoman.com [110308 16:13]:
Tony: I have a couple more patches queued up to add gpio-led and
gpio-keys support to Overo. I've been holding off submitting because
I haven't been quite sure what branch to base them on to minimize
merge conflicts. For the moment they are
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating a unified API which calls omap_device_set_dev_constraint
for all classes of constraints (devices wake-up latency, devices
throughput...).
The implementation of the constraints framework is at the omap_device
level: management
Hi,
This patch is sent as en early review request, the testing is still on-going.
I will post the updated series (with a new revision number) as soon as possible.
I have some inlined comments, questions and concerns about it.
Can you please check?
On Wed, Mar 9, 2011 at 8:19 PM, Jean Pihet
* sricharan r.sricha...@ti.com [110308 23:43]:
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
Overo COMs and expansion boards have three LEDS and 2 push button switches
connected to GPIO pins. This patch series adds support for utilizing
them with gpio-keys and gpio-leds.
Steve Sakoman (2):
OMAP: Add gpio-leds support for Overo
OMAP: Add gpio-keys support for Overo
This patch adds support for the standard LEDs on the Overo COM and expansion
boards
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/mach-omap2/board-overo.c | 51 +
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git
This patch adds support for the standard push buttons available on
Overo expansion boards.
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/mach-omap2/board-overo.c | 42 +
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git
On Wed, Mar 9, 2011 at 11:18 AM, Tony Lindgren t...@atomide.com wrote:
* Steve Sakoman st...@sakoman.com [110308 16:13]:
Tony: I have a couple more patches queued up to add gpio-led and
gpio-keys support to Overo. I've been holding off submitting because
I haven't been quite sure what branch
* Tarun Kanti DebBarma tarun.ka...@ti.com [110308 15:41]:
Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver. It also provides
provision to access
(cc'ing Tero also)
Hi Rajendra
On Wed, 9 Mar 2011, Rajendra Nayak wrote:
On Wednesday 09 March 2011 09:20 AM, Paul Walmsley wrote:
On Fri, 4 Mar 2011, Rajendra Nayak wrote:
PRCM waking up the module's clockdomains when in hardware-supervised
and INACTIVE, atleast does not seem to be true
* Tarun Kanti DebBarma tarun.ka...@ti.com [110308 15:41]:
switch-over to platform device driver through following changes:
(a) initiate dmtimer early initialization from omap2_gp_timer_init()
in timer-gp.c. This is equivalent of timer_init()-timer-init().
(b) modify plat-omap/dmtimer routines
Govindraj govindraj...@gmail.com writes:
[...]
So here's an experiment to try with autosuspend. I suspect this will
work, just hack it up to prove the concept. If it works, we can make
something more generic. Here are a few alternatives to try. I may
experiment with some of them
saw...@ti.com writes:
From: Anand S Sawant saw...@ti.com
omap_sr_probe() creates the smartreflex debug directory and its
underlying nvalue debug directory. These directories are removed in
omap_sr_remove().
Basic smartreflex functionality tested on OMAP3630 Zoom3 OMAP4430 SDP
Jean Pihet jean.pi...@newoldbits.com writes:
The patch adds the new power management trace points for
the OMAP architecture.
The trace points are for:
- default idle handler. Since the cpuidle framework is
instrumented in the generic way there is no need to
add trace points in the OMAP
This patch adds support for the standard LEDs on the Overo COM and expansion
boards
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/mach-omap2/board-overo.c | 53 +
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git
Overo COMs and expansion boards have three LEDS and 2 push button switches
connected to GPIO pins. This patch series adds support for utilizing
them with gpio-keys and gpio-leds.
Changes from version 1: Guard gpio_leds assignment with CONFIG_LEDS_GPIO check
Steve Sakoman (2):
OMAP: Add
This patch adds support for the standard push buttons available on
Overo expansion boards.
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/mach-omap2/board-overo.c | 42 +
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git
On Thu, 3 Mar 2011, Jean Pihet wrote:
The patch adds the new power management trace points for
the OMAP architecture.
The trace points are for:
- default idle handler. Since the cpuidle framework is
instrumented in the generic way there is no need to
add trace points in the OMAP
Some boards can't tolerate IP blocks being reset when they are initialized.
Michael Büsch cites a case with the Nokia N810:
http://www.spinics.net/lists/linux-omap/msg47277.html
To allow such boards to continue working normally, allow board file
maintainers to mark IP blocks to prevent them
Greetings Michael,
On Mon, 28 Feb 2011, Michael Buesch wrote:
The n810 LCD does not work on the 2.6.38(-rc6) kernel
due to changes in the OMAP GPIO-hwmod code.
The hwmod code performs a soft-reset on the GPIO
module. The first GPIO module carries the MIPID
nreset line, which is toggled
From: Rajendra Nayak rna...@ti.com
Some issues seen (which cause lockups in suspend) with GPT1
after the MPU-L4_WKUP static dependency was cleared can be
Worked-around for now by forcing GPT1 in software
controlled idle.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoît Cousson
Commit d34427267186827dfd62bd8cf726601fffb22534 (OMAP3: PM: Adding
smartreflex hwmod data) added data that claims that the L4 CORE has
two slave interfaces that originate from the SmartReflex modules,
omap3_l4_core__sr1 and omap3_l4_core__sr2. But as those two data
structure records show, it's
Hi,
I just queued a patch to fix the SmartReflex problem. It's the part that
fixes the incorrect data:
http://marc.info/?l=linux-omapm=129972435510631w=2
Benoît, if you are happy with it, care to send an Acked-by:? Also, I
guess we should revisit the other part of your patch at some
Hello Jean
Thanks for working on this stuff. Some comments based on a quick look...
On Wed, 9 Mar 2011, Jean Pihet wrote:
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating a unified API which calls omap_device_set_dev_constraint
for all classes of constraints (devices
$subject - OMAP3: pm? this is mfd twl-core rt?
On Wed, Mar 2, 2011 at 19:00, Lesly A M lesl...@ti.com wrote:
Added api to get the TWL5030 Si version from the IDCODE register.
Does this work for 4030 and TPS variants as well? since this is
twl-core - how about the impact to 6030?
It is used
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, March 10, 2011 2:02 AM
To: Sricharan R
Cc: linux-omap@vger.kernel.org; Benoit Cousson; Santosh Shilimkar;
p...@pswan.com; linux-arm-ker...@lists.infradead.org
Subject: [PATCH] omap2+: mux: Add macro for
Update MPU, IVA and CORE voltage Rail values obtained from
OMAP4430 Data Manual Operating Condition Addendum_v0.4.
Tested on OMAP4430 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
V3:
Update CORE Voltages as well
in sync with V0.4 of OMAP4 Data Manual.
V2:
Fixed Comments from
Hi Sanjeev,
On Wed, Mar 9, 2011 at 9:26 PM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org;
Hi Sanjeev,
On Wed, Mar 9, 2011 at 9:20 PM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org;
Hi Sanjeev,
On Wed, Mar 9, 2011 at 9:24 PM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org;
Hi Tomi,
On Wed, Mar 9, 2011 at 7:53 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2011-03-09 at 05:45 -0600, K, Mythri P wrote:
The panel driver(hdmi_omap4_panel.c) in omap2/dss acts as a controller
to manage the enable and disable requests and synchronize audio and video.
On Wed, 2011-03-09 at 18:18 -0700, Paul Walmsley wrote:
Perhaps this patch will do:
http://marc.info/?l=linux-omapm=129971920806386w=2
Afterwards, it should be possible to look up the GPIO1 hwmod in
mach-omap2/board-n8x0.c after the call to
omap2_init_common_infrastructure(), and
OMAP4 has two different Devices IVA and DSP. DSP is bound
with MPU for DVFS and IVA has its own well defined OPPs.
This Patch adds IVA init to 'omap2_init_processor_devices'
and make sure that API 'omap2_set_init_voltage' is called
for apt dev pointer.
It fixes Error logs:
On ARMv7 dsb, dmb instructions are supported and can be used directly
instead of their cp15 equivalnet. Also remove the opcodes for smc
and use the available instruction directly in OMAP3 low power asm code
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
When L1 cache is suppose to be lost, it needs to be cleaned before
entrering to the low power mode.
While at this, also fix few comments and remove un-necessary
clean_l2 lable.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
On the newer ARM processors like CortexA8, CortexA9, the caches can be
speculatively loaded while they are getting flushed.
Clear the SCTLR C bit to prevent further data cache allocation as
part of cache clean routine
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman
Add necessary barriers after enabling MMU. Also use the sane way to
load pc and jump to it instead of executing ldma first up.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/sleep34xx.S |5 +
1 files changed, 5
The current code saves few un-necessary registers which are read-only or
write-only, unused CP15 registers.
Remove them and keep only necessary CP15 registers part of
low power context save/restore.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
On Wed, 2011-03-09 at 23:27 -0600, K, Mythri P wrote:
Hi Tomi,
yes This is based off your tree.
Thanks and regards,
Mythri.
It looks like there were some whitespace issues. I don't know what
caused them...
Also, please don't top-post on public mailing lists.
Tomi
On Wed, Mar 9, 2011
On Wed, 2011-03-09 at 05:45 -0600, K, Mythri P wrote:
The panel driver(hdmi_omap4_panel.c) in omap2/dss acts as a controller
to manage the enable and disable requests and synchronize audio and video.
Signed-off-by: Mythri P K mythr...@ti.com
snip
+static int hdmi_panel_probe(struct
On Wed, 2011-03-09 at 23:22 -0600, K, Mythri P wrote:
Hi Sanjeev,
On Wed, Mar 9, 2011 at 9:20 PM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday,
94 matches
Mail list logo
