Re: [PATCH v2 0/8] Per-user clock constraints

On 9 October 2014 03:32, Stephen Boyd wrote: > On 10/07/2014 08:21 AM, Tomeu Vizoso wrote: >> >> Hello, >> >> this second version of the series adds several cleanups that were >> suggested by >> Stephen Boyd and contains several improvements to the seventh patch (clk: >> Make >> clk API return per

Re: [PATCH 12/13] tty: serial: 8250: omap: add custom irq handling

On Mon, Sep 29, 2014 at 08:06:48PM +0200, Sebastian Andrzej Siewior wrote: > We have (or will have) custom DMA callbacks in the omap driver due to > the different behaviour in the RX and TX case. To make this work > we need a few changes in the IRQ handler to invoke the rx_handler again > after the

[RFC PATCH 3/6] ARM: OMAP4: hwmod: set DSS submodule parent hwmods

Set DSS core hwmod as the parent for all the DSS submodules. Signed-off-by: Tomi Valkeinen --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_d

[RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support

Add parent_hwmod pointer to omap_hwmod. This can be set to point to a "parent" hwmod that needs to be enabled for the "child" hwmod to work. This is used at hwmod setup time: when doing the initial setup and reset, first enable the parent hwmod, and after setup and reset is done, restore the paren

[RFC PATCH 2/6] ARM: OMAP5: hwmod: set DSS submodule parent hwmods

Set DSS core hwmod as the parent for all the DSS submodules. Signed-off-by: Tomi Valkeinen --- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c index 1103aa

[RFC PATCH 4/6] ARM: OMAP4: hwmod: use MODULEMODE properly

Instead of using a hacky "dss_fck" clock (which toggles the MODULEMODE bit) as DSS L3 interface clock, set the .modulemode field in the omap44xx_dss_hwmod. This works now that the DSS core hwmod is enabled during DSS submodule resets. Signed-off-by: Tomi Valkeinen --- arch/arm/mach-omap2/omap_hw

[RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods

This is an RFC to fix the issues with boot time DSS hwmod setup. There was an earlier series sent by Archit here: http://www.spinics.net/lists/linux-omap/msg107700.html This series takes different approach, and just tries to fix the issue at setup time by making sure the DSS core hwmod is enable

[RFC PATCH 5/6] ARM: OMAP4: fix RFBI iclk

RFBI iclk was set to point to hacky "dss_fck", which will be removed. Instead use "l3_div_ck", which is the proper clock for this. "l3_div_ck" is the parent of "dss_fck", so the clock rate is the same as previously. Signed-off-by: Tomi Valkeinen --- arch/arm/boot/dts/omap4.dtsi | 2

[RFC PATCH 6/6] ARM: dts: omap4.dtsi: remove dss_fck

"dss_fck" is a hacky clock, used to work around problems with MODULEMODE bit handling in DSS hwmods. These problems have now been solved, so we can remove the dss_fck clock. Signed-off-by: Tomi Valkeinen --- arch/arm/boot/dts/omap44xx-clocks.dtsi | 8 1 file changed, 8 deletions(-) di

[PATCH v3 0/8] Per-user clock constraints

Hello, this third version of the series is basically just a rebase on top of linux-next 20141009. The first six patches are just cleanups that should be desirable on their own, and that should make easier to review the actual per-user clock patch. The seventh patch actually moves the per-clock

[PATCH v3 7/8] clk: Make clk API return per-user struct clk instances

y: Tomeu Vizoso --- v3: * Rebase on top of linux-next 20141009 v2: * Remove exported functions that aren't really used outside clk.c * Rename new internal functions to clk_core_ prefix * Remove redundant checks for error pointers in *_get_parent * Change __cl

Re: RCU bug with v3.17-rc3 ?

Hi Felipe, On Wed, Oct 08, 2014 at 04:29:38PM -0500, Felipe Balbi wrote: > Finally bisected it down to commit 139e561660fe11e0fc35e142a800df3dd7d03e9d > (lib: radix_tree: tree node interface). Here's full bisect log: > > git bisect start > # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux

Re: RCU bug with v3.17-rc3 ?

Hi Johannes, On Thu, Oct 09, 2014 at 12:01:38PM -0400, Johannes Weiner wrote: > On Wed, Oct 08, 2014 at 04:29:38PM -0500, Felipe Balbi wrote: > > Finally bisected it down to commit 139e561660fe11e0fc35e142a800df3dd7d03e9d > > (lib: radix_tree: tree node interface). Here's full bisect log: > > > >

Re: [RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support

Hi, On Thu, Oct 9, 2014 at 7:33 PM, Tomi Valkeinen wrote: > Add parent_hwmod pointer to omap_hwmod. This can be set to point to a > "parent" hwmod that needs to be enabled for the "child" hwmod to work. > > This is used at hwmod setup time: when doing the initial setup and > reset, first enable t

Re: [RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods

On Thu, Oct 9, 2014 at 7:33 PM, Tomi Valkeinen wrote: > This is an RFC to fix the issues with boot time DSS hwmod setup. > > There was an earlier series sent by Archit here: > > http://www.spinics.net/lists/linux-omap/msg107700.html > > This series takes different approach, and just tries to fix t

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

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

cpuidle - minimum time for sleep

Hello, Does anybody know what is the minimum expected time for sleep period with the cpuidle ? I intend t use the menu governer, and I try to estimate the sleep time. Thanks, Ran -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.k

Re: cpuidle - minimum time for sleep

On Thu, 09 Oct 2014 21:28:23 +0300, Ran Shalit said: > Does anybody know what is the minimum expected time for sleep period > with the cpuidle ? Both processor dependent and sleep level dependent. There's a certain amount of latency induced by the hardware waking up. Look at /sys/devices/system

[PATCH 05/12] rtc: omap: remove redundant debug message

Remove redundant debug message. The corresponding error has already been logged by rtc core. Signed-off-by: Johan Hovold --- drivers/rtc/rtc-omap.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index d1b5562a148b..e50ff

[PATCH 02/12] rtc: omap: fix missing wakealarm attribute

The platform device must be registered as wakeup capable before registering the class device, or the wakealarm attribute will not be created. Also make sure to unregister the wakeup source on probe errors. Fixes: 1d2e2b65d098 ("rtc: omap: restore back (hard-code) wakeup support") Cc: stable Sign

[PATCH 00/12] rtc: omap: fixes and power-off feature

This series fixes a few issues with the omap rtc-driver, cleans up a bit and finally adds support for the PMIC control feature found in some revisions of this RTC IP block. Ultimately, this allows for powering off the Beaglebone and waking it up again on RTC alarms. I noticed yesterday that Lokes

[PATCH 03/12] rtc: omap: fix class-device registration

Make sure not to register the class device until after it has been configured and interrupt handlers registered at probe. Currently, the device is not fully configured (e.g. 24-hour mode) when the class device is registered, something which involves driver callbacks for example to read the current

[PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

Some legacy RTC IP revisions has a power-up reset flag in the status register that later revisions lack. As this flag is always read back as set on later revisions (or is overloaded with a different flag), make sure to only clear the flag and print the info message on legacy platforms. Signed-off

[PATCH 04/12] rtc: omap: remove unused register-base define

Remove register-base define, which is no longer used. Signed-off-by: Johan Hovold --- drivers/rtc/rtc-omap.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index 2eca141e784e..d1b5562a148b 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc

[PATCH 01/12] rtc: omap: fix clock-source configuration

Make sure not to reset the clock-source configuration when enabling the 32kHz clock mux. Until the clock source can be configured through device tree we must not overwrite settings made by the bootloader (e.g. clock-source selection). Fixes: cd914bba03d8 ("drivers/rtc/rtc-omap.c: add support for

[PATCH 10/12] rtc: omap: enable wake-up from power off

The ALARM interrupt must not be disabled during shutdown in order to be able to power up the system using an RTC alarm. Signed-off-by: Johan Hovold --- drivers/rtc/rtc-omap.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-om

[PATCH 12/12] ARM: dts: am335x-bone-common: enable power off and rtc wake up

Configure the RTC as system-power controller, which allows the system to be powered off as well as woken up again on subsequent RTC alarms. Note that the PMIC needs to be put in SLEEP (rather than OFF) mode to maintain RTC power. Specifically, this means that the PMIC ti,pmic-shutdown-controller p

[PATCH 09/12] rtc: omap: add support for pmic_power_en

Add new property "ti,system-power-controller" to register the RTC as a power-off handler. Some RTC IP revisions can control an external PMIC via the pmic_power_en pin, which can be configured to transition to OFF on ALARM2 events and back to ON on subsequent ALARM (wakealarm) events. This is base

[PATCH 11/12] ARM: dts: am33xx: update rtc node compatible property

Enable am33xx specific RTC features (e.g. PMIC control) by adding "ti,am3352-rtc" to the compatible property of the rtc node. Signed-off-by: Johan Hovold --- arch/arm/boot/dts/am33xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm

Re: cpuidle - minimum time for sleep

On 10/09/2014 02:01 PM, valdis.kletni...@vt.edu wrote: > On Thu, 09 Oct 2014 21:28:23 +0300, Ran Shalit said: > >> Does anybody know what is the minimum expected time for sleep period >> with the cpuidle ? > > Both processor dependent and sleep level dependent. There's a certain > amount of late

[PATCH 08/12] rtc: omap: restore irq state after reading TC registers

Make sure to restore local irq state when reading the timer/calendar (TC) registers, so that omap_rtc_read_time() can be called with interrupts disabled. Signed-off-by: Johan Hovold --- drivers/rtc/rtc-omap.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/r

[PATCH 06/12] rtc: omap: use dev_info and dev_dbg

Use dev_info and dev_dbg rather than pr_info and pr_debug. Signed-off-by: Johan Hovold --- drivers/rtc/rtc-omap.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index e50ffd7063f5..1c58920b0c88 100644 --- a

Re: RCU bug with v3.17-rc3 ?

Hi, On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote: > > I'm thinking it's not the slot pointer itself that's bad, because > > __radix_tree_lookup() dereferences that to test if it's populated > > before returning it, and slot life-time is guaranteed by RCU. > > > > That would only l

Re: RCU bug with v3.17-rc3 ?

On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote: > alright, it's pretty deterministic however. Always on the same test, no > matter which USB controller, no matter if backing store is RAM or MMC. > > Those two undefined instructions on the disassembly caught my attention, > perhaps I'

Re: RCU bug with v3.17-rc3 ?

Hi, On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote: > On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote: > > alright, it's pretty deterministic however. Always on the same test, no > > matter which USB controller, no matter if backing store is RAM or MMC. > > > > Those t

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

Tony Lindgren 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 no

Re: RCU bug with v3.17-rc3 ?

Hi, On Thu, Oct 09, 2014 at 03:46:37PM -0500, Felipe Balbi wrote: > On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote: > > On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote: > > > alright, it's pretty deterministic however. Always on the same test, no > > > matter which USB

Re: RCU bug with v3.17-rc3 ?

Hi, On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote: > What GCC version are you using? > > 4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these > find_get_entry() crashes with 0x involved smell a lot like the > earlier reports from kernels build with th

Re: [PATCH v3 7/8] clk: Make clk API return per-user struct clk instances

On 10/09, Tomeu Vizoso wrote: > arch/arm/mach-omap2/cclock3xxx_data.c | 108 -- > arch/arm/mach-omap2/clock.h | 11 +- > arch/arm/mach-omap2/clock_common_data.c | 5 +- > drivers/clk/clk.c | 630 > > drivers/clk/clk.h

Re: [PATCH v3 7/8] clk: Make clk API return per-user struct clk instances

Kodiak Furr liked your message with Boxer for Android. On Oct 9, 2014 6:22 PM, Stephen Boyd wrote: > > On 10/09, Tomeu Vizoso wrote: > >  arch/arm/mach-omap2/cclock3xxx_data.c   | 108 -- > >  arch/arm/mach-omap2/clock.h |  11 +- > >  arch/arm/mach-omap2/clock_common_data.c |