On Fri, 2010-05-07 at 11:58 +0200, Nikula Jani.1 (EXT-Nixu/Helsinki)
wrote:
> Hi -
>
> These patches fix the broken DSS omap_dss_probe() fail path, reported by Kevin
> Hilman [1].
Thanks, looks good. Applied to my DSS tree.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe lin
Op 10 mei 2010, om 08:48 heeft Senthilvadivu Guruswamy het volgende geschreven:
> Exclude VRFB from OMAP4 onwards and include only for
> OMAP2 and OMAP3 builds. In OMAP4 VRFB HW IP is replaced
> with a new HW IP "TILER"
>
> --- a/drivers/video/omap2/Kconfig
> +++ b/drivers/video/omap2/Kconfig
>
On Thu, 2010-05-06 at 17:44 +0200, ext Tony Lindgren wrote:
> * Tomi Valkeinen [100506 00:38]:
> > On Wed, 2010-05-05 at 23:09 +0200, ext Tony Lindgren wrote:
> > > * Koen Kooi [100505 13:16]:
> > > > Tony,
> > > >
> > > > Any chance of https://patchwork.kernel.org/patch/94049/ going in as
> >
Building a multi-omap kernel is not impacted as long as the display is not
choosen in the build. Usually display is chosen from the board file.
> -Original Message-
> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
> Sent: Monday, May 10, 2010 1:10 PM
> To: Guruswamy, Senthilvadivu
Op 10 mei 2010, om 10:01 heeft Guruswamy, Senthilvadivu het volgende geschreven:
> Building a multi-omap kernel is not impacted as long as the display is not
> choosen in the build. Usually display is chosen from the board file.
So you are saying it *IS* broken when wanting vrfb on omap3 and t
Tiler support is not yet in OMAP builds. So multi-omap build will NOT break,
but would exclude VRFB feature in the build.
> -Original Message-
> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
> Sent: Monday, May 10, 2010 1:33 PM
> To: Guruswamy, Senthilvadivu
> Cc: linux-omap@vger.k
From: Roger Quadros
Adds basic support for LCD Panel on Nokia N900
v4:
Don't fail compile if CONFIG_FB_* is not defined
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13 +++
arch/arm/mach-omap2/board-rx
There are some places to scan iotlb entries. This iteration macro
could make these code a bit simpler with proceeding iotlb entries
transparently.
Signed-off-by: Hiroshi DOYU
Tested-by: Hari Kanigeri
---
arch/arm/plat-omap/iommu.c | 58 +++
1 files chan
From: Kanigeri, Hari
Added the missing TLB valid entry setting for cam register
Signed-off-by: Hari Kanigeri
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/iommu2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap
This CONFIG_OMAP_IOMMU_DEBUG option cannot be selected because it's
not visible on menu. Make this option selectable.
Signed-off-by: Hiroshi DOYU
Cc: Laurent Pinchart
---
arch/arm/plat-omap/Kconfig |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-om
From: Kanigeri, Hari
This patch adds TLB preservation support to IOMMU module
Signed-off-by: Hari Kanigeri
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/iommu2.c |4 ++-
arch/arm/plat-omap/iommu.c | 43 +
2 files changed, 29 insertions(+),
This rejects unaligned device virtual address('da') and physical
address('pa') and informs error to caller when a page table entry is
set. Otherwise, a wrong address can be used by IO device.
Signed-off-by: Hiroshi DOYU
Cc: Hari Kanigeri
---
arch/arm/plat-omap/iommu.c | 18 ++
Inserting a gap page between IOVMAs could detect an override on other
IOVMA with iommu fault. This was originally suggested by Sakari Ailus
and based on the work and comment by David Cohen.
Signed-off-by: Hiroshi DOYU
Cc: David Cohen
Cc: Sakari Ailus
---
arch/arm/plat-omap/iovmm.c |6 +++--
From: Ohad Ben-Cohen
use multiple MODULE_AUTHOR lines for multiple authors
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/mailbox.c |3 ++-
arch/arm/plat-omap/mailbox.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/
Searching avaialable spaces should be stopped as soon as it turns out
that there's no possibility with the rest of it.
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/iovmm.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/pla
From: Ohad Ben-Cohen
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/mailbox.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 5140efc..7c60550 100644
--- a/arch
From: Ohad Ben-Cohen
rwlocks are slower and have potential starvation issues
therefore spinlocks are generally preferred.
see also: http://lwn.net/Articles/364583/
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Kanigeri Hari
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/mailbox.c | 30
From: Ohad Ben-Cohen
The underlying buffering implementation of mailbox
is converted from block API to kfifo due to the simplicity
and speed of kfifo.
The default size of the kfifo buffer is set to 256 bytes.
This value is configurable at compile time (via
CONFIG_OMAP_MBOX_KFIFO_SIZE), and can b
From: Kanigeri, Hari
This patch includes changes to omap3-iommu.c file to make it generic
for all OMAPs. Renamed omap3-iommu.c to omap-iommu.c
[Hiroshi DOYU: Remove unnecessary "iommy-y" in Makefile]
Signed-off-by: Hari Kanigeri
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/Makefile
From: Kanigeri, Hari
This patch provides the iommu support for OMAP4 co-processors.
Signed-off-by: Hari Kanigeri
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/omap-iommu.c | 59 +--
arch/arm/plat-omap/include/plat/omap44xx.h |3 +
2 files changed,
Dear Guennadi
> > Why is this "select" needed here ?
> > Do you want "force select MIPI DSI" on AP4 ?
>
> Not on all AP4 systems, only on ap4evb board, because I thought, that's
> the display, that it is using.
sorry, it mean AP4EVB board
> > I asked because AP4 board can select other type LC
On 5/7/2010 10:33 PM, Tony Lindgren wrote:
* Benoit Cousson [100507 09:03]:
From: Rajendra Nayak
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/omap_device.c | 12
2 files change
The errata 1.153 workaround is busy waiting on XUDF bit in interrupt
context, which may lead to kernel hangs. The problem can be reproduced
by running the bus with wrong (too high) speed.
Signed-off-by: Alexander Shishkin
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 9 in
On Mon, May 10, 2010 at 12:16 PM, Hiroshi DOYU wrote:
> From: Kanigeri, Hari
>
> This patch includes changes to omap3-iommu.c file to make it generic
> for all OMAPs. Renamed omap3-iommu.c to omap-iommu.c
>
> [Hiroshi DOYU: Remove unnecessary "iommy-y" in Makefile]
>
> Signed-off-by: Hari Kaniger
On Mon, May 10, 2010 at 12:16 PM, Hiroshi DOYU wrote:
> From: Ohad Ben-Cohen
>
> rwlocks are slower and have potential starvation issues
> therefore spinlocks are generally preferred.
>
> see also: http://lwn.net/Articles/364583/
>
> Signed-off-by: Ohad Ben-Cohen
> Signed-off-by: Kanigeri Hari
Hello,
So, back to this track.
On Wed, May 05, 2010 at 10:59:32AM +0200, Russell King wrote:
> On Wed, May 05, 2010 at 11:42:04AM +0300, Eduardo Valentin wrote:
> > I'm resending this series with minor change in the subject prefix of patch
> > 4/4.
> > Removed the PM: prefix. Everything else is
Hello all,
Here is the patch set to export OMAP id code, production id and die id.
The history of this change is as follows:
1. First attempt tried adding those data under sysfs node. Original patch by
Peter De Schrijver [1]. Then, it was suggested to move it to debugfs, which was
rejected as thi
From: Eduardo Valentin
Report OMAP name and rev under /proc/socinfo node.
Signed-off-by: Eduardo Valentin
---
arch/arm/Kconfig |1 +
arch/arm/mach-omap2/id.c | 48 -
2 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/arch/a
From: Eduardo Valentin
This patch exports the OMAP3 IDCODE and Production ID to userspace
via /proc/socinfo.
Die ID is also exported depending on what users pass as kernel
parameter. It is same protection mechanism made for x86 product
number. So, if user passes "omap3_die_id" parameter, it will
From: Eduardo Valentin
Report OMAP name and rev under /proc/socinfo node.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap1/id.c | 45 +++--
1 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-
From: Eduardo Valentin
This patch introduce the /proc/socinfo node. Its purpose is to
export System on Chip information and specific bits.
The way it is done is basically same structure which is used to build
/proc/cpuinfo. Thus, it relies on the existence of socinfo_op seq_operation
structure.
Hi Felipe,
From: ext Felipe Contreras
Subject: Re: [PATCH 1/4] omap: mailbox: convert rwlocks to spinlock
Date: Mon, 10 May 2010 12:12:52 +0200
> On Mon, May 10, 2010 at 12:16 PM, Hiroshi DOYU wrote:
>> From: Ohad Ben-Cohen
>>
>> rwlocks are slower and have potential starvation issues
>> there
On Mon, May 10, 2010 at 01:37:36PM +0300, Eduardo Valentin wrote:
> From: Eduardo Valentin
>
> Report OMAP name and rev under /proc/socinfo node.
I think this needs to be combined with the previous patch. The previous
patch enables the socinfo file, which means with patch 2 applied but not
patc
On Mon, May 10, 2010 at 01:09:32PM +0300, Felipe Contreras wrote:
> > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > index 4b9fc57..7d2cf0f 100644
> > --- a/arch/arm/mach-omap2/Makefile
> > +++ b/arch/arm/mach-omap2/Makefile
> > @@ -89,10 +89,7 @@ obj-$(CONFIG_OMAP3_EM
On Mon, May 10, 2010 at 01:37:34PM +0300, Eduardo Valentin wrote:
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +extern const struct seq_operations socinfo_op;
This doesn't look promising..
> +static int socinfo_open(struct inode *inode, struct file *file)
> +{
> + return s
On 05/10/2010 03:26 AM, Guruswamy, Senthilvadivu wrote:
Tiler support is not yet in OMAP builds. So multi-omap build will NOT break,
but would exclude VRFB feature in the build.
in which case, is'nt this patch redundant :) ?
joking apart, would'nt a set of function pointers be better - the
fu
Hi,
Hmm.. yes. in my first patch I had OMAP3 and 2
Should I send updated patch above that?
- Dmitry
On 05/05/10 21:38, ext Tony Lindgren wrote:
> * Herbert Xu [100502 20:07]:
>
>> On Wed, Apr 28, 2010 at 05:18:05PM +0300, Dmitry Kasatkin wrote:
>>
>>> Changes to v4:
>>> - concurrent re
Signed-off-by: Dmitry Kasatkin
---
arch/arm/mach-omap2/devices.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index beac46c..79dbf04 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/de
On Mon, May 10, 2010 at 12:52:00PM +0200, Russell King wrote:
> On Mon, May 10, 2010 at 01:37:36PM +0300, Eduardo Valentin wrote:
> > From: Eduardo Valentin
> >
> > Report OMAP name and rev under /proc/socinfo node.
>
> I think this needs to be combined with the previous patch. The previous
> p
On Mon, May 10, 2010 at 03:07:55PM +0300, Dmitry Kasatkin wrote:
> Signed-off-by: Dmitry Kasatkin
> ---
> arch/arm/mach-omap2/devices.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index beac46c..
Nishanth Menon wrote:
> On 05/09/2010 05:51 AM, Venkatraman S wrote:
>>
>> Nishanth Menon wrote:
>>>
>>> Chikkature Rajashekar, Madhusudhan had written, on 05/07/2010 11:59 AM,
>>> the
>>> following:
>
Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma
>
> descri
On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> On Mon, May 10, 2010 at 01:37:34PM +0300, Eduardo Valentin wrote:
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +extern const struct seq_operations socinfo_op;
>
> This doesn't look promising..
Righ
On Mon, May 10, 2010 at 03:35:14PM +0300, Eduardo Valentin wrote:
> On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> > On Mon, May 10, 2010 at 01:37:34PM +0300, Eduardo Valentin wrote:
> > > + */
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +ext
On 10/05/10 15:14, ext Herbert Xu wrote:
> On Mon, May 10, 2010 at 03:07:55PM +0300, Dmitry Kasatkin wrote:
>
>> Signed-off-by: Dmitry Kasatkin
>> ---
>> arch/arm/mach-omap2/devices.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/devic
On Mon, May 10, 2010 at 02:39:02PM +0200, ext Paul Mundt wrote:
> On Mon, May 10, 2010 at 03:35:14PM +0300, Eduardo Valentin wrote:
> > On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> > > On Mon, May 10, 2010 at 01:37:34PM +0300, Eduardo Valentin wrote:
> > > > + */
> > > > +#incl
On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
You'll still need the show function, but all of the rest of this is just
duplicating what single_open() already does. If the socinfo string is
static you may also want to rework this a bit so you can just stash the
string in the proc
On Mon, May 10, 2010 at 02:54:40PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
> On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> >You'll still need the show function, but all of the rest of this is just
> >duplicating what single_open() already does. If the socinfo string is
> >
On 05/10/2010 07:31 AM, Venkatraman S wrote:
Nishanth Menon wrote:
Please see [1] for SOC specific feature handling. any reasons we can't
handle it by adding a new feature?
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/cpu.h#l4
On 05/10/2010 06:24 AM, Nishanth Menon wrote:
On 05/10/2010 03:26 AM, Guruswamy, Senthilvadivu wrote:
Tiler support is not yet in OMAP builds. So multi-omap build will NOT break,
but would exclude VRFB feature in the build.
in which case, is'nt this patch redundant :) ?
joking apart, would'nt
I've been running the TI DVSDK (3.01.00.03) which uses the
2.6.32-rc7 kernel. I now need to run a kernel which has
the RT patch supported (http://www.kernel.org/pub/linux/kernel/projects/rt/)
but it only has support for odd kernel versions (.31, .33, etc)
Is there a 2.6.33 vintage kernel with al
>From ff335087b5185828ec7d2d4b4a162e3bcf528792 Mon Sep 17 00:00:00 2001
From: Venkatraman S
Date: Mon, 10 May 2010 19:01:35 +0530
Subject: [PATCH] update omap3 features bitmap and API to generic names
OMAP3 features bitmap is used a method to check
for SoC specific features. This patch re
Hello again,
On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> On Mon, May 10, 2010 at 01:37:34PM +0300, Eduardo Valentin wrote:
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +extern const struct seq_operations socinfo_op;
>
> This doesn't look pro
On Mon, Apr 19, 2010 at 01:43:28PM +0200, ext Lesly A M wrote:
> This pacth will create the generic TRITON power scripts which can be used
> by different OMAP3 boards with the same power companion chip (TWL4030 series).
>
> Added the api(twl4030_get_scripts/twl4030_get_vc_timings) to update
> the
> -Original Message-
> From: Aaro Koskinen [mailto:aaro.koski...@nokia.com]
> Subject: Re: [PATCH]i2c-omap: pass scll, sclh through board file for Errata
> i585
>
> Hi,
>
> balaj...@ti.com wrote:
> > From: Balaji T K
> >
> > Errata ID: i535 - I2C1 to 3 SCL low period is shorter in FS mo
Tony Lindgren writes:
> * Varadarajan, Charulatha [100506 23:52]:
>> Tony/ Kevin,
>>
>> > -Original Message-
>> > From: Varadarajan, Charulatha
>> > Sent: Thursday, April 22, 2010 9:25 PM
>> > To: linux-omap@vger.kernel.org
>> > Cc: Nayak, Rajendra; p...@pwsan.com; t...@atomide.com;
>>
Has anyone had success with DSS2 on a 36xx platform using the current
l-o top of tree?
I've been working with a Beagle xM prototype and have applied the
"OMAP3630: DSS2: Updating MAX divider value" patch from Tomi's repo as
well as Koen's Beagle DSS2 support patch.
The image works as expected on
Hi Charu,
"Varadarajan, Charulatha" writes:
> While adapting some drivers to HWMOD way, I tried using pm_runtime
> APIs. My understanding is that instead of using clock FW APIs or
> omap_device APIs, we can make use of pm_runtime APIs.
>
> But, I observed that pm_runtime_enable() does not enable
Cliff Brake writes:
> On Sat, May 1, 2010 at 11:32 AM, Nishanth Menon
> wrote:
>> DISCLAIMER: I dont have a overo, so no idea if this would work.. but here
>> you go..
>>
>> Attached is a diff which probably will help you with the specific changes
>> needed for making pm boot on overo. hope it h
"Munegowda, Keshava" writes:
> From: Keshava Munegowda
>
> This patch removes the below warning
> arch/arm/mach-omap2/mux.c:52: warning: 'mux_phys' defined but not used
> The definition of variable mux_phys should be enclosed in the macro
> CONFIG_ARCH_OMAP3
>
> Signed-off-by: Keshava Munegow
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Steve Sakoman
> Sent: Monday, May 10, 2010 8:54 PM
> To: linux-omap@vger.kernel.org
> Subject: DSS2 on 36xx with 2.6.34-rc6
>
> Has anyone had success with DSS2 on a 36x
Ranjith Lohithakshan writes:
> OMAP3530 TRM section 7.4.4.4.2 requires OFFOUTENABLE to be set (active low)
> if wakeup capabilities are enabled on a pad. During OFF mode testing
> on OMAP3530 EVM, it was observed that the device was not residing in
> the OFF state. The device enters into the OFF
Ranjith Lohithakshan writes:
> This patch enables the wakeup capabilities of ads7846 touchscreen driver.
> ads7846 driver can now wakeup the system from suspend on OMAP3430 EVM
> and SDP boards.
>
> The earlier approach of enabling wakeup on the touchscreen GPIO pin during
> board level mux init
* Jason [100505 19:09]:
>
> A question about board version. Is it good to do a hardware check to find
> out hardware version?
> Like function static void __init omap3_evm_get_revision(void) in
> board-omap3evm.c
Sure, that's the best option.
Some boards are also using the system_rev, which con
On Mon, May 10, 2010 at 9:24 AM, Hiremath, Vaibhav wrote:
>> The image works as expected on a 35xx based Beagle, but when run on
>> the Beagle xM results in a "HDMI: Out of Range" error from my monitor.
>> Sadly the monitor won't give me the erroneous timing parameters.
>>
> [Hiremath, Vaibhav]
Ranjith Lohithakshan writes:
> CONFIG_ARCH_OMAP34XX is not defined any more. Replace it with
> CONFIG_ARCH_OMAP3.
>
> Signed-off-by: Ranjith Lohithakshan
> ---
>
> This patch is generated against pm branch.
Thanks, will add to PM-related GPIO patches submitted for 2.6.35.
Kevin
--
To unsubscr
* Dmitry Kasatkin [100510 05:45]:
>
> On 10/05/10 15:14, ext Herbert Xu wrote:
> > On Mon, May 10, 2010 at 03:07:55PM +0300, Dmitry Kasatkin wrote:
> >
> >> Signed-off-by: Dmitry Kasatkin
> >> ---
> >> arch/arm/mach-omap2/devices.c |4 ++--
> >> 1 files changed, 2 insertions(+), 2 deleti
* Nishanth Menon [100510 06:07]:
> On 05/10/2010 06:24 AM, Nishanth Menon wrote:
> >On 05/10/2010 03:26 AM, Guruswamy, Senthilvadivu wrote:
> >>Tiler support is not yet in OMAP builds. So multi-omap build will NOT
> >>break, but would exclude VRFB feature in the build.
> >in which case, is'nt thi
> -Original Message-
> From: Steve Sakoman [mailto:sako...@gmail.com]
> Sent: Monday, May 10, 2010 10:13 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: Re: DSS2 on 36xx with 2.6.34-rc6
>
> On Mon, May 10, 2010 at 9:24 AM, Hiremath, Vaibhav wrote:
>
> >> The image
On Mon, May 10, 2010 at 03:08:09PM +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
I'm not aware of the module parameter stuff.. but the leak might be other thing
than kstrdup?
yeah, I was following the code and the problem is how the kernel handles
charp module parameters
--
balbi
Defec
OMAP3 features bitmap is used a method to check
for SoC specific features. This patch renames the global variables
and the accessor functions to use a generic name from omap3_* to
omap_*
Signed-off-by: Venkatraman S
CC: Nishant Menon
CC: Tony Lindgren
CC: Madhusudhan Chikkature
---
*
* Tony Lindgren [100505 12:59]:
> * Russell King - ARM Linux [100505 12:41]:
> > On Wed, May 05, 2010 at 12:33:09PM -0700, Tony Lindgren wrote:
> > > The emac driver uses generic name for the module and phy
> > > clocks. Updated the omap3xxx_clks table to match the names
> > > used by the Davinci
* Stephen Rothwell [100506 22:05]:
> Hi Tomi,
>
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-rx51-peripherals.c between commit
> e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
> the tlv320aic3x codec driver") from the omap
Hi,
This series remove a couple of useless or non-functional registers
from the OMAP4430 ES1.0 defines.
It cleans as well the registers that didn't stick to the PRCM
naming convention and add a couple of new defines for offset.
Comments are welcome.
Regards,
Benoit
Benoit Cousson (3):
OMAP4
The MPU subsystem was named based on internal code name (CHIRON).
This patch will remove all the occurences of the chiron name
are replace it with PRCM_MPU in order to differentiate
the MPU local PRCM to the global one.
Remove PDA_ from PRCM_MPU registers names to stick to the global
PRM naming co
CM1, CM2, PRM, SCRM and MPU_PRCM are already defined in omap44xx.h
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/prcm-common.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/
The automatic HW restore from OFF mode is not functional at all in
OMAP4430 ES1.0.
Because of that, it will be extensively changed in the next Si revision,
and the compatibilty will not be maintained with ES1.0.
Remove the current XXX_RESTORE registers definition to avoid future
conflicts with the
From: Rajendra Nayak
The cm44xx.h files only had absolute register address
defines for all CM registers.
This patch adds additional register offset defines for all the
registers, so they can be used with apis like cm_read_mod_*
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
Cc: Pa
From: Rajendra Nayak
The prm44xx.h files only had absolute register address
defines for all PRM registers.
This patch adds additional register offset defines for all the
registers, so they can be used with apis like prm_read_mod_*
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
Cc:
* Kevin Hilman [100503 16:28]:
> From: Chunqiu Wang
>
> According to the GPIO 'Wakeup and Interrupt' section of the TRM[1],
> wake-up requests can only be generated on edge transitions.
>
> Also for OMAP3, only edge GPIOs may lose interrupts when PER enters
> RET/OFF state, this is addressed by
>From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
>
>On Sun, May 9, 2010 at 7:26 AM, Ramirez Luna, Omar wrote:
>> >From 451e9733672b7fd3879ec109f3c6b2ac55c21cf5 Mon Sep 17 00:00:00 2001
>>>From: Armando Uribe De Leon
>>>Date: Thu, 8 Apr 2010 17:14:38 -0500
>>>Subject: [PATCH 1/5] DSPBR
* Kevin Hilman [100510 08:09]:
> Tony Lindgren writes:
>
> > * Varadarajan, Charulatha [100506 23:52]:
> >> Tony/ Kevin,
> >>
> >> > -Original Message-
> >> > From: Varadarajan, Charulatha
> >> > Sent: Thursday, April 22, 2010 9:25 PM
> >> > To: linux-omap@vger.kernel.org
> >> > Cc: Na
* Tomi Valkeinen [100510 00:53]:
> On Thu, 2010-05-06 at 17:44 +0200, ext Tony Lindgren wrote:
> > * Tomi Valkeinen [100506 00:38]:
> > > On Wed, 2010-05-05 at 23:09 +0200, ext Tony Lindgren wrote:
> > > > * Koen Kooi [100505 13:16]:
> > > > > Tony,
> > > > >
> > > > > Any chance of https://pat
* Kevin Hilman [100510 09:07]:
> "Munegowda, Keshava" writes:
>
> > From: Keshava Munegowda
> >
> > This patch removes the below warning
> > arch/arm/mach-omap2/mux.c:52: warning: 'mux_phys' defined but not used
> > The definition of variable mux_phys should be enclosed in the macro
> > CONFI
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: i2c-omap-for-ben
Initial commit ID (Likely to change): 4c156dc0e7cc486feb106348fb7159d4be0c9889
PatchWorks
http://patchwork.kernel.org/patch/98127/
Git (Likely to change, and takes a while to get m
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: i2c-omap-for-ben
Initial commit ID (Likely to change): c62d437a11ff76be3ba3997a1ded33848ba41ece
PatchWorks
http://patchwork.kernel.org/patch/96816/
Git (Likely to change, and takes a while to get m
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: i2c-omap-for-ben
Initial commit ID (Likely to change): f95ba23e386509330595c45052ab4cef453ca262
PatchWorks
http://patchwork.kernel.org/patch/95686/
Git (Likely to change, and takes a while to get m
I think I've found a small problem in the board-omap3evm.c file under
arch/arm/mach-omap2 (support for the TI/Mistral OMAP35x EVM board).
What I noticed is that the declaration for the array gpio_leds is initialized
with one element (at line 380):
static struct gpio_led gpio_leds[] = {
On Mon, May 10, 2010 at 2:55 PM, Venkatraman S wrote:
> OMAP3 features bitmap is used a method to check
> for SoC specific features. This patch renames the global variables
> and the accessor functions to use a generic name from omap3_* to
> omap_*
>
> Signed-off-by: Venkatraman S
> CC: Ni
On Wed, May 05, 2010 at 08:45:53PM +0200, Sebastien Jan wrote:
> Low-level functions provide 16bits words read and write capability
> to ks8851 companion eeprom.
Please use the eeprom interface that was added already
> Signed-off-by: Sebastien Jan
> ---
> drivers/net/ks8851.c | 228
> +++
On Thu, May 06, 2010 at 12:20:12AM -0700, David Miller wrote:
> From: Sebastien Jan
> Date: Wed, 5 May 2010 20:45:53 +0200
>
> > Low-level functions provide 16bits words read and write capability
> > to ks8851 companion eeprom.
> >
> > Signed-off-by: Sebastien Jan
>
> Applied.
So I take it t
Enable network chip Micrel KS8851 for OMAP4430 SDP
- Based on mainline version 2.6.34 rc7
- Tested in OMAP4430 SDP
Throughput measurements using nuttcp application:
11.9375 MB / 10.06 sec =9.9519 Mbps 92 %TX 0 %RX 0 retrans 7.87 msRTT
--
All patches have been tagged as version 3
[PATCH
From: Syed Rafiuddin
Change dependency to ARCH_OMAP2PLUS to allow systems based on
omap24xx, omap34xx or omap44xx
Signed-off-by: Syed Rafiuddin
Signed-off-by: Abraham Arce
---
drivers/spi/Kconfig |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/Kconfig
Enable Micrel KS8851 SPI network chip for OMAP4430
Signed-off-by: Abraham Arce
---
arch/arm/mach-omap2/board-4430sdp.c | 81 +++
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430
Enable KS8851 SPI support +
Networking Support
- Packet Socket
- TCP/IP
Network Filesystems
- NFS Client
- Root Filesystem on NFS
Signed-off-by: Abraham Arce
---
arch/arm/configs/omap_4430sdp_defconfig | 57 +-
1 files changed, 55 insertions(+), 2 deleti
On Mon, May 10, 2010 at 05:22:48PM +0300, Eduardo Valentin wrote:
> On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> > You'll still need the show function, but all of the rest of this is just
> > duplicating what single_open() already does. If the socinfo string is
> > static you m
hi, Russell, Tony
Is this patch ignored by you? I do not see any ack for this patch.
Thanks
Janboe Ye
2009/12/3 Tero Kristo :
> From: Tero Kristo
>
> In some ARM architectures, like OMAP3, the VFP context can be lost during
> dynamic sleep cycle. For this purpose, there is now a function
> vfp
On Mon, May 10, 2010 at 03:55:49PM +0300, Eduardo Valentin wrote:
> On Mon, May 10, 2010 at 02:39:02PM +0200, ext Paul Mundt wrote:
> > Note that in the cpuinfo case there is often special handling for the
> > single (or boot CPU) case, such as printing out a descriptor for the
> > machine type and
> -Original Message-
> From: menon.nisha...@gmail.com
> [mailto:menon.nisha...@gmail.com] On Behalf Of Menon, Nishanth
> Sent: Tuesday, May 11, 2010 5:02 AM
> To: S, Venkatraman
> Cc: linux-omap@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; Tony Lindgren;
> Chikkature Rajashek
Hi Trilok,
Thanks for your comments...
[snip]
> > +
> > +/* Interrupt thread handler thread */
> > +
> > +static irqreturn_t omap_keypad_threaded(int irq, void *dev_id)
> > +{
>
> Why is iti threaded? I fo not see anything that will sleep.
It was implemented based on previous comments...
>
Sorry for the confusion in your name Dmitry...
Thanks for your comments...
[snip]
> > > +
> > > +/* Interrupt thread handler thread */
> > > +
> > > +static irqreturn_t omap_keypad_threaded(int irq, void *dev_id)
> > > +{
> >
> > Why is iti threaded? I fo not see anything that will sleep.
It w
1 - 100 of 108 matches
Mail list logo
