On Wed, Mar 9, 2011 at 9:43 AM, Sakari Ailus
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
>> ---
>> arch/arm/mach-omap2/omap-iommu.c | 2 +-
>> 1 files change
> -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
> Varadaraj
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
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 Jones
---
arch/arm/plat-omap/iov
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 no
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 Varada
Kevin,
On Wed, Mar 9, 2011 at 06:54, Varadarajan, Charulatha wrote:
> On Tue, Mar 8, 2011 at 13:23, Kevin Hilman wrote:
>>> On Tue, Mar 8, 2011 at 00:25, Kevin Hilman wrote:
"Varadarajan, Charulatha" writes:
[...]
>>> GPIO driver is modified to use dev_pm_ops instead of
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 thin
> -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 icl
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+
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 relat
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
---
arch/arm/plat-omap/include/plat/display.h |1 +
drivers/video/omap2/dss/display.c |2 ++
drivers/video/omap2/dss/dss_features.c|2 +-
Signed-off-by: Mythri P K
---
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
--- a/drivers/video/o
Adding changes to set gamma table bit for TV interface to make sure it is
disabled
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/dispc.c | 10 ++
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/d
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
---
drivers/video/omap2/dss/Kconfig|8 +
drivers/video/omap2/dss/Makefile |1 +
drivers/video/
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
Yong Zhi
---
drivers/video/omap2/dss/Kconfig |8 +
drivers/video/omap2/dss/Makefile
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
---
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
---
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
---
drivers/video/omap2/dss/core.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index c2
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
---
drivers/video/omap2/dss/hdmi.h | 415
1 files changed, 415 insertions(+), 0 deletions(-)
create mode 100
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 soc_bind_dai_
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 f
On Wed, Mar 9, 2011 at 12:51 AM, Paul Walmsley 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 OMAP_DEVICE
On Wed, Mar 9, 2011 at 7:32 AM, Paul Walmsley 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 section 1
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 Dooks
> Reported-by: Peter Maydell
> Signed-off-by: Andy Green
I have one minor comment about the OMAP4 dev_attr positi
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 imp
Hi Tony,
On 3/9/2011 12:38 AM, Tony Lindgren wrote:
* Cousson, Benoit [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 testing.
I gave i
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 Cousson
The generator is adding a (probably use
> -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, y
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 p
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
> ---
> drivers/video/omap2/dss/Kconfig|8 +
>
On Tue, Mar 8, 2011 at 4:39 PM, Andy Green 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 OMAP_I2C_FLAG_16B
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
> > be
On Wed, Mar 9, 2011 at 6:44 AM, Kevin Hilman wrote:
> Govindraj 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 working, or
> just that the wakeup
> -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: HD
On Wed, Mar 9, 2011 at 7:18 AM, Kevin Hilman wrote:
> Govindraj 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 clocks based on a
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
> -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: HD
> -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: Cal
> -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: HD
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 thi
Rajendra Nayak 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, given how
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 par
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
---
drivers/base
ST-Ericsson's U8500 implementation.
Register sysfs SoC interface, and export SoC ID, process and silicon revision
number.
Signed-off-by: Maxime COQUELIN
---
arch/arm/mach-ux500/id.c | 96 ++
1 files changed, 96 insertions(+), 0 deletions(-)
diff --g
On Tue, 2011-03-08 at 15:02 -0800, Tony Lindgren wrote:
> * Michael Büsch [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
---
The global tahvo_usb_device pointer should
The struct tahvo_usb must be free'd on remove.
Signed-off-by: Michael Buesch
---
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
18:51:46.240795227 +0100
+++
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
---
Index: linux-2.6.38-rc7/drivers/cbus/
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 corr
* Cousson, Benoit [110309 06:00]:
> Hi Tony,
>
> On 3/9/2011 12:38 AM, Tony Lindgren wrote:
> >* Cousson, Benoit [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!
> >
> >>A
* Steve Sakoman [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 based on Tomi
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 an
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 wrot
* sricharan [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 transitions.
Than
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
arch/arm/mach-oma
This patch adds support for the standard LEDs on the Overo COM and expansion
boards
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 51 +
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
This patch adds support for the standard push buttons available on
Overo expansion boards.
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 42 +
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ov
On Wed, Mar 9, 2011 at 11:18 AM, Tony Lindgren wrote:
> * Steve Sakoman [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 minim
* Sricharan R [110309 03:47]:
>
> Btw,I have fixed the comments on the below patches that
> I sent for configuring the serial pads.
>
> 4430sdp:
> http://marc.info/?l=linux-omap&m=129900334420003&w=2
>
> omap4panda:
> http://marc.info/?l=linux-omap&m=129900338520082&w=2
>
> 3430sdp:
> http://m
* Tarun Kanti DebBarma [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 timers during earl
(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
* Tarun Kanti DebBarma [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 to use new re
Govindraj 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 tomorrow as well, bu
saw...@ti.com writes:
> From: Anand S Sawant
>
> 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
>
> Signed-off-by:
Jean Pihet 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 specific cpuidle h
This patch adds support for the standard LEDs on the Overo COM and expansion
boards
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 53 +
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
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 gpio-le
This patch adds support for the standard push buttons available on
Overo expansion boards.
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 42 +
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ov
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 tog
From: Rajendra Nayak
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
Signed-off-by: Benoît Cousson
Signed-off-by: Paul Walm
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-omap&m=129972435510631&w=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 p
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 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 for enabling t
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 macr
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
---
V3:
Update CORE Voltages as well
in sync with V0.4 of OMAP4 Data Manual.
V2:
Fixed Comments from Nishanth Menon.
a
Hi Sanjeev,
On Wed, Mar 9, 2011 at 9:26 PM, Premi, Sanjeev 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; Valkeinen,
Hi Sanjeev,
On Wed, Mar 9, 2011 at 9:20 PM, Premi, Sanjeev 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; Valkeinen,
Hi Sanjeev,
On Wed, Mar 9, 2011 at 9:24 PM, Premi, Sanjeev 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; Valkeinen,
Hi Tomi,
On Wed, Mar 9, 2011 at 7:53 PM, Tomi Valkeinen 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.
>>
>> Signed-off-by: Mythr
Hi Tomi,
yes This is based off your tree.
Thanks and regards,
Mythri.
On Wed, Mar 9, 2011 at 7:45 PM, Tomi Valkeinen wrote:
> 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
>>
On Wed, 2011-03-09 at 18:18 -0700, Paul Walmsley wrote:
> Perhaps this patch will do:
>
>http://marc.info/?l=linux-omap&m=129971920806386&w=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()
Hi Sanjeev,
On Wed, Mar 9, 2011 at 8:19 PM, Premi, Sanjeev 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; Valkeinen,
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:
omap2_set_init_
The series does below fixes to the omap3 low power code.
1. Use supported ARMv7 instructions instead of the legacy ones
2. Fix the MMU on sequence
3. Fix the cache flush scenario when only L1 lost.
4. Remove all un-necessary context save registers
5. Disable
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
Cc: Kevin Hilman
---
arch/arm/mach-omap2/sleep34xx.S |
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
Cc: Kevin Hilman
---
arch/arm/mach-omap2/sleep34xx.S | 15 +++
1 files
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
Cc: Kevin Hilman
---
arch/arm/mach-omap2/sl
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
Cc: Kevin Hilman
---
arch/arm/mach-omap2/sleep34xx.S |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/
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
Cc: Kevin Hilman
---
arch/arm/mach-omap2/sleep34xx.S | 156 ++
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
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
> +static int hdmi_panel_probe(struct omap_dss_device *dssde
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 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,
98 matches
Mail list logo
