a crash on boot with
CONFIG_RTC_DRV_OMAP=y with v3.8-rc5.
Signed-off-by: Hebbar Gururaja
Cc: Koen Kooi
[p...@pwsan.com: noted Koen's test in the patch description]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/cm33xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/
them.
This patch is a prerequisite for a subsequent patch, 'ARM: OMAP2:
am33xx-hwmod: Fix "register offset NULL check" bug'. That patch would
otherwise attempt to read from reserved bits.
Signed-off-by: Hebbar Gururaja
[p...@pwsan.com: add some more explanation in the patch
Hi,
On Thu, 31 Jan 2013, Tero Kristo wrote:
> Personally I don't like too much to have just extra spam during boot,
> which in many cases is even unnecessary (e.g. people who actually have
> good u-boot in use.)
The impact of two or three informative lines sent to the kernel console on
boot is
Hi Tero et al.,
On Tue, 22 Jan 2013, Paul Walmsley wrote:
> As we've discussed, there are known bootloader dependencies with the OMAP4
> PM retention idle code, introduced in v3.8. Boards booted with u-boot
> versions even as recent as 2011 won't enter retention idle correc
On Wed, 30 Jan 2013, Hebbar Gururaja wrote:
> am33xx_cm_wait_module_ready() checks if register offset is NULL.
>
> int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
> {
> int i = 0;
>
> if (!clkctrl_offs)
> return 0;
>
> In case of AM33xx, CLKCTRL
On Wed, 30 Jan 2013, Hebbar, Gururaja wrote:
> On Thu, Dec 20, 2012 at 13:05:27, Paul Walmsley wrote:
> > On Thu, 20 Dec 2012, Hebbar, Gururaja wrote:
> >
> > > On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
> > >
> > > > We've got a f
powerdomain trace integration
Paul Walmsley (13):
ARM: OMAP2xxx: powerdomain: core powerdomain missing logic retention
states
ARM: OMAP3xxx: CPUIdle: simplify the PER next-state code
ARM: OMAP3xxx: CPUIdle: optimize __omap3_enter_idle()
ARM: OMAP4: MPUSS PM: remove unnecessary shim
. . 3730beaglexm omap2plus_defconfig
16k -16k . . 37xxevmomap2plus_defconfig
16k -16k . . 4430es2panda omap2plus_defconfig
16k -16k . . 4460pandaesomap2plus_defconfig
16k -16k . . cmt3517omap2plus_defconfig
Paul
Hi
(redacted some context)
On Wed, 12 Dec 2012, Jean Pihet wrote:
> On Sun, Dec 9, 2012 at 6:53 PM, Paul Walmsley wrote:
>
> +/**
> > + * _match_pwrst: determine the closest supported power state
> > + * @pwrsts: list of allowed states, defined as a bitmask
> > +
Hi
On Wed, 12 Dec 2012, Jean Pihet wrote:
> On Sun, Dec 9, 2012 at 2:23 AM, Paul Walmsley wrote:
>
> > Add a per-powerdomain spinlock. Use that instead of the clockdomain
> > spinlock. Add pwrdm_lock()/pwrdm_unlock() functions to allow other
> > code to acquire or
Hi,
(redacted irrelevant code sections)
On Wed, 12 Dec 2012, Jean Pihet wrote:
> On Sun, Dec 9, 2012 at 2:23 AM, Paul Walmsley wrote:
>
> > -/**
> > - * pwrdm_set_lowpwrstchange - Request a low power state change
> > - * @pwrdm: struct powerdomain *
> > - *
&
Hi
On Fri, 25 Jan 2013, Mohammed, Afzal wrote:
> On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> > On Wed, 23 Jan 2013, Afzal Mohammed wrote:
>
> > > Currently round rate function would return proper rate iff requested
> > > rate exactly matches the
Here are some basic OMAP test results for Linux v3.8-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc5/20130126003323/
Test summary
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37
Remove some clocks that don't appear to be used by anything
and which are not associated with any hardware registers.
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/cclock2420_data.c | 16 +---
arch/arm/mach-omap2/cclock2430_data.c |
ot Tested on both Panda and Panda-es.
>
> Signed-off-by: J Keerthy
> Reviewed-by: Rajendra Nayak
> Cc: Paul Walmsley
> Cc: Eduardo Valentin
While I agree with this patch, my understanding is that Tony wishes to
shift to list-based initialization for clocks, similar to how the hwmod
On Tue, 22 Jan 2013, Afzal Mohammed wrote:
> am335x does not have freqsel, avoid it.
>
> Signed-off-by: Afzal Mohammed
Thanks, queued for 3.9.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo in
Hi,
On Thu, 24 Jan 2013, Bedia, Vaibhav wrote:
> Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or
> just skip earlyprintk option in the bootargs for now?
I'll give this a try over the next few days.
If EARLY_PRINTK is known to be broken for DT boots, could you please pu
Hello Jan,
On Tue, 22 Jan 2013, Jan Lübbe wrote:
> Just a guess, but there can be problems when the appended DTB crosses an
> 1MB boundary. See this mail for details and a patch:
> http://www.spinics.net/lists/arm-kernel/msg216898.html
Thanks for the suggestion. That patch didn't fix it for me.
Hi
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
> Currently round rate function would return proper rate iff requested
> rate exactly matches the PLL lockable rate. This causes set_rate to
> fail if exact rate could not be set. Instead round rate may return
> closest rate possible (less than the re
On Fri, 25 Jan 2013, Rajendra Nayak wrote:
> dpll_usb needs the clkdm association so the clkdm can be
> turned on before a relock. All other dplls for omap4 belong
> to the ALWON (always on) domain.
>
> The association was present as part of the older data file
> (clock44xx_data.c) but looks like
On Fri, 25 Jan 2013, Aaro Koskinen wrote:
> There is a long-standing bug that OHCI USB host controller does
> not respond on 1710, because of wrong clock definitions. See e.g.
> http://marc.info/?l=linux-omap&m=119634441229321&w=2. All register reads
> return just zeroes:
Thanks, queued for v3.8-
On Mon, 21 Jan 2013, Laurent Pinchart wrote:
> OK. The omap3isp patch can go through Paul's tree as well, it won't conflict
> with other changes to the driver in this merge window.
>
> Paul, can you take both patches together ? If so I'll send you a pull request.
Yes I'll take them, as long as
Hi
On Thu, 10 Jan 2013, Peter Korsgaard wrote:
> >>>>> "Paul" == Paul Walmsley writes:
>
> Paul> Probably the DTS is the right place, since this is a board- and
> Paul> bootloader-specific quirk. The original intention was to allow
> Paul>
people expect PM to work correctly with their existing bootloaders. The
least we can do for them is warn them that problems exist.
This should take priority over any new features.
- Paul
-- Forwarded message --
Date: Mon, 7 Jan 2013 18:40:02 + (UTC)
From: Paul Walmsley
To:
Hi Matthieu,
On Wed, 16 Jan 2013, Paul Walmsley wrote:
> On Wed, 16 Jan 2013, Matthieu CASTET wrote:
>
> > Paul Walmsley a écrit :
> > > On Wed, 2 Jan 2013, Matthieu CASTET wrote:
> >
> > > which did not get merged because Tony requested that it
Hi guys,
Regarding the AM33xx test failures with appended DTBs, it would be very
helpful if especially the TI people could try reproducing the problem.
Otherwise it's going to cause problems with merging any new AM33xx
patches, since I won't be able to test them without additional work.
Plus,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
tags/oma
On Fri, 18 Jan 2013, Sebastien Guiriec wrote:
> Paul, Benoit,
>
> Any comments before I resend the serie with the minor comment for Felipe?
Not from me. The series has been queued for 3.9 with Felipe's comment
fix; thanks Felipe.
- Paul
From: Paul Walmsley
Date: Sun, 20 Jan
platform_device creation code has been removed, as it
appears to be unused.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/am35xx-emac.c |2 +-
arch/arm/mach-omap2/devices.c | 25 +-
arch/arm/mach-omap2/display.c |2 +-
arch/arm/mach-omap2/dma.c
Here are some basic OMAP test results for Linux v3.8-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/
Test summary
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37
;
Fix this by adding back calls to omap2xxx_clkt_vps_late_init() in the
OMAP2420 and OMAP2430 clock initialisation code.
Signed-off-by: Jon Hunter
[p...@pwsan.com: dropped the duplicated call to
omap2xxx_clkt_vps_check_bootloader_rates() after consultation with Jon;
updated patch description]
Signed-off-by
Hi Jon,
On Thu, 17 Jan 2013, Jon Hunter wrote:
> Yes I still see it. You don't see it on reboot?
Ah that's probably explains the discrepancy - I missed the part about the
reboot.
> The reason why there is such a large number is because
> omap2_round_to_table_rate() is returning the value -EINV
Hi Mark
On Tue, 8 Jan 2013, Mark A. Greer wrote:
> Sorry to nag but I think the comment needs to be updated to remove the
> sentence about the missing EMAC hwmod.
You are absolutely right, and the correction is very much appreciated.
Updated patch follows.
- Paul
From: Paul Walmsley
Hi Mark,
I regret the delay,
On Tue, 8 Jan 2013, Mark A. Greer wrote:
> On Sun, Dec 23, 2012 at 08:40:43AM +0000, Paul Walmsley wrote:
>
> > - The patch series causes AM3517/3505 to crash. I'd guess this is due to
> > the SHAM/AES modules being initialized on those c
Hi Jon
On Thu, 10 Jan 2013, Jon Hunter wrote:
> During the migration to the common clock framework, calls to the
> functions omap2xxx_clkt_vps_late_init() and
> omap2xxx_clkt_vps_check_bootloader_rates() were not preserved for
> OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and
>
Hi Péter,
On Tue, 15 Jan 2013, Peter Ujfalusi wrote:
> On 01/14/2013 06:59 PM, Paul Walmsley wrote:
> > Failing tests: needing investigation
> >
> >
> > Build tests:
> >
> > * rmk_3430_ldp_allnoconfig, rmk_4430_
On Mon, 14 Jan 2013, Aaro Koskinen wrote:
> N900 boot is unstable again, I2C issues are back.
>
> Boot succeeds and fails randomly. Let's see if this can be bisected.
> The same kernel works on N950.
Thanks, I've added a section about this to the v3.8-rc3 test summary.
- Paul
--
To unsubscribe
Hi Matthieu,
On Wed, 16 Jan 2013, Matthieu CASTET wrote:
> Paul Walmsley a écrit :
> > On Wed, 2 Jan 2013, Matthieu CASTET wrote:
>
> > which did not get merged because Tony requested that it should be
> > based on top of his cleanup work (which takes
Here are some basic OMAP test results for Linux v3.8-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc3/20130109222058/
Test summary
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37
On Thu, 10 Jan 2013, Nishanth Menon wrote:
> Tested on AM335x A5 rev of bone board:
> Could be older u-boot build. booting to ramdisk seems to work on rc2 and
> 3 (with omap2plus_defconfig)
> http://www.hastebin.com/demafogebe.coffee
>
> Comes up to ramdisk at least.
Thanks Nishanth, will add a
Here are some basic OMAP test results for Linux v3.8-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc2/20130103093341/
- Paul
Test summary
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beag
On Sun, 30 Dec 2012, Paul Walmsley wrote:
> However, for some reason, we don't have an EMAC hwmod -- probably some
> bug in the data -- so set the flag on the MDIO hwmod data instead.
Mark and I discussed this in private E-mail. Looks like I managed to
confuse AM33xx and AM3517
OMAP3+:
> hwmod: Add AM33XX HWMOD data). Anybody care to ack this one?
Acked-by: Paul Walmsley
- Paul
--
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-info.html
Hi,
On Sun, 6 Jan 2013, madhusudhan.go...@elektrobit.com wrote:
> Could someone point me if it has been working in any of the releases ?
Serial wakeup from retention suspend seems to work on the OMAP4460
Panda-ES here as of v3.8-rc1, with a really recent U-boot[*]:
http://www.pwsan.com/omap/t
Hi
On Fri, 4 Jan 2013, Sebastien Guiriec wrote:
> Paul,
> Do you want me to rebase this version and update the serie or are you handle
> it?
Sure, it would be great if you could take this over and test it and
repost.
You might find the 'aess_reset_devel_3.9' branch at
git://git.pwsan.com/linu
Hi Sebastien
On Fri, 4 Jan 2013, Sebastien Guiriec wrote:
> The AESS on OMAP4 has additional register on top of SYS_CONFIG for
> auto gatting configuration. In order to avoid running clock after
> boot up we should avoid to enable and reset the module during boot up.
>
> Audio driver will be in
Hi Sebastien
On Fri, 4 Jan 2013, Sebastien Guiriec wrote:
> Rename HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
> dependent on an off-chip functional clock that is not guaranteed to
> be present during initialization. Same flag can be use for IP with
> additional HW registers to
On Fri, 4 Jan 2013, Peter Ujfalusi wrote:
> On 01/04/2013 04:10 PM, Jon Hunter wrote:
> >
> > On 01/04/2013 04:09 AM, Peter Ujfalusi wrote:
> >> To avoid issues with audio caused by non locked ABE DPLL we should
> >> make sure it is locked in all OMAP4 revisions.
> >>
> >> Signed-off-by: Peter Uj
On Thu, 3 Jan 2013, Jon Hunter wrote:
> I am not sure that this change to the comment is completely accurate. On
> OMAP4430 I did not see any issues with the DPLL failing to turn on if
> the DPLL was not locked. I only saw this particular problem on the 4460.
> Therefore, it may be better to leave
Hi Péter
On Thu, 3 Jan 2013, Peter Ujfalusi wrote:
> I have noticed that in 3.8-rc2 kernel OMAP4 audio is not working correctly.
> The
> audio playback is in 'slow motion' mode.
> The following two patch fixes this regression.
>
> We need to lock the ABE DPLL for all OMAP4 revisions not only fo
Hi
On Wed, 2 Jan 2013, Matthieu CASTET wrote:
> I put a warning in order we fix drivers instead of a silent failure.
>
> The omap driver was fixed in the same series with
> http://article.gmane.org/gmane.linux.ports.arm.omap/88551 and
... which got merged by Artem.
> http://article.gmane.org/g
: PRM: Correct wrong instance usage for reading reset sources
Jon Hunter (1):
ARM: OMAP3: clock data: Add missing enable/disable for EMU clock
Nishanth Menon (1):
ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets
Paul Walmsley (4):
ARM: OMAP: 32k counter: resolve sparse warnings
Hi
On Tue, 1 Jan 2013, Tony Lindgren wrote:
> For the plat-omap code it's OK to include for multiplatform
> builds. Other than that looks good to me.
Okay sounds good; an updated pull request is on the way.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
th
ted patch follows.
- Paul
From: Paul Walmsley
Date: Fri, 28 Dec 2012 02:09:15 -0700
Subject: [PATCH] ARM: OMAP: SRAM: resolve sparse warnings
Commit bb77209432873214a796a70a4539e4ebdf3feb54 ("ARM: OMAP: Move
omap2+ specific parts of sram.c to mach-omap2") adds some new sparse
warnings:
arc
Hi,
On Tue, 1 Jan 2013, Tony Lindgren wrote:
> Here it's OK to include for multiplatform builds
> as the path will be included in plat-omap/Makefile.
Thanks for the clarification; the patch has been updated as follows.
- Paul
From: Paul Walmsley
Date: Mon, 10 Dec 2012 11:
Hi
On Mon, 31 Dec 2012, Santosh Shilimkar wrote:
> This is more of question. If the limitation is w.r.t MPU power
> state then shouldn't we just prevent the MPU power state rather
> than blocking the WFI completely.
>
> Can you please clarify if retaining MPU power state in ON can achieve
> the
approach was needed.
Signed-off-by: Paul Walmsley
Cc: Mark A. Greer
---
Applies after the WFI cleanup series -- intended for a post-cleanup fixes
pull request or a new feature pull request.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
d
roblems down in the future seems quite small, we'll provide a
flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c |8
arch/arm/mach-omap2/omap_hwmod.h |9 +
2 files changed, 17 insertions(+
.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |7 ++-
arch/arm/mach-omap2/pm24xx.c | 13 -
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach
This series implements a hwmod flag that can be set on OMAP IP blocks
to indicate that the MPU should not be allowed to enter WFI when the
IP blocks are active. It also drops what appears to be unnecessary
SRAM code used by the OMAP2xxx PM code, using an inline WFI instead.
- Paul
---
Paul
ectly from the mach-omap2/pm24xx.c code. This removes some
unnecessary SRAM code.
Signed-off-by: Paul Walmsley
Cc: Richard Woodruff
Cc: Kevin Hilman
---
arch/arm/mach-omap2/pm24xx.c|9 +++--
arch/arm/mach-omap2/sleep24xx.S | 19 ---
2 files changed, 3 insertions(+
platform_device creation code has been removed, as it
does not appear to be used.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/am35xx-emac.c |2 +-
arch/arm/mach-omap2/devices.c | 25 +-
arch/arm/mach-omap2/display.c |2 +-
arch/arm/mach-omap2/dma.c
and RSTST offsets
Paul Walmsley (4):
ARM: OMAP: 32k counter: resolve sparse warnings
ARM: OMAP AM33xx: hwmod data: resolve sparse warnings
ARM: OMAP: SRAM: resolve sparse warnings
ARM: OMAP2/3: PRM: fix bogus OMAP2xxx powerstate return values
arch/arm/mach-omap2
Here are some basic OMAP test results for Linux v3.8-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/
Test summary
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37
On Wed, 26 Dec 2012, Bedia, Vaibhav wrote:
> In case of AM33xx, this flag should be set for PER and WKUP pwrdms also.
> EMIF, L3, L4 etc come under PER so this domain can't transition on an active
> system. PRCM and Control module come under WKUP, so the WKUP should the kernel
> should attempt to
tatic?
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:2526:26: warning: symbol
'am33xx_cpgmac0__mdio' was not declared. Should it be static?
Fix by marking the two new records as static.
Signed-off-by: Paul Walmsley
Cc: Mugunthan V N
Cc: Vaibhav Hiremath
Cc: Peter Korsgaard
Cc: Richar
atic?
Fix by adding a temporary header file, needed until the 32k counter
code is moved to drivers/.
arch/arm/plat-omap/include/plat/counter-32k.h can't be added due to
ARM CONFIG_ARCH_MULTIPLATFORM restrictions on the use of the "plat/"
include path shortcut.
Signed-off-by: Paul
- needed until the SRAM code is moved to
drivers/. arch/arm/plat-omap/include/plat/sram.h can't be added due
to ARM CONFIG_ARCH_MULTIPLATFORM restrictions on the use of the "plat/"
include path shortcut.
Signed-off-by: Paul Walmsley
Cc: Tony Lindgren
---
arch/arm/plat-
Paul
---
sparse_fixes_a_3.8-rc
textdata bss dec hex filename
7697036 722268 5614832 14034136 d624d8 vmlinux.omap2plus_defconfig.orig
7697036 722268 5614832 14034136 d624d8 vmlinux.omap2plus_defconfig
Paul Walmsley (3):
ARM: OMAP: 32k counter: resolve sparse warnings
ARM:
Hi
On Mon, 3 Dec 2012, Artem Bityutskiy wrote:
> On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
> > - NAND_CMD_READID want an address that it is not scaled on x16 device (it
> > is always 0x20)
> > - NAND_CMD_PARAM want 8 bits data
> >
> > Signed-off-by: Matthieu CASTET
>
> Pushed
Hi Peter,
On Fri, 21 Dec 2012, Peter Korsgaard wrote:
> On a custom am335x board I was surprised to see the kernel resetting
> gpio pins not mentioned anywhere in the dts.
The original plan with DT was to start by focusing on devices on the
board, rather than devices on the SoC. The GPIO is an
#x27;:
> drivers/watchdog/omap_wdt.c:299:19: warning: unused variable 'res'
> [-Wunused-variable]
>
> Signed-off-by: Aaro Koskinen
Reviewed-by: Paul Walmsley
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message
On Sun, 9 Dec 2012, Paul Walmsley wrote:
> in case anyone is interested in trying out the recent powerdomain & PM
> changes, posted for 3.9, there's a temporary branch
> "TEST_pwrdm_post_fpwrst_devel_a_3.9" in the git tree
> git://git.pwsan.com/linux-2.6.
Hi Mark,
On Fri, 21 Dec 2012, Mark A. Greer wrote:
> From: "Mark A. Greer"
>
> [This series supersedes the hwmod related patches sent in the
> "crypto: omap-sham updates" and "crypto: omap-aes updates"
> series a few weeks ago.]
>
> This series adds hwmod support for the OMAP SHAM and AES
>
On Thu, 20 Dec 2012, Paul Walmsley wrote:
> On Thu, 20 Dec 2012, Adrien Ferré wrote:
>
> > The tests have been running for 6 days now and we had only one failing BBxm
> >
> > There are five boards:
> >
> > 2 panda: high network + usb traffic
> > 3 bbxm
(cc Tero)
Hi,
On Thu, 20 Dec 2012, Sasha Levin wrote:
> With the current code, the condition in the if() doesn't make much sense due
> to
> precedence of operators.
>
> Signed-off-by: Sasha Levin
> ---
> drivers/mmc/host/omap_hsmmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Thu, 20 Dec 2012, Jon Hunter wrote:
> The ETM/ETB drivers for OMAP3, enable the emu_src_ck clock in order
> to access the ETM/ETB hardware. The emu_src_ck should enable the EMU
> clock domain so that the ETM/ETB hardware is accessible. However,
> currently when enabling the emu_src_ck the EMU c
On Wed, 19 Dec 2012, Jon Hunter wrote:
> My understanding is that for OMAP4 devices, the core power domain may
> not be active the same time as the MPU power domain. The Cortex-A9 has
> the ability to access some peripherals (such as timer, McBSP) via a
> private bus that does not require the core
Hi Adrien
On Thu, 20 Dec 2012, Adrien Ferré wrote:
> The tests have been running for 6 days now and we had only one failing BBxm
>
> There are five boards:
>
> 2 panda: high network + usb traffic
> 3 bbxm: high network + usb traffic
Nice; is that with (443, 12) or (480, 13) ?
- Paul
On Thu, 20 Dec 2012, Hebbar, Gururaja wrote:
> On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
>
> > We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers
> > listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST.
&
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
> To read reset sources registers we have to use PRM_DEVICE_INST
>
> Signed-off-by: Ivan Khoronzhuk
Thanks, queued for v3.8-rc fixes.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord.
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
> From: Nishanth Menon
>
> RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
> OMAP4460.
>
> Signed-off-by: Nishanth Menon
> [ivan.khoronz...@ti.com: ported from k3.4]
> Signed-off-by: Ivan Khoronzhuk
Thanks guys, queued for v3.8-rc f
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
> In the map for reset sources register we use defines intended for
> using with PRM_RSTCTRL register. So fix it.
>
> Signed-off-by: Ivan Khoronzhuk
Thanks, queued for v3.8-rc fixes.
- Paul
--
To unsubscribe from this list: send the line "unsubscrib
On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
> Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes
> is triggering a BUG()
...
> [0.109688] Security Framework initialized
> [0.109889] Mount-cache hash table entries: 512
> [0.112674] BUG: spinlock bad magic on C
On Tue, 18 Dec 2012, Hebbar Gururaja wrote:
> From: "Hebbar, Gururaja"
>
> omap4_cminst_wait_module_ready() checks if register offset is NULL.
>
> int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
> u16 clkctrl_offs)
> {
> int i = 0;
>
>
Hi
On Mon, 10 Dec 2012, herman...@totalbb.net.tw wrote:
> I implemented gas gauge driver by 1-Wire interface in OMAP4 CPU, the
> driver we used is a GPIO pin to simulate 1-Wire bus but it sometimes can't
> work well of timing issue. So we want to use HDQ/1Wire controller in OMAP4,
> does anyone h
clocks to reflect the original multiplexer name
as specified in the comments. And convert the hwmod data to use the
multiplexer clock name.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Mike Turquette
---
Seems to boot with omap2plus_defconfig, anyway.
arch/arm/mach-omap2
On Mon, 17 Dec 2012, Benoit Cousson wrote:
> It was done for legacy reason but should disappear once the modulemode
> will be be removed from the clock nodes.
Here's a start at taking care of the low-hanging fruit:
http://marc.info/?l=linux-omap&m=135577685007813&w=2
Only lightly tested, so tes
Hi
On Mon, 17 Dec 2012, Ivan Khoronzhuk wrote:
> In the map for reset sources register we use defines intended for
> using with PRM_RSTCTRL register. So fix it.
your changes look good, but they are missing Signed-off-by: lines. Could
you please either resend with those, or confirm that you int
P_MUX_GATE() blocks; the gate portion of
these should be removed
A similar process may also be possible on OMAP2/3.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Mike Turquette
---
It boots with omap2plus_defconfig, at least.
arch/arm/mach-omap2/cclock44xx_data.c
Hi
just a brief note that AM33xx has stopped booting in the testbed here with
a concatenated kernel+DTB after the following mainline commit:
commit d01e4afdbb65e030fd6f1f96c30a558e2eb0f279
Merge: 8287361 794b175
Author: Linus Torvalds
Date: Wed Dec 12 11:51:39 2012 -0800
Merge tag 'clea
tion table for non-M4X dplls
ARM: OMAP4: Enhance support for DPLLs with 4X multiplier
ARM: OMAP4460: Workaround ABE DPLL failing to turn-on
ARM: OMAP4: Fix EMU clock domain always on
Paul Walmsley (3):
ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider
Hi
On Mon, 17 Dec 2012, Ivan Khoronzhuk wrote:
> The address of PRM_RSTST register and flag mask are incorrect,
> so fix it.
>
> Signed-off-by: Ivan Khoronzhuk
arch/arm/mach-omap2/prcm.c no longer exists in current mainline; please
rebase this against Linus' current tree.
- Paul
--
To unsubs
Hi
On Mon, 17 Dec 2012, Ivan Khoronzhuk wrote:
> The flag mask are incorrect, so fix it.
>
> Signed-off-by: Ivan Khoronzhuk
arch/arm/mach-omap2/prcm.c no longer exists in current mainline; please
rebase this against Linus' current tree.
- Paul
--
To unsubscribe from this list: send the line
Hi
On Fri, 14 Dec 2012, Tony Lindgren wrote:
> Paul, what about this patch? Looks like you've acked the other clock
> patches in this series but not this one?
I commented on it briefly here:
https://patchwork.kernel.org/patch/1838111/
Maybe Benoît could comment here, but it looks to me (based
sel_recalc+0xf4/0x12c()
clock: div_iva_hs_clk: could not find fieldval 0 for parent dpll_core_m5x2_ck
Fix by converting the data for this clock to a power-of-two divider.
Signed-off-by: Paul Walmsley
Cc: Mike Turquette
---
arch/arm/mach-omap2/cclock44xx_data.c |6 +++---
1 file changed, 3 i
eries.
- Paul
---
Paul Walmsley (2):
ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider
ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent
lists
arch/arm/mach-omap2/cclock44xx_data.c | 37 +
1 file changed, 28 inser
the
DPLL parent lists.
Signed-off-by: Paul Walmsley
Cc: Mike Turquette
---
arch/arm/mach-omap2/cclock44xx_data.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
On Thu, 13 Dec 2012, Hiremath, Vaibhav wrote:
> On Thu, Dec 13, 2012 at 11:11:49, Paul Walmsley wrote:
> >
> > The branch name to use is:
> >
> > "TEST_pwrdm_post_fpwrst_devel_a_3.9"
>
> If I am correct, it only includes one additional pa
On Wed, 12 Dec 2012, Vaibhav Hiremath wrote:
> I am using your "paul-linux-pwrdm_post_fpwrst_devel_a_3.9" branch, where
> all the patches which you have posted are present (I believe so) and I
> am getting following sparse warning -
The branch name to use is:
"TEST_pwrdm_post_fpwrst_devel_a_3.9"
801 - 900 of 4899 matches
Mail list logo
