On Sat, Nov 5, 2011 at 3:30 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
The custom hwmod activate and deactivate funcs does hwmod_enable
and idle same can be done with omap_device generic API's.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
This one
On Sat, Nov 5, 2011 at 4:30 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Omap-uart can be used as console uart to print early boot
messages using earlyprintk so for console uart prevent
hwmod reset or idling during bootup.
Identify the console_uart set
On Mon, 7 Nov 2011 08:10:45 +0200
Felipe Balbi ba...@ti.com wrote:
Hi,
On Sat, Nov 05, 2011 at 05:19:54PM +0100, Michael Büsch wrote:
tahvo_write_reg() needs to take the mutex to avoid a race
condition with tahvo_set_clear_reg_bits:
tahvo_set_clear_reg_bits(): | tahvo_write_reg():
Hi,
On Mon, Nov 07, 2011 at 09:18:36AM +, Michael Büsch wrote:
On Sat, Nov 05, 2011 at 05:19:54PM +0100, Michael Büsch wrote:
tahvo_write_reg() needs to take the mutex to avoid a race
condition with tahvo_set_clear_reg_bits:
tahvo_set_clear_reg_bits(): | tahvo_write_reg():
Hello,
Changes since v1:
- Move the check after the ERRATA_3_3 re-read test
If the user asks for the sDMA current position before the first
data has been transmitted (before the first DMA request has been
generated), the reported position is not valid:
src position: CSAC is uninitialized
dst
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
register:
CDAC != 0 indicates that the DMA transfer on the channel has
been started already.
When
If the DMA destination position has been asked before the
first actual data transfer has been done, the CDAC
register still contains 0 (it is initialized to 0 at
omsp_dma_start).
If CDAC == 0, return the programmed start address.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi ALL,
I meet a problem when developing scan device (such as a camera)
driver on OMAP3 platform (my MPU is AM3715). The scan application may
change the scan hardware settings (such as exposure time), and try to
find out the best one. But sometimes, after applied the new settings,
the scan
The offset macros for OMAP4_RM_RSTST and OMAP4_RM_RSTTIME
are wrongly swapped up.
Thanks to Gina Glaser for identifying and reporting this.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Gina Glaser g-gla...@ti.com
---
arch/arm/mach-omap2/prm44xx.h |4 ++--
1 files changed, 2
On Fri, Nov 4, 2011 at 10:43 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
for enabling/disabling clocks appropriately. Remove syscore_ops and
instead use SET_RUNTIME_PM_OPS macro.
On Fri, Nov 4, 2011 at 10:27 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishanth Menon n...@ti.com
GPIO debounce registers need to be saved and restored for proper functioning
of driver.
OK.
To save the registers, we cannot cut the clock
On Fri, Nov 4, 2011 at 10:23 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishanth Menon n...@ti.com
GPIO IP revisions such as those used in OMAP4 have a set_dataout
while the previous revisions used a single dataout register.
Depending on
I see below errors and warnings on latest mainline commit
b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig.
Patch to fix the same.
arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or
storage class
arch/arm/plat-omap/dmtimer.c:184: warning: type defaults to
Fixes below compilation error -
CC arch/arm/mach-omap2/hwspinlock.o
cc1: warnings being treated as errors
In file included from arch/arm/mach-omap2/hwspinlock.c:22:0:
include/linux/hwspinlock.h: In function '__hwspin_unlock':
include/linux/hwspinlock.h:121:2: error: 'return' with a
On Mon, Nov 7, 2011 at 6:08 PM, Govindraj.R govindraj.r...@ti.com wrote:
I see below errors and warnings on latest mainline commit
b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig.
Patch to fix the same.
Patches are already posted and applied by Tony on linux-omap master.
Hi Vaibhav,
On 11/07/11 14:58, Vaibhav Hiremath wrote:
Fixes below compilation error -
CC arch/arm/mach-omap2/hwspinlock.o
cc1: warnings being treated as errors
In file included from arch/arm/mach-omap2/hwspinlock.c:22:0:
include/linux/hwspinlock.h: In function
Hi Rajendra,
On 11/7/2011 11:06 AM, Rajendra Nayak wrote:
The offset macros for OMAP4_RM_RSTST and OMAP4_RM_RSTTIME
are wrongly swapped up.
Thanks to Gina Glaser for identifying and reporting this.
Signed-off-by: Rajendra Nayakrna...@ti.com
Cc: Gina Glaserg-gla...@ti.com
---
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Monday, November 07, 2011 6:37 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; t...@atomide.com; o...@wizery.com
Subject: Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from
void
On Fri, Nov 4, 2011 at 10:10 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Currently debounce clock state is not tracked in the system.
??
bank-dbck_enable_mask ?
As I understand, this only tells which all GPIOs have debounce timeout enabled.
But,
On Mon, Nov 7, 2011 at 2:58 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
Fixes below compilation error -
Thanks. We already have this fix queued up though (reported by Axel awhile ago).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Monday, November 07, 2011 7:25 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from
void funtion
On Mon, Nov 7,
On Mon, Nov 7, 2011 at 3:58 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
[Hiremath, Vaibhav] I did try to search before fixing this...but I did not
find any patch for this. Can you point me to it?
http://comments.gmane.org/gmane.linux.kernel/1210678
--
To unsubscribe from this list: send the
On 11/7/2011 1:59 PM, Shilimkar, Santosh wrote:
On Mon, Nov 7, 2011 at 6:08 PM, Govindraj.Rgovindraj.r...@ti.com wrote:
I see below errors and warnings on latest mainline commit
b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig.
Patch to fix the same.
Patches are already
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Monday, November 07, 2011 7:25 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from
void funtion
On Mon, Nov 7,
This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for ID and feature detection; makes
easier to add new SoC (especially for AM devices where we do not have
feature register).
Signed-off-by: Vaibhav
For OMAP3 uarts (module rev = 0x52) and all successor devices
(omap4, TI81xx, AM33xx, etc...) empty fifo read errata is applicable,
so we can get rid of cpu_is_ check and simply check for module rev here.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
NOTE: This patch has been tested on
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, November 07, 2011 8:28 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hiremath, Vaibhav
Subject: [PATCH] arm:omap:serial:cleanup: use module rev instead of
cpu_is_
For OMAP3 uarts (module rev = 0x52) and all
Adding linux-omap and linux-davinci lists
Jean Delvare kh...@linux-fr.org writes:
Both bus drivers i2c-omap and i2c-davinci apparently handle 10-bit addresses:
(i2c-omap.c)
if (msg-flags I2C_M_TEN)
w |= OMAP_I2C_CON_XA;
(i2c-davinci.c)
/* if the slave address
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, October 07, 2011 4:39 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; Hilman, Kevin; p...@pwsan.com; linux-arm-
ker...@lists.infradead.org; Mohammed, Afzal
Subject: Re: [PATCH-V3 4/4]
From: Per Forlin per.for...@linaro.org
Reported by Russell King:
mmcblk0: error -84 transferring data, sector 149201, nr 64,
cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
WARNING: at lib/dma-debug.c:811 check_unmap
omap_hsmmc omap_hsmmc.0: DMA-API: device driver
On Mon, 07 Nov 2011 07:09:38 -0800, Kevin Hilman wrote:
Adding linux-omap and linux-davinci lists
Good point, sorry for missing that. Maybe the following would help?
List i2c-omap and i2c-davinci in MAINTAINERS.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
MAINTAINERS |3 +++
1 file
On Thu, Nov 03, 2011 at 11:30:02AM -0700, Tony Lindgren wrote:
Considering we now have the DT branch merged, I'll apply the earlier
patch from Sanjeev with a minor modification to avoid a build
warning in board-generic.c.
Updated patch below, Sekhar Thomas, care to ack?
When are we likely
* Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]:
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the way there's fatal build errors at EVERY merge
window. The OMAP workflow
* Russell King - ARM Linux li...@arm.linux.org.uk [07 08:31]:
On Thu, Nov 03, 2011 at 11:30:02AM -0700, Tony Lindgren wrote:
Considering we now have the DT branch merged, I'll apply the earlier
patch from Sanjeev with a minor modification to avoid a build
warning in board-generic.c.
On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the way there's fatal build errors at EVERY merge
window.
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]:
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the way
Hi,
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]:
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the
* Russell King - ARM Linux li...@arm.linux.org.uk [07 09:12]:
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]:
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up
commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
mistakenly added MUSB as a hwmod available only on ES2.0
of OMAP3430.
MUSB hwmod has always be available on all OMAP revisions
since OMAP2430.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
* Hiremath, Vaibhav hvaib...@ti.com [07 06:42]:
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, October 07, 2011 4:39 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; Hilman, Kevin; p...@pwsan.com; linux-arm-
allow for the omap4430 es2.3 revision to be recognized in the
omap4_check_revision() function.
most aspects of all omap4430 es2.x versions are identical, however
a number of small variations such as default pullup or pulldown
resistor configurations vary between revisions.
detailed information
Hi,
On Fri, Nov 4, 2011 at 6:27 PM, Kevin Hilman khil...@ti.com wrote:
@@ -821,9 +820,7 @@ static irqreturn_t iommu_fault_handler(int irq, void
*data)
if (!obj-refcount)
return IRQ_NONE;
- clk_enable(obj-clk);
errs = iommu_report_fault(obj, da);
-
On Mon, Nov 07, 2011 at 09:55:11PM +0530, Balaji T K wrote:
From: Per Forlin per.for...@linaro.org
Reported by Russell King:
mmcblk0: error -84 transferring data, sector 149201, nr 64,
cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
WARNING: at
On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote:
commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
mistakenly added MUSB as a hwmod available only on ES2.0
of OMAP3430.
MUSB hwmod has always be available on all OMAP revisions
since OMAP2430.
This doesn't seem to solve it:
Hi,
On Mon, Nov 07 2011, Russell King - ARM Linux wrote:
On Mon, Nov 07, 2011 at 09:55:11PM +0530, Balaji T K wrote:
From: Per Forlin per.for...@linaro.org
Reported by Russell King:
mmcblk0: error -84 transferring data, sector 149201, nr 64,
cmd response 0x900, card status 0xb00
mmcblk0:
Mahaveer, Vishal vish...@ti.com writes:
omap4_clk32kg regulator is used by connectivity (WLAN/BT/GPS) chip on
omap4 platforms.
Set always_on flag to true for connectivity chip to operate.
The driver/init for the connectivity chip should be using the regulator
API to enable/disable the
Hi,
On Mon, Nov 07, 2011 at 06:32:08PM +, Russell King - ARM Linux wrote:
On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote:
commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
mistakenly added MUSB as a hwmod available only on ES2.0
of OMAP3430.
MUSB hwmod has
Vaibhav Hiremath hvaib...@ti.com writes:
For OMAP3 uarts (module rev = 0x52) and all successor devices
(omap4, TI81xx, AM33xx, etc...) empty fifo read errata is applicable,
so we can get rid of cpu_is_ check and simply check for module rev here.
Signed-off-by: Vaibhav Hiremath
Tomi,
* Russell King - ARM Linux li...@arm.linux.org.uk [07 09:12]:
drivers/video/omap/dispc.c:276: warning: data definition has no type or
storage class
drivers/video/omap/dispc.c:276: warning: type defaults to 'int' in
declaration of 'EXPORT_SYMBOL'
drivers/video/omap/dispc.c:276:
* Igor Grinberg grinb...@compulab.co.il [06 04:45]:
Hi Tony,
On 11/05/11 01:57, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [04 16:05]:
* Igor Grinberg grinb...@compulab.co.il [111019 02:05]:
Applying to board branch for v3.3 merge window.
Hmm, actually I suggest
* Axel Lin axel@gmail.com [02 23:26]:
Include linux/export.h to fix below build warning:
CC arch/arm/plat-omap/omap_device.o
arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type
or storage class
arch/arm/plat-omap/omap_device.c:1055: warning: type
Hi Arnd,
Please pull omap fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
This contains the pending fixes I've found in my inbox.
Some of these I would have sent earlier, but was waiting
for the DT branch merge to clear first.
This series fixes all the
omap44xx i2c devices need to have the registers reset post idle
similar to omap3xxx devices. this adds the additional flag for
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE to the omap44xx i2c_dev_attr.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1
Hilman, Kevin wrote:
No.
You want it on only
1) if the connectivity chip is present, *and*
2) BT, WLAN, FM or GPS are being used.
The current patch assumes that a connectivity chip is present
whenever the TWL is present, which may be true on the platform you're
currently working on,
On Mon, Nov 07, 2011 at 09:39:09PM +0200, Felipe Balbi wrote:
Hi,
On Mon, Nov 07, 2011 at 06:32:08PM +, Russell King - ARM Linux wrote:
On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote:
commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
mistakenly added MUSB as a
Arnd,
Don't pull this - there's yet more crap in OMAP to be fixed before
these go to mainline. OMAP3 is severely broken at the moment with,
to put it bluntly, totally fucked up OMAP hwmod code, and should be
fixed *now* by folk before this pull request.
The fixes are damned trivial I expect
On Mon, 7 Nov 2011, Russell King - ARM Linux wrote:
Again, can never have been tested on OMAP3.
Does anyone apart from me bother doing any testing what so ever on OMAP3
platforms? Am I the only one?
This was fixed by
http://www.spinics.net/lists/arm-kernel/msg143549.html
which didn't go
After this, I got some new warnings during bootup about sr1_hwmod and sr2_hwmod.
This is fixed with PATCH2/2.
-Jürgen
--
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
Because omap_hwmod_register() always return '0', checking the
return value as followed:
r = omap_hwmod_register(omap3xxx_hwmods);
if (!r)
return r;
leads to exiting the omap3xxx_hwmod_init() function right after
adding the omap3xxx_hwmods which are common to all
sr1_hwmod and sr2_hwmod are handled in omap34xx_hwmods,
which is for all omap34xx variants.
But they are also defined in omap3xxx_hwmods.
This leads to:
[0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959
omap_hwmod_register+0x40/0x1ac()
[0.00] omap_hwmod: sr1_hwmod:
On Mon, 7 Nov 2011, Felipe Balbi wrote:
commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
mistakenly added MUSB as a hwmod available only on ES2.0
of OMAP3430.
MUSB hwmod has always be available on all OMAP revisions
since OMAP2430.
Are you sure about this? I don't see it in my
On Mon, 7 Nov 2011, Juergen Kilb wrote:
After this, I got some new warnings during bootup about sr1_hwmod and
sr2_hwmod.
This is fixed with PATCH2/2.
Thanks for the patches, but these should be already fixed by
http://www.spinics.net/lists/arm-kernel/msg143549.html
- Paul
--
To
omap44xx i2c devices need to have the registers reset post idle
similar to omap3xxx devices. this adds the additional flag for
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE to the omap44xx i2c_dev_attr.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1
* Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]:
Arnd,
Don't pull this - there's yet more crap in OMAP to be fixed before
these go to mainline. OMAP3 is severely broken at the moment with,
to put it bluntly, totally fucked up OMAP hwmod code, and should be
fixed *now* by
On Mon, Nov 07, 2011 at 02:29:35PM -0700, Paul Walmsley wrote:
On Mon, 7 Nov 2011, Russell King - ARM Linux wrote:
Again, can never have been tested on OMAP3.
Does anyone apart from me bother doing any testing what so ever on OMAP3
platforms? Am I the only one?
This was fixed by
Mahaveer, Vishal vish...@ti.com writes:
Hilman, Kevin wrote:
No.
You want it on only
1) if the connectivity chip is present, *and*
2) BT, WLAN, FM or GPS are being used.
The current patch assumes that a connectivity chip is present
whenever the TWL is present, which may be true on
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:06]:
On Mon, Nov 07, 2011 at 02:29:35PM -0700, Paul Walmsley wrote:
On Mon, 7 Nov 2011, Russell King - ARM Linux wrote:
Again, can never have been tested on OMAP3.
Does anyone apart from me bother doing any testing what
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
Here's what I got. Looks like the removal of the sr[12]_hwmod
part is no longer needed, so only the r value check part is needed.
Err. So do you have anything in your git tree which you're pushing out
this evening which removes the
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:20]:
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
Here's what I got. Looks like the removal of the sr[12]_hwmod
part is no longer needed, so only the r value check part is needed.
Err. So do you have anything
On Mon, Nov 07, 2011 at 03:07:28PM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:20]:
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
Here's what I got. Looks like the removal of the sr[12]_hwmod
part is no longer needed, so only
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:41]:
On Mon, Nov 07, 2011 at 03:07:28PM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:20]:
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
Here's what I got. Looks like
The CPUidle use THIS_MODULE, so needs linux/export.h
Signed-off-by: Kevin Hilman khil...@ti.com
---
Tony, one more for omap/fixes. This one applies to Linus' master branch,
but also applies to your current omap/fixes.
arch/arm/mach-omap2/cpuidle34xx.c |1 +
1 files changed, 1
* Kevin Hilman khil...@ti.com [07 15:23]:
The CPUidle use THIS_MODULE, so needs linux/export.h
Signed-off-by: Kevin Hilman khil...@ti.com
---
Tony, one more for omap/fixes. This one applies to Linus' master branch,
but also applies to your current omap/fixes.
Thanks, applying into
Tero Kristo t-kri...@ti.com writes:
By default all registered pads will trigger mpu_irqs[0]. Now there is
an API for selecting used mpu_irq on pad basis, which can be used to
trigger different irq handlers for different pads in the same hwmod.
Each pad that requires its interrupt to be
* Tony Lindgren t...@atomide.com [07 13:12]:
* Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]:
Arnd,
Don't pull this - there's yet more crap in OMAP to be fixed before
these go to mainline. OMAP3 is severely broken at the moment with,
to put it bluntly, totally
Hi Arnd,
If you did not pull yet, please pull omap fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
This is an updated version of an earlier pull request at:
http://marc.info/?l=linux-arm-kernelm=132069904817116w=2
With one additional fix for cpuidle export.h
On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [07 13:12]:
* Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]:
Arnd,
Don't pull this - there's yet more crap in OMAP to be fixed before
these go to mainline. OMAP3 is
On Tue, Nov 08, 2011 at 12:42:14AM +, Russell King - ARM Linux wrote:
On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [07 13:12]:
* Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]:
Arnd,
Don't pull this -
* Russell King - ARM Linux li...@arm.linux.org.uk [06 05:18]:
Here's a list of my peaves about current platform code - which are
causing me great issue when trying to clean up the arch_reset() stuff:
1. Lack of trailing ',' on structure initializers
This makes it much harder to add
* Russell King - ARM Linux li...@arm.linux.org.uk [07 16:10]:
On Tue, Nov 08, 2011 at 12:42:14AM +, Russell King - ARM Linux wrote:
On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [07 13:12]:
* Russell King - ARM Linux
* Tony Lindgren t...@atomide.com [07 15:51]:
Hi Arnd,
If you did not pull yet, please pull omap fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
This is an updated version of an earlier pull request at:
Hi Vishwa,
Vishwanath BS vishwanath...@ti.com writes:
The folowing patch series provides IO Daisychain feature via omap hwmod mux
framework.
The series looks OK at first glance, but needs a refresh against current
mainline.
Can you refresh this against Tony's 'fixes' branch and re-test.
I
Hi Philip,
On Fri, Nov 4, 2011 at 7:48 PM, Philip Balister phi...@balister.org wrote:
On 11/03/2011 03:25 PM, Tony Lindgren wrote:
* James angweiy...@gmail.com [111023 18:13]:
Dear all,
I'm learning embedded linux development and need help on my task.
I'm trying to communicate with a FPGA
From: Ming Lei tom.leim...@gmail.com
The patch fixes the compile failure:
CC arch/arm/mach-omap2/cpuidle34xx.o
arch/arm/mach-omap2/cpuidle34xx.c:317:12: error: 'THIS_MODULE'
undeclared here (not in a function)
make[1]: *** [arch/arm/mach-omap2/cpuidle34xx.o] Error 1
make: ***
From: Ming Lei tom.leim...@gmail.com
This patch selects ARM_AMBA if OMAP3_EMU is defined because
OC_ETM depends on ARM_AMBA, so fix the link failure[1].
[1],
arch/arm/kernel/built-in.o: In function `etm_remove':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined
reference to
Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified
to use timer-func_base OCP_CFG should not use this wrapper anymore.
Instead use __raw_writel() directly and use timer-io_base instead
to write to OCP_CFG.
The timer-sys_stat is valid only if timer-revision is 1. In the
context
/* OMAP4 specific register offsets */
#define OMAP4_RM_RSTCTRL 0x
-#define OMAP4_RM_RSTTIME 0x0004
-#define OMAP4_RM_RSTST 0x0008
+#define OMAP4_RM_RSTST 0x0004
+#define
Patch to fix below compilation error on latest mainline commit
b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig.
arch/arm/mach-omap2/omap_l3_noc.c:250: error: 'THIS_MODULE' undeclared here
(not in a function)
make[1]: *** [arch/arm/mach-omap2/omap_l3_noc.o] Error 1
On Tue, Nov 8, 2011 at 11:58 AM, Govindraj.R govindraj.r...@ti.com wrote:
Patch to fix below compilation error on latest mainline commit
b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig.
arch/arm/mach-omap2/omap_l3_noc.c:250: error: 'THIS_MODULE' undeclared here
(not in a
On Tuesday 08 November 2011 11:52 AM, Rajendra Nayak wrote:
/* OMAP4 specific register offsets */
#define OMAP4_RM_RSTCTRL 0x
-#define OMAP4_RM_RSTTIME 0x0004
-#define OMAP4_RM_RSTST 0x0008
+#define OMAP4_RM_RSTST 0x0004
+#define OMAP4_RM_RSTTIME 0x0008
#define OMAP4_PM_PWSTCTRL 0x
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git fixes
To get two hwspinlock fixes from Axel.
There was a third, module.h split merge-related fix from Axel that I
dropped because I saw Paul picked it up in his pull request.
Thanks,
Ohad.
The
On Fri, 4 Nov 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [111006 16:33]:
Hi Tony,
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26
17:50:37 -0700)
are available
On Fri, 4 Nov 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [111010 17:09]:
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26
17:50:37 -0700)
are available in the git
93 matches
Mail list logo
