On Fri, 4 Nov 2011, Tony Lindgren wrote:
> * Paul Walmsley [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 reposi
On Fri, 4 Nov 2011, Tony Lindgren wrote:
> * Paul Walmsley [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
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 followi
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
#defi
On Tue, Nov 8, 2011 at 11:58 AM, Govindraj.R 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 function)
> make[1]
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
Signed-off-by
/* 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_RS
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
From: Ming Lei
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 `amba_release_regions'
From: Ming Lei
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: *** [arch/arm/mach-omap2] Error 2
make
Hi Philip,
On Fri, Nov 4, 2011 at 7:48 PM, Philip Balister wrote:
> On 11/03/2011 03:25 PM, Tony Lindgren wrote:
>> * James [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 via the GPMC bus on my
Hi Vishwa,
Vishwanath BS 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 tested this on OMAP3
* Tony Lindgren [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:
>
> http://marc.info/?l=linux-arm-kernel&m=13206990481711
* Russell King - ARM Linux [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 [07 13:12]:
> > > > * Russell King - ARM Linux [07 12:54]:
> > > > > Arnd,
> > >
* Russell King - ARM Linux [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 additional initializ
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 [07 13:12]:
> > > * Russell King - ARM Linux [07 12:54]:
> > > > Arnd,
> > > >
> > > > Don't pull this - there's yet more crap in
On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote:
> * Tony Lindgren [07 13:12]:
> > * Russell King - ARM Linux [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
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-kernel&m=132069904817116&w=2
With one additional fix for cpuidle export.h
* Tony Lindgren [07 13:12]:
> * Russell King - ARM Linux [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
Tero Kristo 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 re-routed this way
* Kevin Hilman [07 15:23]:
> The CPUidle use THIS_MODULE, so needs
>
> Signed-off-by: Kevin Hilman
> ---
> Tony, one more for omap/fixes. This one applies to Linus' master branch,
> but also applies to your current omap/fixes.
Thanks, applying into fixes. Looks like I did not grep for TH
The CPUidle use THIS_MODULE, so needs
Signed-off-by: Kevin Hilman
---
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 insertions(+), 0 deletions(-)
diff --git
* Russell King - ARM Linux [07 14:41]:
> On Mon, Nov 07, 2011 at 03:07:28PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [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
> >
On Mon, Nov 07, 2011 at 03:07:28PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [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 che
* Russell King - ARM Linux [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 in your git tree
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 th
* Russell King - ARM Linux [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 so ever on
"Mahaveer, Vishal" 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
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
* Russell King - ARM Linux [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 folk before this p
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2
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 unsubscr
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
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: _regist
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 om
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 http://vger.kernel.org/major
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
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 even
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 MU
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 w
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2
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 arch/arm
* Axel Lin [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 defaults to 'int'
* Igor Grinberg [06 04:45]:
> Hi Tony,
>
> On 11/05/11 01:57, Tony Lindgren wrote:
> > * Tony Lindgren [04 16:05]:
> >> * Igor Grinberg [111019 02:05]:
> >>
> >> Applying to board branch for v3.3 merge window.
> >
> > Hmm, actually I suggest you respin patches 2 and 3 so they apply
> >
Tomi,
* Russell King - ARM Linux [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: warning: parameter
Vaibhav Hiremath 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
> ---
> NOTE: This
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
"Mahaveer, Vishal" 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 reg
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
>>
>> Reported by Russell King:
>> mmcblk0: error -84 transferring data, sector 149201, nr 64,
>> cmd response 0x900, card status 0xb00
>> mmcblk0: retrying
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 solv
On Mon, Nov 07, 2011 at 09:55:11PM +0530, Balaji T K wrote:
> From: Per Forlin
>
> 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
Hi,
On Fri, Nov 4, 2011 at 6:27 PM, Kevin Hilman 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);
>> - cl
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 on
* Hiremath, Vaibhav [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-
> > ker...@lists.infradead.org; Mo
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
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
1 files cha
* Russell King - ARM Linux [07 09:12]:
> On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [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 breaki
Hi,
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [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 fata
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [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 bui
On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux
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. The OMAP workflow
* Russell King - ARM Linux [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.
> >
> > Updated pa
* Russell King - ARM Linux [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 is totally broken.
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 li
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
---
MAINTAINERS |3 +++
1 file changed, 3 insert
From: Per Forlin
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 tries to free DMA mem
> -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] arm:o
Adding linux-omap and linux-davinci lists
Jean Delvare 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 is ten bit
> -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)
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
---
NOTE: This patch has been tested on OMAP3EVM, and I
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 Hi
> -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, No
On 11/7/2011 1:59 PM, Shilimkar, Santosh wrote:
On Mon, Nov 7, 2011 at 6:08 PM, Govindraj.R 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 Ton
On Mon, Nov 7, 2011 at 3:58 PM, Hiremath, Vaibhav 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 line "unsubscri
> -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, No
On Mon, Nov 7, 2011 at 2:58 PM, Vaibhav Hiremath 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 majord...@vger.kernel.org
On Fri, Nov 4, 2011 at 10:10 PM, Kevin Hilman wrote:
> Tarun Kanti DebBarma 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, during system operation as
> -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
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 Nayak
> Cc: Gina Glaser
> ---
> arch/arm/mach-omap2/prm44xx.
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 '__hwspin_
On Mon, Nov 7, 2011 at 6:08 PM, Govindraj.R 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.
http://www.spinics.
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
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
On Fri, Nov 4, 2011 at 10:23 PM, Kevin Hilman wrote:
> Tarun Kanti DebBarma writes:
>
>> From: Nishanth Menon
>>
>> GPIO IP revisions such as those used in OMAP4 have a set_dataout
>> while the previous revisions used a single dataout register.
>> Depending on what is available restore the datao
On Fri, Nov 4, 2011 at 10:27 PM, Kevin Hilman wrote:
> Tarun Kanti DebBarma writes:
>
>> From: Nishanth Menon
>>
>> GPIO debounce registers need to be saved and restored for proper functioning
>> of driver.
>
> OK.
>
>> To save the registers, we cannot cut the clock before the save,
>> hence mov
On Fri, Nov 4, 2011 at 10:43 PM, Kevin Hilman wrote:
> Tarun Kanti DebBarma 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.
>>
>> Signed-off-by: Charul
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
Cc: Gina Glaser
---
arch/arm/mach-omap2/prm44xx.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
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 hardw
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
---
arch/arm/plat-omap/dma.c | 10
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
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 posi
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_w
On Mon, 7 Nov 2011 08:10:45 +0200
Felipe Balbi 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():
>
On Sat, Nov 5, 2011 at 4:30 AM, Kevin Hilman wrote:
> "Govindraj.R" 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 the id and use the custo
On Sat, Nov 5, 2011 at 3:30 AM, Kevin Hilman wrote:
> "Govindraj.R" 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
>
> This one needs a minor update for current mainline..
93 matches
Mail list logo
