Re: [PATCH] Revert "ARM: dts: twl4030: Add iio properties for bci subnode"

[Kevin Hilman]

Hi Stephen,

On Fri, Nov 6, 2015 at 2:19 PM, Stephen Rothwell <s...@canb.auug.org.au> wrote:

> On Fri, 6 Nov 2015 10:36:34 -0800 Kevin Hilman <khil...@kernel.org> wrote:
>>
>> On Fri, Nov 6, 2015 at 8:13 AM, Sebastian Reichel <s...@kernel.org> wrote:
>> > This reverts commit af19161aaed7ff8d1a52b2e517460f2fa0774e32,
>> > which breaks the omap3 device tree build due to a wrong reference.
>> >
>> > I accidently queued this change via the power supply subsystem while
>> > telling Marek at the same time, that it should go through Tony's tree.
>> > Following that I did miss Stephen's messages about the build failure in
>> > linux-next and since he switched to merging an older snapshot nobody
>> > else noticed the problem in my tree. I didn't notice myself, since I
>> > did not build any device tree files assuming none have changed by me.
>> >
>> > Signed-off-by: Sebastian Reichel <s...@kernel.org>
>>
>> We also found this in kernelci.org build testing, and verified that
>> this fixes the build.
>>
>> Tested-by: Kevin Hilman <khil...@linaro.org>
>>
>> Thanks Felipe for reporting, and thanks Sebastian for the quick fix.
>
> I think "quick fix" is a bit rich.

You're right, sorry.  I didn't have the full context.  I wasn't fully
aware of the history in -next of this problem.  I just found it when
it ended up in mainline.  I don't think the problem was not getting
your emails, looks like the problem was a major disconnect between
what was sent to Linus and what was in -next. :(

Hopefully this snafu will help prevent that in the future,

Kevin
--
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

Re: [PATCH] Revert "ARM: dts: twl4030: Add iio properties for bci subnode"

[Kevin Hilman]

On Fri, Nov 6, 2015 at 8:13 AM, Sebastian Reichel <s...@kernel.org> wrote:
> This reverts commit af19161aaed7ff8d1a52b2e517460f2fa0774e32,
> which breaks the omap3 device tree build due to a wrong reference.
>
> I accidently queued this change via the power supply subsystem while
> telling Marek at the same time, that it should go through Tony's tree.
> Following that I did miss Stephen's messages about the build failure in
> linux-next and since he switched to merging an older snapshot nobody
> else noticed the problem in my tree. I didn't notice myself, since I
> did not build any device tree files assuming none have changed by me.
>
> Signed-off-by: Sebastian Reichel <s...@kernel.org>

We also found this in kernelci.org build testing, and verified that
this fixes the build.

Tested-by: Kevin Hilman <khil...@linaro.org>

Thanks Felipe for reporting, and thanks Sebastian for the quick fix.

Kevin
--
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

Re: [PATCH] ARM: OMAP2+: PM: Denote the cpuidle tracepoints as _rcuidle()

[Kevin Hilman]

Jisheng Zhang <jszh...@marvell.com> writes:

> The cpuidle tracepoints are called within a rcu_idle_exit() section, and
> must be denoted with the _rcuidle() version of the tracepoint.
>
> Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
 
Acked-by: Kevin Hilman <khil...@linaro.org>
--
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

Re: [GIT PULL] omap fixes against v4.3-rc1

[Kevin Hilman]

Tony Lindgren  writes:

> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>
>   Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v4.3/fixes-rc1
>
> for you to fetch changes up to 60fdcb8863d9b4a8b6c6b367886fadb50d4c0b07:
>
>   ARM: dts: Fixup model name for HP t410 dts (2015-09-14 13:33:47 -0700)
>
> 
> Fixes for omaps against v4.3-rc1:
>
> - Fix long time regression on beagle for tfp410 pin muxing
>
> - Fix dm814x control base address typo and related Ethernet
>   phy configuration
>
> - Fix igepv2 Ethernet pinmuxing as only some boards have it
>
> - Fix pbias regulator compatible values as a pending regulator
>   fix needs those for MMC1 to work properly
>
> - Fix beagle-x15 MMC1 regulator and make pcf857x built-in
>
> - Fix omap5 and dra7 Kconfig options when built as the only
>   SoCs selected
>
> - Fix PM errata for omap5 and dra7 as they too need it
>
> - Fix phycore mpu voltage
>
> Also included are a few cosmetic fixes:
>
> - Remove unused of_irq macros
>
> - Fix dra7 ethernet name
>
> 

Thanks, pulled into fixes.

Kevin
--
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

Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get

[Kevin Hilman]

On Tue, Sep 1, 2015 at 8:03 AM, Tony Lindgren  wrote:
> * Grygorii Strashko  [150901 07:57]:
>> On 09/01/2015 05:50 PM, Tony Lindgren wrote:
>> >>
>> >>On -next, Above crash signature could be related to race
>> >>"ARM: OMAP2+: omap-device: fix race deferred probe of omap_hsmmc vs 
>> >>omap_device_late_init"
>> >>http://www.spinics.net/lists/linux-omap/msg121622.html
>> >
>> >Good point thanks, yes that's the case. MMC probing fails and then we hit 
>> >this
>> >separate issue while MMC is trying to probe. Applying your fix makes the
>> >abort disappear, but naturally does not get MMC working again.
>>
>> you may need CONFIG_GPIO_PCF857X=y for dra7-evm
>
> This is a regression at least on omap4 as pointed out by Olof.

FWIW, this problem still exists in mainline[1], and note that it fails
for omap2plus_defconfig which already has CONFIG_REGULATOR_PBIAS=y, so
that is not the fix for this issue.

Kevin

[1] 
http://kernelci.org/boot/omap4-panda-es/?mainline_defconfig
--
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

Re: [GIT PULL] omap fixes for v4.3 merge window

[Kevin Hilman]

Tony Lindgren  writes:

> The following changes since commit 2faf962d90ca4c5ee7ba026b7351b1f74500bcdf:
>
>   Merge tag 'armsoc-defconfig' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2015-09-01 
> 13:17:43 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v4.3/fixes-merge-window
>
> for you to fetch changes up to 21b430d23d233c67e6589ea5054d18392e15a28e:
>
>   ARM: omap2plus_defconfig: Enable MUSB DMA support (2015-09-01 13:59:25 
> -0700)
>
> 
> Few omap bug fixes that have come up recently:
>
> - Fix deferred probe with omap_device idling unused devices
>
> - Fix booting if no timer parent can be set
>
> - Fix always true warning for vc register check
>
> And also two minor changes not strictly fixes:
>
> - Add SoC detection for dra752
>
> - Enable omap related MUSB DMA engines as we can now
>   build them all in finally
>
> 

Queuing this into fixes branch for v4.3-rc2.

Thanks,

Kevin
--
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

Re: [RESEND PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

[Kevin Hilman]

Kishon Vijay Abraham I  writes:

> PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
> OMAP5 and DRA7 SoCs. Enable it here.
>
> Signed-off-by: Kishon Vijay Abraham I 

Thanks, added to our next/late branch.

Kevin
--
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

Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

[Kevin Hilman]

On Wed, Sep 2, 2015 at 6:07 AM, Tony Lindgren <t...@atomide.com> wrote:
> * Neil Brown <n...@brown.name> [150901 23:23]:
>> Kevin Hilman <khil...@kernel.org> writes:
>>
>> > ping... this boot failure has now landed in mainline
>>
>> sorry, I'm on leave at the moment and travelling so I'm unlikely to be
>> able to look at this properly.  I should be able to examine this issue
>> before the end of the month but cannot promise sooner than that (though
>> it is not impossible).
>>
>> Maybe it would be best to just revert it until a proper analysis can be
>> done.
>
> OK yeah let's revert this one for now until we know what goes wrong.

Looks like this is still in mainline.

Tony, can you revert?

Kevin
--
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

Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

[Kevin Hilman]

ping... this boot failure has now landed in mainline

On Thu, Aug 27, 2015 at 1:51 PM, Kevin Hilman <khil...@kernel.org> wrote:
> On Wed, Jul 29, 2015 at 5:11 PM, NeilBrown <n...@brown.name> wrote:
>> Now that twl4030_bci_probe can safely return -EPROBE_DEFER,
>> do so when devm_usb_get_phy_by_node returns that error.
>>
>> Signed-off-by: NeilBrown <n...@brown.name>
>
> This patch has hit linux-next in the form of coommit 3fc3895e4fe1
> (twl4030_charger: correctly handle -EPROBE_DEFER from
> devm_usb_get_phy_by_node) and kernelci.org found a regression on
> omap3-beagle-xm[1].  Bisecting[2] this boot failure pointed at this
> commit, and I verified that reverting it on top of next-20150827 gets
> the board booting again.  I haven't debugged any further.
>
> Kevin
>
> [1] 
> http://storage.kernelci.org/next/next-20150827/arm-omap2plus_defconfig/lab-khilman/boot-omap3-beagle-xm.html
> [2] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/88/console
--
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

Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

[Kevin Hilman]

On Wed, Jul 29, 2015 at 5:11 PM, NeilBrown n...@brown.name wrote:
 Now that twl4030_bci_probe can safely return -EPROBE_DEFER,
 do so when devm_usb_get_phy_by_node returns that error.

 Signed-off-by: NeilBrown n...@brown.name

This patch has hit linux-next in the form of coommit 3fc3895e4fe1
(twl4030_charger: correctly handle -EPROBE_DEFER from
devm_usb_get_phy_by_node) and kernelci.org found a regression on
omap3-beagle-xm[1].  Bisecting[2] this boot failure pointed at this
commit, and I verified that reverting it on top of next-20150827 gets
the board booting again.  I haven't debugged any further.

Kevin

[1] 
http://storage.kernelci.org/next/next-20150827/arm-omap2plus_defconfig/lab-khilman/boot-omap3-beagle-xm.html
[2] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/88/console
--
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

Re: [PATCH 0/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 Ping, looks like these are still pending. Probably should be
 applied directly by the arm-soc maintainers.

If these should go through arm-soc, please resend to:a...@kernel.org so
they make it into our queue of stuff to be reviewed/applied.

Kevin
--
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

Re: [PATCH stable/v4.0] ARM: OMAP3: Fix booting with thumb2 kernel

[Kevin Hilman]

Hi Greg,

On Fri, Jul 10, 2015 at 10:28 AM, Kevin Hilman khil...@kernel.org wrote:
 From: Tony Lindgren t...@atomide.com

 We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

 Internal error: Oops: 8005 [#1] SMP THUMB2
 ...
 [c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
 (omap3_enter_idle_bm+0xc5/0x178)
 [c0024375] (omap3_enter_idle_bm) from [c0374e63]
 (cpuidle_enter_state+0x77/0x27c)
 [c0374e63] (cpuidle_enter_state) from [c00627f1]
 (cpu_startup_entry+0x155/0x23c)
 [c00627f1] (cpu_startup_entry) from [c06b9a47]
 (start_kernel+0x32f/0x338)
 [c06b9a47] (start_kernel) from [8000807f] (0x8000807f)

 The power management related assembly on omaps needs to interact with
 ARM mode bootrom code, so we need to keep most of the related assembly
 in ARM mode.

 Turns out this error is because of missing ENDPROC for assembly code
 as suggested by Stephen Boyd sb...@codeaurora.org. Let's fix the
 problem by adding ENDPROC in two places to sleep34xx.S.

 Let's also remove the now duplicate custom code for mode switching.
 This has been unnecessary since commit 6ebbf2ce437b (ARM: convert
 all mov.* pc, reg to bx reg for ARMv6+).

 And let's also remove the comments about local variables, they are
 now just confusing after the ENDPROC.

 The reason why ENDPROC makes a difference is it sets .type and then
 the compiler knows what to do with the thumb bit as explained at:

 https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

 Reported-by: Kevin Hilman khil...@kernel.org
 Tested-by: Kevin Hilman khil...@linaro.org
 Signed-off-by: Tony Lindgren t...@atomide.com
 (cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
 Cc: sta...@vger.kernel.org # v4.0+
 Signed-off-by: Kevin Hilman khil...@linaro.org

This  one seems to be missing in v4.0.9, though it was submitted ~10
days before.  I missed noticing it was not present in the stable queue
because I've been on vacation.

I know you mentioned you were wrapping up v4.0, but any chance of this
being included?

Thanks,

Kevin
--
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

Re: [PATCH 0/3] ARM: dts: Changes for Gumstix Pepper dts

[Kevin Hilman]

Arun Bharadwaj a...@gumstix.com writes:

 These 3 patches are included to fix the following issues
 with pepper device tree source. The patches are based against
 linux-omap/master.

I tested this series on top of linus/master with omap2plus_defconfig and
it seems to successfully boot now (used to hang after disabling
vdd_mpu.)

However, it still hangs during boot when testing with multi_v7_defconfig
(boot log below.)

Anyways, it's a step in the right direction.  Feel free to add 

Tested-by: Kevin Hilman khil...@linaro.org

Kevin


[1] full console log: linus/master, mutli_v7_defconfig + $SUBJECT series:

Connected to pepper console [channel connected] (~$quit to exit)
(user:khilman) is already connected


# PYBOOT: console: connected.
~$hardreset

Command(pepper console) hardreset
(user:khilman) Reboot pepper

U-Boot SPL 2014.10 (Feb 24 2015 - 21:56:40)
Booting with DDR
reading u-boot.img
reading u-boot.img


U-Boot 2014.10 (Feb 24 2015 - 21:56:40)

AM335X-GP rev 1.0
   Watchdog enabled
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   cpsw
Hit any key to stop autoboot:  1 

# PYBOOT: u-boot: taking control.
 0 
pepper# 
pepper# version
version

U-Boot 2014.10 (Feb 24 2015 - 21:56:40)
arm-poky-linux-gnueabi-gcc (GCC) 4.9.1
GNU ld (GNU Binutils) 2.24
pepper# if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
pepper# if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
pepper# setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
pepper# dhcp
dhcp
cpsw Waiting for PHY auto negotiation to complete... done
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.190 (322 ms)
pepper# setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
pepper# if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
pepper# tftp 0x8100 192.168.1.2:tmp/pepper-B3cJIV/zImage
tftp 0x8100 192.168.1.2:tmp/pepper-B3cJIV/zImage
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.1.2; our IP address is 192.168.1.190
Filename 'tmp/pepper-B3cJIV/zImage'.
Load address: 0x8100
Loading: *#
 #
 #
 #
 #
 #
 #
 2.8 MiB/s
done
Bytes transferred = 6146272 (5dc8e0 hex)
pepper# tftp 0x8200 192.168.1.2:tmp/pepper-B3cJIV/rootfs.cpio.gz
tftp 0x8200 192.168.1.2:tmp/pepper-B3cJIV/rootfs.cpio.gz
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.1.2; our IP address is 192.168.1.190
Filename 'tmp/pepper-B3cJIV/rootfs.cpio.gz'.
Load address: 0x8200
Loading: *#
 #
 #
 #
 #
 #
 2.7 MiB/s
done
Bytes transferred = 4956631 (4ba1d7 hex)
pepper#tftp 0x81f0 192.168.1.2:tmp/pepper-B3cJIV/tmpW6fNjj.dtb
 tftp 0x81f0 192.168.1.2:tmp/pepper-B3cJIV/tmpW6fNjj.dtb
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.1.2; our IP address is 192.168.1.190
Filename 'tmp/pepper-B3cJIV/tmpW6fNjj.dtb'.
Load address: 0x81f0
Loading: *###
 2.5 MiB/s
done
Bytes transferred = 33734 (83c6 hex)
pepper# printenv bootargs
printenv bootargs
## Error: bootargs not defined
pepper# bootz 0x8100 - 0x81f0

# PYBOOT: u-boot: jumping to kernel image
bootz 0x8100 - 0x81f0
Kernel image @ 0x8100 [ 0x00 - 0x5dc8e0 ]
## Flattened Device Tree blob at 81f0
   Booting using the fdt blob at 0x81f0
   Loading Device Tree to 8fff4000, end 83c5 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.2.0-rc2-00080-g9ea52aaed426 (khilman@paris) (gcc 
version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #6 SMP Tue Jul 14 05:13:16 PDT 
2015
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: Gumstix Pepper
[0.00] cma: Reserved 64 MiB at 0x9b80
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (sgx neon )
[0.00] PERCPU: Embedded 11 pages/cpu @dfaa4000 s14784 r8192 d22080 
u45056

[PATCH stable/v4.0] ARM: OMAP3: Fix booting with thumb2 kernel

[Kevin Hilman]

From: Tony Lindgren t...@atomide.com

We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)

The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.

Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's fix the
problem by adding ENDPROC in two places to sleep34xx.S.

Let's also remove the now duplicate custom code for mode switching.
This has been unnecessary since commit 6ebbf2ce437b (ARM: convert
all mov.* pc, reg to bx reg for ARMv6+).

And let's also remove the comments about local variables, they are
now just confusing after the ENDPROC.

The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:

https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
(cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
Cc: sta...@vger.kernel.org # v4.0+
Signed-off-by: Kevin Hilman khil...@linaro.org
---
 arch/arm/mach-omap2/sleep34xx.S | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index d1dedc8195ed..eafd120b53f1 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
 */
ldr r1, kernel_flush
blx r1
-   /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM.  Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb  )
- THUMB(.align  )
- THUMB(bx  pc  )
- THUMB(nop )
-   .arm
-
b   omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
 omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
 kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
  * ===
  */
ldmfd   sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
 sdrc_power:
.word   SDRC_POWER_V
 cm_idlest1_core:
-- 
2.4.5

--
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

Re: [GIT PULL] omap fixes against v4.2-rc1

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

   Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.2/fixes-rc1

 for you to fetch changes up to ae745302c0a3e2b5b768690f631fc14db44467e7:

   Merge branch 'fixes-rc1' into omap-for-v4.2/fixes (2015-07-06 05:33:17 
 -0700)

 
 Minor fixes for omaps against v4.2-rc1. Mostly just minor dts changes
 except for a GPMC fix to not use names for probing devices. Also a
 one liner clean-up to remove unecessary return from a void function.

 The summary for the changes being:

 - Fix probe for GPMC devices by reoving limitations based on device
   name

 - Remove unnecessary return from a void function

 - Revert beaglebone RTC sleep fix, we now have a better fix merged

 - Add am4372 EMIF node to fix a warning

 - Add am57xx-beagle-x15 power supply to fix USB2 if USB1 is disabled

 - Disable rfbi for am4372 as it does not have a driver

 

Pulled into fixes,

Thanks,

Kevin
--
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

Re: [GIT PULL] omap generic wakeirq for v4.2 merge window

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 Hi,

 * Tony Lindgren t...@atomide.com [150616 04:48]:
 Hi,
 
 Here's a late pull request that would be good to get into v4.2.
 This series mostly just drops code that's now unnecessary, and
 also fixes potential interrupt re-entrancy issues that the old
 handling has.
 
 The series changes omap hsmmc, 8250_omap and omap-serial to use
 the Linux generic wakeirq. I had to redo the branch last week on
 recent tty-next branch because of a merge conflict. Other than
 that, these patches were already in Linux next earlier.
 
 The pull request below also shows the related patches in Rafael's
 pm-wakeirq branch as I did not create a separate merge commit to
 base patches on.
 
 This branch depends on both Rafael's pm-wakeirq and Greg's
 tty-next, so it should be sent separately towards the end of the
 merge window.

 This one is OK to merge now, both pm-wakeirq and tty-next
 dependencies have been merged. This leaves the following
 diffstat for thees changes:

OK, thanks.  I'm collecting a few remaining things for a late branch,
but if I miss the merge window, I'll queue it up for -rc2.

Kevin
--
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

Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up

[Kevin Hilman]

On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
 wake_futex_pi() wakes the task before releasing the hash bucket lock
 (HB). The first thing the woken up task usually does is to acquire the
 lock which requires the HB lock. On SMP Systems this leads to blocking
 on the HB lock which is released by the owner shortly after.
 This patch rearranges the unlock path by first releasing the HB lock and
 then waking up the task.

 [bigeasy: redo ontop of lockless wake-queues]
 Signed-off-by: Thomas Gleixner t...@linutronix.de
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
 * Davidlohr Bueso | 2015-06-16 12:50:26 [-0700]:

I prefer having two separate patches, thus keeping their own changelog
for the change justification.

 okay, here it is on top of #1.

A handful of boot test failures on ARM/OMAP were found by kernelci.org
in next-20150619[1] and were bisected down to this patch, which hit
next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the
lock contention on the HB lock during wake up).  I confirmed that
reverting that patch on top of next-20150619 gets things booting again
for the affected platforms.

I haven't debugged this any further, but full boot logs are available
for the boot failures[2][3] and the linux-omap list and maintainer are
Cc'd here to help investigate further if needed.

Kevin

[1] http://kernelci.org/boot/all/job/next/kernel/next-20150619/
[2] 
http://storage.kernelci.org/next/next-20150619/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html
[3] 
http://storage.kernelci.org/next/next-20150619/arm-omap2plus_defconfig/lab-tbaker/boot-omap3-beagle-xm.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in

Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up

[Kevin Hilman]

Thomas Gleixner t...@linutronix.de writes:

 On Fri, 19 Jun 2015, Kevin Hilman wrote:
 On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior
 A handful of boot test failures on ARM/OMAP were found by kernelci.org
 in next-20150619[1] and were bisected down to this patch, which hit
 next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the
 lock contention on the HB lock during wake up).  I confirmed that
 reverting that patch on top of next-20150619 gets things booting again
 for the affected platforms.
 
 I haven't debugged this any further, but full boot logs are available
 for the boot failures[2][3] and the linux-omap list and maintainer are
 Cc'd here to help investigate further if needed.

 Found it. Dunno, how I missed that one. Fix below.


Yup, that fix on top of next-20150619 gets the two OMAP platforms
booting again.

Tested-by: Kevin Hilman khil...@linaro.org

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in

[PATCH stable/3.18.y] ARM: OMAP3: Fix booting with thumb2 kernel

[Kevin Hilman]

From: Tony Lindgren t...@atomide.com

We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)

The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.

Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's fix the
problem by adding ENDPROC in two places to sleep34xx.S.

Let's also remove the now duplicate custom code for mode switching.
This has been unnecessary since commit 6ebbf2ce437b (ARM: convert
all mov.* pc, reg to bx reg for ARMv6+).

And let's also remove the comments about local variables, they are
now just confusing after the ENDPROC.

The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:

https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
(cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
Cc: sta...@vger.kernel.org # v3.18+
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Sasha, please add to your v3.18.y-queue.  This one fixes boot failures
on several ARM/OMAP platforms when CONFIG_THUMB2_KERNEL=y.

 arch/arm/mach-omap2/sleep34xx.S | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index d1dedc8195ed..eafd120b53f1 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
 */
ldr r1, kernel_flush
blx r1
-   /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM.  Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb  )
- THUMB(.align  )
- THUMB(bx  pc  )
- THUMB(nop )
-   .arm
-
b   omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
 omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
 kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
  * ===
  */
ldmfd   sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
 sdrc_power:
.word   SDRC_POWER_V
 cm_idlest1_core:
-- 
2.3.1

--
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

Re: [GIT PULL 2/3] omap defconfig changes for v4.2

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.2/o2_dc

 for you to fetch changes up to 4cbb08336f506cde30c0dfb3e49c55a52842fb5c:

   ARM: omap2plus_defconfig: Enable TOUCHSCREEN_PIXCIR (2015-06-02 07:54:50 
 -0700)

 
 Few omap2plus_defconfig changes for v4.2 merge window:

 - Enable dm9000 as built-in for NFSroot

 - Enable dm816x USB phy as a loadable module

 - Enable Pixcir touch screen as a loadable module

 

Pulled into next/defconfig.

Thanks,

Kevin
--
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

Re: [GIT PULL 1/3] omap device tree changes for v4.2, part 2

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit 52dfcbfc94833b0192d439127ee9ff46023cdbb2:

   ARM: dts: am335x-evm: add mmc3 and wlan definitions to dts (2015-05-21 
 12:05:59 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.2/dt-pt2

 for you to fetch changes up to 8584d4fcabe2501e1c95b4d063cd4a76891d:

   ARM: dts: am335x-sl50: Add Toby-Churchill SL50 board support. (2015-05-28 
 09:49:50 -0700)

 
 Few more omap device tree changes for v4.2 merge window:

 - Add dm9000 Ethernet support to omap3-devkit8000

 - Add Toby-Churchill SL50 board support

 - Add vendor prefix for Toby Churchill Ltd

 

Pulled into next/dt.

Thanks,

Kevin
--
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

Re: [GIT PULL] omap fixes for v4.1, urgent fix to avoid potential hardware damage

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 Hi,

 Here's a pull request to fix potential hardware breaking configuration
 on BeagleBones. For the other fixes, apologies for these coming in so
 late, seems that people have been busy finding regressions.

 Regards,

 Tony


 The following changes since commit f25bf74c8862efdc30453d16d60cf22958a4873e:

   ARM: dts: Fix WLAN interrupt line for AM335x EVM-SK (2015-05-20 10:00:10 
 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.1/fixes-rc6

 for you to fetch changes up to 7a6cb0abe1aa63334f3ded6d2b6c8eca80e72302:

   ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage 
 (2015-06-01 12:48:23 -0700)

 
 Omap fixes for the -rc cycle, including a fix for potential hardware
 breakage on BeagleBones:

 - BeagleBones don't support RTC-only mode, it can cause hardware
   damage if system-power-controller is specified without
   ti,pmic-shutdown-controller

 - Fix a recent regression to am3517 SoCs caused by the recent clock
   move that was not noticed until now despite automated boot
   testing

 - Fix a regression for n900 touchscreen triggered by recent
   recent input changes

 - Fix compatible property for dm816x USB to avoid errors with
   USB Ethernet

 - Fix oops for omap3 when built with CONFIG_THUMB2_KERNEL


Thanks, applied to fixes. 

Kevin
--
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

Re: [RFC] Fix omap3 booting with thumb2 compiled kernel

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 * Kevin Hilman khil...@kernel.org [150527 15:20]:
 [ fix email for Dave Martin, +Tyler ]
 
 Tony Lindgren t...@atomide.com writes:
 
  The power management related assembly needs to interact with
  ARM mode bootrom code, so we need to keep most of the related
  assembly in ARM mode.
 
  Currently we are entering into and ARM mode assembly function
  from thumb2 mode, so we need to make sure we switch to ARM
  mode. And we need to do that again after the cache flush.
 
  ---
 
  Kevin told me about this earlier today.. 
 
 
 And for full boot log/panics, see the kernelci.org thumb2 kernel boots
 that fail: http://kernelci.org/boot/?THUMB2_KERNELfail
 
  Anybody got better ideas for a fix here?
 
 FWIW, a quick test of this patch makes my omap3-beagle-xm pass a simple
 boot test, but it fails with off idle.

 Thanks to Stephen Boyd's suggestion of checking the missing ENDPROC,
 here's a better fix :) Now off idle works too.

 Regards,

 Tony

 8 --
 From: Tony Lindgren t...@atomide.com
 Date: Wed, 27 May 2015 15:33:57 -0700
 Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel

 We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

 Internal error: Oops: 8005 [#1] SMP THUMB2
 ...
 [c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
 (omap3_enter_idle_bm+0xc5/0x178)
 [c0024375] (omap3_enter_idle_bm) from [c0374e63]
 (cpuidle_enter_state+0x77/0x27c)
 [c0374e63] (cpuidle_enter_state) from [c00627f1]
 (cpu_startup_entry+0x155/0x23c)
 [c00627f1] (cpu_startup_entry) from [c06b9a47]
 (start_kernel+0x32f/0x338)
 [c06b9a47] (start_kernel) from [8000807f] (0x8000807f)

 The power management related assembly on moaps needs to interact with
 ARM mode bootrom code, so we need to keep most of the related assembly
 in ARM mode.

 Turns out this error is because of missing ENDPROC for assembly code
 as suggested by Stephen Boyd sb...@codeaurora.org. Let's add the
 missing ENDPROC in two places to sleep34xx.S, and also remove the
 earlier mystery code that was probably also caused by missing ENDPROC
 for earlier kernels.

 Reported-by: Kevin Hilman khil...@kernel.org
 Signed-off-by: Tony Lindgren t...@atomide.com

Yup, boot test is now passing for me on omap3-beagle, omap3-beagle-xm,
omap3-n900, omap3-overo-tobi, omap3-overo-storm-tobi.

Tested-by: Kevin Hilman khil...@linaro.org

Thanks for the quick fix.

Next step is to look at the exynos4412-odroidu3 failure which probably
has a similar cause.

Kevin
--
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

Re: [RFC] Fix omap3 booting with thumb2 compiled kernel

[Kevin Hilman]

[ fix email for Dave Martin, +Tyler ]

Tony Lindgren t...@atomide.com writes:

 The power management related assembly needs to interact with
 ARM mode bootrom code, so we need to keep most of the related
 assembly in ARM mode.

 Currently we are entering into and ARM mode assembly function
 from thumb2 mode, so we need to make sure we switch to ARM
 mode. And we need to do that again after the cache flush.

 ---

 Kevin told me about this earlier today.. 


And for full boot log/panics, see the kernelci.org thumb2 kernel boots
that fail: http://kernelci.org/boot/?THUMB2_KERNELfail

 Anybody got better ideas for a fix here?

FWIW, a quick test of this patch makes my omap3-beagle-xm pass a simple
boot test, but it fails with off idle.

Kevin
--
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

Re: [PATCH 0/3] Introduce SET_NOIRQ_SYSTEM_SLEEP_PM_OPS and use it

[Kevin Hilman]

grygorii.stras...@linaro.org writes:

 From: Grygorii Strashko grygorii.stras...@linaro.org

 While working on suspend-to-disk functionality on TI dra7-evm (DRA7xx SoC)
 i've found that the most common problem I have to dial with is absence
 of corresponding PM callbacks in drivers and, in particular, noirq callbacks.
 So, I've fixed one driver first
 commit 6248015d6867 ARM: omap-device: add missed callback for 
 suspend-to-disk
 but then found another one which need to be fixed too (omap_l3_noc.c).
 At this moment I decided to make my life easier and added new macro
 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS using the same approach as for the existing
 SET_SYSTEM_SLEEP_PM_OPS macro.

 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS: defined for CONFIG_PM_SLEEP and
 assigns -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same
 function. Vice versa happens for -resume_noirq, -thaw_noirq and
 -restore_noirq.

 Further two patches reuse this newly introduced macro.

 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
 point -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same
 function. Vice versa happens for -resume_noirq, -thaw_noirq and
 -restore_noirq.

For the series:

Reviewed-by: Kevin Hilman khil...@linaro.org

And for the omap_device changes:

Acked-by: Kevin Hilman khil...@linaro.org

--
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

Re: [RFC 0/5] PM / clock_ops: provide default runtime ops and cleanup users

[Kevin Hilman]

Rajendra Nayak rna...@codeaurora.org writes:

 Most users of PM clocks do the exact same thing in runtime callbacks.

Probably because they were all copied from mach-davinci. ;)

 Provide default callbacks and cleanup the existing users 
 (keystone/davinci/omap1/sh)

Very nice cleanup, Thanks!

For the series:

Reviewed-by: Kevin Hilman khil...@linaro.org

Kevin
--
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

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Hi Andrew,

On Wed, Apr 1, 2015 at 2:54 PM, Kevin Hilman khil...@kernel.org wrote:
 Andrew Morton a...@linux-foundation.org writes:

 On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier marc.zyng...@arm.com wrote:

  -static int unmap_and_move(new_page_t get_new_page, free_page_t 
  put_new_page,
  -  unsigned long private, struct page *page, int force,
  -  enum migrate_mode mode)
  +static noinline int unmap_and_move(new_page_t get_new_page,
  + free_page_t put_new_page,
  + unsigned long private, struct page *page,
  + int force, enum migrate_mode mode)
   {
 int rc = 0;
 int *result = NULL;
 

 Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
 the parameters on the stack, which is not going to help performance
 either (not that this would be useful on 32bit ARM anyway...).

 Any chance you could make this dependent on some compiler detection
 mechanism?

 With my arm compiler (gcc-4.4.4) the patch makes no difference -
 unmap_and_move() isn't being inlined anyway.

 How does this look?

 Kevin, could you please retest?  I might have fat-fingered something...

 Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
 However, I'm not sure how specific we can be on the versions.

 /me goes to test a few more compilers...   OK...

 ICE: 4.7.1, 4.7.3, 4.8.3
 OK: 4.6.3, 4.9.2, 4.9.3

 The diff below[2] on top of yours compiles fine here and at least covers
 the compilers I *know* to trigger the ICE.

I see my fix in your mmots since last Thurs (4/2), but it's not in
mmotm (last updated today) so today's linux-next still has the ICE for
anything other than gcc-4.7.3.   Just checking to see when you plan to
update mmotm.

Thanks,

Kevin
--
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

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton a...@linux-foundation.org writes:

 On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman khil...@kernel.org wrote:

  The diff below[2] on top of yours compiles fine here and at least covers
  the compilers I *know* to trigger the ICE.
 
 I see my fix in your mmots since last Thurs (4/2), but it's not in
 mmotm (last updated today) so today's linux-next still has the ICE for
 anything other than gcc-4.7.3.   Just checking to see when you plan to
 update mmotm.

 It should all be there today?

Nope.  

In mmotm, only the original patch plus your first fix is there:

$ curl -sO http://www.ozlabs.org/~akpm/mmotm/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r- akpm/eng   1838 2015-04-01 14:41 
broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r- akpm/eng   1309 2015-04-01 14:41 
broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch

but in mmots, the additional ptch from me, plus another comment fixup
from you are also there:

$ curl -sO http://www.ozlabs.org/~akpm/mmots/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r- akpm/eng   1882 2015-04-06 16:24 
broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r- akpm/eng   1271 2015-04-06 16:24 
broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch
-rw-r- akpm/eng   1382 2015-04-06 16:24 
broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix.patch
-rw-r- akpm/eng968 2015-04-06 16:24 
broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix-fix.patch


Kevin
--
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

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton a...@linux-foundation.org writes:

 On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman khil...@kernel.org wrote:

   It should all be there today?
  
  Nope.  
 
  huh, I swear I did an mmotm yesterday.
 
 Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
 did.  That's why I was confused why the gcc-473 patches from mmots aren't
 there.

 Things look a bit better now.

Yup, I can confirm all 4 patches are there now.  Things should be in
good shape for the next -next.

Thanks,

Kevin
--
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

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton a...@linux-foundation.org writes:

 On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman khil...@kernel.org wrote:

 Andrew Morton a...@linux-foundation.org writes:
 
  On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman khil...@kernel.org wrote:
 
   The diff below[2] on top of yours compiles fine here and at least covers
   the compilers I *know* to trigger the ICE.
  
  I see my fix in your mmots since last Thurs (4/2), but it's not in
  mmotm (last updated today) so today's linux-next still has the ICE for
  anything other than gcc-4.7.3.   Just checking to see when you plan to
  update mmotm.
 
  It should all be there today?
 
 Nope.  

 huh, I swear I did an mmotm yesterday.

Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
did.  That's why I was confused why the gcc-473 patches from mmots aren't
there.

 Let me see if I can sort out the watchdog mess and produce something
 releasable...

OK, thanks.

Kevin
--
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

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Kevin Hilman]

On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer lina.i...@linaro.org wrote:
 On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:

 Andrew Morton a...@linux-foundation.org writes:

 On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier marc.zyng...@arm.com
 wrote:

  -static int unmap_and_move(new_page_t get_new_page, free_page_t
  put_new_page,
  - unsigned long private, struct page *page, int
  force,
  - enum migrate_mode mode)
  +static noinline int unmap_and_move(new_page_t get_new_page,
  +free_page_t put_new_page,
  +unsigned long private, struct page
  *page,
  +int force, enum migrate_mode mode)
   {
int rc = 0;
int *result = NULL;
 

 Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
 the parameters on the stack, which is not going to help performance
 either (not that this would be useful on 32bit ARM anyway...).

 Any chance you could make this dependent on some compiler detection
 mechanism?


 With my arm compiler (gcc-4.4.4) the patch makes no difference -
 unmap_and_move() isn't being inlined anyway.

 How does this look?

 Kevin, could you please retest?  I might have fat-fingered something...


 Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
 However, I'm not sure how specific we can be on the versions.

 /me goes to test a few more compilers...   OK...

 ICE: 4.7.1, 4.7.3, 4.8.3
 OK: 4.6.3, 4.9.2, 4.9.3

 The diff below[2] on top of yours compiles fine here and at least covers
 the compilers I *know* to trigger the ICE.


 I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4


Thanks for checking.  I'm assuming my patch fixes it for your since
that should catch any 4.7.x compiler.

Kevin
--
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

Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page

[Kevin Hilman]

Hi Will,

Will Deacon will.dea...@arm.com writes:

[...]

 
  Thanks for testing this and sorry for the continued breakage. Which
  toolchain did you say you were using? Ard has some more patches trying to
  fix this, but none of our toolchains seem to tickle the issue.
 
 I've also tested on the default ARM toolchains available with ubuntu[1]
 
 Are there any updates on this issue?

 It's been fixed since the end of last week!

 (see ARM: kvm: round HYP section to page size instead of log2 upper bound)

 This was confirmed by both my testing and also Simon Horman, who reported
 the initial breakage.

 It ha broken most of the ARM defconfigs in linux-next[2], and since it's
 been broken for a week now, it is masking other types of issues that we
 can normally find via automated boot testing.

 If you're referring to failures such as:

   
 http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log

Yes, that's the one I'm trying to track down.

 Then that's not coming from the arm64 tree, and is a completely separate
 issue from the one originally reported in this thread.

Ugh, womehow I got wires crossed and thought they were related problems.
Looks like Geert now has a proposed fix for the issue I'm tracking.

Sorry for the noise,

Kevin




--
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

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Geert Uytterhoeven ge...@linux-m68k.org writes:

[...]

 build bisect points to commit 21f992084aeb[3], but that doesn't revert
 cleanly so I haven't got any further than that yet.

 I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
 reproduce the ICE. I came up with the workaround below.

Awesome, thanks!

 Does this work for you?

Yes, that patch works well and fixes the regression. Build results for
all the defconfigs here:

   http://kernelci.org/build/khilman/kernel/v4.0-rc6-8294-g2ef3958cc27e/

and the remaining issues arent' realted to this ICE.

 From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
 From: Geert Uytterhoeven geert+rene...@glider.be
 Date: Wed, 1 Apr 2015 11:22:51 +0200
 Subject: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in
  gcc 4.7.3
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

 With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :

 mm/migrate.c: In function ‘migrate_pages’:
 mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at 
 config/arm/arm.c:13500
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
 Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach 
 this to your bugreport.
 make[1]: *** [mm/migrate.o] Error 1
 make: *** [mm/migrate.o] Error 2

 Mark unmap_and_move() (which is used in a single place only) noinline
 to work around this compiler bug.

 Reported-by: Kevin Hilman khil...@kernel.org
 Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be

Tested-by: Kevin Hilman khil...@linaro.org

 ---
  mm/migrate.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/mm/migrate.c b/mm/migrate.c
 index 114602a68111d809..98f8574456c2010c 100644
 --- a/mm/migrate.c
 +++ b/mm/migrate.c
 @@ -904,9 +904,10 @@ out:
   * Obtain the lock on page, remove all ptes and migrate the page
   * to the newly allocated page in newpage.
   */
 -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
 - unsigned long private, struct page *page, int force,
 - enum migrate_mode mode)
 +static noinline int unmap_and_move(new_page_t get_new_page,
 +free_page_t put_new_page,
 +unsigned long private, struct page *page,
 +int force, enum migrate_mode mode)
  {
   int rc = 0;
   int *result = NULL;
--
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

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton a...@linux-foundation.org writes:

 On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier marc.zyng...@arm.com wrote:

  -static int unmap_and_move(new_page_t get_new_page, free_page_t 
  put_new_page,
  -  unsigned long private, struct page *page, int force,
  -  enum migrate_mode mode)
  +static noinline int unmap_and_move(new_page_t get_new_page,
  + free_page_t put_new_page,
  + unsigned long private, struct page *page,
  + int force, enum migrate_mode mode)
   {
 int rc = 0;
 int *result = NULL;
  
 
 Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
 the parameters on the stack, which is not going to help performance
 either (not that this would be useful on 32bit ARM anyway...).
 
 Any chance you could make this dependent on some compiler detection
 mechanism?

 With my arm compiler (gcc-4.4.4) the patch makes no difference -
 unmap_and_move() isn't being inlined anyway.

 How does this look?

 Kevin, could you please retest?  I might have fat-fingered something...

Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
However, I'm not sure how specific we can be on the versions.  

/me goes to test a few more compilers...   OK...

ICE: 4.7.1, 4.7.3, 4.8.3
OK: 4.6.3, 4.9.2, 4.9.3

The diff below[2] on top of yours compiles fine here and at least covers
the compilers I *know* to trigger the ICE.

Kevin


[1]
diff --git a/mm/migrate.c b/mm/migrate.c
index 25fd7f6291de..6e15ae3248e0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -901,10 +901,10 @@ out:
 }
 
 /*
- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work 
around
  * it.
  */
-#if GCC_VERSION == 40703  defined(CONFIG_ARM)
+#if (GCC_VERSION = 40700  GCC_VERSION  40900)  defined(CONFIG_ARM)
 #define ICE_noinline noinline
 #else
 #define ICE_noinline
--
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

Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page

[Kevin Hilman]

Hi Ard,

Ard Biesheuvel ard.biesheu...@linaro.org writes:

[...]

 I think Will and I were both under the impression that this patch

 https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=kvm-bounce-page

 fixed the issue conclusively.

Nope, that branch is already part of linux-next, and linux-next still
fails to compile for 20+ defconfigs[1]

 Could you elaborate on the issue please? What is the error you are
 getting, and can you confirm that is is caused by ld choking on the
 linker script? If not, this is another error than the one we have been
 trying to fix

It's definitely not linker script related.

Using arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3,
here's the error when building for multi_v7_defconfig (full log
available[2]):

../mm/migrate.c: In function 'migrate_pages':
../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at 
config/arm/arm.c:13101
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
this to your bugreport.
make[2]: *** [mm/migrate.o] Error 1
make[2]: Target `__build' not remade because of errors.
make[1]: *** [mm] Error 2

build bisect points to commit 21f992084aeb[3], but that doesn't revert
cleanly so I haven't got any further than that yet.

Kevin

[1] http://kernelci.org/build/next/kernel/next-20150331/
[2] 
http://storage.kernelci.org/next/next-20150331/arm-multi_v7_defconfig/build.log
[3] 21f992084aeb777675ba5f9c2dc6663e8a06e467 is the first bad commit

Author: Kirill A. Shutemov kirill.shute...@linux.intel.com
Date:   Wed Mar 25 13:02:28 2015 +1100

page-flags: define behavior of FS/IO-related flags on compound pages

It seems we don't have compound page on FS/IO path currently.  Use
NO_COMPOUND to catch if we have.

The odd exception is PG_dirty: sound uses compound pages and maps
them
with PTEs.  NO_COMPOUND triggers VM_BUG_ON() in set_page_dirty() on
handling shared fault.  Let's use HEAD for PG_dirty.

Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
Cc: Andrea Arcangeli aarca...@redhat.com
Cc: Hugh Dickins hu...@google.com
Cc: Dave Hansen dave.han...@intel.com
Cc: Mel Gorman mgor...@suse.de
Cc: Rik van Riel r...@redhat.com
Cc: Vlastimil Babka vba...@suse.cz
Cc: Christoph Lameter c...@linux.com 
Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: Steve Capper steve.cap...@linaro.org
Cc: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Jerome Marchand jmarc...@redhat.com
Signed-off-by: Andrew Morton a...@linux-foundation.org

:04 04 0d621460af1123de8fc33c881ae314c914725afc
b843f45fb2a1c2537e8c17946d3f8af512cab84d M  include
bisect run success
--
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

Re: [PATCH] ARM: omap-device: add missed callback for suspend-to-disk

[Kevin Hilman]

grygorii.stras...@linaro.org writes:

 From: Grygorii Strashko grygorii.stras...@linaro.org

 Add missed callback needed for supporting suspend-to-disk (hibernation) mode.

 Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org

Acked-by: Kevin Hilman khil...@linaro.org

 ---
  arch/arm/mach-omap2/omap_device.c | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap_device.c 
 b/arch/arm/mach-omap2/omap_device.c
 index fcd2c9e..345e18e 100644
 --- a/arch/arm/mach-omap2/omap_device.c
 +++ b/arch/arm/mach-omap2/omap_device.c
 @@ -739,6 +739,9 @@ struct dev_pm_domain omap_device_pm_domain = {
   USE_PLATFORM_PM_SLEEP_OPS
   .suspend_noirq = _od_suspend_noirq,
   .resume_noirq = _od_resume_noirq,
 + .freeze_noirq = _od_suspend_noirq,
 + .thaw_noirq = _od_resume_noirq,
 + .restore_noirq = _od_resume_noirq,
   }
  };
--
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

Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 Revert ARM: dts: Disable smc91x on n900 until bootloader
 dependency is removed. We've now fixed the issues that
 caused problems with uninitialized hardware depending on
 the bootloader version. Mostly things got fixed with
 the following commits:

 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 
 smc91x pins)
 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting)

 Note that this only affects the early development boards
 with Ethernet that we still have in a few automated boot
 test systems.

 Signed-off-by: Tony Lindgren t...@atomide.com

Tested-by: Kevin Hilman khil...@linaro.org
--
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

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

[Kevin Hilman]

On Thu, Dec 18, 2014 at 2:37 PM, Nishanth Menon n...@ti.com wrote:

 script download fail does imply my farm has still issues to resolve..
 but anyways.. more or less we are back operational again since it was
 broken by next-20141216

I'm not seeing any more failures in next-20141218 either.

Kevin
--
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

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

[Kevin Hilman]

[+ Tero]

On Tue, Dec 16, 2014 at 8:07 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 17 December 2014 at 02:33, Nishanth Menon n...@ti.com wrote:
 http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html
 [2.071996] [ cut here ]
 [2.076831] kernel BUG at ../drivers/cpufreq/cpufreq.c:1258!
 [2.082753] Internal error: Oops - BUG: 0 [#1] SMP ARM


[...]

 So the SoC was running on unlisted frequency and when we tried to
 change to some other valid (listed) frequency, we failed.

 The comment over it describes why it is a BUG.. Its some SoC issue
 and need to be resolved by somebody with a board.

 So, in short __cpufreq_driver_target() failed to change freq..

So this looks like a bug that has been hiding, but just exposed
because cpufreq-cpu0 (now cpufreq-dt) was not getting built-in since
before v3.18.

On omap4-panda-es, v3.18 with multi_v7_defconfig + CPUFREQ_DT enabled,
I see this:

[2.062103] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted
freq: 699977 KHz
[2.070404] cpufreq: __cpufreq_add_dev: CPU0: Unlisted initial
frequency changed to: 70 KHz

No BUG.  But, in next-20141216,

[2.083953] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted
freq: 699977 KHz
[2.091949] cpu cpu0: failed to set clock rate: -22
[2.097045] cpufreq: __target_index: Failed to change cpu frequency: -22

And then the BUG.

So the BUG() itself isn't the problem with this regression.  There's
been a fair amount of changes in the OMAP clk driver (including some
other regressions), so I suspect the culprit to be lying somewhere in
the recent OMAP clock changes.

Kevin
--
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

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

[Kevin Hilman]

On Wed, Dec 17, 2014 at 9:16 AM, Kevin Hilman khil...@kernel.org wrote:

[...]

 So the BUG() itself isn't the problem with this regression.  There's
 been a fair amount of changes in the OMAP clk driver (including some
 other regressions), so I suspect the culprit to be lying somewhere in
 the recent OMAP clock changes.

So I attempted to bisect this down, and while it's pinpointing the
problem to the clk-next branch, it's not that simple  I bisected this
on next-20141216, which is where it first showed up, and the bisect
reported: e03f3bb62ca8a1124bc408046c50aed7629b24cc is the first bad
commit.

That commit is where clk-next is merged into linux-next.  What's
intersting is that testing clk-next by itself was just fine, and
linux-next before merging clk-next was just fine.  The bisection here
is complicated because OMAP clock-related changes when in through
drivers/clk and through arch/arm/mach-omap2, so debugging this down
further is going to be a more manual effort.  And one I will leave for
someone else.

Kevin
--
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

Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

[Kevin Hilman]

FYI... New boot failures in today's linux-next for omap4-panda-es and
omap5-uevm:

   http://status.armcloud.us/boot/?lab-khilmanfailomap

The omap3-beagle-xm one has been fixed by Tero, but the fix hasn't hit
-next yet.  I haven't had a chance to bisect these yet.

Kevin


-- Forwarded message --
From: Kevin's boot bot khil...@kernel.org
Date: Mon, Dec 15, 2014 at 10:28 PM
Subject: next boot: 101 boots: 89 pass, 12 fail (next-20141216)
To: kernel-build-repo...@lists.linaro.org


Full Build report: http://status.armcloud.us/build/next/kernel/next-20141216/
Full Boot report:
http://status.armcloud.us/boot/all/job/next/kernel/next-20141216/

Tree/Branch: next
Git describe: next-20141216

Failed boot tests
=
 emev2-kzm9d: FAIL:arm-shmobile_defconfig
   u-boot: ERROR: timeout getting
DHCP address.

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-shmobile_defconfig/lab-khilman/boot-emev2-kzm9d.html
 exynos5420-arndale-octa: FAIL:
arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y
   kernel: ERROR: failed to boot:
class 'pexpect.TIMEOUT'

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y/lab-khilman/boot-exynos5420-arndale-octa.html
 exynos5800-peach-pi: FAIL:
arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y
   kernel: ERROR: failed to boot:
class 'pexpect.TIMEOUT'

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y/lab-khilman/boot-exynos5800-peach-pi.html
  omap5-uevm: FAIL:
arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y
   kernel: Unable to handle kernel
paging request at virtual address ffec


http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y/lab-khilman/boot-omap5-uevm.html
 exynos5800-peach-pi: FAIL:arm-multi_v7_defconfig
   kernel: ERROR: failed to boot:
class 'pexpect.TIMEOUT'

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-exynos5800-peach-pi.html
 exynos5420-arndale-octa: FAIL:arm-multi_v7_defconfig
   kernel: ERROR: failed to boot:
class 'pexpect.TIMEOUT'

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-exynos5420-arndale-octa.html
  omap5-uevm: FAIL:arm-multi_v7_defconfig
   kernel: Unable to handle kernel
paging request at virtual address ffec


http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html
  omap4-panda-es: FAIL:arm-multi_v7_defconfig
   kernel: ERROR: failed to boot:
Kernel panic

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap4-panda-es.html
 exynos5420-arndale-octa: FAIL:arm-exynos_defconfig
   kernel: ERROR: failed to boot:
class 'pexpect.TIMEOUT'

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-exynos_defconfig/lab-khilman/boot-exynos5420-arndale-octa.html
 exynos5800-peach-pi: FAIL:arm-exynos_defconfig
   kernel: ERROR: failed to boot:
class 'pexpect.TIMEOUT'

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-exynos_defconfig/lab-khilman/boot-exynos5800-peach-pi.html
exynos5410-odroid-xu: FAIL:arm-exynos_defconfig
   ERROR: Timeout waiting for
command: if test -n ${preboot}; then run preboot; fi.

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-exynos_defconfig/lab-khilman/boot-exynos5410-odroid-xu.html
  omap3-beagle-xm,legacy: FAIL:arm-omap2plus_defconfig
   kernel: ERROR: did not start booting.

http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-omap2plus_defconfig/lab-khilman/boot-omap3-beagle-xm,legacy.html

Full Report
===

arm-shmobile_defconfig
--
 emev2-kzm9d: FAIL  -  u-boot: ERROR: timeout
getting DHCP address.

arm-davinci_all_defconfig
-
 dm365evm,legacy: PASS
   da850-evm: PASS

arm-tegra_defconfig
---
 tegra124-jetson-tk1: PASS
  tegra30-beaver: PASS

arm-bcm2835_defconfig
-
 bcm2835-rpi: PASS

arm-multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y
--
  armada-xp-openblocks-ax3-4: PASS
  armada-370-mirabox: PASS

Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode

[Kevin Hilman]

Tero Kristo t-kri...@ti.com writes:

 On 12/12/2014 09:07 PM, Kevin Hilman wrote:
 Hi Tero,

 Tero Kristo t-kri...@ti.com writes:

 The new usage of determine_rate and set_rate_and_parent calls for
 OMAP DPLLs assumes the DPLLs must have two parents defined, even
 if it is the same clock. Legacy clock data did not fullfill this
 requirement and caused a boot crash. Fixed by adding the missing
 parent information to the DPLL clocks.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Fixes: 2e1a7b014f (ARM: OMAP3+: DPLL: use determine_rate() and...)
 Cc: Kevin Hilman khil...@kernel.org

 I tested this on linux-next (next-20141210, same version where I found
 the bug) and this doesn't fix the boot problem.

 BTW, in testing this, I noticed that the OMAP clock code is still
 spitting out compile warnings[1].  These should cleaned up too.

 Did you apply both of my patches from this set?

No, I didn't.  That wasn't clear (to me) from the changelogs.

 I think the DPLL fix might be required also to get this working
 properly on OMAP3 legacy.

Yup, with both applied, it's now booting fine on omap3-beagle-xm legacy
mode.

Tested-by: Kevin Hilman khil...@linaro.org

And, please add:

Reported-by: Kevin Hilman khil...@linaro.org

(c.f. Reported-by section in Documentation/SubmittingPatches).  

Thanks,

Kevin
--
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

Re: [GIT PULL] few fixes for the v3.19 merge window

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit a0e4467726cd26bacb16f13d207ffcfa82ffc07d:

   Merge tag 'asm-generic-for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic (2014-12-09 
 17:25:00 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.19/fixes-for-merge-window

 for you to fetch changes up to 661ea91b676bcca137c1c3fe838997925ce98060:

   ARM: omap2plus_defconfig: Enable AHCI_PLATFORM driver (2014-12-10 09:33:50 
 -0800)

 
 Fixes for a few issues found that would be good to get
 into -rc1:

 - Update SoC revision detection for am43x es1.2

 - Fix regression with GPMC timings on 2430sdp for some versions
   of u-boot

 - Fix dra7 watchdog compatible property

 - Fix am437x-sk-evm LCD timings

 - Fix dra7 DSS clock muxing

 - Fix dra7-evm voltages

 - Remove a unused function prototype for am33xx_clk_init

 - Enable AHCI in the omap2plus_defconfig

 

Pulled into fixes.

Not sure yet if this will make it before -rc1 or not.  I think Arnd has
a couple more pull requests outstanding, so he may be able to include
this before -rc1.  Otherwise, it may wait until the after -rc1.

Kevin
--
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

Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode

[Kevin Hilman]

Hi Tero,

Tero Kristo t-kri...@ti.com writes:

 The new usage of determine_rate and set_rate_and_parent calls for
 OMAP DPLLs assumes the DPLLs must have two parents defined, even
 if it is the same clock. Legacy clock data did not fullfill this
 requirement and caused a boot crash. Fixed by adding the missing
 parent information to the DPLL clocks.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Fixes: 2e1a7b014f (ARM: OMAP3+: DPLL: use determine_rate() and...)
 Cc: Kevin Hilman khil...@kernel.org

I tested this on linux-next (next-20141210, same version where I found
the bug) and this doesn't fix the boot problem. 

BTW, in testing this, I noticed that the OMAP clock code is still
spitting out compile warnings[1].  These should cleaned up too.

Kevin

[1]
../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: initialization from 
incompatible pointer type [enabled by default]
../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: (near initialization 
for 'dpll1_ck_ops.determine_rate') [enabled by default]
../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: initialization from 
incompatible pointer type [enabled by default]
../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: (near initialization 
for 'dpll4_ck_ops.determine_rate') [enabled by default]
--
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

Re: [PATCH 5/5] ARM: OMAP3+: DPLL: use determine_rate() and set_rate_and_parent()

[Kevin Hilman]

Hi Tero,

On Fri, Oct 3, 2014 at 6:57 AM, Tero Kristo t-kri...@ti.com wrote:
 Currently, DPLLs are hiding the gory details of switching parent
 within set_rate, which confuses the common clock code and is wrong.
 Fixed by applying the new determine_rate() and set_rate_and_parent()
 functionality to any clock-ops previously using the broken approach.
 This patch also removes the broken legacy code.

 Signed-off-by: Tero Kristo t-kri...@ti.com

This patch arrived in linux-next (as commit 2e1a7b014f9c) and broke
the omap2plus_defconfig, non-DT boot for the omap3-beagle-xm.  By
default, there's no output on the console, but turning on DEBUG_LL, I
got the crash below[1].

Reverting this commit on next-20141210 gets things booting again for me.

Kevin


[1]
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
[0.00] Unable to handle kernel paging request at virtual
address 5f737973
[0.00] pgd = c0004000
[0.00] [5f737973] *pgd=
[0.00] Internal error: Oops: 5 [#1] SMP ARM
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.18.0-11367-g6791358f417e #85
[0.00] Hardware name: OMAP3 Beagle Board
[0.00] task: c08da288 ti: c08ce000 task.ti: c08ce000
[0.00] PC is at strcmp+0x4/0x30
[0.00] LR is at clk_fetch_parent_index+0x80/0xd8
[0.00] pc : [c032f3dc]lr : [c04d81c0]psr: 61d3
[0.00] sp : c08cff20  ip :   fp : 
[0.00] r10: c08ec168  r9 : 5f737973  r8 : 0001
[0.00] r7 : de00d280  r6 : c0770eb4  r5 : de00d284  r4 : 
[0.00] r3 : 0073  r2 :   r1 : 5f737973  r0 : c0770eb5
[0.00] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM
Segment kernel
[0.00] Control: 10c5387d  Table: 80004019  DAC: 0015
[0.00] Process swapper/0 (pid: 0, stack limit = 0xc08ce240)
[0.00] Stack: (0xc08cff20 to 0xc08d)
[0.00] ff20: c08ec168 c0770eb4 c08ebbf0 23c34600 07270e00
413fc082 dfeff140 c04d82b0
[0.00] ff40: c08ebbf0 07270e00 c08ec168 c08ec168 07270e00
001a 23c34600 c08ab890
[0.00] ff60: dfeff140 c04d8bfc 34300133 0190 c08ec168
c086ffc8 34300133 0190
[0.00] ff80:  c0870318 0258 c09768c4 c09768c4
c09768c4 0001 
[0.00] ffa0: c0976480 c08681a8  c086a114 c08aa1e8
c0862684 0002 c085eb08
[0.00] ffc0:   c085e670  
c08ab890  c0976694
[0.00] ffe0: c08d6968 c08ab88c c08dbc2c 80004059 
80008074  
[0.00] [c032f3dc] (strcmp) from [c04d81c0]
(clk_fetch_parent_index+0x80/0xd8)
[0.00] [c04d81c0] (clk_fetch_parent_index) from [c04d82b0]
(clk_calc_new_rates+0x98/0x194)
[0.00] [c04d82b0] (clk_calc_new_rates) from [c04d8bfc]
(clk_set_rate+0x50/0x90)
[0.00] [c04d8bfc] (clk_set_rate) from [c086ffc8]
(omap3_clk_lock_dpll5+0x1c/0xb4)
[0.00] [c086ffc8] (omap3_clk_lock_dpll5) from [c0870318]
(omap3xxx_clk_init+0x2b8/0x398)
[0.00] [c0870318] (omap3xxx_clk_init) from [c08681a8]
(omap_clk_init+0x3c/0x50)
[0.00] [c08681a8] (omap_clk_init) from [c086a114]
(omap3_secure_sync32k_timer_init+0x8/0x58)
[0.00] [c086a114] (omap3_secure_sync32k_timer_init) from
[c0862684] (time_init+0x1c/0x30)
[0.00] [c0862684] (time_init) from [c085eb08]
(start_kernel+0x25c/0x3fc)
[0.00] [c085eb08] (start_kernel) from [80008074] (0x80008074)
[0.00] Code: e12fff1e e1a03000 eaf7 e4d03001 (e4d12001)
[
--
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

Re: [RFC 0/2] i2c: omap: new fixes for driver

[Kevin Hilman]

Alexander Kochetkov al.koc...@gmail.com writes:

 The first patch fix i2c-omap driver for omap2420, found by code review and
 later reported by Tony Lindgren t...@atomide.com here[1].
 Candidate for stable?

 The second patch unhide the reson of system lockup.

 The patch is rebased on branch 'i2c/for-next' of
 git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
 (6e79807443cba7397cd855ed29d6faba51d4c893)

 Tony, could you check, what the patches fix the problem reported[1]?
 Kevin, could you run tests for patches on all omap boards?

Done.  Built v3.18-rc7 + these 2 patches using omap2plus_defconfig. Boot
logs here for your amusement:

http://people.linaro.org/~khilman/tmp/v3.18-rc7-2-gdf84e23f2864/arm-omap2plus_defconfig/

Kevin
--
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

Re: [RFC] i2c: omap: TEST: do IP reset during probe.

[Kevin Hilman]

Alexander Kochetkov al.koc...@gmail.com writes:

 NOT FOR UPSTREAM

 The patch checks if IP reset during probe could bring I2C bus
 to a free state on omap2430 - omap3530 boards.

 I guess, IP hold one of I2C lines in a low state.
 I guess, u-boot haven't sent a stop condition.

 The patch is rebased on branch 'i2c/for-next' of
 git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
 (6e79807443cba7397cd855ed29d6faba51d4c893)

 Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
 Reported-by: Kevin Hilman khil...@kernel.org
 Tested-by: Kevin Hilman khil...@kernel.org

Built for omap2plus_defconfig and tested on all my OMAP boards.  Results
here:

http://people.linaro.org/~khilman/tmp/next-20141126-1-g760388ee02e4/arm-omap2plus_defconfig/
--
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

Re: [PATCH v2] omap: i2c: don't check bus state IP rev3.3 and earlier

[Kevin Hilman]

Alexander Kochetkov al.koc...@gmail.com writes:

 25 нояб. 2014 г., в 22:13, Kevin Hilman khil...@kernel.org написал(а):

 I'll test your patch on all my OMAP boards.  Put whatever debug output
 you want, and I'll send you links to all the boot output.

 Hello, Kevin!

 I've sent the patch[1]. Could you be so kind to run it on all your OMAP 
 boards?
 Thank you very much!
 It is not urgent at all.

Done.  Built for omap2plus_defconfig, boot reports for all my OMAP
boards here: 
http://people.linaro.org/~khilman/tmp/next-20141126-1-g760388ee02e4/arm-omap2plus_defconfig/

 What is the preferred way for giving patches for you (for future)?

Email is fine.  I have things fully automated for primary upstream trees
(mainline, linux-next, stable, etc.) but for stuff like this, I can
trigger one-off tests.

However, if Tony wants to have a branch (besides the one already goes to
linux-next) which I would add to the automation cycle, I'm willing to do that.

 I have one more fixes for i2c-omap (I think final).
 I don't want to break tests anymore.

 And I found, that n900 boot test PASS, but in fact it doesn't[2].
 [2] 
 http://status.armcloud.us/boot/omap3-n900/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/

Right.  For these boot tests, PASS means it got to a userspace shell,
which it did.  The kernel got some warnings etc. during boot, but it
still booted up to a shell.

Kevin
--
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

Re: [PATCH v2] omap: i2c: don't check bus state IP rev3.3 and earlier

[Kevin Hilman]

Alexander Kochetkov al.koc...@gmail.com writes:

 Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 (i2c: omap: implement
 workaround for handling invalid BB-bit values) introduce the error result
 in boot test fault on OMAP3530 boards

 The patch fix the error (disable i2c bus test for OMAP3530).

 Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
 Fixes: 903c3859f77f9b0aace551da03267ef7a211dbc4
 Reported-by: Kevin Hilman khil...@kernel.org
 Tested-by: Tony Lindgren t...@atomide.com

Tested-by: Kevin Hilman khil...@linaro.org

I tested DT and legacy boot on 3430/n900, 3530/beagle and
3530/overo-tobi.  All boot fine.

Kevin
--
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

Re: [PATCH v2] omap: i2c: don't check bus state IP rev3.3 and earlier

[Kevin Hilman]

Alexander Kochetkov al.koc...@gmail.com writes:

 25 нояб. 2014 г., в 17:19, Wolfram Sang w...@the-dreams.de написал(а):

 I'll push out this evening to make the boot tests work again. If there
 is more to be investigated, either hurry up and post v3 ;) or let me
 know that you need more time.

 Ok, thank you. Let the fix go to the kernel-next.
 Maybe small fix to subject omap: i2c: to i2c: omap:

 I still guessing what some boards have broken i2c pull-ups.
 And real fix must go in the board file.
 http://www.spinics.net/lists/linux-i2c/msg17750.html

 I could create a patch to confirm this.
 But I don't have omap3530 boards to run.
 I'll be very appreciated if someone could run the patch.

I'll test your patch on all my OMAP boards.  Put whatever debug output
you want, and I'll send you links to all the boot output.

Kevin

--
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

Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values

[Kevin Hilman]

On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov
al.koc...@gmail.com wrote:
 In a multimaster environment, after IP software reset, BB-bit value doesn't
 correspond to the current bus state. It may happen what BB-bit will be 0,
 while the bus is busy due to another I2C master activity.

 Any transfer started when BB=0 and bus is busy wouldn't be completed by IP
 and results in controller timeout. More over, in some cases IP could
 interrupt another master's transfer and corrupt data on wire.

 The commit implement method allowing to prevent IP from entering into
 controller timeout state and from data corruption state.

 The one drawback is the need to wait for 10ms before the first transfer.

 Tested on Beagleboard XM C.
 Tested on BBB and AM437x Starter Kit by Felipe Balbi.

 Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
 Tested-by: Felipe Balbi ba...@ti.com
 Reviewed-by: Felipe Balbi ba...@ti.com

This patch recently hit linux-next (as commit 903c3859f77f) and boot
breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards
was bisected down to this commit.

Kevin

[1] http://status.armcloud.us/boot/?next-20141124omap
--
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

Re: [PATCH] ARM: OMAP4+: PM: Program CPU logic power state

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 CPU logic power state is never programmed in either the initialization
 or the suspend/resume logic, instead, we depend on mpuss to program this
 properly. However, this leaves CPU logic power state indeterminate and
 most probably in reset configuration (If bootloader or other similar
 software have'nt monkeyed with the register). This can make powerstate=
 RET be either programmed for CSWR (logic=ret) or OSWR(logic = OFF) and
 in OSWR, there can be context loss when the code does not expect it.

 To prevent all these confusions, just support clearly ON, INA, CSWR,
 OFF which is the intent of the existing code by explicitly programming
 logic state.

 NOTE: since this is a hot path (using in cpuidle), the exit path just
 programs powerstate (logic state is immaterial when powerstate is ON).

 Without doing this, we end up with lockups when CPUs enter OSWR and
 multiple blocks loose context, when we expect them to hit CSWR.

 Signed-off-by: Nishanth Menon n...@ti.com

Acked-by: Kevin Hilman khil...@linaro.org
--
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

Re: [PATCH] ARM: dts: Disable smc91x on n900 until bootloader dependency is removed

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 I added smc91x support but turns out we currently do not set the
 smc91x timings in gpmc.c but rely on the bootloader timings. This
 produces the following error unless the smc91x GPMC timings are
 initialized by the bootloader:

 Unhandled fault: external abort on non-linefetch (0x1008) at 0xd080630e
 ...
 [c04067fc] (smc_drv_probe) from [c038e9c4] (platform_drv_probe+0x2c/0x5c)
 [c038e9c4] (platform_drv_probe) from [c038d450] 
 (driver_probe_device+0x104/0x22c)
 [c038d450] (driver_probe_device) from [c038d60c] 
 (__driver_attach+0x94/0x98)
 [c038d60c] (__driver_attach) from [c038bc3c] (bus_for_each_dev+0x54/0x88)
 [c038bc3c] (bus_for_each_dev) from [c038cc3c] (bus_add_driver+0xd8/0x1d8)
 [c038cc3c] (bus_add_driver) from [c038dd74] (driver_register+0x78/0xf4)
 [c038dd74] (driver_register) from [c0008924] (do_one_initcall+0x80/0x1c0)
 [c0008924] (do_one_initcall) from [c0852d9c] 
 (kernel_init_freeable+0x1b8/0x28c)
 [c0852d9c] (kernel_init_freeable) from [c05ce86c] (kernel_init+0x8/0xec)
 [c05ce86c] (kernel_init) from [c000e728] (ret_from_fork+0x14/0x2c)

 Let's fix the issue by disabling the smc91x module for now until we
 have sorted out the issues in gpmc.c.

 Reported-by: Kevin Hilman khil...@linaro.org
 Signed-off-by: Tony Lindgren t...@atomide.com

Tested-by: Kevin Hilman khil...@linaro.org
--
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

Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Kevin Hilman]

Dave Gerlach d-gerl...@ti.com writes:

 Kevin/Ohad,
 On 09/09/2014 02:59 PM, Suman Anna wrote:
 Hi Ohad,
 
 On 09/09/2014 05:31 AM, Ohad Ben-Cohen wrote:
 On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman khil...@linaro.org wrote:
 To me, it's not terribly clear how you made the split between this PM
 core code an the remoteproc code.  In the changelog for the remoteproc
 patch, it states it's to load the firmware for and boot the wkup_m3.
 But, while parts of the IPC are here in pm33xx.c, parts of the IPC are
 also inside the remoteproc driver, so I'm quite curious if that's OK
 with the remoteproc maintainers.  Either way, please make it clearer how
 and why you made the split, and please isolate the wkup_m3 IPC/protocol
 from this code.  Think of people wanting to rework/extend the wkup_m3
 firmware.  They shouldn't be messing around in here, but rather inside a
 driver specificaly for the wkup_m3.

 I haven't looked at the code very thoroughly yet, but generally a
 remoteproc driver should only implement the three start/stop/kick
 rproc_ops, and then register them via the remoteproc framework.
 Exposing additional API directly from that driver isn't something we
 immediately want to accept.

 If relevant, we would generally prefer to extend remoteproc instead,
 so other platform-specific drivers could utilize that functionality as
 well. Or rpmsg - if we're missing some IPC functionality.
 
 The WkupM3 cannot access DDR, and so we don't intend to use rpmsg. The
 IPC with wkup_m3 is usually one of the last steps for putting the SoC
 into a desired low-power state either during suspend or cpuidle, and the
 communication uses a bank of fixed registers. The .kick is specific
 to virtio-based communication, and so this is not gonna be used.
 
 If you can take a closer look at the wkup_m3 remoteproc driver and give
 your comments, then we can plan on the next steps. Especially as there
 are also pieces pertaining to the PM layer knowing the WkupM3 has been
 loaded and booted. There are already some pending comments on code
 fragments from Santosh and myself, but let us know your inputs on the
 integration aspects on PM, remoteproc and IPC with WkupM3.


 The split was defined by putting all the application specific (to the
 firmware in use) code in the platform pm code while trying to keep all the
 IPC code within the wkup_m3_rproc driver. 

I don't even see that split.  I see the platform PM code directly
setting IPC register values, but then rproc driver actually sends the
mailbox command.

 The exposed API is definitely heavily biased towards the intended
 use-case, 

Maybe if the API was actually documented, it would be easier for us to
review it.

 but the CM3 was designed with this exact purpose in mind and
 not much else, and due to the limited IPC registers we have to work
 with there isn't a whole lot of flexibility. Only IPC reg 0 is always
 used as the resume address, the usage of the other registers is
 defined by the firmware and pm code.

 Just as a refresher for those not familiar with it, the IPC mechanism works
 like this: we load the ipc registers (8 for am33xx, 16 for am43xx) with any
 information we want to communicate to the CM3, 

OK, and this happens currently in the platform PM code, right?

 then we make a dummy write to
 the Mailbox which triggers an interrupt on the CM3, the CM3 does what it
 needs to with the info passed in the IPC regs and writes anything it wants to
 communicate back to these registers, and then triggers a different interrupt
 (not related to mailbox) to let the MPU know it is done. 

And this part happens in the rproc driver, right?

 It's kind of a mess so I figured one driver was the best way to
 encapsulate it all,

So where is this one driver that encapsulates it all?  

 and I still had to
 introduce callbacks within the wkup_m3_rproc driver so it could let the pm 
 code
 know when the FW loaded (to actually enable pm) and when an interrupt was
 received from the wkup_m3 (so the pm code can process the response).

 As Suman stated, this sequence is part of the suspend path and also will be 
 part
 of the lower c-states for cpuidle, so we need something fast and lightweight.
 RPMsg is way more than we need and it doesn't really fit the use case, so I'm
 not sure what makes the most sense, extending remoteproc in some way to 
 support
 IPC communication like described above or leaving the basic FW loading
 functionality in place in remoteproc but moving the IPC and wkup_m3
 functionality back into the platform pm33xx code as it's so specific to that
 use-case anyway.

I'm not advocating for using rpmsg (anymore).  But I dont' think shoving
your rpmsg-lite IPC into your rproc driver is the right answer either
(and Ohad's repsonse confirmed my suspicion.)

What I think you need to do (and what I've recommended at least once in
earlier reviews) put all the (non-rproc) wkup_m3 IPC into into one
driver and create a well-described, well-documented API

Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain

[Kevin Hilman]

Laurent Pinchart laurent.pinch...@ideasonboard.com writes:

 Hi Grygorii and Grant,

 On Monday 28 July 2014 23:52:34 Grant Likely wrote:
 On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote:
  On 07/28/2014 05:05 PM, Grant Likely wrote:
  On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko wrote:

[...]

 
  - Where and when to call of_clk_register_runtime_pm_clocks()?
  
Bus notifier/ platform core/ device drivers
 
 I would say in device drivers.

 I tend to agree with that.

 It will help here to take a step back and remember what the problem we're 
 trying to solve is.

[jumping in late, after Grygorii ping'd me about looking at this]

Laurent, thanks for summarizing the problem so well.  It helped me
catchup on the discussion.

 At the root is clock management. Our system comprise many clocks, and they 
 need to be handled. The Common Clock Framework nicely models the clocks, and 
 offers an API for drivers to retrieve device clocks and control them. Drivers 
 can thus implement clock management manually without much pain.

 A clock can be managed in roughly three different ways :

 - it can be enabled at probe time and disabled at remove time ;

 - it can be enabled right before the device leaves its idle state and 
 disabled 
 when the device goes back to idle ; or

 - it can be enabled and disabled in a more fine-grained, device-specific 
 manner.

 The selected clock management granularity depends on constraints specific to 
 the device and on how aggressive power saving needs to be. Enabling the 
 clocks 
 at probe time and disabling them at remove time is enough for most devices, 
 but leads to a high power consumption. For that reason the second clock 
 management scheme is often desired.

 Managing clocks manually in the driver is a valid option. However, when 
 adding 
 runtime PM to the equation, and realizing that the clocks need to be enabled 
 in the runtime PM resume handler and disabled in the suspend handler, the 
 clock management code starts looking very similar in most drivers. We're thus 
 tempted to factorize it away from the drivers into a shared location.

 It's important to note at this point that the goal here is only to simplify 
 drivers. Moving clock management code out of the drivers doesn't (unless I'm 
 missing something) open the door to new possibilities, it just serves as a 
 simplification.

I disagree. Actually, it opens up the door to lots of new possibilities
that are crucial for fine-grained PM with QoS.  It is not just
simplification.  There are many good reasons that some SoCs have moved
all the management of PM-related clocks *out* of device drivers.  More
on that below...

 Now, as Grygorii mentioned, differences between how a given IP core is 
 integrated in various SoCs can make clock management SoC-dependent. In the 
 vast majority of cases (which is really what we need to target, given that 
 our 
 target is simplifying drivers) SoC integration can be described as a list of 
 clocks that must be managed. That list can be common to all devices in a 
 given 
 SoC, or can be device-dependent as well.

If we care about fine-grained PM, this is a way-too oversimplified
version of what SoC integragion means.

There are lots of pieces which fall under SoC integration, for
example: clock domains, power domains, voltage domains, SoC-specific
wakeup capabilities, etc. etc.  Then, for fun throw in QoS constraints,
and things get really exciting.

IOW, if you care about fine-grained PM and QoS, you simply can't reduce
SoC integration down to a list of clocks to be managed.

QoS makes this interesting as well because a device driver's decision to
gate its own clocks may have serious repercussions on the wakeup latency
of *other* devices in the same power domain.  For example, the clock
gating of the last active device in a powerdomain may cause the
enclosing power-domain to be power gated, having a major impact on the
wakup latency of *all* devices in that power domain.

So if we're going to manage the list of PM-related clocks in the device
driver, we'll also keep track of all the other devices in the same power
domain, whether or not they're active, whether or not they have QoS
constraints, etc. etc.  Hopefully you can see that we're quickly way
outside the scope of the IP block that the device driver is intended to
manage.

All of this is SoC integration knowledge, and IMO doen't belong in the
device drivers.  It belongs at the SoC integration level, and in todays
kernel frameworks that means pm_domain/genpd.

 Few locations can be used to express a per-device list of per-SoC clocks. We 
 can have clocks lists in a per-SoC and per-device location, per-device clocks 
 lists in an SoC-specific location, or per-SoC clocks lists in a device-
 specific location.

 The first option would require listing clocks to be managed by runtime PM in 
 DT nodes, as proposed by this patch set. I don't think this is the best 
 option, as that information is a mix of 

Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Kevin Hilman]

+Ohad

Dave Gerlach d-gerl...@ti.com writes:

 AM335x supports various low power modes as documented
 in section 8.1.4.3 of the AM335x Technical Reference Manual.

 DeepSleep0 mode offers the lowest power mode with limited
 wakeup sources without a system reboot and is mapped as
 the suspend state in the kernel. In this state, MPU and
 PER domains are turned off with the internal RAM held in
 retention to facilitate the resume process. As part of
 the boot process, the assembly code is copied over to OCMCRAM
 using the OMAP SRAM code so it can be executed to turn of the
 EMIF.

 AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
 in DeepSleep0 and Standby entry and exit. WKUP_M3 takes care
 of the clockdomain and powerdomain transitions based on the
 intended low power state. MPU needs to load the appropriate
 WKUP_M3 binary onto the WKUP_M3 memory space before it can
 leverage any of the PM features like DeepSleep.

 The WKUP_M3 is managed by a remoteproc driver. The PM code hooks
 into the remoteproc driver through an rproc_ready callback to
 allow PM features to become available once the firmware for the
 wkup_m3 has been loaded. This code maintains its own state machine
 for the wkup_m3 so that it can be used in the manner intended for
 low power modes.

 In the current implementation when the suspend process
 is initiated, MPU interrupts the WKUP_M3 to let it know about
 the intent of entering DeepSleep0 and waits for an ACK. When
 the ACK is received MPU continues with its suspend process
 to suspend all the drivers and then jumps to assembly in
 OCMC RAM. The assembly code puts the external RAM in self-refresh
 mode, gates the MPU clock, and then finally executes the WFI
 instruction. Execution of the WFI instruction with MPU clock gated
 triggers another interrupt to the WKUP_M3 which then continues
 with the power down sequence wherein the clockdomain and
 powerdomain transition takes place. As part of the sleep sequence,
 WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI
 execution on WKUP_M3 causes the hardware to disable the main
 oscillator of the SoC and from here system remains in sleep state
 until a wake source brings the system into resume path.

 When a wakeup event occurs, WKUP_M3 starts the power-up
 sequence by switching on the power domains and finally
 enabling the clock to MPU. Since the MPU gets powered down
 as part of the sleep sequence in the resume path ROM code
 starts executing. The ROM code detects a wakeup from sleep
 and then jumps to the resume location in OCMC which was
 populated in one of the IPC registers as part of the suspend
 sequence.

 Code is based on work by Vaibhav Bedia.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
 v3-v4:
   Remove all direct wkup_m3 usage and moved to rproc driver introduced
   in previous patch.

This statement is rather confusing as there's still quite a bit of
direct wkup_m3 usage, including the guts of the protocal for message
passing.  I thought you had agreed based on earilier reviews to split
out the wkup_m3 into it's on little driver with a clear/clean API which
could be called from here?

To me, it's not terribly clear how you made the split between this PM
core code an the remoteproc code.  In the changelog for the remoteproc
patch, it states it's to load the firmware for and boot the wkup_m3.
But, while parts of the IPC are here in pm33xx.c, parts of the IPC are
also inside the remoteproc driver, so I'm quite curious if that's OK
with the remoteproc maintainers.  Either way, please make it clearer how
and why you made the split, and please isolate the wkup_m3 IPC/protocol
from this code.  Think of people wanting to rework/extend the wkup_m3
firmware.  They shouldn't be messing around in here, but rather inside a
driver specificaly for the wkup_m3.

Also, I'll beat this drum again even though nobody is listening: it's
still very fuzzy to me how this approach is going to be used to manage
low-power idle?  Is low-power idle just being completely ignored for
this SoC?

Kevin
--
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

Re: [GIT PULL] omap fixes against v3.17-rc3

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f:

   Linux 3.17-rc3 (2014-08-31 18:23:04 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-fixes-against-v3.17-rc3

 for you to fetch changes up to c7cc9ba11f8c09a4d12af0fc4aa9f9b026cdd354:

   ARM: dts: dra7-evm: Add vtt regulator support (2014-09-04 12:49:22 -0700)

 
 Few fixes for omaps mostly for various devices to get them working
 properly on the new am437x and dra7 hardware for several devices
 such as I2C, NAND, DDR3 and USB. There's also a clock fix for omap3.

 And also included are two minor cosmetic fixes that are not
 stictly fixes for the new hardware support added recently to
 downgrade a GPMC warning into a debug statement, and fix the
 confusing comments for dra7-evm spi1 mux.

 Note that these are all .dts changes except for a GPMC change.

 

Applied to fixes,

Kevin
--
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

Re: [PATCH 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 powerdomain configuration in OMAP is done using PWRSTCTRL register for
 each power domain. However, PRCM lets us write any value we'd like to
 the logic and power domain target states, however the SoC integration
 tends to actually function only at a few discrete states. These valid
 states are already in our powerdomains_xxx_data.c file.

 So, provide a function to easily query valid low power state that the
 power domain is allowed to go to.

 Based on work originally done by Jean Pihet j-pi...@ti.com
 https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
 create a new powerdomain solution here, except fixing issues seen
 attempting invalid programming attempts. Future consolidation to the
 generic powerdomain framework should consider this requirement as
 well.

 Similar solutions have been done in product kernels in the past such
 as:
 https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c

 Signed-off-by: Nishanth Menon n...@ti.com
 ---

nit: this is part of a fixes series, but it's more of a new feature.

That being said, the feature is needed and looks OK, except for...

 +up_search:
 + /* OK, no deeper ones, can we get a higher match? */
 + new_pwrst = req_state + 1;
 + while (!(pwrdm_states  BIT(new_pwrst))) {
 + /* BUG if we have messed up database */
 + BUG_ON(new_pwrst  PWRDM_POWER_ON);

I don't think this is BUG() worthy, and should have a saner way to recover.

Kevin
--
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

Re: [PATCH 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain

[Kevin Hilman]

On Wed, Aug 27, 2014 at 11:35 AM, Nishanth Menon n...@ti.com wrote:
 On Wed, Aug 27, 2014 at 1:27 PM, Kevin Hilman
 khil...@deeprootsystems.com wrote:
 Nishanth Menon n...@ti.com writes:

 powerdomain configuration in OMAP is done using PWRSTCTRL register for
 each power domain. However, PRCM lets us write any value we'd like to
 the logic and power domain target states, however the SoC integration
 tends to actually function only at a few discrete states. These valid
 states are already in our powerdomains_xxx_data.c file.

 So, provide a function to easily query valid low power state that the
 power domain is allowed to go to.

 Based on work originally done by Jean Pihet j-pi...@ti.com
 https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
 create a new powerdomain solution here, except fixing issues seen
 attempting invalid programming attempts. Future consolidation to the
 generic powerdomain framework should consider this requirement as
 well.

 Similar solutions have been done in product kernels in the past such
 as:
 https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c

 Signed-off-by: Nishanth Menon n...@ti.com
 ---

 nit: this is part of a fixes series, but it's more of a new feature.

 That being said, the feature is needed and looks OK, except for...

 +up_search:
 + /* OK, no deeper ones, can we get a higher match? */
 + new_pwrst = req_state + 1;
 + while (!(pwrdm_states  BIT(new_pwrst))) {
 + /* BUG if we have messed up database */
 + BUG_ON(new_pwrst  PWRDM_POWER_ON);

 I don't think this is BUG() worthy, and should have a saner way to recover.

 it is not even a legal value to have a power state higher than ON. I
 mean, yeah, we can do
 if (new_pwrst  PWRDM_POWER_ON) {
  pr_debug(powerdomain: %s: fix my powerdomain max to ON\n,
 pwrdm-name);
  return PWRDM_POWER_ON;
 }

 if that is your suggestion here, personally, I would use a WARN at least 
 here..

WARN, pr_warn() as you like.

The point is that BUG* calls panic() and locks up the system tight.
As what your'e adding is not fatal to the entire system, you should
not be using bug.  From asm-generic/bug.h:

*
 * Don't use BUG() or BUG_ON() unless there's really no way out; one
 * example might be detecting data structure corruption in the middle
 * of an operation that can't be backed out of.  If the (sub)system
 * can somehow continue operating, perhaps with reduced functionality,
 * it's probably not BUG-worthy.
 *
 * If you're tempted to BUG(), think again:  is completely giving up
 * really the *only* solution?  There are usually better options, where
 * users don't need to reboot ASAP and can mostly shut down cleanly.
 */
--
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

Re: [PATCH 02/10] ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 From: Santosh Shilimkar santosh.shilim...@ti.com

 With EMIF clock-domain put under hardware supervised control, memory
 corruption and untraceable crashes are observed on OMAP5. Further
 investigation revealed that there is a weakness in the PRCM on this
 specific dynamic depedency.

hmm, weakness.  That's a rather polite way of saying bug. :)

Kevin
--
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

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 From: Rajendra Nayak rna...@ti.com

 On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
 and instead attempt a CPU RET and side effect, MPU RET in suspend.

 Signed-off-by: Rajendra Nayak rna...@ti.com
 [n...@ti.com: update to do save_state only on DRA7]
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 
  arch/arm/mach-omap2/omap-wakeupgen.c  |2 +-
  arch/arm/mach-omap2/pm44xx.c  |9 +++--
  3 files changed, 12 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c 
 b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 index 207fce2..0d640eb 100644
 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int 
 power_state)
   save_state = 1;
   break;
   case PWRDM_POWER_RET:
 + if (soc_is_omap54xx() || soc_is_dra7xx()) {

Aren't we trying to get away from these soc_* checks for anything other
than init code?

Kevin

 + save_state = 0;
 + break;
 + }
   default:
   /*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
 diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
 b/arch/arm/mach-omap2/omap-wakeupgen.c
 index e844e16..87c1c0d 100644
 --- a/arch/arm/mach-omap2/omap-wakeupgen.c
 +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
 @@ -381,7 +381,7 @@ static struct notifier_block irq_notifier_block = {
  static void __init irq_pm_init(void)
  {
   /* FIXME: Remove this when MPU OSWR support is added */
 - if (!soc_is_omap54xx())
 + if (!soc_is_omap54xx()  !soc_is_dra7xx())
   cpu_pm_register_notifier(irq_notifier_block);
  }
  #else
 diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
 index b6f243d..c063833 100644
 --- a/arch/arm/mach-omap2/pm44xx.c
 +++ b/arch/arm/mach-omap2/pm44xx.c
 @@ -36,6 +36,8 @@ struct power_state {
   struct list_head node;
  };
  
 +static u32 cpu_suspend_state = PWRDM_POWER_OFF;
 +
  static LIST_HEAD(pwrst_list);
  
  #ifdef CONFIG_SUSPEND
 @@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
* domain CSWR is not supported by hardware.
* More details can be found in OMAP4430 TRM section 4.3.4.2.
*/
 - omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
 + omap4_enter_lowpower(cpu_id, cpu_suspend_state);
  
   /* Restore next powerdomain state */
   list_for_each_entry(pwrst, pwrst_list, node) {
 @@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain 
 *pwrdm, void *unused)
* through hotplug path and CPU0 explicitly programmed
* further down in the code path
*/
 - if (!strncmp(pwrdm-name, cpu, 3))
 + if (!strncmp(pwrdm-name, cpu, 3)) {
 + if (soc_is_omap54xx() || soc_is_dra7xx())
 + cpu_suspend_state = PWRDM_POWER_RET;
   return 0;
 + }
  
   pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
   if (!pwrst)
--
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

Re: [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 The following series are various fixes and improvements for
 supporting suspend-to-ram. This depends on the following for basic 
 functionality:
 series 1/6 where powerdomain fixes were involved.

I had a look through this series, and it looks good overall.  I think Daniel
needs to weigh in on the CPUidle driver, otherwise.

Reviewed-by: Kevin Hilman khil...@linaro.org

I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch.

Tested-by: Kevin Hilman khil...@linaro.org

Kevin
--
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

Re: [PATCH V2 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 powerdomain configuration in OMAP is done using PWRSTCTRL register for
 each power domain. However, PRCM lets us write any value we'd like to
 the logic and power domain target states, however the SoC integration
 tends to actually function only at a few discrete states. These valid
 states are already in our powerdomains_xxx_data.c file.

 So, provide a function to easily query valid low power state that the
 power domain is allowed to go to.

 Based on work originally done by Jean Pihet j-pi...@ti.com
 https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
 create a new powerdomain solution here, except fixing issues seen
 attempting invalid programming attempts. Future consolidation to the
 generic powerdomain framework should consider this requirement as
 well.

 Similar solutions have been done in product kernels in the past such
 as:
 https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c

 Reviewed-by: Kevin Hilman khil...@linaro.org
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: Nishanth Menon n...@ti.com
 ---

 Not posting the entire series again and updating just this patch..

 V2: drop BUG in favor of WARN, picked up Santosh and Kevin's acks.

Looks good, thanks,

Kevin
--
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

Re: [PATCH] gpio: omap: Fix interrupt names

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 When viewing the /proc/interrupts, there is no information about which
 GPIO bank a specific gpio interrupt is hooked on to. This is more than a
 bit irritating as such information can esily be provided back to the
 user and at times, can be crucial for debug.

 So, instead of displaying something like:
 31:   0   0  GPIO   0  palmas
 32:   0   0  GPIO  27  mmc0

 Display the following with appropriate device name:
 31:   0   0  4ae1.gpio   0  palmas
 32:   0   0  4805d000.gpio  27  mmc0

 This requires that we create irq_chip instance specific for each GPIO
 bank which is trivial to achieve.

 Signed-off-by: Nishanth Menon n...@ti.com

Acked-by: Kevin Hilman khil...@linaro.org
--
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

Re: [PATCH 0/3] GPIO OMAP driver changes for v3.17

[Kevin Hilman]

Javier Martinez Canillas jav...@dowhile0.org writes:

 Hi Linus,

 This is a small series with trivial changes to the gpio-omap driver.

 There are no functional changes. Patches 1 and 2 removes code that it's
 not necessary anymore now that the driver has been converted to use the
 gpiolib irqchip and Patch 3 adds an omap prefix to all driver functions,
 something that you suggested me to do before if I remember correctly.

 The patch-set is composed of the following patches:

 Javier Martinez Canillas (3):
   gpio: omap: Remove unnecessary lockdep class
   gpio: omap: Remove unneeded include
   gpio: omap: Add an omap prefix to all functions

Acked-by: Kevin Hilman khil...@linaro.org

For the series.

Kevin
--
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

Re: omap4-panda-es boot issues with v3.15-rc4

[Kevin Hilman]

Santosh Shilimkar santosh.shilim...@ti.com writes:

 On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote:
 * Kevin Hilman khil...@linaro.org [140509 16:46]:
 Roger Quadros rog...@ti.com writes:

 Kevin,

 On 05/09/2014 01:15 AM, Kevin Hilman wrote:
 Tony Lindgren t...@atomide.com writes:

 [...]

 ..but I think I found the cause for recent hangs on panda, just a wild
 guess based on looking at the recent cpuidle patches after v3.14.

 Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
 until all coupled CPUs leave idle) makes booting work reliably again
 on panda.

 Can you guys confirm, so far no issues here after few boot tests,
 but it might be too early to tell.

 Reverting that makes things a bit more stable, but it still eventually
 fails in the same way.  For me it took 8 boots for it to eventually
 fail.

 However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
 (20+ boots in a row and still going.)


 Can you please test with CPU_IDLE enabled but C3 disabled as in below 
 patch?
 It worked for me 10/10 boots.

 Yup, it worked for me too for 10/10 boots in a row.
 
 But what has caused this regression, does it work reliably with let's
 say v3.13 or v3.12?
 
 IIRC things were stable till some CPUIDLE code consolidation happened.
 I don't recall exactly but some one did discuss about it a while back.

 Can you re-run your test-cases with patch at end of the email. This
 is just a hunch so don't blame me if I waste your time testing the
 patch.

With your patch applied on top of next-20140512, my 4460 Panda-ES has
booted 25 times in a row, and still going.

Kevin
--
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

Re: omap4-panda-es boot issues with v3.15-rc4

[Kevin Hilman]

Roger Quadros rog...@ti.com writes:

 Kevin,

 On 05/09/2014 01:15 AM, Kevin Hilman wrote:
 Tony Lindgren t...@atomide.com writes:
 
 [...]
 
 ..but I think I found the cause for recent hangs on panda, just a wild
 guess based on looking at the recent cpuidle patches after v3.14.

 Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
 until all coupled CPUs leave idle) makes booting work reliably again
 on panda.

 Can you guys confirm, so far no issues here after few boot tests,
 but it might be too early to tell.
 
 Reverting that makes things a bit more stable, but it still eventually
 fails in the same way.  For me it took 8 boots for it to eventually
 fail.
 
 However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
 (20+ boots in a row and still going.)
 

 Can you please test with CPU_IDLE enabled but C3 disabled as in below patch?
 It worked for me 10/10 boots.

Yup, it worked for me too for 10/10 boots in a row.

Kevin
--
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

Re: omap4-panda-es boot issues with v3.15-rc4

[Kevin Hilman]

Roger Quadros rog...@ti.com writes:

 Hi,

 Nishant pointed me to a booting issue with omap4-panda-es on linux-next but 
 I'm observing
 similar issues, although less frequent, with v3.15-rc4 as well.

 Configuration:

 - kernel v3.15-rc4 or linux-next (20140507)
 - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled
 - u-boot/master   173d294b94cf

 Observations:

 - Out of 10 boots a few may not succeed and hang midway without any warnings. 
 Heartbeat LED stops.
 e.g. http://www.hastebin.com/ebumojegoq.vhdl

 - Hang more noticeable on linux-next (20140507) than on v3.15-rc4

I've beeen noticing the same thing for awhile with my boot tests.  For
me, next-20140508 is failing most of the time now.

 - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even 
 without USB_EHCI_HCD.
 Maybe related to when high speed interrupts occur in the boot process.

 - On successful boots following warning is seen
 [4.010375] gic_timer_retrigger: lost localtimer interrupt

 - On successful boots heartbeat LED stops blinking after boot process and 
 left idle. LED can remain stuck in
 ON state as well. It does blink again when doing activity on console.

 Workaround:

 - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all 
 the above issues.

 I don't really know what exactly is the issue but it seems to be specific to 
 OMAP4, GIC, MPU OSWR.

I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem
go away.  Hmm

Kevin


--
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

Re: omap4-panda-es boot issues with v3.15-rc4

[Kevin Hilman]

On Thu, May 8, 2014 at 8:31 AM, Kevin Hilman khil...@linaro.org wrote:
 Roger Quadros rog...@ti.com writes:

 Hi,

 Nishant pointed me to a booting issue with omap4-panda-es on linux-next but 
 I'm observing
 similar issues, although less frequent, with v3.15-rc4 as well.

 Configuration:

 - kernel v3.15-rc4 or linux-next (20140507)
 - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled
 - u-boot/master   173d294b94cf

 Observations:

 - Out of 10 boots a few may not succeed and hang midway without any 
 warnings. Heartbeat LED stops.
 e.g. http://www.hastebin.com/ebumojegoq.vhdl

 - Hang more noticeable on linux-next (20140507) than on v3.15-rc4

 I've beeen noticing the same thing for awhile with my boot tests.  For
 me, next-20140508 is failing most of the time now.

 - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even 
 without USB_EHCI_HCD.
 Maybe related to when high speed interrupts occur in the boot process.

 - On successful boots following warning is seen
 [4.010375] gic_timer_retrigger: lost localtimer interrupt

 - On successful boots heartbeat LED stops blinking after boot process and 
 left idle. LED can remain stuck in
 ON state as well. It does blink again when doing activity on console.

 Workaround:

 - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all 
 the above issues.

 I don't really know what exactly is the issue but it seems to be specific to 
 OMAP4, GIC, MPU OSWR.

 I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem
 go away.  Hmm

Another finger pointing in the same direction: omap2plus_defconfig +
CONFIG_CPU_IDLE=y also fails to boot rather consistently in today's
-next.

Kevin
--
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

Re: omap4-panda-es boot issues with v3.15-rc4

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

[...]

 ..but I think I found the cause for recent hangs on panda, just a wild
 guess based on looking at the recent cpuidle patches after v3.14.

 Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
 until all coupled CPUs leave idle) makes booting work reliably again
 on panda.

 Can you guys confirm, so far no issues here after few boot tests,
 but it might be too early to tell.

Reverting that makes things a bit more stable, but it still eventually
fails in the same way.  For me it took 8 boots for it to eventually
fail.

However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
(20+ boots in a row and still going.)

Kevin




--
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

Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core

[Kevin Hilman]

Geert Uytterhoeven geert+rene...@glider.be writes:

 When adding a device from DT, check if its clocks are suitable for Runtime
 PM, and register them with the PM core.
 If Runtime PM is disabled, just enable the clock.

 This allows the PM core to automatically manage gate clocks of devices for
 Runtime PM.

...unless the device is already in an existing pm_domain, right?

I like this approach, and it extends nicely what we already do on
platforms using drivers/base/power/clock_ops.c into DT land.

My only concern is how this will interact if it's used along with
devices that have existing pm_domains.  I don't have any specific
concerns (yet, because it's Friday, and my brain is turing off), but it
just made me wonder if this will be potentially confusing.
 
Also...

[...]

 +static int of_clk_register(struct device *dev, struct clk *clk)
 +{
 + int error;
 +
 + if (!dev-pm_domain) {
 + error = pm_clk_create(dev);
 + if (error)
 + return error;
 +
 + dev-pm_domain = of_clk_pm_domain;
 + }
 +
 + dev_dbg(dev, Setting up clock for runtime PM management\n);
 + return pm_clk_add_clk(dev, clk);

I would've expected these 2 lines to be inside the pm_domain check.

What's the reason for doing the pm_clk_add() when the pm_domain isn't
going to be used?  I suppose it's harmless, but it's a bit confusing.

Kevin
--
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

Re: regressions in linux-next?

[Kevin Hilman]

Linus Walleij linus.wall...@linaro.org writes:

 On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
 jav...@dowhile0.org wrote:

 I've revised the patch again and I couldn't find the reason why
 certain boards are failing to boot.

 I can't reproduce this issue since I only have a DM3730 IGEPv2 board
 which boots fine but I should have access to an AM3354 IGEP Aquila
 board which is similar to the am335x-evmsk so I may be able to debug
 it.

 It would really REALLY appreciate if some of the people maintaining
 and using OMAP1 would help Javier out in this refactoring operation.

 I'd really *hate* to have to drop his patches because of a lack of
 boards. This refactoring is necessary to handle the exploding
 multitude of GPIO drivers moving forward.

 We even tried to get an Innovator to boot just to be able to refactor
 OMAP stuff but fell short on some special JTAG reflash snag so
 we are dependent on maintainers to help out here :-/

Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been
able to get it booting again.  I wonder if Spectrum Digital still has
these available?  Their websites[1] says call for price.

Kevin

[1] http://www.spectrumdigital.com/product_info.php?products_id=39
--
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

Re: [PATCH v3] gpio: omap: implement get_direction

[Kevin Hilman]

Linus Walleij linus.wall...@linaro.org writes:

 On Thu, Apr 24, 2014 at 8:57 AM,  yegorsli...@googlemail.com wrote:

 From: Yegor Yefremov yegorsli...@googlemail.com

 This patch implements gpio_chip's get_direction() routine, that
 lets other drivers get particular GPIOs direction using
 struct gpio_desc.

 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
 Acked-by: Javier Martinez Canillas jav...@dowhile0.org
 ---
 Changes:
 v3: get rid of _get_gpio_direction() (Linus Walleij)
 v2: rework return value calculation

 Looks good to me, Kevin, Santosh?

Reviewed-by: Kevin Hilman khil...@linaro.org

 Part of me wants to list Javier as maintainer for this driver.

That's fine with me. 

Kevin
--
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

Re: [PATCH] ARM: dts: Add support for the BeagleBoard xM A/B

[Kevin Hilman]

Robert Nelson robertcnel...@gmail.com writes:

 BeagleBoard xM A/B has an inverted usb hub enable line vs the xM C

 Signed-off-by: Robert Nelson robertcnel...@gmail.com
 ---
  arch/arm/boot/dts/Makefile   |  1 +
  arch/arm/boot/dts/omap3-beagle-xm-ab.dts | 15 +++
  2 files changed, 16 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap3-beagle-xm-ab.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 35c146f..0bdeba3 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -246,6 +246,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
   omap3-sbc-t3730.dtb \
   omap3-devkit8000.dtb \
   omap3-beagle-xm.dtb \
 + omap3-beagle-xm-ab.dtb \
   omap3-evm.dtb \
   omap3-evm-37xx.dtb \
   omap3-ldp.dtb \
 diff --git a/arch/arm/boot/dts/omap3-beagle-xm-ab.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
 new file mode 100644
 index 000..9d81123
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
 @@ -0,0 +1,15 @@
 +/*
 + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include omap3-beagle-xm.dts
 +
 +/ {
 + /* HS USB Port 2 Power enable was inverted with the xM C */
 + hsusb2_power: hsusb2_power_reg {
 + enable-active-high;

Missing '};' here?

This causes build breakage in linux-omap master, which now has this
applied.

 +};

Kevin
--
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

Re: [PATCH] ARM: dts: Add support for the BeagleBoard xM A/B

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 * Gupta, Pekon pe...@ti.com [140421 23:49]:
 Tony,
 
 From: Tony Lindgren
 * Robert Nelson robertcnel...@gmail.com [140418 16:42]:
  On Fri, Apr 18, 2014 at 5:51 PM, Tony Lindgren t...@atomide.com wrote:
   * Robert Nelson robertcnel...@gmail.com [140415 08:46]:
  
   Background: i also tried getting this having this fixed in u-boot:
  
   Do we still need to apply this patch then?
 
  Yeah, Tom want's it done in the kernel:
 
  Here's my proposed u-boot patch:
  http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
 
  and Tom's recommendation:
  http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
 
  Once this hits mainline, i'll submit a patch to u-boot to check for
  the presence of this version and drop to the old dtb if not found.
 
 OK applying into omap-for-v3.15/fixes thanks.
 
 Tony
 
 You probably missed fixing below typo before applying this patch.
 omap3-beagle-xm-ab.dts breaks without this.

 Yeah pushed out omap-for-v3.15/fixes-v2 with the missing bracket.

Your master branch still has the one that doesn't compile.

Kevin


--
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

Re: [PATCH] ARM: dts: Add support for the BeagleBoard xM A/B

[Kevin Hilman]

On Thu, Apr 24, 2014 at 3:32 PM, Kevin Hilman khil...@linaro.org wrote:
 Robert Nelson robertcnel...@gmail.com writes:

 BeagleBoard xM A/B has an inverted usb hub enable line vs the xM C

 Signed-off-by: Robert Nelson robertcnel...@gmail.com
 ---
  arch/arm/boot/dts/Makefile   |  1 +
  arch/arm/boot/dts/omap3-beagle-xm-ab.dts | 15 +++
  2 files changed, 16 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap3-beagle-xm-ab.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 35c146f..0bdeba3 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -246,6 +246,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
   omap3-sbc-t3730.dtb \
   omap3-devkit8000.dtb \
   omap3-beagle-xm.dtb \
 + omap3-beagle-xm-ab.dtb \
   omap3-evm.dtb \
   omap3-evm-37xx.dtb \
   omap3-ldp.dtb \
 diff --git a/arch/arm/boot/dts/omap3-beagle-xm-ab.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
 new file mode 100644
 index 000..9d81123
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
 @@ -0,0 +1,15 @@
 +/*
 + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include omap3-beagle-xm.dts
 +
 +/ {
 + /* HS USB Port 2 Power enable was inverted with the xM C */
 + hsusb2_power: hsusb2_power_reg {
 + enable-active-high;

 Missing '};' here?

 This causes build breakage in linux-omap master, which now has this
 applied.

ignore this.  It's already been fixed, but was still lingering in
Tony's master branch.

Kevin
--
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

Re: [RFC 3/5] ARM: OMAP2+: timer: Add clocksource initialization and powerup support

[Kevin Hilman]

Joel Fernandes jo...@ti.com writes:

 On 03/13/2014 04:52 PM, Rob Herring wrote:
 On Thu, Mar 13, 2014 at 3:35 PM, Joel Fernandes jo...@ti.com wrote:
 Introduce a generic omap timer initialization function that can
 be used by all SoCs for which support is available in the clocksource
 driver introduced in the series.

 The function will also be responsible for calling clock initialization
 required for everything else to work.

 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  arch/arm/mach-omap2/common.h |1 +
  arch/arm/mach-omap2/timer.c  |   28 
  2 files changed, 29 insertions(+)

 diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
 index a6aae30..e58d9a4 100644
 --- a/arch/arm/mach-omap2/common.h
 +++ b/arch/arm/mach-omap2/common.h
 @@ -92,6 +92,7 @@ extern void omap3_secure_sync32k_timer_init(void);
  extern void omap3_gptimer_timer_init(void);
  extern void omap4_local_timer_init(void);
  extern void omap5_realtime_timer_init(void);
 +void omap_generic_timer_init(void);

  void omap2420_init_early(void);
  void omap2430_init_early(void);
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index 74044aa..08c73a0 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -324,6 +324,25 @@ static int __init omap_dm_timer_init_one(struct 
 omap_dm_timer *timer,
 return r;
  }

 +int __init omap_dmtimer_powerup(struct omap_dm_timer *timer,
 +   struct device_node *np) {
 
 This function seems unrelated to the commit message.

 Ok, I'll add it in the message.

 
 +   struct omap_hwmod *oh;
 +   const char *oh_name = NULL;
 +
 +   of_property_read_string_index(np, ti,hwmods, 0, oh_name);
 +   if (!oh_name)
 +   return -ENODEV;
 +
 +   oh = omap_hwmod_lookup(oh_name);
 +   if (!oh)
 +   return -ENODEV;
 +
 +   omap_hwmod_setup_one(oh_name);
 +
 +   omap_hwmod_enable(oh);
 +   return 0;
 +}
 +
  static void __init omap2_gp_clockevent_init(int gptimer_id,
 const char *fck_source,
 const char *property)
 @@ -615,6 +634,15 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, 
 ti,timer-alwon,
2, sys_clkin_ck, NULL);
  #endif

 +void omap_generic_timer_init(void)
 +{
 +   if (!of_have_populated_dt())
 +   BUG_ON(Generic timer init should only be used for DT 
 boot\n);
 
 I thought omap2 is always DT boot now.

 That's right, sorry- I'll get rid of the check.

Actually, mainline still supports legacy boot and has board files for
OMAP3 platforms, and we shouldn't break legacy boot on purpose IMO.

Kevin
--
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

Re: [PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
 CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
 failure complaining about the following:
 arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
 :(.text+0x8a70): undefined reference to `pm44xx_errata'

 Fixes: c962184 (ARM: OMAP4: PM: add errata support)
 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Nishanth Menon n...@ti.com

Acked-by: Kevin Hilman khil...@linaro.org
--
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

Re: [PATCH 0/3] ARM: dts: Fixes for Overo/Tobi against 3.14-rc1

[Kevin Hilman]

Florian Vaussard florian.vauss...@epfl.ch writes:

 Hi,

 On 02/06/2014 06:09 PM, Kevin Hilman wrote:
 Florian Vaussard florian.vauss...@epfl.ch writes:
 
 OMAP36xx-based Overo (Storm and alike) are now failing to boot with 
 3.14-rc1 [1].
 This series fixes this, by moving model-agnostic DT into a common dtsi file,
 and creating model-specific DT files:

 - omap3-overo-tobi.dts - older OMAP35xx Overo
 - omap3-overo-storm-tobi.dts - newer OMAP36xx/AM37xx/DM37xx Overo

 People will have to use the right Overo / expansion board combination.

 (Patch 2 in an unrelated fix that was waiting in my queue.)

 omap3-overo-tobi.dts tested with Overo Sand (OMAP3503) and 
 omap3-overo-storm-tobi.dts
 tested with Overo EarthStorm (AM3703). Both boot. With the Overo Sand, I 
 cannot
 mount the ext3 rootfs, but this seems unrelated to the current topic, maybe
 a missing errata.
 
 And I tested with my 35xx/Overo with omap3-overo-tobi.dts and my
 37xx/Overo STORM with omap3-overo-storm-tobi.dts and they're both
 working.
 
 Tested-by: Kevin Hilman khil...@linaro.org
 
 Tony, with your ack, I can apply these directly to arm-soc/fixes.
 
 Florian, thanks for the fixes.
 

 This issue is still present in 3.14-rc2.

 Shall I send a v2, including the suggestion of Nishanth, against 3.14-rc2?


Feel free to send a v2.  I was just waiting for Tony to queue them up
(or ack and I'll take them through arm-soc.)

Kevin
--
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

Re: next boot: 36 pass, 3 fail (next-20140210)

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 On 02/10/2014 10:33 AM, Kevin Hilman wrote:
 +linux-omap list
 
 On Mon, Feb 10, 2014 at 7:58 AM, Kevin's boot bot khil...@linaro.org wrote:
 Automated DT boot report for various ARM defconfigs.


 Tree/Branch: next
 Git describe: next-20140210
 Failed boot tests (console logs at the end)
 ===
  omap3-beagle-xm: FAIL:multi_v7_defconfig
   omap3-tobi: FAIL:multi_v7_defconfig
   omap4-panda-es: FAIL:multi_v7_defconfig
 
 These are all new OMAP failures, and appear to be an EHCI panic during
 boot.  Note that omap2plus_defconfig boots fine on all these boards,
 this failure is only for multi_v7_defconfig.
 
 Not sure if anyone else has seen this yet.

 yep - reported and being looked here:
 http://marc.info/?t=13920480394r=1w=2

Great, thanks.

Kevin
--
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

Re: next boot: 36 pass, 3 fail (next-20140210)

[Kevin Hilman]

+linux-omap list

On Mon, Feb 10, 2014 at 7:58 AM, Kevin's boot bot khil...@linaro.org wrote:
 Automated DT boot report for various ARM defconfigs.


 Tree/Branch: next
 Git describe: next-20140210
 Failed boot tests (console logs at the end)
 ===
  omap3-beagle-xm: FAIL:multi_v7_defconfig
   omap3-tobi: FAIL:multi_v7_defconfig
   omap4-panda-es: FAIL:multi_v7_defconfig

These are all new OMAP failures, and appear to be an EHCI panic during
boot.  Note that omap2plus_defconfig boots fine on all these boards,
this failure is only for multi_v7_defconfig.

Not sure if anyone else has seen this yet.

Kevin

[...]

 Console logs for failures
 =

 multi_v7_defconfig
 --

 omap3-beagle-xm: FAIL: last 80 lines of boot log:
 -

 [1.710632] 9e20:  de214810 de68c800 c0927e58 de217680 c03e0c68 
 c07654b4 de68cb7c
 [1.719207] 9e40:  005d 00df de214810 c0927e84  
 c0927e84 c0861b20
 [1.727783] 9e60: 00df de0c8030  c030676c c0306754 de214810 
 c098e4cc c0304fc8
 [1.736358] 9e80:  de214810 c0927e84 de214844  c03051b4 
  c0927e84
 [1.744934] 9ea0: c0305128 c03035e0 de00c85c de2181b4 c0927e84 de67fb80 
 c091d3c0 c0304790
 [1.753479] 9ec0: c0788444 de0c9edc c0927e84 c0927e84 0006 c0952f00 
 c0952f00 c03057b8
 [1.762054] 9ee0: c0306198 c08a58dc 0006 c0008bbc de009480 c0730330 
 de0f4880 c05a8de8
 [1.770629] 9f00:  c0952f00 c082750c c012e9a4  c08ec6d8 
 6153 0001
 [1.779205] 9f20: dfeff153 c05b85f8 00df c005d83c c07f19b0 0006 
 dfeff1a1 0006
 [1.787750] 9f40: c08ec6c8 c08a58dc 0006 c0952f00 c0952f00 c082750c 
 00df c0887f34
 [1.796325] 9f60: c0887f28 c0827c48 0006 0006 c082750c 45870402 
 8e00 05601080
 [1.804901] 9f80: 08008c40  c0597d44    
  
 [1.813476] 9fa0:  c0597d4c  c000e5b8   
  
 [1.822021] 9fc0:       
  
 [1.830596] 9fe0:     0013  
 0d094204 00041010
 [1.839172] [c03dd368] (ehci_setup) from [c03e0f3c] 
 (ehci_platform_reset+0x8c/0xc0)
 [1.847564] [c03e0f3c] (ehci_platform_reset) from [c03c77c0] 
 (usb_add_hcd+0x1b0/0x714)
 [1.856231] [c03c77c0] (usb_add_hcd) from [c03e0c68] 
 (ehci_platform_probe+0x168/0x3b0)
 [1.864898] [c03e0c68] (ehci_platform_probe) from [c030676c] 
 (platform_drv_probe+0x18/0x48)
 [1.874023] [c030676c] (platform_drv_probe) from [c0304fc8] 
 (driver_probe_device+0x124/0x240)
 [1.883331] [c0304fc8] (driver_probe_device) from [c03051b4] 
 (__driver_attach+0x8c/0x90)
 [1.892181] [c03051b4] (__driver_attach) from [c03035e0] 
 (bus_for_each_dev+0x60/0x94)
 [1.900756] [c03035e0] (bus_for_each_dev) from [c0304790] 
 (bus_add_driver+0x148/0x1f0)
 [1.909393] [c0304790] (bus_add_driver) from [c03057b8] 
 (driver_register+0x78/0xf8)
 [1.917785] [c03057b8] (driver_register) from [c0008bbc] 
 (do_one_initcall+0xf8/0x144)
 [1.926361] [c0008bbc] (do_one_initcall) from [c0827c48] 
 (kernel_init_freeable+0x13c/0x1dc)
 [1.935485] [c0827c48] (kernel_init_freeable) from [c0597d4c] 
 (kernel_init+0x8/0xf0)
 [1.943969] [c0597d4c] (kernel_init) from [c000e5b8] 
 (ret_from_fork+0x14/0x3c)
 [1.951904] Code: e1a04000 e24dd008 e2806e13 e59031cc (e5932000)
 [1.958312] ---[ end trace 1b1cb8cc8ee0b223 ]---
 [1.963195] In-band Error seen by MPU  at address 0
 [1.968292] [ cut here ]
 [1.973144] WARNING: CPU: 0 PID: 1 at 
 /home/build/work/batch/drivers/bus/omap_l3_smx.c:162 
 omap3_l3_app_irq+0xe4/0x118()
 [1.984527] Modules linked in:
 [1.987731] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G  D  
 3.14.0-rc1-next-20140210 #1
 [1.996582] [c001588c] (unwind_backtrace) from [c001143c] 
 (show_stack+0x10/0x14)
 [2.004699] [c001143c] (show_stack) from [c059d8d0] 
 (dump_stack+0x84/0x94)
 [2.012298] [c059d8d0] (dump_stack) from [c0044630] 
 (warn_slowpath_common+0x6c/0x88)
 [2.020782] [c0044630] (warn_slowpath_common) from [c00446e8] 
 (warn_slowpath_null+0x1c/0x24)
 [2.029998] [c00446e8] (warn_slowpath_null) from [c021a8d0] 
 (omap3_l3_app_irq+0xe4/0x118)
 [2.038940] [c021a8d0] (omap3_l3_app_irq) from [c0081d64] 
 (handle_irq_event_percpu+0x54/0x180)
 [2.048309] [c0081d64] (handle_irq_event_percpu) from [c0081ed0] 
 (handle_irq_event+0x40/0x60)
 [2.057617] [c0081ed0] (handle_irq_event) from [c008476c] 
 (handle_level_irq+0x94/0x108)
 [2.066375] [c008476c] (handle_level_irq) from [c008152c] 
 (generic_handle_irq+0x2c/0x3c)
 [2.075225] [c008152c] (generic_handle_irq) from [c000edfc] 
 

Re: regression(ti platforms): next-20140210 (ehci?)

[Kevin Hilman]

Roger Quadros rog...@ti.com writes:

 +devicetree

 On 02/10/2014 05:59 PM, Nishanth Menon wrote:
 Hi,
 
 A quick note to report that I saw regression in today's next tag (logs
 indicate around EHCI) boot on various TI platforms:
 
 Note: crane and sdp2430 are not expected to pass with
 multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
 but USB is disabled there)
 
 next-20140210-multi_v7_defconfig
  1: am335x-evm:  Boot PASS: http://slexy.org/raw/s2zYHdPb94
  2:  am335x-sk:  Boot PASS: http://slexy.org/raw/s2UChLyzSE
  3: am3517-evm:  Boot FAIL: http://slexy.org/raw/s20Br9XLO1
 around ehci
 
  4:  am37x-evm:  Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
 around ehci
 
  5: am43xx-epos:  Boot PASS: http://slexy.org/raw/s2byveBYtT
  6: BeagleBoard-XM:  Boot FAIL: http://slexy.org/raw/s21sOgJNwK
 around ehci
 
  7: BeagleBone-Black:  Boot PASS: http://slexy.org/raw/s2ovVNAmO7
  8:  crane: No Image built - Missing platform support?:
  9:   dra7:  Boot PASS: http://slexy.org/raw/s217qwaXsM
 10:ldp:  Boot FAIL: http://slexy.org/raw/s203IvjE23
 around ehci
 
 11: PandaBoard-ES:  Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
 around ehci

 I think the problem is that ehci-platform driver gets loaded instead of 
 ehci-omap.

 In the DT node we have compatible ids for both. e.g. for omap4.dtsi

 usbhsehci: ehci@4a064c00 {
 compatible = ti,ehci-omap, usb-ehci;
 reg = 0x4a064c00 0x400;
 interrupt-parent = gic;
 interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
 };

 Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?

 A quick fix would be to eliminate usb-ehci from the DT node of all failing 
 platforms.

I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
fixed the problem for me on 3530/overo, 3730/beagle-xM and
4460/panda-es.  But I don't think that's the right fix.  First we have
to figure out why ehci-omap stopped getting loaded first.

Kevin
--
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

Re: [PATCH] ARM: multi_v7_defconfig: Select CONFIG_SOC_DRA7XX

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 Select CONFIG_SOC_DRA7XX so that we can boot dra7-evm.
 DRA7 family are A15 based processors that supports LPAE and an
 evolutionary update to the OMAP5 generation of processors.

 Signed-off-by: Nishanth Menon n...@ti.com
 ---

 based on v3.13-rc1 kernel tag - tested on v3.14-rc1 and next-20140206

Applied to arm-soc/fixes for v3.14-rc.

Kevin
--
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

Re: regression(ti platforms): next-20140210 (ehci?)

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 On 02/10/2014 12:28 PM, Kevin Hilman wrote:
 Roger Quadros rog...@ti.com writes:
 
 +devicetree

 On 02/10/2014 05:59 PM, Nishanth Menon wrote:
 Hi,

 A quick note to report that I saw regression in today's next tag (logs
 indicate around EHCI) boot on various TI platforms:

 Note: crane and sdp2430 are not expected to pass with
 multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
 but USB is disabled there)

 next-20140210-multi_v7_defconfig
  1: am335x-evm:  Boot PASS: http://slexy.org/raw/s2zYHdPb94
  2:  am335x-sk:  Boot PASS: http://slexy.org/raw/s2UChLyzSE
  3: am3517-evm:  Boot FAIL: http://slexy.org/raw/s20Br9XLO1
 around ehci

  4:  am37x-evm:  Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
 around ehci

  5: am43xx-epos:  Boot PASS: http://slexy.org/raw/s2byveBYtT
  6: BeagleBoard-XM:  Boot FAIL: http://slexy.org/raw/s21sOgJNwK
 around ehci

  7: BeagleBone-Black:  Boot PASS: http://slexy.org/raw/s2ovVNAmO7
  8:  crane: No Image built - Missing platform support?:
  9:   dra7:  Boot PASS: http://slexy.org/raw/s217qwaXsM
 10:ldp:  Boot FAIL: http://slexy.org/raw/s203IvjE23
 around ehci

 11: PandaBoard-ES:  Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
 around ehci

 I think the problem is that ehci-platform driver gets loaded instead of 
 ehci-omap.

 In the DT node we have compatible ids for both. e.g. for omap4.dtsi

 usbhsehci: ehci@4a064c00 {
 compatible = ti,ehci-omap, usb-ehci;
 reg = 0x4a064c00 0x400;
 interrupt-parent = gic;
 interrupts = GIC_SPI 77 
 IRQ_TYPE_LEVEL_HIGH;
 };

 Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?

 A quick fix would be to eliminate usb-ehci from the DT node of all 
 failing platforms.
 
 I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
 fixed the problem for me on 3530/overo, 3730/beagle-xM and
 4460/panda-es.  But I don't think that's the right fix.  First we have
 to figure out why ehci-omap stopped getting loaded first.

 Wont that depend on driver probe order? of_match_device is fairly
 simple compatible walk through without looking at other drivers which
 might also be compatible, but not yet probed?

 The issue started I think with the following patch getting merged:
 ehci-platform: Add support for clks and phy passed through devicetree
 some version of http://www.spinics.net/lists/linux-usb/msg101061.html
 introduced { .compatible = usb-ehci, },

This is what I was getting at: an understanding of what caused the
failue in the first place.

 Now, in the build we have two drivers which dts claims compatibility
 with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
 for the platform. Thinking that way, in fact, the current
 compatibility even matches drivers/usb/host/ehci-ppc-of.c which
 obviously wont work either.

Right, so I agree that it makes sense to remove a compatible string
where there is no compatability, but a couple other things should happen
here.

1) changelog should describe why this compatible string is in the omap
dtsi files in first place.

2) investigation into the patch that introduced this change to double
check it's not introducing other breakage as well.

Kevin
--
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

Re: next boot: 34 pass, 5 fail (next-20140122)

[Kevin Hilman]

On Fri, Jan 24, 2014 at 10:13 AM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
 Hi,

 On 01/24/2014 07:11 PM, Tony Lindgren wrote:
 * Florian Vaussard florian.vauss...@epfl.ch [140123 01:17]:

 I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing
 the include to omap36xx.dtsi do not fix the issue. I still get the
 external abort on non-linefetch (full log here [1]).

 I think the issue here is that you need to have ti,omap36xx in
 the compatible string in addition to including omap36xx.dtsi.
 Otherwise ti,omap3 will initialize things for 34xx.

 For the initial minimal fix, I suggest we do something like the
 following. This should fix things for 36xx based tobi, then
 34xx based tobi support can be added later on. Untested as I
 don't have one.


 You are probably right. I will test Monday.

Any progress on this?

We still have the 36xx Tobi boards failing basic boot tests -next, but
now also in mainline.

Kevin
--
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

Re: [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 * Kevin Hilman khil...@linaro.org [140123 09:55]:
 Grygorii Strashko grygorii.stras...@ti.com writes:
 
  On 01/20/2014 10:06 PM, Nishanth Menon wrote:
  Move all OMAP4 PM errata initializations to centralized location in
  omap4_pm_init_early. This allows for users to utilize the erratas
  in various submodules as needed.
  
  Tested-by: Grygorii Strashko grygorii.stras...@ti.com
 
  This patch fixes build failure caused by patch 
  https://patchwork.kernel.org/patch/3084521/ 
  in case if SMP is not enabled.
 
 So does that mean that that patch can now be applied as is?
 
 We could sure use that fix (or equivalent) for CPUidle breakage on 4460.

 Yeah, seems OK to me, feel free to apply it directly:

 Acked-by: Tony Lindgren t...@atomide.com

OK, I've picked up both $SUBJECT patch and the one from the above
patchworks link and will queue them up for v3.14-rc (and have added your
Ack to both.)

Thanks,

Kevin
--
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

Re: [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early

[Kevin Hilman]

Grygorii Strashko grygorii.stras...@ti.com writes:

 On 01/20/2014 10:06 PM, Nishanth Menon wrote:
 Move all OMAP4 PM errata initializations to centralized location in
 omap4_pm_init_early. This allows for users to utilize the erratas
 in various submodules as needed.
 
 Tested-by: Grygorii Strashko grygorii.stras...@ti.com

 This patch fixes build failure caused by patch 
 https://patchwork.kernel.org/patch/3084521/ 
 in case if SMP is not enabled.

So does that mean that that patch can now be applied as is?

We could sure use that fix (or equivalent) for CPUidle breakage on 4460.

Kevin
--
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

Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion

[Kevin Hilman]

Mike Turquette mturque...@linaro.org writes:

[...]

 I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
 Tero's series. This includes the AM3517 bits now. I've pushed this
 branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
 final sanity test before I merge this into clk-next?

I merged clk-next-omap into next-20140117 and build/boot tested
omap2plus_defconfig, multi_v7_defconfig and
multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for
omap5uevm.

I'll add OMAP5 to the automated boot testing starting with the next
linux-next.

Kevin
--
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

Re: [PATCH v2] ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle

[Kevin Hilman]

On Fri, Nov 15, 2013 at 8:12 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
 On Friday 15 November 2013 11:11 AM, Tony Lindgren wrote:
 * Taras Kondratiuk taras.kondrat...@linaro.org [131115 08:03]:
 On 11/15/2013 05:36 PM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [131114 10:36]:
 * Grygorii Strashko grygorii.stras...@ti.com [131022 12:09]:
 The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859
 ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ...
 need to be applied not only when system is booting, but when MPUSS hits
 OSWR state through CPUIdle too. Without this WA the same issue is
 reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460
 when CONFIG_CPU_IDLE is enabled.
 After MPUSS has enterred OSWR and waken up:
 - GIC distributor became disabled forever
 - scheduling is not performed any more

 Cc: Kevin Hilman khil...@linaro.org
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Reported-by: Taras Kondratiuk taras.kondrat...@linaro.org
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com

 Applying into omap-for-v3.13/fixes thanks.

 Hmm looks like this breaks the build with randconfigs at least
 with the attached .config, so dropping for now.

 Hi Tony
 Have you forgot to attach .config?

 Oops, sorry looks like I removed it already as I rebuilt the tree
 and started a new set of randconfig build tests.

 arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled':
 :(.text+0xb48c): undefined reference to `pm44xx_errata'

 I assume that .config doesn't have CONFIG_SMP enabled while
 pm44xx_errata is defined in omap-smp.c.
 I think it should be a separate patch to move pm44xx_errata somewhere
 else, so this patch will remain the same.

 Yes something like that probably. Sounds like that should be then
 patches before this fix.

 Btw, do we need omap_enter_idle_coupled() in UP?

 That should be checked, am43xx may need it.

 Nope. omap_enter_idle_coupled() is needed only for SMP
 systems. UP don't need couple idle functionality as
 such.

So what's the status of this fix and dependencies?

Both linux-next[1] and arm-soc/for-next[2] are failing boot tests on
omap4460/panda-es because multi_v7_defconfig now has CPUidle enabled
by default.

Kevin

[1] 
http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001891.html
[2] 
http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001898.html
--
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

Re: [GIT PULL 1/4] non-urgent omap fixes for v3.14 merge window

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:

   Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.14/fixes-not-urgent-signed

 for you to fetch changes up to bbc28cdbd003be5ceeaf644be3533e898c25da2b:

   ARM: OMAP2+: gpmc: Move legacy GPMC width setting (2014-01-08 09:49:47 
 -0800)

 
 Some non-urgent fixes to enable am335x features, update documentation,
 and to remove unnecessary double initialization for the GPMC code.

 

Thanks, adding to next/fixes-non-critical.

Kevin
--
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

Re: [GIT PULL 3/4] trivial omap big endian changes for v3.14 merge window

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:

   Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.14/be-signed

 for you to fetch changes up to fc6ca98c81bf0ea8b46064915b5947b971594101:

   ARM: OMAP: debug-leds: raw read and write endian fix (2014-01-07 16:09:45 
 -0800)

 
 Trivial search and replace of read and write functions to allow
 further patches to make omaps work also in big endian mode.

 

I think this one should wait for v3.15.  While a trivial rename, it's a
pretty broad change and risks having conflicts and fallouts with other
changes (thinking especially of ongoing clock changes.)

Kevin
--
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

Re: [GIT PULL 2/4] omap device tree fixes for v3.14 merge window

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit adfe9361b236154215d4b0fc8b6d79995394b15c:

   ARM: dts: Add basic devices on am3517-evm (2013-12-08 14:15:46 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.14/dt-signed

 for you to fetch changes up to e37e1cb0ee231ffdc9b5ef1da63a0c7e1077c603:

   ARM: dts: OMAP2: fix interrupt number for rng (2014-01-08 10:24:44 -0800)

 
 Split omap3 core padconf area into two as some of the registers in
 the padconf area are not accessible and used for other devices.
 Also fix the interrupt number for omap2 RNG, and add basic support
 for sbc-3xxx with cm-t3730.

 Note that the minor merge conflicts for omap_hwmod_2xxx_ipblock_data.c
 can be solved by just dropping the legacy hwmod data for interrupts
 for v3.14.

 

Applying to next/fixes-non-critical.

Kevin
--
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

Re: [GIT PULL 4/4] GIC crossbar support for v3.14 merge window

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:

   Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.14/crossbar-signed

 for you to fetch changes up to 70d4545544853e2d95909b919d4565ff32c3e3c5:

   ARM: DRA: Enable Crossbar IP support for DRA7XX (2014-01-08 09:21:42 -0800)

 
 Add support for GIC crossbar that routes interrupts on newer omaps.

 

I think this one is a little late for v3.14 also, and should spend some
more time in -next before v3.15.  Also...

 Sricharan R (4):
   irqchip: irq-gic: Add support for routable irqs

... I see a Reviewed-by from tglx on this one...

   irqchip: crossbar: Add support for Crossbar IP

...but no signs of irqchip mainainer review/ack on this one.

Ideally, these two irqchip ones would be merged through the irqchip
maintainers...

   ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
   ARM: DRA: Enable Crossbar IP support for DRA7XX

.. and then we'd take these two through arm-soc.

If there are strong dependencies, we can take them all through arm-soc,
but I'd like to see the tags from the irqchip maintainers first.

Kevin
--
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

Re: [GIT PULL] omap display regression fix against v3.13-rc4

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:

   Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.13/display-fix

 for you to fetch changes up to 130f769e81fc472beb2211320777e26050e3fa15:

   Revert ARM: OMAP2+: Remove legacy mux code for display.c (2013-12-17 
 16:28:34 -0800)

 
 I accidentally removed some mux code for omap4 that I thought was
 dead code as omap4 has been booting with device tree only since
 v3.10. Turns out I also removed some display related mux code,
 so let's revert that except for the dead code parts.

 

Pulled into fixes,

Thanks,

Kevin
--
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

Re: [GIT PULL] make omap24xx boot in dt mode only, prepare omap3 to drop legacy booting for v3.14

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 * Tony Lindgren t...@atomide.com [131210 12:27]:
 The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:
 
   ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 

 Sorry forgot to push the new tag, the link is:

 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.14/board-removal-safe
  

Pulled into next/boards.

Thanks,

Kevin
--
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

Re: [GIT PULL] ARM: OMAP2+: hwmod code/data: fixes for v3.13-rc

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 Arnd, Kevin, Olof,

 Care to pull this one from Paul into the fixes too?


Pulled into fixes,

Thanks,

Kevin


 Tony

 * Paul Walmsley p...@pwsan.com [131209 11:08]:
 Hi Tony,
 
 The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
 
   Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/for-v3.13-rc/hwmod-fixes-a
 
 for you to fetch changes up to 0e7dc862cf687234ed1b01a6b2461b782ea0bca0:
 
   ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is 
 not present (2013-12-09 11:51:30 -0700)
 
 
 ARM: OMAP2+: hwmod code/data: fixes for v3.13-rc
 
 Fix a few hwmod code problems involving recovery with bad data and bad
 IP block OCP reset handling.  Also, fix the hwmod data to enable IP
 block OCP reset for the OMAP USBHOST devices on OMAP3+.
 
 Basic build, boot, and PM tests are available here:
 
 http://www.pwsan.com/omap/testlogs/prcm_fixes_a_v3.13-rc/20131209030611/
 
 
 Nishanth Menon (1):
   ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node 
 is not present
 
 Roger Quadros (3):
   ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
   ARM: OMAP2+: hwmod: Fix SOFTRESET logic
   ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module
 
  arch/arm/mach-omap2/omap_hwmod.c   | 45 
 +-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 ++---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 ++---
  4 files changed, 52 insertions(+), 31 deletions(-)
 
--
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

Re: [GIT PULL] wl1251 platform data changes for v3.14

[Kevin Hilman]

Hi Tony,

Tony Lindgren t...@atomide.com writes:

 The following changes since commit 736e812636ea72be444b85fa7e92554967459069:

   ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 
 14:15:46 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.14/omap3-board-removal-wl1251

 for you to fetch changes up to ce226391aec803a49b39c22d3385057c9db02f30:

   Merge branch 'wl1251-pdata' into omap-for-v3.14/omap3-board-removal 
 (2013-12-09 19:39:51 -0800)

 

 Minimal changes for the wl151 platform data that would otherwise
 cause merge conflicts between the wireless tree and linux-omap
 tree. This was discussed on the mailing lists here:

 http://www.spinics.net/lists/linux-omap/msg99906.html

 
 Luciano Coelho (1):
   wl1251: split wl251 platform data to a separate structure

 Sebastian Reichel (1):
   wl1251: move power GPIO handling into the driver

 Tony Lindgren (1):
   Merge branch 'wl1251-pdata' into omap-for-v3.14/omap3-board-removal

  drivers/net/wireless/ti/wilink_platform_data.c | 37 
 +-
  drivers/net/wireless/ti/wl1251/sdio.c  | 31 ++---
  drivers/net/wireless/ti/wl1251/spi.c   | 35 +++-
  drivers/net/wireless/ti/wl1251/wl1251.h|  2 +-
  include/linux/wl12xx.h | 24 +++--
  5 files changed, 97 insertions(+), 32 deletions(-)

This was sent as a pull request to arm-soc, but looks like it should be
going through the net tree.

Kevin
--
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

Re: [PATCH] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 * Kevin Hilman khil...@linaro.org [131209 08:07]:
 Tony Lindgren t...@atomide.com writes:
 
  * Nishanth Menon n...@ti.com [131203 17:40]:
  Due to the cross dependencies between hwmod for automanaged device
  information for OMAP and dts node definitions, we can run into scenarios
  where the dts node is defined, however it's hwmod entry is yet to be
  added. In these cases:
  a) omap_device does not register a pm_domain (since it cannot find
 hwmod entry).
  b) driver does not know about (a), does a pm_runtime_get_sync which
 never fails
  c) It then tries to do some operation on the device (such as read the
revision register (as part of probe) without clock or adequate OMAP
generic PM operation performed for enabling the module.
  
  This causes a crash such as that reported in:
  https://bugzilla.kernel.org/show_bug.cgi?id=66441
  
  When 'ti,hwmod' is provided in dt node, it is expected that the device
  will not function without the OMAP's power automanagement. Hence, when
  we hit a fail condition (due to hwmod entries not present or other
  similar scenario), fail at pm_domain level due to lack of data, provide
  enough information for it to be fixed, however, it allows for the driver
  to take appropriate measures to prevent crash.
 
  Kevin, any comments on this one?
 
 Looks like a good approach to catch these corner cases.
 
 Acked-by: Kevin Hilman khil...@linaro.org

 Kevin, care to apply this directly?

 Acked-by: Tony Lindgren t...@atomide.com 

Applied.

Kevin
--
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

Re: [RFC/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

[Kevin Hilman]

Chao Xu caesarxuc...@gmail.com writes:

 From: Felipe Balbi ba...@ti.com

 try to keep gpio block suspended as much as possible.

 Tested with pandaboard and a sysfs exported gpio.

 Signed-off-by: Felipe Balbi balbi at ti.com

 [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added
 revision check to enable aggressive pm_runtime on OMAP4-only. Because
 am33xx_gpio_sysc.idlemodes seems to be wrongly marked as
 SIDLE_SMART_WKUP, which might cause missed interrupts with this patch.
 Tested on Pandaboard rev A2.]
 Signed-off-by: Chao Xu caesarxuc...@gmail.com

I have several problems with this patch.

First, the changelog is missing a lot of information.  In particular, nowhere
is it described what problem is this patch addressing  and how this
patch addresses that problem.

Second, I don't see any mention of off-mode, and I suspect there are
issues with off-mode here that are not being addressed.

Also, I *really* don't like any approach that is targetted at a single
SoC.

Kevin
--
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

Re: [PATCH] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 * Nishanth Menon n...@ti.com [131203 17:40]:
 Due to the cross dependencies between hwmod for automanaged device
 information for OMAP and dts node definitions, we can run into scenarios
 where the dts node is defined, however it's hwmod entry is yet to be
 added. In these cases:
 a) omap_device does not register a pm_domain (since it cannot find
hwmod entry).
 b) driver does not know about (a), does a pm_runtime_get_sync which
never fails
 c) It then tries to do some operation on the device (such as read the
   revision register (as part of probe) without clock or adequate OMAP
   generic PM operation performed for enabling the module.
 
 This causes a crash such as that reported in:
 https://bugzilla.kernel.org/show_bug.cgi?id=66441
 
 When 'ti,hwmod' is provided in dt node, it is expected that the device
 will not function without the OMAP's power automanagement. Hence, when
 we hit a fail condition (due to hwmod entries not present or other
 similar scenario), fail at pm_domain level due to lack of data, provide
 enough information for it to be fixed, however, it allows for the driver
 to take appropriate measures to prevent crash.

 Kevin, any comments on this one?

Looks like a good approach to catch these corner cases.

Acked-by: Kevin Hilman khil...@linaro.org
--
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