Hi Paul,
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break those, at least it causes problem with omap3evm, see below
But this is
Jon,
On Thu, May 10, 2012 at 3:03 AM, Jon Hunter jon-hun...@ti.com wrote:
From: Jon Hunter jon-hun...@ti.com
This series adds PMU support for OMAP4 devices. This is based upon Will
Deacons
series [1]. This series attempts to fix the management of the EMU power domain
so that PMU can be
On Thu, May 10, 2012 at 3:05 AM, Jon Hunter jon-hun...@ti.com wrote:
From: Jon Hunter jon-hun...@ti.com
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. This is based upon Benoit Cousson's
patch [1].
[1]
On Thu, May 10, 2012 at 3:05 AM, Jon Hunter jon-hun...@ti.com wrote:
From: Ming Lei ming@canonical.com
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
l3_instr, l3_main_3, debugss
so build the arm-pmu device via
On Tue, May 8, 2012 at 3:47 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Mon, May 07, 2012 at 10:51:53, J, KEERTHY wrote:
On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
On Thu, May 10, 2012 at 3:05 AM, Jon Hunter jon-hun...@ti.com wrote:
From: Jon Hunter jon-hun...@ti.com
This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4
[1]. In Ming's original patch the CTI interrupts were being enabled during
runtime when the PMU was used but
Hi Tony,
On Wed, May 09, 2012 at 03:06:26, Tony Lindgren wrote:
To resolve this and as per your earlier question on whether old along
with new interface can be made to work parallely, here is suggestion
from my end to deal with it.
I think this is the only way to keep this all building
Hi Tarun,
On Fri, Apr 27, 2012 at 7:43 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level
Would you be able to help me understand exactly what it means for the
USB
bus to go to suspend? Is this something that the host initiates or
something that the gadget initiates?
Host initiates it, when host wants to suspend the whole bus or certain port,
it will stop sending SOF, after
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
* Russ Dill russ.d...@ti.com [120509 15:53]:
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote:
* Russ Dill russ.d...@ti.com [120509 15:12]:
The Beagleboard xM gpio used for TFP410 powerdown is connected through
On Thursday 10 May 2012 03:06 AM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
following transition modes ...
NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
irrespective
On Wed, 2012-05-09 at 15:08 -0700, Russ Dill wrote:
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
Signed-off-by: Russ Dill
Benoit,
On Wednesday 09 May 2012 04:28 PM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
P.S. Please note there is also already a different fix in
Hi Ivan,
On Wed, May 09, 2012 at 21:01:42, Tony Lindgren wrote:
Note that I could prepare a new MTD patch with BCH ecc code included,
allowing to drop the GPMC BCH ecc api.
OK, let's do that then. I'll drop this patch and you can coordinate
your patch with Afzal.
Now that some review
On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [120509 01:12]:
Below is the pull request for board file related changes. Tested on
panda 4430sdp.
Thanks, I've merged that into clenaup-dss branch and will send it
along with other still
On Wednesday 09 May 2012 09:18 PM, Russell King - ARM Linux wrote:
On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote:
On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
The
On Wed, 2012-05-09 at 23:12 -0500, Ricardo Neri wrote:
Under the new strategy, in addition to not allowing the audio functions
to be called from multiple threads, audio functions will fail if the
sequence _CONFIGURED - _ENABLED - PLAYING - DISABLED is not followed.
This is aligned with the
On Wed, 2012-05-09 at 22:47 +0800, Hein Tibosch wrote:
Tomi,
In drivers/video/omap2/omapfb/omapfb-main.c:
static int omapfb_parse_vram_param(const char *param, int max_entries,
unsigned long *sizes, unsigned long *paddrs)
{
int fbnum;
unsigned long size;
On Wed, May 09, 2012 at 00:04:14, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120508 00:18]:
Tony,
Please pull the following preparatory cleanup series to add OMAP5 minimal
support. Boot tested on OMAP2430 SDP, OMAP3430 SDP and OMAP4430 SDP
platforms.
I
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
Hi All,
Hi Jon,
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda. Hopefully Ming and/or Will can also
From: Afzal Mohammed af...@ti.com
Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin
On Thu, May 10, 2012 at 12:41:35PM +0530, Santosh Shilimkar wrote:
Are you planning to merge below patch as is or split
the patch like 1) Refactoring 2) ARMv7 fix
I don't see any point in splitting this up, especially as the ARMv7
fix would involve merely changing two lines (the domain register
On Thu, May 10, 2012 at 10:44 AM, Will Deacon will.dea...@arm.com wrote:
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
Hi All,
Hi Jon,
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
On Thursday 10 May 2012 02:23 PM, Russell King - ARM Linux wrote:
On Thu, May 10, 2012 at 12:41:35PM +0530, Santosh Shilimkar wrote:
Are you planning to merge below patch as is or split
the patch like 1) Refactoring 2) ARMv7 fix
I don't see any point in splitting this up, especially as the
Tony,
[snip]
So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS
it can be changed as
#ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
So this will avoid patching this for the future socs. ?
Well it seems that we've come to a conclusion
On Thu, 2012-05-10 at 00:14 +0100, Russell King - ARM Linux wrote:
On Wed, May 09, 2012 at 03:46:02PM -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Hi,
First version for this work. Applies on top of mainline + iochain set +
OMAP4 core retention set. Working tree
Hi Jon Ming,
On 5/9/2012 11:35 PM, Jon Hunter wrote:
From: Ming Leiming@canonical.com
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
l3_instr, l3_main_3, debugss
so build the arm-pmu device via the three hwmods.
The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files
even if the cpuidle option is not set in the kernel.
This patch fixes this by creating a section in the Makefile where these
files are compiled only if the CONFIG_CPU_IDLE option is set.
This modification breaks an implicit
Hi,
These patches fix DSS hwmod data related to sysc flags. I haven't seen any
problem produced by these missing bits, but by looking at the TRM it's clear
that they should be defined.
However, applying these will cause additional warnings to show during boot:
omap_hwmod: dss_dispc: softreset
hwmod class for rfbi is missing SYSS_HAS_RESET_STATUS, which this patch
adds.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
hwmod class for dispc is missing sysc flags, which this patch adds.
OMAP2 is missing SYSS_HAS_RESET_STATUS
OMAP3 is missing SYSS_HAS_RESET_STATUS and SYSC_HAS_CLOCKACTIVITY
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |3 ++-
hwmod data for OMAP3 does not define sysconfig for DSI. This patch adds
it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
On Thu, 2012-05-10 at 18:51 +0800, Hein Tibosch wrote:
On 5/10/2012 4:23 PM, Tomi Valkeinen wrote:
On Wed, 2012-05-09 at 22:47 +0800, Hein Tibosch wrote:
fbnum = simple_strtoul(p, p, 10);
- if (p == param)
+ if (p == start)
correct?
Yes, looks like a
Hi,
\
On 05/03/2012 10:26 AM, R Sricharan wrote:
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
Instead of failing, allow it to configure the first overlay as if there
was only one overlay, the remaining ones will have to be configured in
other ways (sysfs).
This allows overlay-controlling programs (like video players)
Hi Roger,
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+
On 5/10/2012 4:23 PM, Tomi Valkeinen wrote:
On Wed, 2012-05-09 at 22:47 +0800, Hein Tibosch wrote:
fbnum = simple_strtoul(p, p, 10);
-if (p == param)
+if (p == start)
correct?
Yes, looks like a correct fix. I'll cook up a patch.
How did you encounter
Hi,
On 05/03/2012 10:26 AM, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from
On Thu, May 10, 2012 at 5:06 PM, Roger Quadros rog...@ti.com wrote:
Hi,
On 05/03/2012 10:26 AM, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4
On 05/10/2012 02:42 PM, Shilimkar, Santosh wrote:
On Thu, May 10, 2012 at 5:06 PM, Roger Quadros rog...@ti.com wrote:
Hi,
On 05/03/2012 10:26 AM, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
-
On Thursday 10 May 2012 05:18 PM, Roger Quadros wrote:
On 05/10/2012 02:42 PM, Shilimkar, Santosh wrote:
On Thu, May 10, 2012 at 5:06 PM, Roger Quadros rog...@ti.com wrote:
Hi,
On 05/03/2012 10:26 AM, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4 and OMAP5 share
Hi,
On 05/03/2012 10:26 AM, R Sricharan wrote:
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory
On Wed, 2012-05-09 at 08:31 -0700, Tony Lindgren wrote:
Note that I could prepare a new MTD patch with BCH ecc code included,
allowing to drop the GPMC BCH ecc api.
OK, let's do that then. I'll drop this patch and you can coordinate
your patch with Afzal.
Ivan, so are you going to send
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads was used in
different mode by any other module then it
On 12:56 Thu 03 May , R Sricharan wrote:
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
Hi J,
why do you duplicate this
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
do this
case 0:
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
+
Jon Hunter jon-hun...@ti.com writes:
[...]
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda.
There are some differences between 4430 and 4460 here. Can you test
Grant,
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
Hi,
On Thu, May 10, 2012 at 3:06 AM, Janusz Krzysztofik
jkrzy...@tis.icnet.pl wrote:
On Mon, 7 May 2012 10:52:28 DebBarma, Tarun Kanti wrote:
On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas nota...@gmail.com wrote:
On Mon, Apr 30,
On Thu, 10 May 2012, NeilBrown wrote:
Maybe we need to not suspend the USB OTG interface when the device as a
whole enters suspend-to-RAM. Maybe we need to register a dummy gadget to
the bus active while in suspend?
Does the gadget have to be responsive while-ever the bus is not
On Tue, May 8, 2012 at 5:05 PM, Venkatraman S svenk...@ti.com wrote:
Cleanups for the legacy omap mmc driver to remove clutter and
make it well behaved as module.
Venkatraman S (3):
mmc: omap: convert to per instance workqueue
mmc: omap: make it behave well as module
mmc: omap: convert
On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote:
But in order to do so, I need the changes that Afzal has submitted
(in particular [3]). Those changes (and as a consequence, my new patch)
won't hit 3.5.
So, when Afzal's patches are pushed, I'll submit a new, single MTD patch.
But this
* Tomi Valkeinen tomi.valkei...@ti.com [120510 00:15]:
On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [120509 01:12]:
Below is the pull request for board file related changes. Tested on
panda 4430sdp.
Thanks, I've merged that into
* Tomi Valkeinen tomi.valkei...@ti.com [120509 23:56]:
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
* Russ Dill russ.d...@ti.com [120509 15:53]:
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote:
* Russ Dill russ.d...@ti.com [120509 15:12]:
The
* Hiremath, Vaibhav hvaib...@ti.com [120510 01:37]:
On Wed, May 09, 2012 at 00:04:14, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120508 00:18]:
Tony,
Please pull the following preparatory cleanup series to add OMAP5 minimal
support. Boot tested on OMAP2430
On 05/09/2012 03:38 PM, Jassi Brar wrote:
On 10 May 2012 00:40, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/08/2012 01:09 PM, Jassi Brar wrote:
There is important difference between providing data via clients
during runtime vs providing info about every client to the dmac driver
at one
On 05/09/2012 02:49 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120509 13:22]:
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504 11:59]:
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD
omap_secure_ram_reserve_memblock is stubbed for OMAP1,2 only builds using a
ifdef check. But this results in adding CONFIG_ARCH_OMAPxx checks for
future socs that use the real function. So move this to common.c file and
call it __weak.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
This is a continuation of the previous cleanup series from
santosh.shilim...@ti.com [1]. Patches are outcome of the OMAP5
review suggestions from Tony/Benoit/Santosh/Rajendra.
[1] http://www.spinics.net/lists/linux-omap/msg69730.html
R Sricharan (4):
ARM: OMAP2+: Introduce
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common
The DPLL ip was introduced and used in the OMAP3PLUS socs, while
OMAP2 had the APLL IP. There are some features which are common
to both ips, and some which are only applicable to DPLL ip's.
Currently CONFIG_ARCH_OMAP_XXX checks is used to conditionally
compile the additional features for every
OMAP socs has a legacy and a highlander version of the
32k sync counter IP. The register offsets vary between the
highlander and the legacy scheme. So use the 'SCHEME'
bits(30-31) of the revision register to distinguish between
the two versions and choose the CR register offset accordingly.
-Original Message-
From: R Sricharan [mailto:r.sricha...@ti.com]
Sent: Thursday, May 10, 2012 10:37 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com;
t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com; p...@pswan.com
Subject:
Hi Tero,
On Wed, 9 May 2012, Tero Kristo wrote:
On Fri, 2012-04-20 at 09:55 -0700, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [120420 01:24]:
Hi,
What happened with this pull request? It doesn't seem to be in 3.4 at
least.
There was a boot issue on omap3 evm and that
Partially fix the hwmod data for the AM35xx USB OTG hwmod. This
should resolve the following boot warning on AM35xx platforms:
omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3)
While here, also fix the clkdev records, to avoid warnings about
duplicate clock aliases.
The hwmod is also
During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:
omap_hwmod: uart4: softreset failed (waited 1 usec)
This also results in another warning later in the boot process:
omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or
disabled state
Hi
On Thu, 10 May 2012, R Sricharan wrote:
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are
Hi Tony,
-Original Message-
From: R Sricharan [mailto:r.sricha...@ti.com]
Sent: Thursday, May 03, 2012 12:56 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com;
t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com
Subject: [PATCH
Hi Paul,
On Thu, 10 May 2012, R Sricharan wrote:
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks
On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote:
On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote:
But in order to do so, I need the changes that Afzal has submitted
(in particular [3]). Those changes (and as a consequence, my new patch)
won't hit 3.5.
So, when
* Tony Lindgren t...@atomide.com [120509 11:58]:
* Vaibhav Hiremath hvaib...@ti.com [120509 04:28]:
Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
* Tony Lindgren t...@atomide.com [120510 11:06]:
* Tony Lindgren t...@atomide.com [120509 11:58]:
* Vaibhav Hiremath hvaib...@ti.com [120509 04:28]:
Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8
On Thu, May 10, 2012 at 23:35:36, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120510 11:06]:
* Tony Lindgren t...@atomide.com [120509 11:58]:
* Vaibhav Hiremath hvaib...@ti.com [120509 04:28]:
Initially, we decided to make am33xx family of device to fall
under omap3 class
On Thu, May 10, 2012 at 22:36:52, R, Sricharan wrote:
The DPLL ip was introduced and used in the OMAP3PLUS socs, while
OMAP2 had the APLL IP. There are some features which are common
to both ips, and some which are only applicable to DPLL ip's.
Currently CONFIG_ARCH_OMAP_XXX checks is used to
* Hiremath, Vaibhav hvaib...@ti.com [120510 11:22]:
On Thu, May 10, 2012 at 23:35:36, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120510 11:06]:
* Tony Lindgren t...@atomide.com [120509 11:58]:
* Vaibhav Hiremath hvaib...@ti.com [120509 04:28]:
Initially, we decided to
On Fri, May 11, 2012 at 00:00:25, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120510 11:22]:
On Thu, May 10, 2012 at 23:35:36, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120510 11:06]:
* Tony Lindgren t...@atomide.com [120509 11:58]:
* Vaibhav Hiremath
Hi Mark
On Thu, 10 May 2012, Mark A. Greer wrote:
On Thu, May 10, 2012 at 11:29:13AM -0600, Paul Walmsley wrote:
Hello,
this series fixes some of the warnings observed at boot with the AM35xx
boards. Intended for either the 3.5 or 3.5-rc merge windows.
Particularly appreciated
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit b3431f5ba402a98a89b78a9408b4972d8870df4d:
arm/dts: OMAP3: Add mmc controller nodes and board data (2012-03-14
21:54:57 +0100)
are available in the git repository at:
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit bfd17879866b36e95c58721da070d9f2ac7f8901:
Merge tag 'omap-devel-c-for-3.5' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
devel-hwmod-data (2012-05-09 09:58:42 -0700)
are
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
Hi Will,
On 05/10/2012 03:44 AM, Will Deacon wrote:
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
Hi All,
Hi Jon,
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on
* Tony Lindgren t...@atomide.com [120510 11:47]:
The following changes since commit 7a8bcf067d2b11964cb83ce3d753ac2d3ab9843c:
Merge branch 'devel-hwmod' into cleanup (2012-05-08 10:17:32 -0700)
are available in the git repository at:
* Ivan Djelic ivan.dje...@parrot.com [120510 10:49]:
On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote:
On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote:
But in order to do so, I need the changes that Afzal has submitted
(in particular [3]). Those changes (and as a
Hi Kevin,
On 05/10/2012 09:12 AM, Kevin Hilman wrote:
Jon Hunter jon-hun...@ti.com writes:
[...]
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda.
There
On Thu, May 10, 2012 at 11:29:17AM -0600, Paul Walmsley wrote:
Partially fix the hwmod data for the AM35xx USB OTG hwmod. This
should resolve the following boot warning on AM35xx platforms:
omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3)
While here, also fix the clkdev records,
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X machine init.
During last merge window, two separate patches supporting am33xx
machine init had been submitted,
1. Link to earlier Baseport patch submission (Legacy):
Hi Jean,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of J, KEERTHY
Sent: Thursday, April 26, 2012 12:41 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Hilman, Kevin; r...@sisk.pl;
* Govindraj.R govindraj.r...@ti.com [120510 06:09]:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads
On Thu, May 10, 2012 at 11:29:18AM -0600, Paul Walmsley wrote:
Add missing terminators to the arrays of IRQ, DMA, and address space
structure records in the AM35xx UART4 hwmod data. Without these
terminators, the following warnings appear on boot:
omap_uart.3: failed to claim resource 58
On Thu, May 10, 2012 at 11:29:19AM -0600, Paul Walmsley wrote:
During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:
omap_hwmod: uart4: softreset failed (waited 1 usec)
This also results in another warning later in the boot process:
omap_hwmod: uart4: enabled
On 10 May 2012 22:30, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/09/2012 03:38 PM, Jassi Brar wrote:
One point is about 'qos' here something like bandwidth allocation.
If the dmac driver knew up-front the max possible clients that could be
active simultaneously, it could divide the
This set of patches provides the foundation for enabling
OMAP4 Dsp as remote processor.
The first patch is a generic fix for mailbox in mach-omap2.
Without this patch, the irq for a mailbox instance other than
the first one is not properly enabled.
The second patch fixes the clock and irq names
The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.
The enable_irq function should be called every time a
new mbox instance is created/opened, in the
Irq and clock names were wrong for dsp iommu configuration
for omap4.
- Renamed tesla_ick to dsp_fck:
This is required because the new naming convention introduced
by: commit 0e43327 OMAP4 clock: Fix clock names and align
with hwmod names
- Renamed INT_44XX_DSP_MMU to
* Tony Lindgren t...@atomide.com [120510 11:55]:
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit bfd17879866b36e95c58721da070d9f2ac7f8901:
Merge tag 'omap-devel-c-for-3.5' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
On Thu, May 10, 2012 at 11:09 PM, Juan Gutierrez jgutier...@ti.com wrote:
The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.
The enable_irq function
Dnia czwartek, 3 maja 2012 13:28:58 Vaibhav Hiremath pisze:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
This patch series cleans up the
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, May 09, 2012 at 00:09:34, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
With addition to TI81XX, AM33XX family of devices, the number
of interrupts supported has increased to 128, compared to 96.
The current
Hi Janusz,
On Thu, 10 May 2012, Janusz Krzysztofik wrote:
Tried to test this branch, merged into 3.4-rc6, and with my Amstrad
Delta fixes applied, using my custom Amstrad Delta config, but initially
failed because an unrelated issue rised to the surface:
| LD .tmp_vmlinux1
|
* Kevin Hilman khil...@ti.com [120510 14:53]:
Hiremath, Vaibhav hvaib...@ti.com writes:
Let me finish up with am33xx baseport upstream activity which is currently
going on at full swing, then next thing I will pick up is this code cleanup.
I still feel, this is still a valid cleanup
1 - 100 of 110 matches
Mail list logo
