On Fri, Feb 4, 2011 at 9:00 PM, Igor Grinberg wrote:
>
>
> On 02/04/11 17:11, Poddar, Sourav wrote:
>
>> On Fri, Feb 4, 2011 at 8:17 PM, Igor Grinberg
>> wrote:
>>>
>>> On 02/04/11 16:16, G, Manjunath Kondaiah wrote:
>>>
On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
> On
On Thu, Feb 03, 2011 at 05:15:39PM -0800, Tony Lindgren wrote:
> * Tony Lindgren [110118 12:36]:
> > * Russell King - ARM Linux [110118 10:32]:
> > > A warning for OMAP.
> > >
> > > Your use of the __virt_to_phys() in assembly code for the debug stuff
> > > will break with this patch... please e
Vasiliy Kulikov writes:
> Don't allow everybody to change voltage settings.
>
> Signed-off-by: Vasiliy Kulikov
> ---
> Cannot compile the driver, so it is not tested at all.
Acked-by: Kevin Hilman
> arch/arm/mach-omap2/smartreflex.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deleti
Vasiliy Kulikov writes:
> Don't allow all users to change timer settings.
>
> Signed-off-by: Vasiliy Kulikov
> ---
> Cannot compile the driver, so it is not tested at all.
Acked-by: Kevin Hilman
> arch/arm/mach-omap2/pm-debug.c |8
> 1 files changed, 4 insertions(+), 4 deletio
"Govindraj.R" writes:
> Changes invloves:
>
> 1) Addition of hwmod data for omap2/3/4.
> 2) McSPI driver hwmod adaptation with cleanup of base address
>macros and using omap-device API's.
> 3) Runtime Conversion of McSPI driver.
>
> Changes from v5:
> ---
> Rebase
"Cousson, Benoit" writes:
> On 2/4/2011 8:45 PM, Hilman, Kevin wrote:
>> Kishon Vijay Abraham I writes:
>>
>>> Adds a structure member 'name' to 'omap_hwmod_addr_space' structure.
>>> The drivers can use platform_get_resource_byname() to get resource of
>>> type 'IORESOURCE_MEM' by name so that
Kishon Vijay Abraham I writes:
> Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs.
>
> Created on top of linux OMAP master (linux-omap-2.6 :master)
> Did digital loopback testing on OMAP4430, OMAP3430 and OMAP2430 SDP boards.
> Verified that this patch series does not bre
On Fri, 4 Feb 2011, Tony Lindgren wrote:
> * Nicolas Pitre [110204 12:14]:
> >
> > Just create a get_config_ptr macro or similar and the trickery will be
> > nicely encapsulated. You'd have:
> >
> > .macro get_config_ptr ptr, tmp
> > b 9002f
> > .align
> > 9001: .long
* Nicolas Pitre [110204 12:14]:
>
> Just create a get_config_ptr macro or similar and the trickery will be
> nicely encapsulated. You'd have:
>
> .macro get_config_ptr ptr, tmp
> b 9002f
> .align
> 9001: .long .
> .long uart_param_storage
> 9002: adr \ptr,
On 2/4/2011 8:45 PM, Hilman, Kevin wrote:
Kishon Vijay Abraham I writes:
Adds a structure member 'name' to 'omap_hwmod_addr_space' structure.
The drivers can use platform_get_resource_byname() to get resource of
type 'IORESOURCE_MEM' by name so that it need not rely on the order to get
the pro
On Fri, 4 Feb 2011, Tony Lindgren wrote:
> * Nicolas Pitre [110203 19:32]:
> > On Thu, 3 Feb 2011, Tony Lindgren wrote:
> >
> > > This way we can have the debug-macro.S be common for omap1 and omap2+
> > > and get sensible error messages booting the wrong zImage with
> > > CONFIG_AUTO_ZRELADDR s
* Vasiliy Kulikov [110204 04:22]:
> Don't allow everybody to change voltage settings.
>
> Signed-off-by: Vasiliy Kulikov
> ---
> Cannot compile the driver, so it is not tested at all.
And this one.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a
* Vasiliy Kulikov [110204 04:21]:
> Don't allow all users to change timer settings.
>
> Signed-off-by: Vasiliy Kulikov
> ---
> Cannot compile the driver, so it is not tested at all.
Taking this one too.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body
* Vasiliy Kulikov [110204 04:21]:
> Do not create mux debugfs files as world-writable.
>
> Signed-off-by: Vasiliy Kulikov
> ---
> Cannot compile the driver, so it is not tested at all.
Thanks, will queue this as a fix for the -rc cycle.
Tony
> arch/arm/mach-omap2/mux.c |2 +-
> 1 files
* Felipe Balbi [110204 04:42]:
> Hi Tony,
>
> I saw a few patches floating around regarding world writeable sysfs
> files and decided to grep around arch/arm/*omap* to try and see if we
> were safe. Turns out anyone can change MUX entries via the debugfs
> interface:
>
> static void __init omap_
Kishon Vijay Abraham I writes:
> Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs.
>
> Created on top of linux OMAP master (linux-omap-2.6 :master)
> Did digital loopback testing on OMAP4430, OMAP3430 and OMAP2430 SDP boards.
> Verified that this patch series does not bre
Kishon Vijay Abraham I writes:
> Adds a structure member 'name' to 'omap_hwmod_addr_space' structure.
> The drivers can use platform_get_resource_byname() to get resource of
> type 'IORESOURCE_MEM' by name so that it need not rely on the order to get
> the proper resource.
>
> Signed-off-by: Kish
* Russell King - ARM Linux [110204 09:14]:
>
> The other point to make is that for every machine in OMAP1, the
> serial port is located at 0xffXX virtual, 0xfeXX physical.
> For OMAP2, that's 0xfaXX virtual and 0x48XX physical.
>
> So it's pointless storing both the virtual and ph
Jeff Graham wrote:
>
> Hello,
>
> I have an Overo Fire board (OMAP 3530) and also a Mistral DM3730 EVM
> board.
>
> I would like to try some of the newer kernels on each, and maybe some
> patches mentioned in this list. I could be a tester for these once I
> figure out how to update bootloaders and
On Thu, Feb 03, 2011 at 10:33:42PM -0500, Nicolas Pitre wrote:
> On Thu, 3 Feb 2011, Tony Lindgren wrote:
>
> > This way we can have the debug-macro.S be common for omap1 and omap2+
> > and get sensible error messages booting the wrong zImage with
> > CONFIG_AUTO_ZRELADDR selected. Note that this
* Nicolas Pitre [110203 19:32]:
> On Thu, 3 Feb 2011, Tony Lindgren wrote:
>
> > This way we can have the debug-macro.S be common for omap1 and omap2+
> > and get sensible error messages booting the wrong zImage with
> > CONFIG_AUTO_ZRELADDR selected. Note that this does not seem to work
> > with
* Grazvydas Ignotas [110204 04:03]:
> On Fri, Feb 4, 2011 at 3:27 AM, Tony Lindgren wrote:
> > Set the debug serial port based on machine ID. Note that most
> > of the patch is just trivial checking for the machine ID.
> >
..
> This looks a bit wasteful not only because of repeated CMPs, but al
* Russell King - ARM Linux [110204 04:31]:
> On Fri, Feb 04, 2011 at 08:39:34AM +, Russell King - ARM Linux wrote:
> > Can't we just hard-configure the virtual/physical address at build
> > time and be done with it?
> >
> > I've given up with the current state of affairs which tries to use th
Vishwanath BS writes:
> Currently voltage values on opp tables are hardcoded. As these voltage values
> are anyway defined in voltage.h as macros, opp table can reuse these values.
> This will avoid opp table and voltage layer having conflicting values.
ok
> Signed-off-by: Vishwanath BS
> This
On Fri, Feb 04, 2011 at 04:46:57PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Dave Martin [mailto:dave.mar...@linaro.org]
> > Sent: Friday, February 04, 2011 4:33 PM
> > To: Santosh Shilimkar
> > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; Jean Pihet-
> >
Hello,
I have an Overo Fire board (OMAP 3530) and also a Mistral DM3730 EVM
board.
I would like to try some of the newer kernels on each, and maybe some
patches mentioned in this list. I could be a tester for these once I
figure out how to update bootloaders and build and install kernels. Is
ther
Vishwanath BS writes:
> From: Thara Gopinath
>
> This patch adds voltage domain info in the relevant
> device hwmod structures so as to enable OMAP3 DVFS
> support.
Has there been work yet on the autogen scripts to auto-generate this for
OMAP4?
Kevin
> Signed-off-by: Thara Gopinath
> ---
>
Vishwanath BS writes:
> Changes in the omap cpufreq driver for DVFS support.
Missing descriptive changelog.
Should describe what, why, etc.
Kevin
> Signed-off-by: Vishwanath BS
> Cc: Santosh Shilimkar
> ---
> arch/arm/plat-omap/cpu-omap.c | 35 ---
> 1 fil
Hi,
On Fri, Feb 04, 2011 at 05:37:29PM +0200, Igor Grinberg wrote:
> Hi,
>
> On 02/04/11 17:15, G, Manjunath Kondaiah wrote:
>
> > On Fri, Feb 04, 2011 at 04:47:09PM +0200, Igor Grinberg wrote:
> >> On 02/04/11 16:16, G, Manjunath Kondaiah wrote:
> >>> On Fri, Feb 04, 2011 at 03:08:47PM +0100, W
Vishwanath BS writes:
> From: Thara Gopinath
>
> This patch also introduces omap3_mpu_set_rate, omap3_iva_set_rate,
> omap3_l3_set_rate, omap3_mpu_get_rate, omap3_iva_get_rate,
> omap3_l3_get_rate as device specific set rate and get rate
> APIs for OMAP3 mpu, iva and l3_main devices. This patch
Vishwanath BS writes:
> From: Thara Gopinath
>
> This patch disables smartreflex for a particular voltage
> domain when the the voltage domain and the devices belonging
> to it is being scaled and re-enables it back once the scaling
> is done.
Should also describe why.
> Signed-off-by: Thara G
Vishwanath BS writes:
> This patch adds omap_device_scale API which can be used to generic
> device rate scaling.
I would've expected a new omap_device_* API to be part of the
omap_device layer, not added here.
> Based on original patch from Thara.
>
> Signed-off-by: Vishwanath BS
> Cc: Thara
On Mon, 24 Jan 2011 17:51:22 +0200
Jarkko Nikula wrote:
> OMAP can do also dynamic idling so wake-up enable register should be set
> also while system is running. If UART_OMAP_WER is not set, then for instance
> the RX activity cannot wake up the UART port that is sleeping.
>
> This RX wake-up f
Hi,
On 02/04/11 17:15, G, Manjunath Kondaiah wrote:
> On Fri, Feb 04, 2011 at 04:47:09PM +0200, Igor Grinberg wrote:
>> On 02/04/11 16:16, G, Manjunath Kondaiah wrote:
>>> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kon
Vishwanath BS writes:
> There could be dependencies between various voltage domains for
> maintaining system performance or hardware limitation reasons
> like VDD should be at voltage v1 when VDD is at voltage v2.
> This patch introduce dependent vdd information structures in the
> voltage layer
On 02/04/11 17:11, Poddar, Sourav wrote:
> On Fri, Feb 4, 2011 at 8:17 PM, Igor Grinberg wrote:
>>
>> On 02/04/11 16:16, G, Manjunath Kondaiah wrote:
>>
>>> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote:
On Fri, Feb 4, 2011 at 8:17 PM, Igor Grinberg wrote:
>
>
> On 02/04/11 16:16, G, Manjunath Kondaiah wrote:
>
>> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
>>> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote:
On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dm
On Fri, Feb 04, 2011 at 04:47:09PM +0200, Igor Grinberg wrote:
>
>
> On 02/04/11 16:16, G, Manjunath Kondaiah wrote:
>
> > On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
> >> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote:
> >>> On Thu, Feb 03, 2011 at 09:19
Hi Dmitry,
On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote:
>> On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote:
>>> The ads7846 driver requests a gpio but does not currently
>>> configure it explicitly as an input. Use gpio_request_one
>>> to request and configure it
For various reasons, Linux now only officially supports being built
with tools which are new enough to understand the SMC instruction.
Replacing the hand-encoded instructions when the mnemonic also
allows for correct assembly in Thumb-2 (otherwise, the result is
random data in the middle of the co
On Fri, Feb 04, 2011 at 08:28:53PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Dave Martin [mailto:dave.mar...@linaro.org]
> > Sent: Friday, February 04, 2011 7:52 PM
> > To: linux-arm-ker...@lists.infradead.org
> > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jea
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Friday, February 04, 2011 7:52 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v3 3/5
On Fri, Feb 04, 2011 at 07:46:18PM +0530, G, Manjunath Kondaiah wrote:
> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
> > On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote:
> > > On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote:
> > > > On Thu, Fe
On 02/04/11 16:16, G, Manjunath Kondaiah wrote:
> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
>> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote:
>>> On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote:
On Thu, Feb 03, 2011 at 08:54:05AM -
For various reasons, Linux now only officially supports being built
with tools which are new enough to understand the SMC instruction.
Replacing the hand-encoded instructions when the mnemonic also
allows for correct assembly in Thumb-2 (otherwise, the result is
random data in the middle of the co
* Use BSYM() to get the correct Thumb branch address
for adr ,
* Fix an out-of-range ADR when building for ARM
* Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
* Remove deprecated/undefined PC-relative stores
* Add the required ENDPROC() directive for each ENTRY().
* .alig
* Remove deprecated/undefined PC-relative stores
* Add the required ENDPROC() directive for each ENTRY().
* .align before data words
Signed-off-by: Dave Martin
Tested-by: Santosh Shilimkar
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap2/sram34xx.S | 28
1
Code marked with ENTRY() also needs a matching ENDPROC() directive,
in order to ensure that the type and instruction set of the
symbol are correctly annotated.
ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong in
Now that wfi() in is suitably generic, we can
remove the omap-specific do_wfi() macro.
Signed-off-by: Dave Martin
---
arch/arm/mach-omap2/include/mach/omap4-common.h |7 ---
arch/arm/mach-omap2/omap-hotplug.c |3 ++-
arch/arm/mach-omap2/pm44xx.c|
This set of patches, along with some other patches under
discussion on alkml, should enable omap3 and omap4 kernels to be
built with CONFIG_THUMB2_KERNEL.
This patch set builds on recent cleanup done by the omap
maintainers.
It is also more aggressive than my last post: all affected
low-level cod
Pre-v7 processors don't have wfe/sev, so these are defined for
consistency as empty barrier asms.
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6, wfi() is not defined. If needed, som
On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote:
> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote:
> > On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote:
> > > On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote:
> > > > On Thu, Feb 03,
On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote:
> On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote:
> > On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote:
> > > On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote:
> > > > The ads7846 dri
The search was made with trivial shell commands:
find | xargs grep S_IWUGO
find | xargs grep S_IWOTH
I didn't precisely investigate how exactly one may damage the
system/hardware because of issues number, maybe the harm is very limited
in case of some of these drivers.
One suspicious file is ./s
On Fri, Feb 04, 2011 at 02:45:09PM +0530, Kishon Vijay Abraham I wrote:
> Some macros defined in mcbsp.h related to audio, which are never being used
> is removed.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Charulatha V
> Cc: Jarkko Nikula
> ---
> arch/arm/plat-omap/include/plat/
On 02/04/11 11:15, ext Kishon Vijay Abraham I wrote:
> Some macros defined in mcbsp.h related to audio, which are never being used
> is removed.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Charulatha V
> Cc: Jarkko Nikula
> ---
> arch/arm/plat-omap/include/plat/mcbsp.h | 14
Kishore,
On Fri, Feb 04, 2011 at 07:07:37PM +0530, Kishore Kadiyala wrote:
> Manju,
>
> Line wrapped, looks like your .muttrc needs to be configured for 80
> characters limit.
Thanks for reporting. Configured mutt on new machine recently. I will
check and fix it.
-Manjunath
--
To unsubscribe from
Manju,
Line wrapped, looks like your .muttrc needs to be configured for 80
characters limit.
Regards,
Kishore
On Fri, Feb 4, 2011 at 7:02 PM, G, Manjunath Kondaiah wrote:
> On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote:
>> On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torok
On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote:
> > On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote:
> > > The ads7846 driver requests a gpio but does not currently
> > > configure it explicitly as an
Hello.
On 01-02-2011 18:36, Aaro Koskinen wrote:
With the commit 757902513019e6ee469791ff76f954b19ca8d036 fixed voltage
Please also specify the commit summary in parens, as asked by Linus.
regulator setup will fail if there are voltage constraints defined. This
made MMC unusable on this
On Thu, Feb 3, 2011 at 10:49 PM, Dmitry Torokhov
wrote:
> On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote:
>> On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote:
>> > The ads7846 driver requests a gpio but does not currently
>> > configure it explicitly as an input. Use
Hi Tony,
I saw a few patches floating around regarding world writeable sysfs
files and decided to grep around arch/arm/*omap* to try and see if we
were safe. Turns out anyone can change MUX entries via the debugfs
interface:
static void __init omap_mux_dbg_create_entry(
On Fri, Feb 04, 2011 at 08:39:34AM +, Russell King - ARM Linux wrote:
> Can't we just hard-configure the virtual/physical address at build
> time and be done with it?
>
> I've given up with the current state of affairs which tries to use the
> platform ID to select the UART to use as it never
Don't allow everybody to change voltage settings.
Signed-off-by: Vasiliy Kulikov
---
Cannot compile the driver, so it is not tested at all.
arch/arm/mach-omap2/smartreflex.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/ar
Don't allow all users to change timer settings.
Signed-off-by: Vasiliy Kulikov
---
Cannot compile the driver, so it is not tested at all.
arch/arm/mach-omap2/pm-debug.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mac
Do not create mux debugfs files as world-writable.
Signed-off-by: Vasiliy Kulikov
---
Cannot compile the driver, so it is not tested at all.
arch/arm/mach-omap2/mux.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
On Fri, Feb 4, 2011 at 3:27 AM, Tony Lindgren wrote:
> Set the debug serial port based on machine ID. Note that most
> of the patch is just trivial checking for the machine ID.
>
> Also note that this code won't work for debugging the uncompress code.
>
> Signed-off-by: Tony Lindgren
> ---
> di
On Fri, Feb 4, 2011 at 11:03 AM, Russell King - ARM Linux
wrote:
> On Thu, Dec 09, 2010 at 11:59:42AM +, Dave Martin wrote:
>> Because the nwfpe support is unlikely to be used on new platforms
>> and requires CONFIG_OABI_COMPAT, which is not generally used with
>> ARMv7+, we shouldn't expect t
On Thursday, January 27, 2011 13:32:16 Laurent Pinchart wrote:
> Hi everybody,
>
> Here's the fifth version of the OMAP3 ISP driver patches, updated to
> 2.6.37 and the latest changes in the media controller and sub-device APIs.
Hmm, patch 5/5 is missing. It's probably too big.
Anyway, I got the
Jean,
> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Tuesday, February 01, 2011 5:01 PM
> To: Jean Pihet
> Cc: linux-omap@vger.kernel.org; Jean Pihet-XID
> Subject: RE: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
>
> > -Original Message--
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Friday, February 04, 2011 5:01 PM
> To: Santosh Shilimkar
> Cc: catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-
> o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> ccr...@an
On Fri, Feb 04, 2011 at 04:16:07PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Friday, February 04, 2011 4:11 PM
> > To: Santosh Shilimkar
> > Cc: catalin.mari...@arm.com; linus.ml.wall...@gmail.com; lin
On Fri, Feb 4, 2011 at 11:16 AM, Santosh Shilimkar
wrote:
>> -Original Message-
>> From: Dave Martin [mailto:dave.mar...@linaro.org]
>> Sent: Friday, February 04, 2011 4:33 PM
>> To: Santosh Shilimkar
>> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; Jean Pihet-
>> XID; linux-oma
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Friday, February 04, 2011 4:28 PM
> To: Santosh Shilimkar
> Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org;
> Tony Lindgren; Nicolas Pitre; linux-omap@vger.kernel.org; Jean
> Pihet-XID
> Sub
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Friday, February 04, 2011 4:33 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; Jean Pihet-
> XID; linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: Re: [PATCH v2 0/5] AR
On Thu, Dec 09, 2010 at 11:59:42AM +, Dave Martin wrote:
> Because the nwfpe support is unlikely to be used on new platforms
> and requires CONFIG_OABI_COMPAT, which is not generally used with
> ARMv7+, we shouldn't expect to build nwfpe support into a Thumb-2
> kernel.
>
> At present, nwfpe c
On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
wrote:
> Dave,
>> -Original Message-
>> From: Dave Martin [mailto:dave.mar...@linaro.org]
>> Sent: Thursday, February 03, 2011 11:33 PM
>> To: linux-arm-ker...@lists.infradead.org
>> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean
On Wed, Jan 19, 2011 at 04:02, Martin Hostettler
wrote:
> Adds board support for an MT9M032 based camera to omap3evm.
>
> Sigend-off-by: Martin Hostettler
> ---
> arch/arm/mach-omap2/Makefile | 1 +
> arch/arm/mach-omap2/board-omap3evm-camera.c | 177
> +++
On Thu, Feb 3, 2011 at 7:30 PM, Santosh Shilimkar
wrote:
>> -Original Message-
>> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
>> Sent: Friday, February 04, 2011 12:38 AM
>> To: Santosh Shilimkar
>> Cc: Dave Martin; linux-arm-ker...@lists.infradead.org; Tony
>> Lindgren;
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Thursday, December 09, 2010 5:30 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Dave Martin; Santosh Shilimkar; linux-omap@vger.kernel.org
> Subject: [PATCH 2/2] ARM: Make CONFIG_FPE_NWFPE depend on
> !CON
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Thursday, December 09, 2010 5:30 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Dave Martin; Santosh Shilimkar; linux-omap@vger.kernel.org
> Subject: [PATCH 1/2] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL dep
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Friday, February 04, 2011 4:11 PM
> To: Santosh Shilimkar
> Cc: catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-
> o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> ccr...@an
Dave,
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: [PAT
On Tue, Jan 25, 2011 at 11:53:35PM +0530, Santosh Shilimkar wrote:
> After fixing the 3rd version for base address break, I was able to
> use this patch and test it. Seems to work. SMC related stuff can
> be ignored because OMAP4 ES1.0 doesn't have functional PM hardware
> support.
I think I'd pre
On Tue, Jan 18, 2011 at 11:32:16PM +0100, Martin Hostettler wrote:
> +#include
Please use linux/gpio.h in future.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Russell,
> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Monday, January 24, 2011 2:21 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: linux-omap@vger.kernel.org; ccr...@android.com;
> catalin.mari...@arm.com; li...@arm.linux.org.uk;
> linus.ml.w
On OMAP4, one can explicitly program INACTIVE as the power state of
the logic area inside the power domain. Techincally PD state programmed
to ON and if all the clock domains within the PD are idled, is equivalent
tp PD programmed to INACTIVE and all the clock domains within the PD are
idled. There
From: Rajendra Nayak
All OMAP3/4 dpll's support hardware level autogating.
Populate allow_idle/deny_idle function pointers for all
DPLL's in clkops.
Also for OMAP4, call omap_clk_enable_autoidle() from PM
core (only with CONFIG_PM) to enable hardware level
autogating on all clock nodes which sup
From: Rajendra Nayak
Enable hardware gate control for all dpll MX postdividers.
This requires the allow_idle/deny_idle functions to be
populated for all clock nodes (mx post dividers) in
clkops.
The autogen script is updated for the same.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/
From: Rajendra Nayak
On OMAP various clock nodes (dpll's, mx post dividers, interface clocks)
support hardware level autogating which can be controlled from
software.
Support such functionality by adding two new function pointer
allow_idle and deny_idle in the clkops structure.
These function po
From: Rajendra Nayak
On OMAP4, the dpll post divider outputs (MX outputs)
provide a way to allow/deny hardware level autogating.
Allowing autoidle would mean that the hw would autogate
this clock when there is no dependency for it.
Denying idle would mean that this clock output will be
forced to
From: Benoit Cousson
The register naming convention for clock domain control inside
power domain instance is:
OMAPCDOFFS
Both CPU0 and CPU1 use MPU as clock domain name instead of CPU0
and CPU1.
Change the name to stick to the convention.
The autogen scripts are updated accordingly.
Si
The series mainly contains dpll initialisation, CPUx clock
domain offset fix, addiing INACTIVE power domain state and
fixing logic flag for IVAHD and ABE power domains.
Changes in v2:
- All dpll autoidling moved late in boot, (as part of
PM core init) and is done only with CONFIG_PM.
IVAHD and ABE power domain logic state is populated using directly
value instead of the capability flags.
Fix the same.
This was getting generated due to a bug 'gen_logicst' macro
in powerdomain autogen script bug which is fixed as well.
Signed-off-by: Santosh Shilimkar
Cc: Paul Walmsley
Cc: R
CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
domain control register
Fix the same.
The autogen scripts is fixed thanks to Benoit Cousson
Signed-off-by: Santosh Shilimkar
Cc: Paul Walmsley
Cc: Raje
From: Rajendra Nayak
Check if enable/disable operations are supported for a given
clock node before attempting to call them.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/c
On Fri, 4 Feb 2011 14:45:09 +0530
Kishon Vijay Abraham I wrote:
> Some macros defined in mcbsp.h related to audio, which are never being used
> is removed.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Charulatha V
> Cc: Jarkko Nikula
> ---
> arch/arm/plat-omap/include/plat/mcbsp
Some macros defined in mcbsp.h related to audio, which are never being used
is removed.
Signed-off-by: Kishon Vijay Abraham I
Reviewed-by: Charulatha V
Cc: Jarkko Nikula
---
arch/arm/plat-omap/include/plat/mcbsp.h | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff -
On Thu, Feb 03, 2011 at 05:22:07PM -0800, Tony Lindgren wrote:
> Allow machine specific init of the DEBUG_LL serial port. This is needed
> to debug kernels built with support for multiple machines compiled in
> without recompiling the kernel.
>
> As some SoCs need to use variables to store the por
On Thu, Feb 3, 2011 at 22:49, Dmitry Torokhov wrote:
> On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote:
>> On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote:
>> > The ads7846 driver requests a gpio but does not currently
>> > configure it explicitly as an input. Use gpi
100 matches
Mail list logo
