Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Aaro Koskinen]

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> From: Tony Lindgren <t...@atomide.com>
> Date: Tue, 5 Jan 2016 12:04:20 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
>  corruption
> 
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> unified the GPMC debug for the SoCs with GPMC. The commit also left
> out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> for GPMC to be able to remap GPMC devices out of address 0.
> 
> Unfortunately on 900, onenand now only partially works with the device
> tree provided timings. It works enough to get detected but the clock
> rate supported by the onenand chip gets misdetected. This in turn causes
> the GPMC timings to be miscalculated and this leads into file system
> corruption on n900.
> 
> Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> write. This is needed also for async timings when we write to onenand
> with omap2_onenand_set_async_mode(). Without sync write bit set, the
> async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> 
> Let's exit with an error if onenand rate is not detected. And let's
> remove the extra call to omap2_onenand_set_async_mode() as we only
> need to do this once at the end of omap2_onenand_setup_async().
> 
> Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

This fixes also the detection issue on N950. Also tested the patch
with N810.

Tested-by: Aaro Koskinen <aaro.koski...@iki.fi>

A.

> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -149,8 +149,8 @@ static int omap2_onenand_get_freq(struct 
> omap_onenand_platform_data *cfg,
>   freq = 104;
>   break;
>   default:
> - freq = 54;
> - break;
> + pr_err("onenand rate not detected, bad GPMC async timings?\n");
> + freq = 0;
>   }
>  
>   return freq;
> @@ -271,6 +271,11 @@ static int omap2_onenand_setup_async(void __iomem 
> *onenand_base)
>   struct gpmc_timings t;
>   int ret;
>  
> + /*
> +  * Note that we need to keep sync_write set for the call to
> +  * omap2_onenand_set_async_mode() to work to detect the onenand
> +  * supported clock rate for the sync timings.
> +  */
>   if (gpmc_onenand_data->of_node) {
>   gpmc_read_settings_dt(gpmc_onenand_data->of_node,
> _async);
> @@ -281,12 +286,9 @@ static int omap2_onenand_setup_async(void __iomem 
> *onenand_base)
>   else
>   gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
>   onenand_async.sync_read = false;
> - onenand_async.sync_write = false;
>   }
>   }
>  
> - omap2_onenand_set_async_mode(onenand_base);
> -
>   omap2_onenand_calc_async_timings();
>  
>   ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, _async);
> @@ -310,6 +312,8 @@ static int omap2_onenand_setup_sync(void __iomem 
> *onenand_base, int *freq_ptr)
>   if (!freq) {
>   /* Very first call freq is not known */
>   freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
> + if (!freq)
> + return -ENODEV;
>   set_onenand_cfg(onenand_base);
>   }
>  
--
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] mtd: onenand: omap2: Simplify the DMA setup for various paths

[Aaro Koskinen]

Hi,

On Fri, Dec 18, 2015 at 10:39:48AM -0800, Tony Lindgren wrote:
> * Brian Norris  [151218 10:11]:
> > On Mon, Dec 14, 2015 at 11:49:32AM +0200, Peter Ujfalusi wrote:
> > > We have 4 functions containing almost identical DMA setup code. Create one
> > > function which can set up the DMA for both read and write and use this in
> > > place for the setup code in the driver.
> > > The new function will use wait_for_completion_timeout() and it will figure
> > > out the best data_type to be used for the transfer instead of hardwiring
> > > 32 or 16 bit data.
> > > 
> > > Signed-off-by: Peter Ujfalusi 
> > 
> > Does anyone use this driver? I've seen practically zero activity on the
> > entire OneNAND codebase in the last few years, and I presumed it was
> > essentially dead.
> > 
> > If it's not dead, I'd like to know some contingency of people who are
> > willing to actually maintain (or at least review) this stuff.
> > 
> > Kyungmin, are you still out there? Or Tony, do you know of any users for
> > this?
> > 
> > Peter, are you actually using this, or are you just refactoring for the
> > fun of it?
> 
> It's used for n8x0 and n900, but mostly in read-only mode. I suggest we

It's also used on n9/n950 phones. Also write functionality is needed
for mtdoops and kernel flashing.

> remove the DMA support for it completely because of the following:
> 
> 1. The DMA support for this driver is not done correctly. The pin used
>as GPIO should be used as external DMA request line.
> 
> 2. AFAIK the DMA for this driver is mostly disabld, probably largely
>due to #1 above
> 
> 3. If we remove DMA support, we can then easily switch to use the
>generic onenand driver.
> 
> I'd like to hear Aaro's comments too before doing this tough.

Probably DMA support is not that critical. Looks like with DT boot it's
not even possible to enable it at the moment.

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

[PATCH] ARM: OMAP: RX-51: fix a typo in log writing

[Aaro Koskinen]

Fix a typo when registering HW RNG.

Signed-off-by: Aaro Koskinen <aaro.koski...@iki.fi>
---
 arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
 arch/arm/mach-omap2/pdata-quirks.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 14edcd7..ff1520b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1257,7 +1257,7 @@ static struct platform_device omap3_rom_rng_device = {
 static void __init rx51_init_omap3_rom_rng(void)
 {
if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
-   pr_info("RX-51: Registring OMAP3 HWRNG device\n");
+   pr_info("RX-51: Registering OMAP3 HWRNG device\n");
platform_device_register(_rom_rng_device);
}
 }
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 1dfe346..35ea6c0 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -268,7 +268,7 @@ static void __init nokia_n900_legacy_init(void)
pr_warn("Thumb binaries may crash randomly without this 
workaround\n");
}
 
-   pr_info("RX-51: Registring OMAP3 HWRNG device\n");
+   pr_info("RX-51: Registering OMAP3 HWRNG device\n");
platform_device_register(_rom_rng_device);
 
}
-- 
2.4.0

--
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: [4.4-rc][PATCH] gpio: omap: drop omap1 mpuio specific irq_mask/unmask callbacks

[Aaro Koskinen]

Hi,

On Fri, Nov 20, 2015 at 03:35:14PM +0200, Grygorii Strashko wrote:
> Originally OMAP MPUIO GPIO irqchip was implemented using Generic irq
> chip, but after set of reworks Generic irq chip code was replaced by
> common OMAP GPIO implementation and finally removed by
> commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> Unfortunately, above commit left .irq_mask/unmask callbacks assigned
> as below for MPUIO GPIO case:
>   irqc->irq_mask = irq_gc_mask_set_bit;
>   irqc->irq_unmask = irq_gc_mask_clr_bit;
> 
> This now causes boot failure on OMAP1 platforms, after
> commit 450fa54cfd66 ("gpio: omap: convert to use generic irq handler")
> which forces these callbacks to be called during GPIO IRQs mapping
> from gpiochip_irq_map:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 
> pgd = c0004000
> [] *pgd=
> Internal error: Oops: 75 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.4.0-rc1-e3-los_afe0c+-2-g25379c0-dirty #1
> Hardware name: Amstrad E3 (Delta)
> task: c1836000 ti: c1838000 task.ti: c1838000
> PC is at irq_gc_mask_set_bit+0x1c/0x60
> LR is at __irq_do_set_handler+0x118/0x15c
> pc : []lr : []psr: 60d3
> sp : c1839c90  ip : c1862c64  fp : c1839c9c
> r10:   r9 : c0411950  r8 : c0411bbc
> r7 :   r6 : c185c310  r5 : c00444e8  r4 : c185c300
> r3 : c1854b50  r2 :   r1 :   r0 : c185c310
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> Control: 317f  Table: 10004000  DAC: 0057
> Process swapper (pid: 1, stack limit = 0xc1838190)
> Stack: (0xc1839c90 to 0xc183a000)
> 
> [...]
> 
> Backtrace:
> [] (irq_gc_mask_set_bit) from [] 
> (__irq_do_set_handler+0x118/0x15c)
> [] (__irq_do_set_handler) from [] 
> (__irq_set_handler+0x44/0x5c)
>  r6: r5:c00444e8 r4:c185c300
> [] (__irq_set_handler) from [] 
> (irq_set_chip_and_handler_name+0x30/0x34)
>  r7:0050 r6: r5:c00444e8 r4:0050
> [] (irq_set_chip_and_handler_name) from [] 
> (gpiochip_irq_map+0x3c/0x8c)
>  r7:0050 r6: r5:0050 r4:c1862c64
> [] (gpiochip_irq_map) from [] 
> (irq_domain_associate+0x7c/0x1c4)
>  r5:c185c310 r4:c185cb00
> [] (irq_domain_associate) from [] 
> (irq_domain_add_simple+0x98/0xc0)
>  r8:c0411bbc r7:c185cb00 r6:0050 r5:0010 r4:0001
> [] (irq_domain_add_simple) from [] 
> (_gpiochip_irqchip_add+0x64/0x10c)
>  r7:c1862c64 r6:c0419280 r5:c1862c64 r4:c1854b50
> [] (_gpiochip_irqchip_add) from [] 
> (omap_gpio_probe+0x2fc/0x63c)
>  r5:c1854b50 r4:c1862c10
> [] (omap_gpio_probe) from [] 
> (platform_drv_probe+0x2c/0x64)
>  r10: r9:c03e45e8 r8: r7:c0419294 r6:c0411984 r5:c0419294
>  r4:c0411950
> [] (platform_drv_probe) from [] (really_probe+0x160/0x29c)
> 
> Hence, fix it by remove obsolete callbacks assignment. After this
> changeomap_gpio_mask_irq()/omap_gpio_unmask_irq() will be used
> for MPUIO IRQs masking, but this now happens anyway from
> omap_gpio_irq_startup/shutdown().
> 
> Cc: Tony Lindgren <t...@atomide.com>
> Fixes: commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts")
> Reported-by: Aaro Koskinen <aaro.koski...@iki.fi>
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Tested-by: Aaro Koskinen <aaro.koski...@iki.fi>

> ---
>  drivers/gpio/gpio-omap.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 56d2d02..f7fbb46 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1122,8 +1122,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
> struct irq_chip *irqc)
>   /* MPUIO is a bit different, reading IRQ status clears it */
>   if (bank->is_mpuio) {
>   irqc->irq_ack = dummy_irq_chip.irq_ack;
> - irqc->irq_mask = irq_gc_mask_set_bit;
> - irqc->irq_unmask = irq_gc_mask_clr_bit;
>   if (!bank->regs->wkup_en)
>   irqc->irq_set_wake = NULL;
>   }
> -- 
> 2.6.3
> 
> --
> 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
--
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: [BISECTED] v4.4-rc1 GPIO regression on OMAP1

[Aaro Koskinen]

Hi,

On Thu, Nov 19, 2015 at 01:57:37PM +0200, Grygorii Strashko wrote:
> On 11/18/2015 08:31 PM, Aaro Koskinen wrote:
> > On Wed, Nov 18, 2015 at 02:58:38PM +0200, Grygorii Strashko wrote:
> >> On 11/17/2015 11:42 PM, Aaro Koskinen wrote:
> >>> Amstrad E3 computer (OMAP1) boot crashes early with v4.4-rc1. Bisected to:
> >>>
> >>>   450fa54cfd66e3dda6eda26256637ee8928af12a is the first bad commit
> >>>   commit 450fa54cfd66e3dda6eda26256637ee8928af12a
> >>>   Author: Grygorii Strashko <grygorii.stras...@ti.com>
> >>>   Date:   Fri Sep 25 12:28:03 2015 -0700
> >>>   
> >>>   gpio: omap: convert to use generic irq handler
> >>
> >> Could you check pls if below change will solve this issue, pls?
> >>
> >> iff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> >> index 56d2d02..2905e0d 100644
> >> --- a/drivers/gpio/gpio-omap.c
> >> +++ b/drivers/gpio/gpio-omap.c
> >> @@ -1129,7 +1129,7 @@ static int omap_gpio_chip_init(struct gpio_bank 
> >> *bank,
> >> struct irq_chip *irqc)
> >>  }
> >>
> >>  ret = gpiochip_irqchip_add(>chip, irqc,
> >> -  irq_base, handle_bad_irq,
> >> +  irq_base, handle_simple_irq,
> >> IRQ_TYPE_NONE);
> > 
> 
> Thanks for testing it. But I'd like to ask you for more help here if possible 
> :)
> Above change is expected to fix the OMAP1 boot, but looking at the OMAP GPIO 
> code
> I think that MPUIO IRQ are not working :( and this functionality has been 
> broken 
> long time ago - commit "gpio: omap: convert to use generic irq handler" has 
> just 
> made hidden issue visible.
> (I've found only one OMAP1 board which uses MPUIO GPIO as IRQ (board-osk.c)).
> 
> So, could I ask you to test another change instead of previous one?
> 
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1122,8 +1122,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
> struct irq_chip *irqc)
> /* MPUIO is a bit different, reading IRQ status clears it */
> if (bank->is_mpuio) {
> irqc->irq_ack = dummy_irq_chip.irq_ack;
> -   irqc->irq_mask = irq_gc_mask_set_bit;
> -   irqc->irq_unmask = irq_gc_mask_clr_bit;
> if (!bank->regs->wkup_en)
> irqc->irq_set_wake = NULL;
> }

This fixes the boot crash issue as well...

> In my opinion real test will be
> - request(any MPUIO GPIO IRQ, IRQF_TRIGGER_LOW/HIGH), 
> - trigger MPUIO GPIO IRQ
> - free(MPUIO GPIO IRQ)

...but I don't think I can cover that with my boards (E3/770)?

Anyone willing to donate a 5912 OSK?

A.
--
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: [BISECTED] v4.4-rc1 GPIO regression on OMAP1

[Aaro Koskinen]

Hi,

On Wed, Nov 18, 2015 at 02:58:38PM +0200, Grygorii Strashko wrote:
> On 11/17/2015 11:42 PM, Aaro Koskinen wrote:
> >Amstrad E3 computer (OMAP1) boot crashes early with v4.4-rc1. Bisected to:
> >
> > 450fa54cfd66e3dda6eda26256637ee8928af12a is the first bad commit
> > commit 450fa54cfd66e3dda6eda26256637ee8928af12a
> > Author: Grygorii Strashko <grygorii.stras...@ti.com>
> > Date:   Fri Sep 25 12:28:03 2015 -0700
> > 
> > gpio: omap: convert to use generic irq handler
>
> Could you check pls if below change will solve this issue, pls?
> 
> iff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 56d2d02..2905e0d 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1129,7 +1129,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
> struct irq_chip *irqc)
> }
> 
> ret = gpiochip_irqchip_add(>chip, irqc,
> -  irq_base, handle_bad_irq,
> +  irq_base, handle_simple_irq,
>IRQ_TYPE_NONE);

This works!

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

[PATCH v2] hw_random: omap3-rom-rng: convert timer to delayed work

[Aaro Koskinen]

We cannot put the HW RNG to idle using a timer because we cannot disable
clocks from atomic context. Use a delayed work instead.

Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot.

Reported-by: Sebastian Reichel <s...@kernel.org>
Signed-off-by: Aaro Koskinen <aaro.koski...@iki.fi>
---

v2: Include workqueue.h instead of timer.h.

 drivers/char/hw_random/omap3-rom-rng.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/omap3-rom-rng.c 
b/drivers/char/hw_random/omap3-rom-rng.c
index a405cdc..8da14f1 100644
--- a/drivers/char/hw_random/omap3-rom-rng.c
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -29,11 +29,11 @@
 /* param1: ptr, param2: count, param3: flag */
 static u32 (*omap3_rom_rng_call)(u32, u32, u32);
 
-static struct timer_list idle_timer;
+static struct delayed_work idle_work;
 static int rng_idle;
 static struct clk *rng_clk;
 
-static void omap3_rom_rng_idle(unsigned long data)
+static void omap3_rom_rng_idle(struct work_struct *work)
 {
int r;
 
@@ -51,7 +51,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
u32 r;
u32 ptr;
 
-   del_timer_sync(_timer);
+   cancel_delayed_work_sync(_work);
if (rng_idle) {
clk_prepare_enable(rng_clk);
r = omap3_rom_rng_call(0, 0, RNG_GEN_PRNG_HW_INIT);
@@ -65,7 +65,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
 
ptr = virt_to_phys(buf);
r = omap3_rom_rng_call(ptr, count, RNG_GEN_HW);
-   mod_timer(_timer, jiffies + msecs_to_jiffies(500));
+   schedule_delayed_work(_work, msecs_to_jiffies(500));
if (r != 0)
return -EINVAL;
return 0;
@@ -102,7 +102,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   setup_timer(_timer, omap3_rom_rng_idle, 0);
+   INIT_DELAYED_WORK(_work, omap3_rom_rng_idle);
rng_clk = devm_clk_get(>dev, "ick");
if (IS_ERR(rng_clk)) {
pr_err("unable to get RNG clock\n");
@@ -118,6 +118,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
 
 static int omap3_rom_rng_remove(struct platform_device *pdev)
 {
+   cancel_delayed_work_sync(_work);
hwrng_unregister(_rom_rng_ops);
clk_disable_unprepare(rng_clk);
return 0;
-- 
2.4.0

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

[BISECTED] v4.4-rc1 GPIO regression on OMAP1

[Aaro Koskinen]

Hi,

Amstrad E3 computer (OMAP1) boot crashes early with v4.4-rc1. Bisected to:

450fa54cfd66e3dda6eda26256637ee8928af12a is the first bad commit
commit 450fa54cfd66e3dda6eda26256637ee8928af12a
Author: Grygorii Strashko 
Date:   Fri Sep 25 12:28:03 2015 -0700

gpio: omap: convert to use generic irq handler

Reverting the commit works (as a quick workaround at least).

The crash log:

[0.253612] Unable to handle kernel NULL pointer dereference at virtual 
address 
[0.262613] pgd = c0004000
[0.265754] [] *pgd=
[0.269862] Internal error: Oops: 75 [#1] ARM
[0.274734] Modules linked in:
[0.278313] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.4.0-rc1-e3-los_afe0c+-2-g25379c0-dirty #1
[0.288246] Hardware name: Amstrad E3 (Delta)
[0.293146] task: c1836000 ti: c1838000 task.ti: c1838000
[0.299155] PC is at irq_gc_mask_set_bit+0x1c/0x60
[0.304525] LR is at __irq_do_set_handler+0x118/0x15c
[0.310165] pc : []lr : []psr: 60d3
[0.310165] sp : c1839c90  ip : c1862c64  fp : c1839c9c
[0.322740] r10:   r9 : c0411950  r8 : c0411bbc
[0.328533] r7 :   r6 : c185c310  r5 : c00444e8  r4 : c185c300
[0.335687] r3 : c1854b50  r2 :   r1 :   r0 : c185c310
[0.342858] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.351153] Control: 317f  Table: 10004000  DAC: 0057
[0.357494] Process swapper (pid: 1, stack limit = 0xc1838190)
[0.363917] Stack: (0xc1839c90 to 0xc183a000)
[0.368837] 9c80: c1839cc4 c1839ca0 
c0047d4c c0048480
[0.377916] 9ca0:   0050 c185c300 c00444e8  
c1839cec c1839cc8
[0.386989] 9cc0: c0047dd4 c0047c44 c0046f40 a053 0050 c00444e8 
 0050
[0.396064] 9ce0: c1839d0c c1839cf0 c0047e1c c0047da0 c1862c64 0050 
 0050
[0.405139] 9d00: c1839d24 c1839d10 c01b345c c0047dfc c185cb00 c185c310 
c1839d54 c1839d28
[0.414214] 9d20: c0049670 c01b3430 c0075888 c0043440 c1854b50 0001 
0010 0050
[0.423293] 9d40: c185cb00 c0411bbc c1839d7c c1839d58 c0049894 c0049604 
 c1862c64
[0.432375] 9d60: c1854b50 c1862c64 c0419280 c1862c64 c1839d9c c1839d80 
c01b3328 c004980c
[0.441456] 9d80: c1862c64 c1862c64 c1862c10 c1854b50 c1839ddc c1839da0 
c01b79f4 c01b32d4
[0.450530] 9da0:   c0411958 c0419294  c0411950 
c0419294 c0411984
[0.459605] 9dc0: c0419294  c03e45e8  c1839df4 c1839de0 
c01fcf58 c01b7708
[0.468684] 9de0: c0411950 c045ce30 c1839e1c c1839df8 c01fb668 c01fcf3c 
c0411950 c0419294
[0.477759] 9e00: c0411984   c03e45e8 c1839e3c c1839e20 
c01fb844 c01fb518
[0.486836] 9e20:  c0419294 c01fb7a4  c1839e64 c1839e40 
c01f9a90 c01fb7b4
[0.495913] 9e40: c185434c c185b450 c185b514 c0419294 c185b4e0 c041d9c8 
c1839e74 c1839e68
[0.504991] 9e60: c01fb078 c01f9a28 c1839e9c c1839e78 c01facf8 c01fb068 
c03931d0 c1839e88
[0.514069] 9e80: c0419294 c040bb80 c1804960 c03f5a08 c1839eb4 c1839ea0 
c01fbdb0 c01fab7c
[0.523150] 9ea0: c040bb80 c040bb80 c1839ec4 c1839eb8 c01fcf18 c01fbd40 
c1839ed4 c1839ec8
[0.532227] 9ec0: c03f5a20 c01fcef0 c1839f4c c1839ed8 c000966c c03f5a18 
c1839efc c1839ee8
[0.541304] 9ee0: c03e4604 c019b3b4 c03e2700 c1ffcd34 c1839f4c c1839f00 
c00314ec c03e45f8
[0.550384] 9f00:   0002 0002  c03e2024 
c038f2fc 
[0.559465] 9f20: c1839f4c 0002 c03ff81c 0002 c03ff820 005e 
c042ba80 c042ba80
[0.568543] 9f40: c1839f94 c1839f50 c03e4e14 c00095f0 0002 0002 
 c03e45e8
[0.577625] 9f60: 9b7bd08b c0406660 ad19cf47  c0305764  
 
[0.586701] 9f80:   c1839fac c1839f98 c0305774 c03e4d18 
 c0305764
[0.595775] 9fa0:  c1839fb0 c000a440 c0305774   
 
[0.604845] 9fc0:       
 
[0.613916] 9fe0:     0013  
faef8a80 f438707c
[0.622908] Backtrace: 
[0.625894] [] (irq_gc_mask_set_bit) from [] 
(__irq_do_set_handler+0x118/0x15c)
[0.635897] [] (__irq_do_set_handler) from [] 
(__irq_set_handler+0x44/0x5c)
[0.645458]  r6: r5:c00444e8 r4:c185c300
[0.650746] [] (__irq_set_handler) from [] 
(irq_set_chip_and_handler_name+0x30/0x34)
[0.661128]  r7:0050 r6: r5:c00444e8 r4:0050
[0.667559] [] (irq_set_chip_and_handler_name) from [] 
(gpiochip_irq_map+0x3c/0x8c)
[0.677869]  r7:0050 r6: r5:0050 r4:c1862c64
[0.684300] [] (gpiochip_irq_map) from [] 
(irq_domain_associate+0x7c/0x1c4)
[0.693885]  r5:c185c310 r4:c185cb00
[0.698072] [] (irq_domain_associate) from [] 

Re: [BISECTED] v4.3-rc5: OMAP1 boot hang

[Aaro Koskinen]

Hi,

Any suggestions how to debug this further? This happens also with v4.3
final. Is the CPU_SW_DOMAIN_PAN supposed to work with this CPU?

I tried to disable various drivers (e.g. NAND, USB) and it still
hangs... And it seems always at the same printk time stamp (roughly at
25 seconds).

A.

On Tue, Oct 13, 2015 at 10:30:46AM +0300, Aaro Koskinen wrote:
> Hi,
> 
> Amstrad E3 / OMAP1 boot hangs, and I bisected it to
> a5e090acbf545c0a3b04080f8a488b17ec41fe02 ("ARM: software-based
> priviledged-no-access support").
> 
> Below is the boot log. Disabling CPU_SW_DOMAIN_PAN helps.
> 
> Uncompressing Linux... done, booting the kernel.
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpu
> [0.00] Linux version 4.3.0-rc5-e3-los_df2ad+ (aaro@amd-fx-6350) (gcc 
> version 5.2.0 (GCC) ) #1 Tue Oct 13 10:08:05 EEST 2015
> [0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f
> [0.00] CPU: VIVT data cache, VIVT instruction cache
> [0.00] Machine: Amstrad E3 (Delta)
> [0.00] Ignoring memory below PHYS_OFFSET: 0x0200-0x1000
> [0.00] Memory policy: Data cache writethrough
> [0.00] On node 0 totalpages: 8192
> [0.00] free_area_init_node: node 0, pgdat c0427018, node_mem_map 
> c1fb7000
> [0.00]   Normal zone: 64 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 8192 pages, LIFO batch:0
> [0.00] OMAP1510
> [0.00]  revision 2 handled as 15xx id: bc058c9b93111a16
> [0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2cb3 ARM_CKCTL: 0x250e
> [0.00] Clocking rate (xtal/DPLL1/MPU): 12.0/150.0/150.0 MHz
> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 8128
> [0.00] Kernel command line: mem=32M console=tty 
> console=ttyS0,115200n8 root=/dev/ram0 initrd=0x11c0,2894948 
> initcall_debug=1 loglevel=9
> [0.00] PID hash table entries: 128 (order: -3, 512 bytes)
> [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Memory: 25136K/32768K available (3074K kernel code, 141K 
> rwdata, 864K rodata, 140K init, 212K bss, 7632K reserved, 0K cma-reserved)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xc280 - 0xff00   ( 968 MB)
> [0.00] lowmem  : 0xc000 - 0xc200   (  32 MB)
> [0.00] modules : 0xbf00 - 0xc000   (  16 MB)
> [0.00]   .text : 0xc0008000 - 0xc03e0ec4   (3940 kB)
> [0.00]   .init : 0xc03e1000 - 0xc0404000   ( 140 kB)
> [0.00]   .data : 0xc0404000 - 0xc04277e0   ( 142 kB)
> [0.00].bss : 0xc04277e0 - 0xc045c9c0   ( 213 kB)
> [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] Total of 64 interrupts in 2 interrupt banks
> [0.000131] sched_clock: 32 bits at 6MHz, resolution 166ns, wraps every 
> 357913940908ns
> [0.000382] clocksource: mpu_timer2: mask: 0x max_cycles: 
> 0x, max_idle_ns: 318543407797 ns
> [0.001561] Console: colour dummy device 80x30
> [0.009527] console [tty0] enabled
> [0.010230] Calibrating delay loop... 74.13 BogoMIPS (lpj=370688)
> [0.100420] pid_max: default: 32768 minimum: 301
> [0.101672] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [0.102202] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
> bytes)
> [0.108589] CPU: Testing write buffer coherency: ok
> [0.111741] calling  init_static_idmap+0x0/0x11c @ 1
> [0.112570] Setting up static identity map for 0x10008400 - 0x1000842c
> [0.113178] initcall init_static_idmap+0x0/0x11c returned 0 after 0 usecs
> [0.113812] calling  spawn_ksoftirqd+0x0/0x30 @ 1
> [0.115210] initcall spawn_ksoftirqd+0x0/0x30 returned 0 after 0 usecs
> [0.115820] calling  init_workqueues+0x0/0x2ec @ 1
> [0.120426] initcall init_workqueues+0x0/0x2ec returned 0 after 9765 usecs
> [0.121133] calling  rand_initialize+0x0/0x34 @ 1
> [0.122426] initcall rand_initialize+0x0/0x34 returned 0 after 0 usecs
> [0.126229] devtmpfs: initialized
> [0.136417] calling  ipc_ns_init+0x0/0x44 @ 1
> [0.136959] initcall ipc_ns_init+0x0/0x44 returned 0 after 0 usecs
> [0.137461] calling  init_mmap_min_addr+0x0/0x2c @ 1
>

[PATCH] hw_random: omap3-rom-rng: convert timer to delayed work

[Aaro Koskinen]

We cannot put the HW RNG to idle using a timer because we cannot disable
clocks from atomic context. Use a delayed work instead.

Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot.

Reported-by: Sebastian Reichel <s...@kernel.org>
Signed-off-by: Aaro Koskinen <aaro.koski...@iki.fi>
---
 drivers/char/hw_random/omap3-rom-rng.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/char/hw_random/omap3-rom-rng.c 
b/drivers/char/hw_random/omap3-rom-rng.c
index a405cdc..58191c6 100644
--- a/drivers/char/hw_random/omap3-rom-rng.c
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -29,11 +29,11 @@
 /* param1: ptr, param2: count, param3: flag */
 static u32 (*omap3_rom_rng_call)(u32, u32, u32);
 
-static struct timer_list idle_timer;
+static struct delayed_work idle_work;
 static int rng_idle;
 static struct clk *rng_clk;
 
-static void omap3_rom_rng_idle(unsigned long data)
+static void omap3_rom_rng_idle(struct work_struct *work)
 {
int r;
 
@@ -51,7 +51,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
u32 r;
u32 ptr;
 
-   del_timer_sync(_timer);
+   cancel_delayed_work_sync(_work);
if (rng_idle) {
clk_prepare_enable(rng_clk);
r = omap3_rom_rng_call(0, 0, RNG_GEN_PRNG_HW_INIT);
@@ -65,7 +65,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
 
ptr = virt_to_phys(buf);
r = omap3_rom_rng_call(ptr, count, RNG_GEN_HW);
-   mod_timer(_timer, jiffies + msecs_to_jiffies(500));
+   schedule_delayed_work(_work, msecs_to_jiffies(500));
if (r != 0)
return -EINVAL;
return 0;
@@ -102,7 +102,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   setup_timer(_timer, omap3_rom_rng_idle, 0);
+   INIT_DELAYED_WORK(_work, omap3_rom_rng_idle);
rng_clk = devm_clk_get(>dev, "ick");
if (IS_ERR(rng_clk)) {
pr_err("unable to get RNG clock\n");
@@ -118,6 +118,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
 
 static int omap3_rom_rng_remove(struct platform_device *pdev)
 {
+   cancel_delayed_work_sync(_work);
hwrng_unregister(_rom_rng_ops);
clk_disable_unprepare(rng_clk);
return 0;
-- 
2.4.0

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

[PATCH] ARM: OMAP1: fix incorrect INT_DMA_LCD

[Aaro Koskinen]

Commit 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for
sparse IRQ") turned on SPARSE_IRQ on OMAP1, but forgot to change
the number of INT_DMA_LCD. This broke the boot at least on Nokia 770,
where the device hangs during framebuffer initialization.

Fix by defining INT_DMA_LCD like the other interrupts.

Cc: sta...@vger.kernel.org
Fixes: 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for sparse IRQ")
Signed-off-by: Aaro Koskinen <aaro.koski...@iki.fi>
---
 include/linux/omap-dma.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index e5a7013..88fa8af 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -17,7 +17,7 @@
 
 #include 
 
-#define INT_DMA_LCD25
+#define INT_DMA_LCD(NR_IRQS_LEGACY + 25)
 
 #define OMAP1_DMA_TOUT_IRQ (1 << 0)
 #define OMAP_DMA_DROP_IRQ  (1 << 1)
-- 
2.4.0

--
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: [BISECTED] Nokia 770 framebuffer breakage

[Aaro Koskinen]

On Mon, Oct 19, 2015 at 11:50:33PM +0100, Russell King - ARM Linux wrote:
> It shouldn't (I've been through the resulting assembly code.)  I wonder
> if this is fixing the problem, but it's now failing elsewhere instead.
> 
> What happens if you change it to:
> 
>   l = clkdev_create(r, alias, alias_dev_name);
> 
> which should be 100% identical to how older kernels behaved

Ok, this and the earlier patch works on top of
2568999835d7797afce3dcc3a3f368051ffcaf1f, but not on 4.2 or newer - so
it fixes the clk_add_alias issue, and newer kernels have other issues...

> if that works, can you print out 'alias' and 'alias_dev_name' for
> every call to clk_add_alias() and send that please?

There is only one call:

arch/arm/mach-omap1/board-nokia770.c:   clk_add_alias("hwa_sys_ck", NULL, 
"bclk", NULL);

With newer kernels and this fix the kernel now hangs during FB
initialization. I tried to bisect it and it seemed to point to OMAP1
sparse IRQ changes. Unfortunately those are difficult to test because
e.g. commit 685e2d08c54b1a1bf31bbe6562f06db089d31c7b does not seem to
compile without some other changes...

Below is the boot log with 4.3-rc6 and clk_add_alias() fix:

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.3.0-rc6-770_tiny-los_350d5+-dirty 
(aaro@amd-fx-6350) (gcc version 5.2.0 (GCC) ) #1 Tue Oct 20 11:32:43 EEST 2015
[0.00] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Nokia 770
[0.00] Ignoring unrecognised tag 0x414f4d50
[0.00] debug: skip boot console de-registration.
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: Data cache writeback
[0.00] OMAP1710
[0.00]  revision 8 handled as 16xx id: 8b5f702f03330200
[0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2a93 ARM_CKCTL: 0x050e
[0.00] Clocking rate (xtal/DPLL1/MPU): 12.0/252.0/252.0 MHz
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 16256
[0.00] Kernel command line: mem=64M console=tty keep_bootcon=1 
earlyprintk=1
[0.00] PID hash table entries: 256 (order: -2, 1024 bytes)
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Memory: 61528K/65536K available (1654K kernel code, 94K rwdata, 
284K rodata, 1140K init, 184K bss, 4008K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc480 - 0xff00   ( 936 MB)
[0.00] lowmem  : 0xc000 - 0xc400   (  64 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc01ecd0c   (1940 kB)
[0.00]   .init : 0xc01ed000 - 0xc030a000   (1140 kB)
[0.00]   .data : 0xc030a000 - 0xc03219e0   (  95 kB)
[0.00].bss : 0xc03219e0 - 0xc034fbd0   ( 185 kB)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] Total of 128 interrupts in 4 interrupt banks
[0.00] clocksource: 32k_counter: mask: 0x max_cycles: 
0x, max_idle_ns: 58327039986419 ns
[0.30] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
6553584741ns
[0.008728] OMAP clocksource: 32k_counter at 32768 Hz
[0.014556] Console: colour dummy device 80x30
[0.019256] console [tty0] enabled
[0.022918] Calibrating delay loop... 125.33 BogoMIPS (lpj=626688)
[0.116790] pid_max: default: 32768 minimum: 301
[0.122009] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.129058] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.138214] CPU: Testing write buffer coherency: ok
[0.144409] Setting up static identity map for 0x10008400 - 0x1000843c
[0.155426] devtmpfs: initialized
[0.164703] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.176940] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.186126] irq: Cannot allocate irq_descs @ IRQ144, assuming pre-allocated
[0.194061] irq: Cannot allocate irq_descs @ IRQ160, assuming pre-allocated
[0.201599] OMAP GPIO hardware version 1.1
[0.206298] irq: Cannot allocate irq_descs @ IRQ176, assuming pre-allocated
[0.214202] irq: Cannot allocate irq_descs @ IRQ192, assuming pre-allocated
[0.221984] irq: Cannot allocate irq_descs @ IRQ208, assuming pre-allocated
[0.231140] MUX: initialized V6_USB0_TXD
[0.235443] MUX: initialized W5_USB0_SE0
[0.239624] MUX: initialized Y5_USB0_RCV
[0.243835] MUX: initialized AA9_USB0_VP
[

Re: [BISECTED] Nokia 770 framebuffer breakage

[Aaro Koskinen]

Hi,

On Tue, Oct 20, 2015 at 05:05:24PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 10:07:00AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 11:50:03AM +0300, Aaro Koskinen wrote:
> > > On Mon, Oct 19, 2015 at 11:50:33PM +0100, Russell King - ARM Linux wrote:
> > > > It shouldn't (I've been through the resulting assembly code.)  I wonder
> > > > if this is fixing the problem, but it's now failing elsewhere instead.
> > > > 
> > > > What happens if you change it to:
> > > > 
> > > > l = clkdev_create(r, alias, alias_dev_name);
> > > > 
> > > > which should be 100% identical to how older kernels behaved
> > > 
> > > Ok, this and the earlier patch works on top of
> > > 2568999835d7797afce3dcc3a3f368051ffcaf1f, but not on 4.2 or newer - so
> > > it fixes the clk_add_alias issue, and newer kernels have other issues...
> > 
> > Thanks, so this fixes the regression you were seeing with the above
> > mentioned commit, so I'll get that into mainline and stable kernels.
> > 
> > Can I add a tested-by tag for it please?
> 
> Also make that reported-by as well.
> 
> I'll hold the patch back pending a reply...

Yes, both or either are fine.

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

[BISECTED] Nokia 770 framebuffer breakage

[Aaro Koskinen]

Hi,

Somewhere between 4.1 .. 4.3-rc6 framebuffer on Nokia 770 stopped working.

Bisection points to:

commit 2568999835d7797afce3dcc3a3f368051ffcaf1f
Author: Russell King 
Date:   Mon Mar 2 15:40:29 2015 +

clkdev: add clkdev_create() helper

The commit cannot be reverted cleanly from current trees, but I re-tested
that commit 2568999835d7797afce3dcc3a3f368051ffcaf1f does not work and
commit 2568999835d7797afce3dcc3a3f368051ffcaf1f^1 indeed works.

A.
--
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: [BISECTED] Nokia 770 framebuffer breakage

[Aaro Koskinen]

On Mon, Oct 19, 2015 at 09:05:22PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 10:37:59PM +0300, Aaro Koskinen wrote:
> > Hi,
> > 
> > Somewhere between 4.1 .. 4.3-rc6 framebuffer on Nokia 770 stopped working.
> > 
> > Bisection points to:
> > 
> > commit 2568999835d7797afce3dcc3a3f368051ffcaf1f
> > Author: Russell King <rmk+ker...@arm.linux.org.uk>
> > Date:   Mon Mar 2 15:40:29 2015 +
> > 
> > clkdev: add clkdev_create() helper
> > 
> > The commit cannot be reverted cleanly from current trees, but I re-tested
> > that commit 2568999835d7797afce3dcc3a3f368051ffcaf1f does not work and
> > commit 2568999835d7797afce3dcc3a3f368051ffcaf1f^1 indeed works.
> 
> Really need more information than that, like a kernel log or something.

This is a device with normal consumer electronics mechnics so serial
port access is PITA. However I managed to get a boot log, see below,
it's from commit 2568999835d7797afce3dcc3a3f368051ffcaf1f.

> Can you try this patch please?

Unfortunately with the patch it dies even earlier, without any output.

...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.1.0-rc1-770_tiny-los_350d5+-6-g2568999 
(aaro@amd-fx-6350) (gcc version 5.2.0 (GCC) ) #1 Tue Oct 20 00:41:44 EEST 2015
[0.00] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Nokia 770
[0.00] Ignoring unrecognised tag 0x414f4d50
[0.00] earlycon: no match for ttyS0,115200
[0.00] Memory policy: Data cache writeback
[0.00] OMAP1710
[0.00]  revision 8 handled as 16xx id: 8b5f702f03330200
[0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2a93 ARM_CKCTL: 0x050e
[0.00] Clocking rate (xtal/DPLL1/MPU): 12.0/252.0/252.0 MHz
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 16256
[0.00] Kernel command line: mem=64M console=ttyS0,115200
[0.00] PID hash table entries: 256 (order: -2, 1024 bytes)
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Memory: 61296K/65536K available (1614K kernel code, 138K rwdata, 
532K rodata, 1124K init, 178K bss, 4240K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc480 - 0xff00   ( 936 MB)
[0.00] lowmem  : 0xc000 - 0xc400   (  64 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc0220d04   (2148 kB)
[0.00]   .init : 0xc0221000 - 0xc033a000   (1124 kB)
[0.00]   .data : 0xc033a000 - 0xc035c880   ( 139 kB)
[0.00].bss : 0xc035c880 - 0xc038914c   ( 179 kB)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:368
[0.00] Total of 128 interrupts in 4 interrupt banks
[0.00] clocksource 32k_counter: mask: 0x max_cycles: 
0x, max_idle_ns: 58327039986419 ns
[0.30] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
6553584741ns
[0.61] OMAP clocksource: 32k_counter at 32768 Hz
[0.000610] Console: colour dummy device 80x30
[0.000701] Calibrating delay loop... 125.33 BogoMIPS (lpj=626688)
[0.090118] pid_max: default: 32768 minimum: 301
[0.090423] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.090484] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.092102] CPU: Testing write buffer coherency: ok
[0.093048] Setting up static identity map for 0x10008400 - 0x1000843c
[0.096374] devtmpfs: initialized
[0.102111] clocksource jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.104034] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.107269] omap_gpio omap_gpio.1: Could not get gpio dbck
[0.107452] OMAP GPIO hardware version 1.1
[0.107635] omap_gpio omap_gpio.2: Could not get gpio dbck
[0.107940] omap_gpio omap_gpio.3: Could not get gpio dbck
[0.108245] omap_gpio omap_gpio.4: Could not get gpio dbck
[0.110229] MUX: initialized V6_USB0_TXD
[0.110290] MUX: initialized W5_USB0_SE0
[0.110321] MUX: initialized Y5_USB0_RCV
[0.110351] MUX: initialized AA9_USB0_VP
[0.110351] MUX: initialized R9_USB0_VM
[0.110382] USB: hmc 16, usb0 6 wires, Mini-AB on usb0
[0.110748] MUX: initialized W19_1610_MMC2_DATDIR1
[0.112640] Clocking rate (xtal/DPLL1/MPU): 12.0/216.0/216.0 MHz
[0.116882] OMAP DMA hardware version 1
[   

[BISECTED] v4.3-rc5: OMAP1 boot hang

[Aaro Koskinen]

Hi,

Amstrad E3 / OMAP1 boot hangs, and I bisected it to
a5e090acbf545c0a3b04080f8a488b17ec41fe02 ("ARM: software-based
priviledged-no-access support").

Below is the boot log. Disabling CPU_SW_DOMAIN_PAN helps.

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.3.0-rc5-e3-los_df2ad+ (aaro@amd-fx-6350) (gcc 
version 5.2.0 (GCC) ) #1 Tue Oct 13 10:08:05 EEST 2015
[0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Amstrad E3 (Delta)
[0.00] Ignoring memory below PHYS_OFFSET: 0x0200-0x1000
[0.00] Memory policy: Data cache writethrough
[0.00] On node 0 totalpages: 8192
[0.00] free_area_init_node: node 0, pgdat c0427018, node_mem_map 
c1fb7000
[0.00]   Normal zone: 64 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 8192 pages, LIFO batch:0
[0.00] OMAP1510
[0.00]  revision 2 handled as 15xx id: bc058c9b93111a16
[0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2cb3 ARM_CKCTL: 0x250e
[0.00] Clocking rate (xtal/DPLL1/MPU): 12.0/150.0/150.0 MHz
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 8128
[0.00] Kernel command line: mem=32M console=tty console=ttyS0,115200n8 
root=/dev/ram0 initrd=0x11c0,2894948 initcall_debug=1 loglevel=9
[0.00] PID hash table entries: 128 (order: -3, 512 bytes)
[0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Memory: 25136K/32768K available (3074K kernel code, 141K rwdata, 
864K rodata, 140K init, 212K bss, 7632K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc280 - 0xff00   ( 968 MB)
[0.00] lowmem  : 0xc000 - 0xc200   (  32 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc03e0ec4   (3940 kB)
[0.00]   .init : 0xc03e1000 - 0xc0404000   ( 140 kB)
[0.00]   .data : 0xc0404000 - 0xc04277e0   ( 142 kB)
[0.00].bss : 0xc04277e0 - 0xc045c9c0   ( 213 kB)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] Total of 64 interrupts in 2 interrupt banks
[0.000131] sched_clock: 32 bits at 6MHz, resolution 166ns, wraps every 
357913940908ns
[0.000382] clocksource: mpu_timer2: mask: 0x max_cycles: 
0x, max_idle_ns: 318543407797 ns
[0.001561] Console: colour dummy device 80x30
[0.009527] console [tty0] enabled
[0.010230] Calibrating delay loop... 74.13 BogoMIPS (lpj=370688)
[0.100420] pid_max: default: 32768 minimum: 301
[0.101672] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.102202] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.108589] CPU: Testing write buffer coherency: ok
[0.111741] calling  init_static_idmap+0x0/0x11c @ 1
[0.112570] Setting up static identity map for 0x10008400 - 0x1000842c
[0.113178] initcall init_static_idmap+0x0/0x11c returned 0 after 0 usecs
[0.113812] calling  spawn_ksoftirqd+0x0/0x30 @ 1
[0.115210] initcall spawn_ksoftirqd+0x0/0x30 returned 0 after 0 usecs
[0.115820] calling  init_workqueues+0x0/0x2ec @ 1
[0.120426] initcall init_workqueues+0x0/0x2ec returned 0 after 9765 usecs
[0.121133] calling  rand_initialize+0x0/0x34 @ 1
[0.122426] initcall rand_initialize+0x0/0x34 returned 0 after 0 usecs
[0.126229] devtmpfs: initialized
[0.136417] calling  ipc_ns_init+0x0/0x44 @ 1
[0.136959] initcall ipc_ns_init+0x0/0x44 returned 0 after 0 usecs
[0.137461] calling  init_mmap_min_addr+0x0/0x2c @ 1
[0.137893] initcall init_mmap_min_addr+0x0/0x2c returned 0 after 0 usecs
[0.138440] calling  net_ns_init+0x0/0x1c8 @ 1
[0.139019] initcall net_ns_init+0x0/0x1c8 returned 0 after 0 usecs
[0.140507] calling  ptrace_break_init+0x0/0x34 @ 1
[0.141046] initcall ptrace_break_init+0x0/0x34 returned 0 after 0 usecs
[0.141573] calling  omap1_pm_runtime_init+0x0/0x28 @ 1
[0.142020] initcall omap1_pm_runtime_init+0x0/0x28 returned 0 after 0 usecs
[0.142531] calling  wq_sysfs_init+0x0/0x38 @ 1
[0.144169] initcall wq_sysfs_init+0x0/0x38 returned 0 after 0 usecs
[0.144753] calling  ksysfs_init+0x0/0xa8 @ 1
[0.145728] initcall ksysfs_init+0x0/0xa8 returned 0 after 0 usecs
[0.146299] calling  

GCC 5.1 bug affecting ARM kernels

[Aaro Koskinen]

Hi,

There is a code generation bug in GCC 5.1 that affects some ARM kernels:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932

The bug report mentions arm926ej-s, and also some OMAP1 and 2 kernels
fail to boot (there is a crash after warnings about some bogus duplicate
sysfs files) unless they are compiled with -fno-ipa-sra.

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

v4.1-rc1 N900: annoying Nokia modem spam

[Aaro Koskinen]

Hi,

With v4.1-rc1, after loading nokia_modem I get the following endless
log spam until I load cmt_speech (for whatever reason it does not get
modprobed automatically with busybox modprobe):

[   41.626983] nokia-modem n900-modem: Missing cmt-speech driver
[   41.804565] nokia-modem n900-modem: GPIO lookup for consumer (null)
[   41.804626] nokia-modem n900-modem: using device tree for GPIO lookup
[   41.804687] of_get_named_gpiod_flags: parsed 'gpios' property of 
node '/ocp/ssi-controller@48058000/ssi-port@4805a000/hsi-client[0]' - status (0)
[   41.804718] no flags found for (null)
[   41.805023] nokia-modem n900-modem: GPIO lookup for consumer (null)
[   41.805023] nokia-modem n900-modem: using device tree for GPIO lookup
[   41.805145] of_get_named_gpiod_flags: parsed 'gpios' property of 
node '/ocp/ssi-controller@48058000/ssi-port@4805a000/hsi-client[1]' - status (0)
[   41.805145] no flags found for (null)
[   41.805389] nokia-modem n900-modem: GPIO lookup for consumer (null)
[   41.805419] nokia-modem n900-modem: using device tree for GPIO lookup
[   41.805541] of_get_named_gpiod_flags: parsed 'gpios' property of 
node '/ocp/ssi-controller@48058000/ssi-port@4805a000/hsi-client[2]' - status (0)
[   41.805572] no flags found for (null)
[   41.805816] nokia-modem n900-modem: GPIO lookup for consumer (null)
[   41.805816] nokia-modem n900-modem: using device tree for GPIO lookup
[   41.805969] of_get_named_gpiod_flags: parsed 'gpios' property of 
node '/ocp/ssi-controller@48058000/ssi-port@4805a000/hsi-client[3]' - status (0)
[   41.805999] no flags found for (null)

Not nice.

Also, I now realize there is a forced nokia_modem Kconfig dependency
to cmt_speech. Before I was able to use data connection only, so why
now force this dependency to cmt_speech?

A.
--
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: [PATCHv3 1/2] HSI: cmt_speech: Add cmt-speech driver

[Aaro Koskinen]

Hi,

On Sat, Mar 21, 2015 at 08:09:16PM +0100, Sebastian Reichel wrote:
 From: Kai Vehmanen kai.vehma...@nokia.com
 
 Introduces the cmt-speech driver, which implements
 a character device interface for transferring speech
 data frames over HSI/SSI.
 
 The driver is used to exchange voice/speech data between
 the Nokia N900/N950/N9's modem and its cpu.
 
 Signed-off-by: Kai Vehmanen kai.vehma...@nokia.com
 Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
 Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
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: [PATCHv3 2/2] HSI: nokia-modem: Add cmt-speech support

[Aaro Koskinen]

Hi,

On Sat, Mar 21, 2015 at 08:09:17PM +0100, Sebastian Reichel wrote:
 Register cmt-speech driver in nokia-modem driver and forward
 hsi channel information.
 
 Signed-off-by: Sebastian Reichel s...@kernel.org

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

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

[PATCH 0/3] mfd: menelaus: couple simple cleanups

[Aaro Koskinen]

Hi,

I came across these while trying to start DT conversion for menelaus
(http://marc.info/?t=14197028735r=1w=2).

While the DT work failed and is still pending, I think it's still worth
to apply these as they are independent and they remove some cruft
from the tree.

A.

Aaro Koskinen (3):
  mfd: menelaus: delete omap_has_menelaus
  mfd: menelaus: drop support for SW controller VCORE
  mfd: menelaus: use macro for magic number

 drivers/mfd/menelaus.c   | 25 +
 include/linux/mfd/menelaus.h |  7 ---
 2 files changed, 1 insertion(+), 31 deletions(-)

-- 
2.2.0

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

[PATCH 1/3] mfd: menelaus: delete omap_has_menelaus

[Aaro Koskinen]

Delete unused macro.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 include/linux/mfd/menelaus.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index f097e89..a1e12bf3 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -38,10 +38,4 @@ extern int menelaus_set_vcore_hw(unsigned int roof_mV, 
unsigned int floor_mV);
 
 extern int menelaus_set_regulator_sleep(int enable, u32 val);
 
-#if defined(CONFIG_ARCH_OMAP2)  defined(CONFIG_MENELAUS)
-#define omap_has_menelaus()1
-#else
-#define omap_has_menelaus()0
-#endif
-
 #endif
-- 
2.2.0

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

[PATCH 3/3] mfd: menelaus: use macro for magic number

[Aaro Koskinen]

Use macro to check a register bit.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/mfd/menelaus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 917fa86..c2ca665 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1216,7 +1216,7 @@ static int menelaus_probe(struct i2c_client *client,
err = menelaus_read_reg(MENELAUS_VCORE_CTRL1);
if (err  0)
goto fail;
-   if (err  BIT(7))
+   if (err  VCORE_CTRL1_HW_NSW)
menelaus-vcore_hw_mode = 1;
else
menelaus-vcore_hw_mode = 0;
-- 
2.2.0

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

[PATCH 2/3] mfd: menelaus: drop support for SW controller VCORE

[Aaro Koskinen]

Drop support for SW controlled VCORE, nobody uses it.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/mfd/menelaus.c   | 23 ---
 include/linux/mfd/menelaus.h |  1 -
 2 files changed, 24 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9f01aef..917fa86 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -532,29 +532,6 @@ static const struct menelaus_vtg_value vcore_values[] = {
{ 1450, 18 },
 };
 
-int menelaus_set_vcore_sw(unsigned int mV)
-{
-   int val, ret;
-   struct i2c_client *c = the_menelaus-client;
-
-   val = menelaus_get_vtg_value(mV, vcore_values,
-ARRAY_SIZE(vcore_values));
-   if (val  0)
-   return -EINVAL;
-
-   dev_dbg(c-dev, Setting VCORE to %d mV (val 0x%02x)\n, mV, val);
-
-   /* Set SW mode and the voltage in one go. */
-   mutex_lock(the_menelaus-lock);
-   ret = menelaus_write_reg(MENELAUS_VCORE_CTRL1, val);
-   if (ret == 0)
-   the_menelaus-vcore_hw_mode = 0;
-   mutex_unlock(the_menelaus-lock);
-   msleep(1);
-
-   return ret;
-}
-
 int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV)
 {
int fval, rval, val, ret;
diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index a1e12bf3..9e85ac0 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -24,7 +24,6 @@ extern int menelaus_set_vaux(unsigned int mV);
 extern int menelaus_set_vdcdc(int dcdc, unsigned int mV);
 extern int menelaus_set_slot_sel(int enable);
 extern int menelaus_get_slot_pin_states(void);
-extern int menelaus_set_vcore_sw(unsigned int mV);
 extern int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV);
 
 #define EN_VPLL_SLEEP  (1  7)
-- 
2.2.0

--
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/8] gpio: omap: cleanup: get rid of system GPIO - GPIO offset converseations

[Aaro Koskinen]

Hi,

On Fri, Mar 20, 2015 at 05:11:23PM +0200, grygorii.stras...@linaro.org wrote:
 On 03/20/2015 01:00 AM, Tony Lindgren wrote:
  * grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150319 
  10:26]:
  From: Grygorii Strashko grygorii.stras...@linaro.org
  Now in TI OMAP GPIO driver there are a lot of places where
  System GPIO number calculated and then converted to GPIO offset.
  What is worse is that in many place such conversation performed twice
  or even three times. But actually, we don't need to do that at all, because
  - gpiolib always passes GPIO offset to GPIO controller
  - OMAP GPIO driver converted to use IRQ domain, so
 struct irq_data-hwirq contains GPIO offset
 
  Hence, it is safe to convert all GPIO OMAP functions to use GPIO
  offset instead of system GPIO numbers. Also, this allows to remove
  unneeded conversations routines
#define GPIO_INDEX(bank, gpio)
#define GPIO_BIT(bank, gpio)
int omap_irq_to_gpio()
  
  Right on! This is excellent news. I've tested this set on top of -rc4
  plus the patch mentioned below, and I'm not seeing regressions on
  the platforms I tested with. Wake up to smsc911x ping with off-idle
  still works on omap3.
  
  I only briefly tested on omap1 (osk5912), so I'like to wait for
  Aaro's ack before this gets merged.
  
  I found one build error, other than that, for the whole series
  please feel free to add:
  
  Tested-by: Tony Lindgren t...@atomide.com
 
 Thanks Tony. 
 Yep. I'll wait for news from Aaro then will re-send if ok.

Works fine on 770 and E3.

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
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] omap3 crypto fixes

[Aaro Koskinen]

Hi,

On Fri, Feb 27, 2015 at 01:40:44PM +0100, Pali Rohár wrote:
  However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
  is not set:
  
  alg: hash: Chunking test 1 failed for omap-sha1
  alg: hash: Chunking test 1 failed for omap-md5
  alg: hash: Chunking test 1 failed for omap-hmac-sha1
  alg: hash: Chunking test 1 failed for omap-hmac-md5

BTW, it seems these errors are reported to be introduced possibly
somewhere between 3.11 and 3.15:

https://lists.fedoraproject.org/pipermail/arm/2014-August/008240.html 

A.
--
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] omap3 crypto fixes

[Aaro Koskinen]

Hi,

On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote:
 Are there any fixes in this series that should go into
 v4.0-rc series, or can it all wait for v4.1?

I think these all should wait for v4.1.

A.
--
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: [PATCHv2 0/2] N900 Modem Speech Support

[Aaro Koskinen]

On Wed, Mar 04, 2015 at 08:24:19PM +0100, Pavel Machek wrote:
 @@ -1239,8 +1234,8 @@ static long cs_char_ioctl(struct file *file, unsigned 
 int cmd,
  
   if (copy_to_user((void __user *)arg, ifver, sizeof(ifver)))
   r = -EFAULT;
 - break;
   }
 + break;
   case CS_CONFIG_BUFS: {
   struct cs_buffer_config buf_cfg;
  
 @@ -1249,8 +1244,8 @@ static long cs_char_ioctl(struct file *file, unsigned 
 int cmd,
   r = -EFAULT;
   else
   r = cs_hsi_buf_config(csdata-hi, buf_cfg);
 - break;
   }
 + break;

I think having the break inside the block is more readable.
Now the indendation is mess.

A.
--
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 1/9] HSI: cmt_speech: Add cmt-speech driver

[Aaro Koskinen]

Hi,

On Mon, Mar 02, 2015 at 05:38:51AM +0100, Sebastian Reichel wrote:
 From: Kai Vehmanen kai.vehma...@nokia.com
 
 Introduces the cmt-speech driver, which implements
 a character device interface for transferring speech
 data frames over HSI/SSI.
 
 The driver is used to exchange voice/speech data between
 the Nokia N900/N950/N9's modem and its cpu.
 
 Signed-off-by: Kai Vehmanen kai.vehma...@nokia.com
 Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
 Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com
 Signed-off-by: Sebastian Reichel s...@kernel.org

I think the initial mainline kernel submission for this driver should be
a single patch, so just squash all the cleanups and fixes into this one.
You can document the changes you have made by describing the changes
before your own Signed-off-by line.

A.
--
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, RESEND] usb: musb: fix Kconfig regression

[Aaro Koskinen]

Hi,

On Sat, Feb 28, 2015 at 12:19:41AM +0100, Arnd Bergmann wrote:
 A recent bug fix I did that was marked for stable backports
 introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY.
 
 I was missing the fact that the PHY driver already stubs out the
 omap_control_usb_set_mode, and we only need to add a dependency
 to prevent the musb-omap2430 driver from being built-in when
 the phy driver is a loadable module, but we should not prevent it
 from being built altogether when the phy driver is disabled.
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 Fixes: ca784be36cc725 (usb: start using the control module driver)
 Acked-by: Acked-by: Pavel Machek pa...@ucw.cz
 Cc: sta...@vger.kernel.org # v3.9+

This patch allows me to disable redundant CONFIG_OMAP_CONTROL_PHY
from 4.0-rc1 .config and still get a working USB on Nokia N9. So:

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

Thanks,

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

[PATCH] ARM: OMAP: enable TWL4030_USB in omap2plus_defconfig

[Aaro Koskinen]

Enable TWL4030_USB which is used at least on Nokia N900/N950/N9 (OMAP3).

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/configs/omap2plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index b738652..8c93aa9 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -375,6 +375,7 @@ CONFIG_PWM_TWL=m
 CONFIG_PWM_TWL_LED=m
 CONFIG_OMAP_USB2=m
 CONFIG_TI_PIPE3=m
+CONFIG_TWL4030_USB=m
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set
-- 
2.2.0

--
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] omap3 crypto fixes

[Aaro Koskinen]

Hi,

On Thu, Feb 26, 2015 at 02:49:50PM +0100, Pali Rohár wrote:
 This patch series fix crypto support for omap3 devices which use DT.
 
 It enables AES and SHAM on N9/N950 and SHAM on N900. AES is still disabled 
 for N900.

(Please format your lines somewhere near  76 chars, especially in
commit logs, otherwise git log looks ugly on 80 char terminals.)

I tested these with stock bootloaders, and devices boot normally
and I can now modprobe omap-aes (on N9 and N950) and omap-sham
(on all three):

omap-aes 480c5000.aes: OMAP AES hw accel rev: 2.6
omap-sham 480c3000.sham: hw accel on OMAP rev 0.9

However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set:

alg: hash: Chunking test 1 failed for omap-sha1
alg: hash: Chunking test 1 failed for omap-md5
alg: hash: Chunking test 1 failed for omap-hmac-sha1
alg: hash: Chunking test 1 failed for omap-hmac-md5

But that's probably unrelated to this series. For patches 1-8,
feel free to add:

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
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: 3.20-rc0 breaks nfsroot over usb

[Aaro Koskinen]

Hi,

On Thu, Feb 26, 2015 at 11:19:50PM +0100, Pavel Machek wrote:
 Ok, it seems that new config dependencies broke my kconfig. These will
 not be enabled if you just to make oldconfig; you want to make sure
 they are on.
 
  OMAP2430 and onwards (USB_MUSB_OMAP2PLUS) [N/m/y] (NEW)
 TWL4030 USB Transceiver Driver (TWL4030_USB) [N/m/y/?] (NEW)

Yes, also other users have reported USB breakage with 4.0-rc1 on N900
etc caused by this.

Commit fbba7db3990cb707ff91cd6507d53a0a730afe97 (usb: musb:
add omap-control dependency) changed USB_MUSB_OMAP2PLUS to depend
on OMAP_CONTROL_PHY but that seems to be wrong at least for OMAP3.
omap_control_phy.h provides dummy functions when it's not enabled.
So there should be no dependency.

A.
--
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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

[Aaro Koskinen]

Hi,

On Thu, Feb 19, 2015 at 07:20:41PM +0100, Pali Rohár wrote:
 Anyway, in Nokia Harmattan N9/N950 2.6.32 kernel is this patch:

 +/* Do we need runtime check ? */
 +#if __LINUX_ARM_ARCH__  6
   { do_bad,   SIGBUS,  0, external abort on 
 linefetch  },
 +#else
 + { do_translation_fault, SIGSEGV, SEGV_MAPERR,   I-cache maintenance 
 fault},
 +#endif

 Maybe it is related?

That was unrelated. Also, the patch is also in mainline,
see 8c0b742ca7a7d21de0ddc87eda6ef0b282e4de18 (ARM: 6134/1: Handle
instruction cache maintenance fault properly).

A.
--
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: v3.19: Nokia N900 - boot errors

[Aaro Koskinen]

Hi,

On Sat, Jan 31, 2015 at 10:28:46AM +0100, Pali Rohár wrote:
 when I boot 3.19 kernel on real n900 device it show these errors in dmesg:
 
 [0.256103] hw-breakpoint: debug architecture 0x4 unsupported.
 [0.257659] In-band Error seen by MPU  at address 0
 [0.257720] [ cut here ]
 [0.257781] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 
 omap3_l3_app_irq+0xd4/0x118()

This should be fixed in 3.16-rc6.

A.
--
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: v3.19: Nokia N900 - boot errors

[Aaro Koskinen]

Hi,

On Sat, Jan 31, 2015 at 12:08:31PM +0100, Pali Rohár wrote:
 On Saturday 31 January 2015 12:05:09 Aaro Koskinen wrote:
  Hi,
  
  On Sat, Jan 31, 2015 at 10:28:46AM +0100, Pali Rohár wrote:
   when I boot 3.19 kernel on real n900 device it show these
   errors in dmesg:
   
   [0.256103] hw-breakpoint: debug architecture 0x4
   unsupported. [0.257659] In-band Error seen by MPU  at
   address 0 [0.257720] [ cut here
   ] [0.257781] WARNING: CPU: 0 PID: 1 at
   drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0xd4/0x118()
  
  This should be fixed in 3.16-rc6.
 
 Apparently not, still present in 3.19.0-rc5+.

Sorry, I made a typo. I meant 3.19-rc6. The commit is:

commit 4b149e417463bbb6d1d9b805f729627ca2b54495
Author: Felipe Balbi ba...@ti.com
Date:   Tue Jan 6 14:38:08 2015 -0600

irqchip: omap-intc: Fix legacy DMA regression

A.
--
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: N900 v3.19-rc5 arm atags_to_fdt.c is broken

[Aaro Koskinen]

On Tue, Jan 27, 2015 at 01:50:22PM -0500, Nicolas Pitre wrote:
 Hence the ATAG-to-DT compat code in the decompressor.  This 
 was meant to smooth things around the transition to DT, etc.  After all, 
 those devices with non-replaceable bootloaders where shim layers are not 
 possible should get out of commission eventually?

Probably after 5 years there are still people using and hacking mainline
Linux with N900 etc., and newer OMAPs (since there no useful devices)
are long forgotten...

A.
--
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: N900 v3.19-rc5 errors

[Aaro Koskinen]

Hi,

On Fri, Jan 23, 2015 at 02:15:56PM +0100, Pali Rohár wrote:
 I'm getting these two errors when booting DT linux v3.19-rc5 in n900 qemu:
 
 [0.309234] device-tree: Duplicate name in onenand@0,0, renamed to #1
 [0.309417] device-tree: Duplicate name in onenand@0,0, renamed to #2
 [0.309844] device-tree: Duplicate name in ethernet@gpmc, renamed to #1
 [0.309967] device-tree: Duplicate name in ethernet@gpmc, renamed to #2
 
 [0.730743] [ cut here ]
 [0.731018] WARNING: CPU: 0 PID: 31 at drivers/memory/omap-gpmc.c:1757 
 gpmc_probe_generic_child+0x128/0x24c()

I don't see these on real HW.

A.
--
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: 3.19 on Nokia n900: audio quality awful

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 11:58:56PM +0100, Pavel Machek wrote:
 On Wed 2015-01-07 00:27:17, Aaro Koskinen wrote:
  On Tue, Jan 06, 2015 at 11:08:05PM +0100, Pavel Machek wrote:
   On Tue 2015-01-06 22:57:30, Aaro Koskinen wrote:
Hi,

On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote:
 PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least,
 and boot from MMC card is broken and has been for quite some time.

USB networking works fine with 3.19-rc3 and also MMC card rootfs.
   
   Does nfsroot work for you? USB networking works as a module but not
   build-in. [Patch is available for this one.]
   
   u-SD card seems to have similar problem. If I try it after boot, I can
   access it ok, but using u-SD card for rootfs fails. If it works for
   you, it would be interesting to know.
  
  I haven't tried nfsroot, but I've been using USB networking for ssh
  for a couple of years without issues. I have g_ether as module.
  
  Also I recently switched rootfs to u-SD card, and it (MMC) works fine
  as builtin.
  
  But I'm mounting it from userspace (using builtin initramfs inside
  zImage), with a poll loop that waits for a device to appear. Maybe if you
  do it from kernel you need to use root wait/delay etc. options?
 
 Yes, it works if I mount it later. It fails when done directly using
 root=, even with rootwait etc. Hard to believe, yes, but try it. You
 can watch the results on console.

Well, I tried and it works. 3.19-rc3 mounting logs are below.

I used root=/dev/mmcblk0p2 rootwait. Note that the external MMC
is mmcblk0 from kernel point of view.

Without serial console I guess you could maybe capture the failure
logs using mtdoops (assuming the kernel panics when it fails to mount
the rootfs). mtdoops was used even in the sales model kernel, so there
is MTD partition reserved already for it called log.

I would also recommend using initramfs to do the mounting etc. Then you
could use the framebuffer console to observe and debug some obvious issues
(assuming the framebuffer works, it often regresses unfortunately...).

A.

...

[2.145721] Waiting for root device /dev/mmcblk0p2...
[2.194335] mmc0: host does not support reading read-only switch, assuming 
write-enable
[2.213775] mmc0: new high speed SDHC card at address 
[2.227905] mmcblk0: mmc0: SL32G 29.7 GiB
[2.252227]  mmcblk0: p1 p2
[2.381958] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature 
incompatibilities
[2.399627] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature 
incompatibilities
[2.420196] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly 
filesystem
[2.435485] EXT4-fs (mmcblk0p2): write access will be enabled during 
recovery[2.497375] mmc1: switch to bus width 2 failed
[2.510620] mmc1: switch to bus width 1 failed
[2.524658] mmc1: new high speed MMC card at address 0001
[2.541229] mmcblk1: mmc1:0001 MMC32G 29.8 GiB
[2.553710] mmcblk1boot0: mmc1:0001 MMC32G partition 1 512 KiB
[2.569854] mmcblk1boot1: mmc1:0001 MMC32G partition 2 512 KiB
[2.587646]  mmcblk1: p1 p2 p3
[2.827606] EXT4-fs (mmcblk0p2): recovery complete
[2.848327] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. 
Opts: (null)
[2.863464] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
--
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: 3.18.1-3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,
On Mon, Jan 05, 2015 at 08:01:22PM -0600, Felipe Balbi wrote:
 On Tue, Jan 06, 2015 at 01:16:21AM +0200, Aaro Koskinen wrote:
  I did some debugging and it seems the In-band Error
  occurs when omap_system_dma_probe() is being run, specifically when
  the interrupt is enabled. I believe the DMA interrupt it's trying
  set up is completely wrong:
  
   28:  0  GPIO   2  DMA
  
  GPIO 2?! Where is that coming from?
 
 heh, it's probably the linux number used ended up mapping to another irq
 domain. Can you add this debugging patch and report dmesg ?

Post-commit:

[0.208251] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[0.216125] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 22

 22:  5  INTC  13  omap-dma-engine
 28:  0  GPIO   2  DMA

Pre-commit:

[0.208557] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[0.216461] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 29

 28:  0  INTC  12  DMA
 29:  5  INTC  13  omap-dma-engine

 Note that I need one log post commit and another log pre commit. If any
 of the IRQ numbers change, if means that irq_domain_add_linear() ended
 up changing IRQ start and we would need some trick to grab the correct
 IRQ number again.

So looks like static OMAP_INTC_START cannot be used anymore, but hwmod
data is full of these?

mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c: { .name = 0, .irq = 12 + 
OMAP_INTC_START, }, /* INT_24XX_SDMA_IRQ0 */

A.
--
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: 3.18.1-3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 12:52:50PM +0100, Sebastian Reichel wrote:
 On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
  Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
  Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
  Perhaps this is something related to another OMAP3-only driver?
  Perhaps HSI/SSI ?
  
  I see a ssi error directly before the IN-Band error:
  
  [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
  [0.346893] In-band Error seen by MPU  at address 0
  [0.346923] [ cut here ]
 
 mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.

This log occurs also on 3630, because ssi hwmod stuff is missing from
omap36xx_hwmod_ocp_ifs... Anyway, it's not related to this error, but need
to be added since we should get nokia-modem working also on N950/N9...

Peter: if you boot with initcall_debug, you should see the error
is during the DMA setup.

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

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote:
 * Pavel Machek pa...@ucw.cz [150106 00:03]:
  On Mon 2015-01-05 15:02:29, Tony Lindgren wrote:
   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
  
  Normally, the early development boards should have separate dts file
  (then include common parts), no?
 
 In this case it won't matter. The GPMC hardware is there, the probe
 just fails if no smsc91x is found.
  
  Could you at least add a note to the dts file what is it? Because I
  always thought it is a bug.
 
 Sure, updated patch below. Can somebody please test boot it on
 a production n900 too to make sure it no longer causes issues?

Seems to work fine with normal n900.

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

I also tested with a development board, eth0 seemed to appear,
but couldn't configure the MAC address with busybox ifconfig.
How should it be done, I guess the interface does not have any
MAC by default?

A.
--
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: 3.19 on Nokia n900: audio quality awful

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 06:51:15PM +0100, Pavel Machek wrote:
 On Tue 2015-01-06 11:25:45, Felipe Balbi wrote:
  On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote:
   In 3.18, sound is nice and clear.
   
   In 3.19, sound is unusable. It produces nasty tone when it should be
   quiet, and there's at least as much noise as is sound.
   
   Unfortunately, list of mixers also changed (and there's cca 120
   settings), but a) it does not work with the old list and b) nothing I
   could figure out did make the sound usable. Some setting resulted in
   even more noise.
   
   Any idea what could have caused it?
  
  $ git bisect start
  $ git bisect good v3.18
  $ git bisect bad
  
  that'll help find what caused it.
 
 Telling someone to do hard and time consuming job that probably will
 not succeed, instead of actually providing help. Very very funny.

No, that was actually really a good advice. You should try to bisect it.
It doesn't take that long (I assume you are cross-compiling instead
of doing native builds), also Linux maintainers are generally doing
a very good job ensuring the tree is bisectable.

I would do it myself, but so far I never have set up my N900 to play
any audio and I don't have any reference points between good or bad.

A.
--
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: 3.19 on Nokia n900: audio quality awful

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote:
 PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least,
 and boot from MMC card is broken and has been for quite some time.

USB networking works fine with 3.19-rc3 and also MMC card rootfs.

What issues are you seeing?

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

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 11:54:55AM -0800, Tony Lindgren wrote:
 Run u-boot/tools/gen_eth_addr to generate a random local mac,
 then swap the bytes for it for big endian. Enter them into a
 file with hexedit in big endian order. Then just do:
 
 # cat mac | ethtool -E eth0 offset 0x40 length 6
 
 Then ethtool -e eth0 should show you the configuration.

Does any other eeprom data need to be set? It seems to be all 0xff.
I generated a mac from /dev/random and it shows up fine in those offsets
and with ifconfig, but I still can't get a link up:

ifconfig: SIOCSIFFLAGS: Cannot assign requested address

A.
--
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: 3.19 on Nokia n900: audio quality awful

[Aaro Koskinen]

On Tue, Jan 06, 2015 at 11:08:05PM +0100, Pavel Machek wrote:
 On Tue 2015-01-06 22:57:30, Aaro Koskinen wrote:
  Hi,
  
  On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote:
   PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least,
   and boot from MMC card is broken and has been for quite some time.
  
  USB networking works fine with 3.19-rc3 and also MMC card rootfs.
 
 Does nfsroot work for you? USB networking works as a module but not
 build-in. [Patch is available for this one.]
 
 u-SD card seems to have similar problem. If I try it after boot, I can
 access it ok, but using u-SD card for rootfs fails. If it works for
 you, it would be interesting to know.

I haven't tried nfsroot, but I've been using USB networking for ssh
for a couple of years without issues. I have g_ether as module.

Also I recently switched rootfs to u-SD card, and it (MMC) works fine
as builtin.

But I'm mounting it from userspace (using builtin initramfs inside
zImage), with a poll loop that waits for a device to appear. Maybe if you
do it from kernel you need to use root wait/delay etc. options?

 I'm loading zImage using 0x directly from the PC.

Same here.

A.
--
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] irqchip: omap-intc: fix legacy DMA regression

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 06:05:32PM +, Russell King - ARM Linux wrote:
 On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
  +* FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
  +* depends is still not ready for linear IRQ domains; because of that
  +* we need to temporarily blacklist OMAP2 and OMAP3 devices from using
  +* linear IRQ Domain until that driver is finally fixed.
 
 finally fixed or finally killed off like it really needs to be, once
 all users of it are killed.
 
 We've been trying to do this for, what, three years now... I finally
 pushed a WARN_ON() into that code to make it obvious to anyone who
 uses omap_request_dma() that they really need to update their code.

 Here's the list of references to that symbol which *still* need to be
 fixed so that we can kill the legacy DMA driver:
 
 drivers/usb/gadget/udc/omap_udc.c:  status = 
 omap_request_dma(dma_channel,
 drivers/usb/gadget/udc/omap_udc.c:  status = 
 omap_request_dma(dma_channel,

I only learned about this after the WARN_ON() appeared in 3.17
(just couple months ago), and it's on my TODO list...

A.
--
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] irqchip: omap-intc: fix legacy DMA regression

[Aaro Koskinen]

On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
 commit 55601c9f2467 (arm: omap: intc: switch over
 to linear irq domain) introduced a regression with
 SDMA legacy driver because that driver strictly depends
 on INTC's IRQs starting at NR_IRQs. Aparently
 irq_domain_add_linear() won't guarantee that, since we see
 a 7 IRQs difference when booting with and without the
 commit cited above.
 
 Until arch/arm/plat-omap/dma.c is properly fixed, we
 must maintain OMAP2/3 using irq_domain_add_legacy().
 
 A FIXME note was added so people know to delete that
 code once that legacy DMA driver is fixed up.
 
 Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
 Signed-off-by: Felipe Balbi ba...@ti.com

I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
and also the In-band Error is gone.

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
so maybe you should consider adding also Cc: stable...

A.

 ---
  drivers/irqchip/irq-omap-intc.c | 26 +-
  1 file changed, 21 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
 index 3c970259c0eb..6ef88f56cf8d 100644
 --- a/drivers/irqchip/irq-omap-intc.c
 +++ b/drivers/irqchip/irq-omap-intc.c
 @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node 
 *node)
   return ret;
  }
  
 -static int __init omap_init_irq_legacy(u32 base)
 +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
  {
   int j, irq_base;
  
 @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
   irq_base = 0;
   }
  
 - domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
 + domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
   irq_domain_simple_ops, NULL);
  
   omap_irq_soft_reset();
 @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct 
 device_node *node)
  {
   int ret;
  
 - if (node)
 + /*
 +  * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
 +  * depends is still not ready for linear IRQ domains; because of that
 +  * we need to temporarily blacklist OMAP2 and OMAP3 devices from using
 +  * linear IRQ Domain until that driver is finally fixed.
 +  */
 + if (of_device_is_compatible(node, ti,omap2-intc) ||
 + of_device_is_compatible(node, ti,omap3-intc)) {
 + struct resource res;
 +
 + if (of_address_to_resource(node, 0, res))
 + return -ENOMEM;
 +
 + base = res.start;
 + ret = omap_init_irq_legacy(base, node);
 + } else if (node) {
   ret = omap_init_irq_of(node);
 - else
 - ret = omap_init_irq_legacy(base);
 + } else {
 + ret = omap_init_irq_legacy(base, NULL);
 + }
  
   if (ret == 0)
   omap_irq_enable_protection();
 -- 
 2.2.0
 
--
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: 3.18.1-3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Mon, Jan 05, 2015 at 09:43:13AM -0600, Felipe Balbi wrote:
 On Sat, Jan 03, 2015 at 02:16:22PM +0200, Aaro Koskinen wrote:
   When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
   I see a In-band ERROR warning which wasn't present in 3.18.1.
   Could it be that I missed some DT updates?
   
   [0.366882] In-band Error seen by MPU  at address 0
   [0.366912] [ cut here ]
   [0.366943] WARNING: CPU: 0 PID: 1 at 
   drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
   
   This appears also on N900/N950/N9...
   
   Do you have CONFIG_PREEMPT enabled? It seems there's some
   regression related to CONFIG_PREEMPT that started happening
   with the merge window?
   
   Indeed, when I disable CONFIG_PREEMPT the warning is gone.
  
  Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
  thread / patch set for this already; or should we try to bisect 
  this?
 
 AFAIK I'm not aware of other threads, I noticied it with the
 OMAP 4430 SDP: rather sick with recent kernels thread, but
 never got anywhere with it.
 
 Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
 that too should be verified. Sounds like running git bisect on
 this one is needed.

I tried to bisect this on N950, and it resulted in:

aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
commit aa25729cfd9709156661bea0f9293deb7729f57a
Author: Tony Lindgren t...@atomide.com
Date:   Wed Nov 5 09:21:23 2014 -0800

ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree

But when I tried to revert this from 3.19-rc2, my board won't boot at
all...
   
   Hmm OK that commit just fixed the omap_l3_smx so we now see
   warnings about the unclocked register access.
   
   It seems that probably the CONFIG_PREEMPT issue has been lurking
   around for longer but we have not seen any errors because
   omap_l3_smx just recently started exposing them.
   
   Does v3.18 + commit aa25729cfd9 manually applied also produce
   the CONFIG_PREEMPT errors?
  
  Yes it does, so I made another bisection between 3.17 and 3.18
  using the above patch to trigger the issue, and I got:
  
  55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
  commit 55601c9f24670ba926ebdd4d712ac3b177232330
  Author: Felipe Balbi ba...@ti.com
  Date:   Mon Sep 8 17:54:58 2014 -0700
  
  arm: omap: intc: switch over to linear irq domain
 
 Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
 Perhaps this is something related to another OMAP3-only driver ? Perhaps
 HSI/SSI ?

I did some debugging and it seems the In-band Error
occurs when omap_system_dma_probe() is being run, specifically when
the interrupt is enabled. I believe the DMA interrupt it's trying
set up is completely wrong:

 28:  0  GPIO   2  DMA

GPIO 2?! Where is that coming from?

With the commit before the arm: omap: intc: switch over
to linear irq domain it seems to be more reasonable:

 28:  0  INTC  12  DMA

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

[PATCH] hsi: nokia-modem: fix uninitialized device pointer

[Aaro Koskinen]

modem-device was never initialized. This resulted in logs such as:

[  241.386322] (NULL device *): CMT rst line change detected

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/hsi/clients/nokia-modem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hsi/clients/nokia-modem.c 
b/drivers/hsi/clients/nokia-modem.c
index f0c2145..eb4dc63 100644
--- a/drivers/hsi/clients/nokia-modem.c
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -162,6 +162,7 @@ static int nokia_modem_probe(struct device *dev)
return -ENOMEM;
}
dev_set_drvdata(dev, modem);
+   modem-device = dev;
 
irq = irq_of_parse_and_map(np, 0);
if (!irq) {
-- 
2.2.0

--
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: OMAP baseline test results for v3.19-rc1

[Aaro Koskinen]

Hi,

On Sun, Jan 04, 2015 at 05:46:31PM +0100, Arnd Bergmann wrote:
 On Saturday 03 January 2015 15:44:38 Aaro Koskinen wrote:
  On Sat, Jan 03, 2015 at 01:51:53PM +0100, Arnd Bergmann wrote:
   On Saturday 03 January 2015 07:21:49 Paul Walmsley wrote:
Another ~300KB kernel object size increase for omap2plus_defconfig 
kernels.
   
   300kb seems like a lot for a single release. Have you looked into
   where this is coming from?
  
  In 3.19-rc1, all initrd decompressors are by default enabled...
 
 Interesting, this seems to be the opposite of the intention of the
 change that caused it, which tried to let you disable the algorithms
 without selecting CONFIG_EXPERT. For some reason that is impossible
 to know now, they already defaulted to 'n' when EXPERT was set, but
 now they default to 'y'.
 
 Does this indeed cause the entire change in size?

Actually, no. It seems a bigger contributor is enabling SATA
in omap2plus_defconfig. But there still something else... Below is some
data based on quick checks.

v3.18 / omap2plus_defconfig:

text data   bss dec hex filename
8811980  790500 8423536 180260161130e20 vmlinux

v3.19-rc1 / omap2plus_defconfig:

text data   bss dec hex filename
9093858  800316 8419072 18313246117701e vmlinux

v3.19-rc1 / omap2plus_defconfig + revert ec72c666fb34 (usr/Kconfig: make
initrd compression algorithm selection not expert):

text data   bss dec hex filename
9070939  800260 8419072 18290271117165f vmlinux

v3.19-rc1 / omap2plus_defconfig + revert 661ea91b676b (ARM:
omap2plus_defconfig: Enable AHCI_PLATFORM driver):

text data   bss dec hex filename
8928148  792700 8414784 18135632114ba50 vmlinux

v3.19-rc1 / omap2plus_defconfig + revert ec72c666fb34  661ea91b676b:

text data   bss dec hex filename
8901129  792644 8414784 18108557114508d vmlinux

A.
--
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: 3.18.1-3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Fri, Jan 02, 2015 at 04:02:21PM -0800, Tony Lindgren wrote:
 * Aaro Koskinen aaro.koski...@iki.fi [150102 14:37]:
  On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
   * Aaro Koskinen aaro.koski...@iki.fi [150102 12:21]:
On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
 Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
 * Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
 On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
 When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
 I see a In-band ERROR warning which wasn't present in 3.18.1.
 Could it be that I missed some DT updates?
 
 [0.366882] In-band Error seen by MPU  at address 0
 [0.366912] [ cut here ]
 [0.366943] WARNING: CPU: 0 PID: 1 at 
 drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
 
 This appears also on N900/N950/N9...
 
 Do you have CONFIG_PREEMPT enabled? It seems there's some
 regression related to CONFIG_PREEMPT that started happening
 with the merge window?
 
 Indeed, when I disable CONFIG_PREEMPT the warning is gone.

Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
thread / patch set for this already; or should we try to bisect this?
   
   AFAIK I'm not aware of other threads, I noticied it with the
   OMAP 4430 SDP: rather sick with recent kernels thread, but
   never got anywhere with it.
   
   Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
   that too should be verified. Sounds like running git bisect on
   this one is needed.
  
  I tried to bisect this on N950, and it resulted in:
  
  aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
  commit aa25729cfd9709156661bea0f9293deb7729f57a
  Author: Tony Lindgren t...@atomide.com
  Date:   Wed Nov 5 09:21:23 2014 -0800
  
  ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
  
  But when I tried to revert this from 3.19-rc2, my board won't boot at
  all...
 
 Hmm OK that commit just fixed the omap_l3_smx so we now see
 warnings about the unclocked register access.
 
 It seems that probably the CONFIG_PREEMPT issue has been lurking
 around for longer but we have not seen any errors because
 omap_l3_smx just recently started exposing them.
 
 Does v3.18 + commit aa25729cfd9 manually applied also produce
 the CONFIG_PREEMPT errors?

Yes it does, so I made another bisection between 3.17 and 3.18
using the above patch to trigger the issue, and I got:

55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
commit 55601c9f24670ba926ebdd4d712ac3b177232330
Author: Felipe Balbi ba...@ti.com
Date:   Mon Sep 8 17:54:58 2014 -0700

arm: omap: intc: switch over to linear irq domain

A.
--
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: OMAP baseline test results for v3.19-rc1

[Aaro Koskinen]

Hi,

On Sat, Jan 03, 2015 at 01:51:53PM +0100, Arnd Bergmann wrote:
 On Saturday 03 January 2015 07:21:49 Paul Walmsley wrote:
  Another ~300KB kernel object size increase for omap2plus_defconfig 
  kernels.
 
 300kb seems like a lot for a single release. Have you looked into
 where this is coming from?

In 3.19-rc1, all initrd decompressors are by default enabled...

 CONFIG_RD_GZIP=y
-# CONFIG_RD_BZIP2 is not set
-# CONFIG_RD_LZMA is not set
-# CONFIG_RD_XZ is not set
-# CONFIG_RD_LZO is not set
-# CONFIG_RD_LZ4 is not set
+CONFIG_RD_BZIP2=y
+CONFIG_RD_LZMA=y
+CONFIG_RD_XZ=y
+CONFIG_RD_LZO=y
+CONFIG_RD_LZ4=y

A.
--
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: 3.18.1-3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
 Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
 * Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
 On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
 When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
 I see a In-band ERROR warning which wasn't present in 3.18.1.
 Could it be that I missed some DT updates?
 
 [0.366882] In-band Error seen by MPU  at address 0
 [0.366912] [ cut here ]
 [0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 
 omap3_l3_app_irq+0x100/0x134()
 
 This appears also on N900/N950/N9...
 
 Do you have CONFIG_PREEMPT enabled? It seems there's some
 regression related to CONFIG_PREEMPT that started happening
 with the merge window?
 
 Indeed, when I disable CONFIG_PREEMPT the warning is gone.

Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
thread / patch set for this already; or should we try to bisect this?

Thanks,

A.
--
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: 3.18.1-3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
 * Aaro Koskinen aaro.koski...@iki.fi [150102 12:21]:
  On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
   Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
   * Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
   On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
   When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
   I see a In-band ERROR warning which wasn't present in 3.18.1.
   Could it be that I missed some DT updates?
   
   [0.366882] In-band Error seen by MPU  at address 0
   [0.366912] [ cut here ]
   [0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 
   omap3_l3_app_irq+0x100/0x134()
   
   This appears also on N900/N950/N9...
   
   Do you have CONFIG_PREEMPT enabled? It seems there's some
   regression related to CONFIG_PREEMPT that started happening
   with the merge window?
   
   Indeed, when I disable CONFIG_PREEMPT the warning is gone.
  
  Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
  thread / patch set for this already; or should we try to bisect this?
 
 AFAIK I'm not aware of other threads, I noticied it with the
 OMAP 4430 SDP: rather sick with recent kernels thread, but
 never got anywhere with it.
 
 Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
 that too should be verified. Sounds like running git bisect on
 this one is needed.

I tried to bisect this on N950, and it resulted in:

aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
commit aa25729cfd9709156661bea0f9293deb7729f57a
Author: Tony Lindgren t...@atomide.com
Date:   Wed Nov 5 09:21:23 2014 -0800

ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree

But when I tried to revert this from 3.19-rc2, my board won't boot at
all...

A.
--
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: 3.18.1-3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
 When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
 I see a In-band ERROR warning which wasn't present in 3.18.1.
 Could it be that I missed some DT updates?

 [0.366882] In-band Error seen by MPU  at address 0
 [0.366912] [ cut here ]
 [0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 
 omap3_l3_app_irq+0x100/0x134()

This appears also on N900/N950/N9...

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

N900 / v3.19-rc2: nokia-modem crash

[Aaro Koskinen]

Hi,

The below crash seems to be easily reproducible on N900.

Just do: modprobe nokia-modem; modprobe -r nokia-modem; modprobe nokia-modem

[  139.990173] omap_ssi 48058000.ssi-controller: ssi controller 0 initialized 
(1 ports)!
[  140.022674] NET: Registered protocol family 35
[  140.048797] SSI protocol aka McSAAB added
[  160.323547] SSI protocol driver removed
[  160.462524] NET: Unregistered protocol family 35
[  178.334014] omap_ssi 48058000.ssi-controller: failed to create ssi 
controller port
[  178.354492] [ cut here ]
[  178.365020] WARNING: CPU: 0 PID: 835 at 
/home/aaro/los/work/shared/linux-v3.19-rc2/fs/sysfs/group.c:219 
sysfs_remove_group+0x9c/0xa0()
[  178.389068] sysfs group c0874fb4 not found for kobject 'port0'
[  178.401153] Modules linked in: omap_ssi(+) hsi usb_f_ecm g_ether u_ether 
libcomposite configfs [last unloaded: phonet]
[  178.425231] CPU: 0 PID: 835 Comm: modprobe Tainted: GW  
3.19.0-rc2-omap3-los_4583+ #1
[  178.441223] Hardware name: Generic OMAP3 (Flattened Device Tree)
[  178.454162] Backtrace: 
[  178.463256] [c0011d58] (dump_backtrace) from [c0011f7c] 
(show_stack+0x18/0x1c)
[  178.477966]  r6:c0141c50 r5:0009 r4: r3:
[  178.490661] [c0011f64] (show_stack) from [c03d7a8c] 
(dump_stack+0x24/0x28)
[  178.504974] [c03d7a68] (dump_stack) from [c0036064] 
(warn_slowpath_common+0x8c/0xb8)
[  178.520141] [c0035fd8] (warn_slowpath_common) from [c00360c8] 
(warn_slowpath_fmt+0x38/0x40)
[  178.536041]  r8:cfb4b400 r7:cf95b400 r6:cfb4b808 r5:c0874fb4 r4:c04bb964
[  178.549987] [c0036094] (warn_slowpath_fmt) from [c0141c50] 
(sysfs_remove_group+0x9c/0xa0)
[  178.565887]  r3:c0874fb4 r2:c04bb964
[  178.576416]  r4:
[  178.585540] [c0141bb4] (sysfs_remove_group) from [c025fc54] 
(dpm_sysfs_remove+0x54/0x58)
[  178.601196]  r6:cfb4b800 r5:cfb4b808 r4:c0874fb4
[  178.612915] [c025fc00] (dpm_sysfs_remove) from [c0255e2c] 
(device_del+0x40/0x218)
[  178.628295]  r6:bf0593f0 r5:cfb4b800 r4:cfb4b800 r3:
[  178.641479] [c0255dec] (device_del) from [c0256018] 
(device_unregister+0x14/0x28)
[  178.656951]  r8:ffed r7:cf95b400 r6:bf0593f0 r5: r4:cfb4b800
[  178.671386] [c0256004] (device_unregister) from [bf059418] 
(hsi_remove_port+0x28/0x30 [hsi])
[  178.687896]  r4:cfb4b800 r3:
[  178.698730] [bf0593f0] (hsi_remove_port [hsi]) from [c0255b34] 
(device_for_each_child+0x58/0x84)
[  178.722534]  r4: r3:cfb4b800
[  178.733306] [c0255adc] (device_for_each_child) from [bf0593e4] 
(hsi_unregister_controller+0x20/0x2c [hsi])
[  178.757751]  r6:0001 r5:cfceee10 r4:cfb4b400
[  178.769714] [bf0593c4] (hsi_unregister_controller [hsi]) from [bf0633f4] 
(ssi_probe+0x308/0x540 [omap_ssi])
[  178.794464]  r4: r3:0002
[  178.805267] [bf0630ec] (ssi_probe [omap_ssi]) from [c025b338] 
(platform_drv_probe+0x4c/0xac)
[  178.821838]  r10: r9:cfb4c048 r8:002b r7:fdfb r6:bf060f14 
r5:cf95b410
[  178.837677]  r4:c0999c74
[  178.847381] [c025b2ec] (platform_drv_probe) from [c0259938] 
(driver_probe_device+0x110/0x244)
[  178.864074]  r7:bf060f14 r6: r5:cf95b410 r4:c0999c74
[  178.877380] [c0259828] (driver_probe_device) from [c0259b4c] 
(__driver_attach+0x94/0x98)
[  178.893829]  r8:0001 r7: r6:cf95b444 r5:bf060f14 r4:cf95b410 
r3:
[  178.909667] [c0259ab8] (__driver_attach) from [c0257cec] 
(bus_for_each_dev+0x74/0xa8)
[  178.925811]  r6:c0259ab8 r5:bf060f14 r4: r3:
[  178.939331] [c0257c78] (bus_for_each_dev) from [c025942c] 
(driver_attach+0x24/0x28)
[  178.955322]  r6:c0874bf0 r5:cfb2c680 r4:bf060f14
[  178.967651] [c0259408] (driver_attach) from [c02590d4] 
(bus_add_driver+0x150/0x1f8)
[  178.983673] [c0258f84] (bus_add_driver) from [c025a20c] 
(driver_register+0x80/0x100)
[  178.999725]  r7:bf06362c r6:cfb4c440 r5:0001 r4:bf060f14
[  179.013183] [c025a18c] (driver_register) from [c025b27c] 
(__platform_driver_register+0x5c/0x64)
[  179.037353]  r5:0001 r4:bf060f00
[  179.048461] [c025b220] (__platform_driver_register) from [c025b3d8] 
(__platform_driver_probe+0x28/0xb8)
[  179.073364] [c025b3b0] (__platform_driver_probe) from [bf063654] 
(ssi_pdriver_init+0x28/0x2c [omap_ssi])
[  179.098724]  r6:cfb4c440 r5:c0851ba8 r4:c0851ba8 r3:
[  179.112304] [bf06362c] (ssi_pdriver_init [omap_ssi]) from [c00089f4] 
(do_one_initcall+0x94/0x1dc)
[  179.137207] [c0008960] (do_one_initcall) from [c0087bf0] 
(load_module+0x15ec/0x1e18)
[  179.153533]  r10:bf060f58 r9:cfb4c048 r8:0001 r7:cfb4c040 r6:0001 
r5:bf060f64
[  179.169708]  r4:cfb23f48
[  179.179931] [c0086604] (load_module) from [c0088500] 
(SyS_init_module+0xe4/0xf8)
[  179.195770]  r10: r9:cfb22000 r8:c000ed04 r7:0080 r6:00089ab8 
r5:000a34f8
[  179.211822]  r4:3604
[  179.221923] [c008841c] (SyS_init_module) from [c000eb60] 
(ret_fast_syscall+0x0/0x30)
[  179.238067]  r6: r5:000a34f8 r4:000a3020
[  179.250488] ---[ end trace 

Re: v3.19-rc1 regression(?) on N900

[Aaro Koskinen]

Hi,

On Mon, Dec 29, 2014 at 10:04:46AM +0200, Tomi Valkeinen wrote:
 On 26/12/14 00:21, Aaro Koskinen wrote:
 
  ...however, I can confirm that framebuffer is broken:
  
  [8.230743] omapfb omapfb: no displays
  [8.255584] omapfb omapfb: failed to setup omapfb
  [8.260620] platform omapfb: Driver omapfb requests probe deferral
  [8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of 
  node
  '/ocp/spi@48098000/acx565akm@2[0]' - status (0)
  [8.284271] acx565akm spi1.2: failed to find video source
  [8.290069] spi spi1.2: Driver acx565akm requests probe deferral
  
  I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
  by matching reg-id). When I revert that, also FB works with 3.19-rc1.
 
 I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
 please report if it works.

That works, thanks.

A.
--
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 3/7] mfd: menelaus: add initial DT support

[Aaro Koskinen]

Hi,

On Sat, Dec 27, 2014 at 03:25:53PM -0600, Felipe Balbi wrote:
 On Sat, Dec 27, 2014 at 07:52:55PM +0200, Aaro Koskinen wrote:
  Add initial DT support.
  
  Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
  ---
   Documentation/devicetree/bindings/mfd/menelaus.txt | 30 +
   drivers/mfd/menelaus.c | 52 
  --
   2 files changed, 78 insertions(+), 4 deletions(-)
   create mode 100644 Documentation/devicetree/bindings/mfd/menelaus.txt
  
  diff --git a/Documentation/devicetree/bindings/mfd/menelaus.txt 
  b/Documentation/devicetree/bindings/mfd/menelaus.txt
  new file mode 100644
  index 000..5f69f23
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/mfd/menelaus.txt
  @@ -0,0 +1,30 @@
  +Menelaus (Texas Instruments TWL92330) Power Management chip
  +
  +Menelaus provides facilities to control the power resources.
  +
  +Required properties:
  +- compatible: must be menelaus
  +- reg: I2C address of the chip
  +
  +Optional properties:
  +- interrupts: the interrupt
  +- ti,autosleep: All regulators are put to sleep by default.
  +- ti,vcore-min-microvolt: Range floor for the HW controlled VCORE
  +- ti,vcore-max-microvolt: Range roof for the HW controlled VCORE
  +
  +The use of ti,autosleep is recommended at least on Nokia N800/N810.
  +
  +Example:
  +
  +i2c1 {
  +   clock-frequency = 40;
  +
  +   pmic@72 {
  +   compatible = menelaus;
  +   reg = 0x72;
  +   interrupts = 7 IRQ_TYPE_EDGE_RISING;
  +   ti,autosleep;
  +   ti,vcore-min-microvolt = 105;
  +   ti,vcore-max-microvolt = 140;
 
 looks like these should be first converted to actual regulators
 otherwise we will have to maintain this binding forever which means that
 any effort of adding regulator fwk support for menelaus will become a
 lot more difficult because it'll have to cope with the legacy/bogus
 binding.

I was thinking such conversion could be done with incremental patches...
There's basically only one board (n8x0) that uses this and not likely
to be any others. Is there a way to declare bindings unstable?

 I started doing irqchip/irqdomain conversion but I don't have where to
 test and got side-tracked by other stuff. I'll see if I can restart that
 work early next year.
 
 Then, if you change your series so that first you add proper regulator
 fwk support, we should be pretty good with menelaus.

Ok, let's see.

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

[PATCH 0/7] Menelaus cleanup for DT, phase 1

[Aaro Koskinen]

Hi,

These patches start removal of board-specific callbacks from Menelaus:
delete platform data and a callback from the driver to the board files.

Tested on top of 3.19-rc1 on N800/N810 which are the only in-tree users
for the driver.

Aaro Koskinen (7):
  mfd: menelaus: delete omap_has_menelaus
  mfd: menelaus: drop support for SW controller VCORE
  mfd: menelaus: add initial DT support
  ARM: OMAP: N8x0: configure menelaus using DT
  mfd: menelaus: delete platform data support
  mfd: menelaus: make vcore and regulator controls internal
  mfd: menelaus: use macro for magic number

 Documentation/devicetree/bindings/mfd/menelaus.txt | 30 
 arch/arm/boot/dts/omap2420-n8x0-common.dtsi|  3 +
 arch/arm/mach-omap2/board-n8x0.c   | 57 --
 arch/arm/mach-omap2/common-board-devices.h |  2 -
 arch/arm/mach-omap2/pdata-quirks.c |  1 -
 drivers/mfd/menelaus.c | 86 ++
 include/linux/mfd/menelaus.h   | 25 ---
 7 files changed, 87 insertions(+), 117 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/menelaus.txt

-- 
2.2.0

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

[PATCH 4/7] ARM: OMAP: N8x0: configure menelaus using DT

[Aaro Koskinen]

Configure Menelaus using DT.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/boot/dts/omap2420-n8x0-common.dtsi |  3 ++
 arch/arm/mach-omap2/board-n8x0.c| 57 -
 arch/arm/mach-omap2/pdata-quirks.c  |  1 -
 3 files changed, 3 insertions(+), 58 deletions(-)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index c9f1e93..c19718c 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -32,6 +32,9 @@
compatible = menelaus;
reg = 0x72;
interrupts = 7 IRQ_TYPE_EDGE_RISING;
+   ti,autosleep;
+   ti,vcore-min-microvolt = 105;
+   ti,vcore-max-microvolt = 140;
};
 };
 
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index b6443a4..0b511c0 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -516,63 +516,6 @@ void __init n8x0_mmc_init(void)
 }
 #endif /* CONFIG_MMC_OMAP */
 
-#ifdef CONFIG_MENELAUS
-
-static int n8x0_auto_sleep_regulators(void)
-{
-   u32 val;
-   int ret;
-
-   val = EN_VPLL_SLEEP | EN_VMMC_SLEEP\
-   | EN_VAUX_SLEEP | EN_VIO_SLEEP \
-   | EN_VMEM_SLEEP | EN_DC3_SLEEP \
-   | EN_VC_SLEEP | EN_DC2_SLEEP;
-
-   ret = menelaus_set_regulator_sleep(1, val);
-   if (ret  0) {
-   pr_err(Could not set regulators to sleep on menelaus: %u\n,
-  ret);
-   return ret;
-   }
-   return 0;
-}
-
-static int n8x0_auto_voltage_scale(void)
-{
-   int ret;
-
-   ret = menelaus_set_vcore_hw(1400, 1050);
-   if (ret  0) {
-   pr_err(Could not set VCORE voltage on menelaus: %u\n, ret);
-   return ret;
-   }
-   return 0;
-}
-
-static int n8x0_menelaus_late_init(struct device *dev)
-{
-   int ret;
-
-   ret = n8x0_auto_voltage_scale();
-   if (ret  0)
-   return ret;
-   ret = n8x0_auto_sleep_regulators();
-   if (ret  0)
-   return ret;
-   return 0;
-}
-
-#else
-static int n8x0_menelaus_late_init(struct device *dev)
-{
-   return 0;
-}
-#endif
-
-struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = {
-   .late_init = n8x0_menelaus_late_init,
-};
-
 struct aic3x_pdata n810_aic33_data __initdata = {
.gpio_reset = 118,
 };
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d7eee1..fca4650 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -369,7 +369,6 @@ static struct pdata_init auxdata_quirks[] __initdata = {
 struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 #ifdef CONFIG_MACH_NOKIA_N8X0
OF_DEV_AUXDATA(ti,omap2420-mmc, 0x4809c000, mmci-omap.0, NULL),
-   OF_DEV_AUXDATA(menelaus, 0x72, 1-0072, 
n8x0_menelaus_platform_data),
OF_DEV_AUXDATA(tlv320aic3x, 0x18, 2-0018, n810_aic33_data),
 #endif
 #ifdef CONFIG_ARCH_OMAP3
-- 
2.2.0

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

[PATCH 3/7] mfd: menelaus: add initial DT support

[Aaro Koskinen]

Add initial DT support.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 Documentation/devicetree/bindings/mfd/menelaus.txt | 30 +
 drivers/mfd/menelaus.c | 52 --
 2 files changed, 78 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/menelaus.txt

diff --git a/Documentation/devicetree/bindings/mfd/menelaus.txt 
b/Documentation/devicetree/bindings/mfd/menelaus.txt
new file mode 100644
index 000..5f69f23
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/menelaus.txt
@@ -0,0 +1,30 @@
+Menelaus (Texas Instruments TWL92330) Power Management chip
+
+Menelaus provides facilities to control the power resources.
+
+Required properties:
+- compatible: must be menelaus
+- reg: I2C address of the chip
+
+Optional properties:
+- interrupts: the interrupt
+- ti,autosleep: All regulators are put to sleep by default.
+- ti,vcore-min-microvolt: Range floor for the HW controlled VCORE
+- ti,vcore-max-microvolt: Range roof for the HW controlled VCORE
+
+The use of ti,autosleep is recommended at least on Nokia N800/N810.
+
+Example:
+
+i2c1 {
+   clock-frequency = 40;
+
+   pmic@72 {
+   compatible = menelaus;
+   reg = 0x72;
+   interrupts = 7 IRQ_TYPE_EDGE_RISING;
+   ti,autosleep;
+   ti,vcore-min-microvolt = 105;
+   ti,vcore-max-microvolt = 140;
+   };
+};
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 917fa86..3e04c64 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -16,6 +16,8 @@
  * Amit Kucheria amit.kuche...@nokia.com
  * Copyright (C) 2005, 2006 Nokia Corporation
  *
+ * Cleanups and DT modifications by Aaro Koskinen aaro.koski...@iki.fi.
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
@@ -767,6 +769,22 @@ out:
return ret;
 }
 
+static int menelaus_auto_sleep_regulators(void)
+{
+   u32 val;
+   int ret;
+
+   val = EN_VPLL_SLEEP | EN_VMMC_SLEEP | EN_VAUX_SLEEP | EN_VIO_SLEEP | \
+ EN_VMEM_SLEEP | EN_DC3_SLEEP  | EN_VC_SLEEP   | EN_DC2_SLEEP;
+   ret = menelaus_set_regulator_sleep(1, val);
+   if (ret  0) {
+   dev_err(the_menelaus-client-dev,
+   could not set regulators to sleep: %d\n, ret);
+   return ret;
+   }
+   return 0;
+}
+
 /*---*/
 
 /* Handles Menelaus interrupts. Does not run in interrupt context */
@@ -1162,6 +1180,7 @@ static int menelaus_probe(struct i2c_client *client,
struct menelaus_chip*menelaus;
int rev = 0;
int err = 0;
+   struct device_node  *np = client-dev.of_node;
struct menelaus_platform_data *menelaus_pdata =
dev_get_platdata(client-dev);
 
@@ -1221,10 +1240,35 @@ static int menelaus_probe(struct i2c_client *client,
else
menelaus-vcore_hw_mode = 0;
 
-   if (menelaus_pdata != NULL  menelaus_pdata-late_init != NULL) {
-   err = menelaus_pdata-late_init(client-dev);
-   if (err  0)
-   goto fail;
+   if (menelaus_pdata != NULL) {
+   if (menelaus_pdata-late_init != NULL) {
+   err = menelaus_pdata-late_init(client-dev);
+   if (err  0)
+   goto fail;
+   }
+   } else if (np) {
+   u32 vcore_min;
+   u32 vcore_max;
+
+   if (!of_property_read_u32(np, ti,vcore-min-microvolt,
+ vcore_min) 
+   !of_property_read_u32(np, ti,vcore-max-microvolt,
+ vcore_max)) {
+   err = menelaus_set_vcore_hw(vcore_max / 1000,
+   vcore_min / 1000);
+   if (err  0) {
+   dev_err(client-dev,
+   could not set VCORE voltage: %d\n,
+   err);
+   goto fail;
+   }
+   }
+
+   if (of_property_read_bool(np, ti,autosleep)) {
+   err = menelaus_auto_sleep_regulators();
+   if (err  0)
+   goto fail;
+   }
}
 
menelaus_rtc_init(menelaus);
-- 
2.2.0

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

[PATCH 2/7] mfd: menelaus: drop support for SW controller VCORE

[Aaro Koskinen]

Drop support for SW controlled VCORE, nobody uses it.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/mfd/menelaus.c   | 23 ---
 include/linux/mfd/menelaus.h |  1 -
 2 files changed, 24 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9f01aef..917fa86 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -532,29 +532,6 @@ static const struct menelaus_vtg_value vcore_values[] = {
{ 1450, 18 },
 };
 
-int menelaus_set_vcore_sw(unsigned int mV)
-{
-   int val, ret;
-   struct i2c_client *c = the_menelaus-client;
-
-   val = menelaus_get_vtg_value(mV, vcore_values,
-ARRAY_SIZE(vcore_values));
-   if (val  0)
-   return -EINVAL;
-
-   dev_dbg(c-dev, Setting VCORE to %d mV (val 0x%02x)\n, mV, val);
-
-   /* Set SW mode and the voltage in one go. */
-   mutex_lock(the_menelaus-lock);
-   ret = menelaus_write_reg(MENELAUS_VCORE_CTRL1, val);
-   if (ret == 0)
-   the_menelaus-vcore_hw_mode = 0;
-   mutex_unlock(the_menelaus-lock);
-   msleep(1);
-
-   return ret;
-}
-
 int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV)
 {
int fval, rval, val, ret;
diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index a1e12bf3..9e85ac0 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -24,7 +24,6 @@ extern int menelaus_set_vaux(unsigned int mV);
 extern int menelaus_set_vdcdc(int dcdc, unsigned int mV);
 extern int menelaus_set_slot_sel(int enable);
 extern int menelaus_get_slot_pin_states(void);
-extern int menelaus_set_vcore_sw(unsigned int mV);
 extern int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV);
 
 #define EN_VPLL_SLEEP  (1  7)
-- 
2.2.0

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

[PATCH 5/7] mfd: menelaus: delete platform data support

[Aaro Koskinen]

Delete platform data support.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/mach-omap2/common-board-devices.h |  2 --
 drivers/mfd/menelaus.c | 10 +-
 include/linux/mfd/menelaus.h   |  6 --
 3 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/common-board-devices.h 
b/arch/arm/mach-omap2/common-board-devices.h
index 07c88ae..7a30228 100644
--- a/arch/arm/mach-omap2/common-board-devices.h
+++ b/arch/arm/mach-omap2/common-board-devices.h
@@ -2,7 +2,6 @@
 #define __OMAP_COMMON_BOARD_DEVICES__
 
 #include sound/tlv320aic3x.h
-#include linux/mfd/menelaus.h
 #include twl-common.h
 
 #define NAND_BLOCK_SIZESZ_128K
@@ -14,7 +13,6 @@ void omap_ads7846_init(int bus_num, int gpio_pendown, int 
gpio_debounce,
   struct ads7846_platform_data *board_pdata);
 void *n8x0_legacy_init(void);
 
-extern struct menelaus_platform_data n8x0_menelaus_platform_data;
 extern struct aic3x_pdata n810_aic33_data;
 
 #endif /* __OMAP_COMMON_BOARD_DEVICES__ */
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 3e04c64..4a900cc 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1181,8 +1181,6 @@ static int menelaus_probe(struct i2c_client *client,
int rev = 0;
int err = 0;
struct device_node  *np = client-dev.of_node;
-   struct menelaus_platform_data *menelaus_pdata =
-   dev_get_platdata(client-dev);
 
if (the_menelaus) {
dev_dbg(client-dev, only one %s for now\n,
@@ -1240,13 +1238,7 @@ static int menelaus_probe(struct i2c_client *client,
else
menelaus-vcore_hw_mode = 0;
 
-   if (menelaus_pdata != NULL) {
-   if (menelaus_pdata-late_init != NULL) {
-   err = menelaus_pdata-late_init(client-dev);
-   if (err  0)
-   goto fail;
-   }
-   } else if (np) {
+   if (np) {
u32 vcore_min;
u32 vcore_max;
 
diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index 9e85ac0..21eeff5 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -5,12 +5,6 @@
 #ifndef __ASM_ARCH_MENELAUS_H
 #define __ASM_ARCH_MENELAUS_H
 
-struct device;
-
-struct menelaus_platform_data {
-   int (* late_init)(struct device *dev);
-};
-
 extern int menelaus_register_mmc_callback(void (*callback)(void *data, u8 
card_mask),
  void *data);
 extern void menelaus_unregister_mmc_callback(void);
-- 
2.2.0

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

[PATCH 1/7] mfd: menelaus: delete omap_has_menelaus

[Aaro Koskinen]

Delete unused macro.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 include/linux/mfd/menelaus.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index f097e89..a1e12bf3 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -38,10 +38,4 @@ extern int menelaus_set_vcore_hw(unsigned int roof_mV, 
unsigned int floor_mV);
 
 extern int menelaus_set_regulator_sleep(int enable, u32 val);
 
-#if defined(CONFIG_ARCH_OMAP2)  defined(CONFIG_MENELAUS)
-#define omap_has_menelaus()1
-#else
-#define omap_has_menelaus()0
-#endif
-
 #endif
-- 
2.2.0

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

[PATCH 7/7] mfd: menelaus: use macro for magic number

[Aaro Koskinen]

Use macro to check a register bit.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/mfd/menelaus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8660adf..05bae40 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1242,7 +1242,7 @@ static int menelaus_probe(struct i2c_client *client,
err = menelaus_read_reg(MENELAUS_VCORE_CTRL1);
if (err  0)
goto fail;
-   if (err  BIT(7))
+   if (err  VCORE_CTRL1_HW_NSW)
menelaus-vcore_hw_mode = 1;
else
menelaus-vcore_hw_mode = 0;
-- 
2.2.0

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

[PATCH 6/7] mfd: menelaus: make vcore and regulator controls internal

[Aaro Koskinen]

Make vcore and regulator control functions internal to the driver.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/mfd/menelaus.c   | 13 +++--
 include/linux/mfd/menelaus.h | 12 
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 4a900cc..8660adf 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -163,6 +163,15 @@
 #define MCT_PIN_ST_S1_CD_ST(1  0)
 #define MCT_PIN_ST_S2_CD_ST(1  1)
 
+#define EN_VPLL_SLEEP  (1  7)
+#define EN_VMMC_SLEEP  (1  6)
+#define EN_VAUX_SLEEP  (1  5)
+#define EN_VIO_SLEEP   (1  4)
+#define EN_VMEM_SLEEP  (1  3)
+#define EN_DC3_SLEEP   (1  2)
+#define EN_DC2_SLEEP   (1  1)
+#define EN_VC_SLEEP(1  0)
+
 static void menelaus_work(struct work_struct *_menelaus);
 
 struct menelaus_chip {
@@ -534,7 +543,7 @@ static const struct menelaus_vtg_value vcore_values[] = {
{ 1450, 18 },
 };
 
-int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV)
+static int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV)
 {
int fval, rval, val, ret;
struct i2c_client *c = the_menelaus-client;
@@ -743,7 +752,7 @@ int menelaus_get_slot_pin_states(void)
 }
 EXPORT_SYMBOL(menelaus_get_slot_pin_states);
 
-int menelaus_set_regulator_sleep(int enable, u32 val)
+static int menelaus_set_regulator_sleep(int enable, u32 val)
 {
int t, ret;
struct i2c_client *c = the_menelaus-client;
diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index 21eeff5..bcabc03 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -18,17 +18,5 @@ extern int menelaus_set_vaux(unsigned int mV);
 extern int menelaus_set_vdcdc(int dcdc, unsigned int mV);
 extern int menelaus_set_slot_sel(int enable);
 extern int menelaus_get_slot_pin_states(void);
-extern int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV);
-
-#define EN_VPLL_SLEEP  (1  7)
-#define EN_VMMC_SLEEP  (1  6)
-#define EN_VAUX_SLEEP  (1  5)
-#define EN_VIO_SLEEP   (1  4)
-#define EN_VMEM_SLEEP  (1  3)
-#define EN_DC3_SLEEP   (1  2)
-#define EN_DC2_SLEEP   (1  1)
-#define EN_VC_SLEEP(1  0)
-
-extern int menelaus_set_regulator_sleep(int enable, u32 val);
 
 #endif
-- 
2.2.0

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

[PATCH] ARM: OMAP: DTS: N950/N9: add twl_power

[Aaro Koskinen]

Add twl_power for N950/N9. Start with the simplest configuration to just
enable power off.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/boot/dts/omap3-n950-n9.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 1e49dfe..c41db94 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -60,6 +60,11 @@
 
 twl {
compatible = ti,twl5031;
+
+   twl_power: power {
+   compatible = ti,twl4030-power;
+   ti,use_poweroff;
+   };
 };
 
 twl_gpio {
-- 
2.2.0

--
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: v3.19-rc1 regression(?) on N900

[Aaro Koskinen]

Hi,

On Thu, Dec 25, 2014 at 10:11:21AM +0100, Pavel Machek wrote:
 On Thu 2014-12-25 09:32:40, Pali Rohár wrote:
  On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
   based on automated testing with u-boot as a chained
   bootloader..
   
   v3.19-rc1: hung
   https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
   2plus_defconfig/n900.txt
 
 Early hang, independend on config. That's dtb too big. Delete
 something, and it should work again.

For me, DT boot works fine with 3.19-rc1 as is...

 Plus you'll note video regression.

...however, I can confirm that framebuffer is broken:

[8.230743] omapfb omapfb: no displays
[8.255584] omapfb omapfb: failed to setup omapfb
[8.260620] platform omapfb: Driver omapfb requests probe deferral
[8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
'/ocp/spi@48098000/acx565akm@2[0]' - status (0)
[8.284271] acx565akm spi1.2: failed to find video source
[8.290069] spi spi1.2: Driver acx565akm requests probe deferral

I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
by matching reg-id). When I revert that, also FB works with 3.19-rc1.

A.
--
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] tty: serial: serial-omap: depend on !8250_omap

[Aaro Koskinen]

Hi,

On Mon, Dec 01, 2014 at 02:09:14PM +, One Thousand Gnomes wrote:
  Well the nightmare userspace switch from ttyS to ttyO few years ago is
  something we want to avoid.. I think the best solution would be to make
  serial-omap.c transparently provide support for ttyO using the new 8250
  code so both ttyS and ttyO devices would just work. Otherwise it will
  be years of my serial port stopped working questions again.
 
 Thata a udev problem not a kernel one surely.

People also use serial console to observe the early kernel boot before
the userspace is started.

A.
--
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+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote:
 Does kernel provide some interface for telling userspace
 applications something like bootreason (e.g power key, software
 reset, rtc alarm, charger connected, ...)?

In N950/N9, NOLO passes this information using kernel command line
and applications are reading /proc/cmdline. If I remember correctly all
those custom proc files were removed from Nokia kernel, and everything
was passed via command line.

A.
--
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+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote:
 uboot (in mode when is loaded from NOLO) has those issues:
 
 1) uboot cannot read n900 onenand mtd (uboot onenand driver not
 working, do not know why)
 2) missing support for battery charging (can totally discharge
 battery)

NOLO enables watchdogs when booting. So if you get stuck in the U-boot
for whatever reason the device will power off after ~30 secs or so.

A.
--
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+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Fri, Nov 28, 2014 at 11:49:00PM +0100, Pali Rohár wrote:
 On Friday 28 November 2014 23:41:35 Aaro Koskinen wrote:
  On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote:
   uboot (in mode when is loaded from NOLO) has those issues:
   
   1) uboot cannot read n900 onenand mtd (uboot onenand driver
   not working, do not know why)
   2) missing support for battery charging (can totally
   discharge battery)
  
  NOLO enables watchdogs when booting. So if you get stuck in
  the U-boot for whatever reason the device will power off
  after ~30 secs or so.
 
 Not truth!
 
 Uboot RX51 code periodically kick watchdogs if are enabled. I 
 implemented that before RX51 uboot was merged into mainline.

Maybe then it shouldn't do that.

A.
--
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] i2c: omap: fix NACK and Arbitration Lost irq handling

[Aaro Koskinen]

On Tue, Nov 18, 2014 at 09:00:58PM +0400, Alexander Kochetkov wrote:
 commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
 changed the interrupt handler to complete transfers without clearing
 XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
 fired again. As a result, ISR keep processing transfer after it was already
 complete (from the driver code point of view).
 
 A didn't see real impacts of the 1d7afc9, but it is really bad idea to
 have ISR running on user data after transfer was complete.
 
 It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
 handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).
 
 According to specs (if I understood correctly), in case of NACK and AL driver
 must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
 NACK, AL, ARDY, and XDR (Master Transmitter Mode).
 
 All that is done down the code under the if condition:
 if (stat  (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...
 
 The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
 no interrupts is fired after ISR informs the rest of driver what transfer
 complete.
 
 Note: instead of removing break under NACK case, we could just replace 'break'
 with 'continue' and allow NACK transfer to finish using ARDY event. I found
 that NACK and ARDY bits usually set together. That case confirm TI wiki:
 http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK
 
 In order if someone interested in the event traces for NACK and AL cases,
 I sent them to mailing list.
 
 Tested on Beagleboard XM C.
 
 Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
 Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
 Cc: sta...@vger.kernel.org # v3.7+

I could not see any breakage or anything wrong on OMAP2  OMAP3.
On OMAP1 I don't have anything on the OMAP I2C bus, so cannot really
test anything there.

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

 ---
  drivers/i2c/busses/i2c-omap.c |2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index 90dcc2e..9af7095 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -926,14 +926,12 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
   if (stat  OMAP_I2C_STAT_NACK) {
   err |= OMAP_I2C_STAT_NACK;
   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
 - break;
   }
  
   if (stat  OMAP_I2C_STAT_AL) {
   dev_err(dev-dev, Arbitration lost\n);
   err |= OMAP_I2C_STAT_AL;
   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
 - break;
   }
  
   /*
 -- 
 1.7.9.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
--
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 v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S

[Aaro Koskinen]

Hi,

On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote:
 + config DEBUG_OMAP1UART1
 + bool Kernel low-level debugging via OMAP1 UART1
 + depends on ARCH_OMAP1
 + select DEBUG_UART_8250
 + help
 +   Say Y here if you want kernel low-level debugging support
 +   on OMAP1 based platforms (expect OMAP730) on the UART1.
[...]
 +   on OMAP1 based platforms (expect OMAP730) on the UART2.
[...]
 +   on OMAP1 based platforms (expect OMAP730) on the UART3.
^^

Spelling again wrong. I think it was already corrected in v11?

A.
--
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: N900 modem support in 3.18-rc1

[Aaro Koskinen]

Hi,

On Thu, Nov 13, 2014 at 09:45:36AM -0800, Tony Lindgren wrote:
 * Pavel Machek pa...@ucw.cz [141113 08:23]:
  OTOH ofono seems pretty reasonable. So I played a bit, and result
  is python/pygtk gui which can receive an sms, initiate a call, and
  report missed call. If someone wants to play, source is at
  
  https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone
 
 Pavel, care to fill in the the following type patch with some
 instructions in the description now that you got it working?

Could we even have some permanent instructions under Documentation/?

 I did not have luck yet when I tried. I got the /dev/cmt/*
 entries after adding pm=1 param, but no luck scanning any networks.

I haven't tested anything yet, but looking forward to do that during
the weekend... Sounds pretty exciting. :-)

A.
--
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+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

On Wed, Oct 29, 2014 at 04:45:41PM -0500, Nishanth Menon wrote:
 On 12:39-20141029, Tony Lindgren wrote:
  OK, you want me to guess? A hundred million days, or maybe ten more
  minutes, somewhere in there, I just can't say, don't know.
 
 How about ~1 year? We have been talking about dt only boot for over an
 year already... Can we say 3.22 kernel, platforms that are not converted
 to device tree only loose legacy boot support. 

If you want to define some date, it should be a calendar date instead
of some kernel version based on guesswork (you cannot really predict
the kernel versions for future, just remember the 2.6.39 - 3.0 change).

Also, you cannot expect all kernel users to know what you have been
talking about. E.g. OMAP DMA API deprecation may have been discussed
before, but I only learned it after the WARN appeared in the kernel tree.
So you should start counting from that.

Personally I don't mind if you delete OMAP3 legacy boot support already
tomorrow morning, but if you want to give ~1 year transition period it
should end somewhere in the end of 2015. Of course if there are no legacy
boot users you can do it faster.

A.
--
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+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

On Wed, Oct 29, 2014 at 12:39:16PM -0700, Tony Lindgren wrote:
 From: Tony Lindgren t...@atomide.com
 Date: Mon, 27 Oct 2014 13:05:54 -0700
 Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
 
 We're moving omaps to use device tree based booting and already have
 omap2, omap4, omap5, am335x and am437x booting in device tree only
 mode.
 
 Only omap3 still has legacy booting still around and we really want
 to make that device tree only. So let's add a warning about deprecated
 legacy booting so we get people to upgrade their boards to use device
 tree based booting and find out about any remaining issues.
 
 Note that for most boards we already have the .dts file and those can
 be booted with without changing the bootloader using the appended
 DTB mode.
 
 Signed-off-by: Tony Lindgren t...@atomide.com

Reviewed-by: Aaro Koskinen aaro.koski...@iki.fi

 --- a/arch/arm/mach-omap2/omap_device.c
 +++ b/arch/arm/mach-omap2/omap_device.c
 @@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device 
 *dev, void *data)
  static int __init omap_device_late_init(void)
  {
   bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle);
 +
 + WARN(!of_have_populated_dt(),
 + legacy booting deprecated, please update to boot with .dts\n);
 +
   return 0;
  }
  omap_late_initcall_sync(omap_device_late_init);
--
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+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
 +
 + if (!of_have_populated_dt())
 + pr_warn(WARNING: legacy booting deprecated, please update to 
 boot with .dts\n);
 +

Maybe use WARN so that the warning is more verbose and kernel gets tainted?

A.
--
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: USB Ethernet gadget on Nokia n900

[Aaro Koskinen]

Hi,

On Sun, Oct 19, 2014 at 09:19:37PM +0200, Pavel Machek wrote:
 I am trying to use nfsroot, so I can't use modules.

Why not?

 (I am attaching full config, in case I missed something important).

I'm using the below config with 3.17 and g_ether works OK.

(My initramfs modprobes g_ether, runs busybox ifconfig for usb0
and launches sshd.)

A.

---

CONFIG_LOCALVERSION=-omap3
CONFIG_KERNEL_LZMA=y
CONFIG_SYSVIPC=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
CONFIG_EXPERT=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
# CONFIG_EFI_PARTITION is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_ARCH_OMAP3=y
# CONFIG_SOC_TI81XX is not set
# CONFIG_MACH_OMAP3_BEAGLE is not set
# CONFIG_MACH_DEVKIT8000 is not set
# CONFIG_MACH_OMAP_LDP is not set
# CONFIG_MACH_OMAP3530_LV_SOM is not set
# CONFIG_MACH_OMAP3_TORPEDO is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3517EVM is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
# CONFIG_MACH_TOUCHBOOK is not set
# CONFIG_MACH_OMAP_3430SDP is not set
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_CM_T35 is not set
# CONFIG_MACH_CM_T3517 is not set
# CONFIG_MACH_SBC3530 is not set
CONFIG_ARM_THUMBEE=y
CONFIG_PREEMPT=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_CMDLINE=console=ttyO2,115200 console=tty
CONFIG_KEXEC=y
CONFIG_BINFMT_MISC=y
CONFIG_PM_DEBUG=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_INET=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_IPV6 is not set
# CONFIG_WIRELESS is not set
CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
CONFIG_DEVTMPFS=y
CONFIG_MTD=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_OOPS=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
CONFIG_MTD_ONENAND_OMAP2=y
CONFIG_MTD_UBI=y
# CONFIG_BLK_DEV is not set
CONFIG_EEPROM_93CX6=y
CONFIG_SENSORS_LIS3_I2C=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_INPUT_POLLDEV=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_TWL4030=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=y
CONFIG_TOUCHSCREEN_TSC2005=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_TWL4030_PWRBUTTON=y
CONFIG_INPUT_UINPUT=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_I2C_CHARDEV=y
CONFIG_SPI=y
CONFIG_SPI_OMAP24XX=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_TWL4030=y
CONFIG_POWER_SUPPLY=y
CONFIG_WATCHDOG=y
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_OMAP2_DSS=y
# CONFIG_OMAP2_DSS_DPI is not set
CONFIG_OMAP2_DSS_SDI=y
CONFIG_FB_OMAP2=y
# CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
CONFIG_DISPLAY_PANEL_SONY_ACX565AKM=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
# CONFIG_LOGO_LINUX_CLUT224 is not set
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_ETH=m
# CONFIG_USB_ETH_RNDIS is not set
CONFIG_MMC=y
CONFIG_SDIO_UART=y
CONFIG_MMC_OMAP_HS=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_TWL4030=y
CONFIG_DMADEVICES=y
CONFIG_DMA_OMAP=y
CONFIG_TWL4030_USB=y
CONFIG_EXT4_FS=y
# CONFIG_FILE_LOCKING is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
CONFIG_TMPFS=y
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_OMAP3UART3=y
CONFIG_EARLY_PRINTK=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
--
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: USB Ethernet gadget on Nokia n900

[Aaro Koskinen]

Hi,

On Tue, Oct 21, 2014 at 12:35:18AM +0300, Aaro Koskinen wrote:
 On Sun, Oct 19, 2014 at 09:19:37PM +0200, Pavel Machek wrote:
  I am trying to use nfsroot, so I can't use modules.
 
 Why not?
 
  (I am attaching full config, in case I missed something important).
 
 I'm using the below config with 3.17 and g_ether works OK.

Also, I'm using DT boot.

A.
--
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] watchdog: Fix omap watchdogs to enable the magic close bit

[Aaro Koskinen]

Hi,

On Tue, Oct 14, 2014 at 12:25:19PM -0700, Tony Lindgren wrote:
 This allows testing the watchdog easily with distros just by
 doing pkill -9 watchdog.
 
 Reported-by: Thomas Dziedzic gos...@gmail.com
 Signed-off-by: Tony Lindgren t...@atomide.com

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
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: RCU bug with v3.17-rc3 ?

[Aaro Koskinen]

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 those compilers:
   
   https://lkml.org/lkml/2014/6/25/456
   https://lkml.org/lkml/2014/6/30/375
   https://lkml.org/lkml/2014/6/30/660
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
   https://lkml.org/lkml/2014/5/9/330

Is it possible to blacklist those GCC versions on ARM somehow as it
seems people are still using them?

This bug also ruined a file system on one of my boxes last year
(see e.g. http://marc.info/?l=linux-arm-kernelm=139033442527244w=2).

A.
--
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 v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Aaro Koskinen]

Hi,

On Tue, Sep 16, 2014 at 11:46:24PM +0100, Daniel Thompson wrote:
 + config DEBUG_OMAP1UART1
 + bool Kernel low-level debugging via OMAP1 UART1
 + depends on ARCH_OMAP1
 + select DEBUG_UART_8250
 + help
 +   Say Y here if you want kernel low-level debugging support
 +   on OMAP1 based platforms (expect OMAP730) on the UART1.
^^

 + select DEBUG_UART_8250
 + help
 +   Say Y here if you want kernel low-level debugging support
 +   on OMAP1 based platforms (expect OMAP730) on the UART2.
^^

 + select DEBUG_UART_8250
 + help
 +   Say Y here if you want kernel low-level debugging support
 +   on OMAP1 based platforms (expect OMAP730) on the UART3.
^^

I already commented earlier, that expect here is probably a typo?

A.
--
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] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators

[Aaro Koskinen]

Hi,

On Tue, Aug 19, 2014 at 08:24:05AM -0700, Tony Lindgren wrote:
 Commit 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn
 off oscillator during off-idle) added support for configuring the PMIC
 to cut off resources during deeper idle states to save power.

[...]

 Fixes: 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off 
 oscillator during off-idle)
 Cc: sta...@vger.kernel.org # v3.16
 Signed-off-by: Tony Lindgren t...@atomide.com

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
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 CFT v2] arm: omap1: Migrate debug_ll macros to use 8250.S

[Aaro Koskinen]

Hi,

On Fri, Jul 18, 2014 at 03:44:02PM +0100, Daniel Thompson wrote:
 The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
 the 8520 code the omap1 macro automatically determines what UART to use
 based on breadcrumbs left by the bootloader and automatically copes with
 the eccentric register layout on OMAP7XX.
 
 This patch drops both these features and relies instead on the generic
 8250 macros:
 
 1. Dropping support for the bootloader breadcrumbs is identical to the
way the migration was handled for OMAP2 (see 808b7e07464d...).
 
 2. Support for OMAP7XX still exists but it must be configured by hand
(DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.
 
 Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

I tested this on OMAP1510. The generic code works, though there will be
some more work for the user. Maybe that's acceptable if we want to get
rid of the asm file, since the use case is rare.

The patch still has couple typos, see comments below.

 Cc: Russell King li...@arm.linux.org.uk
 Cc: Tony Lindgren t...@atomide.com
 Cc: Arnd Bergmann arnd.bergm...@linaro.org
 Cc: linux-omap@vger.kernel.org
 ---
 
 Notes:
 Changes since v1:
 
 * Removed !ARCH_OMAP7XX from the DEBUG_OMAP1UART1/2/3 options
   (thanks to Aaro Koskinen)
 
  arch/arm/Kconfig.debug |  57 +-
  arch/arm/mach-omap1/include/mach/debug-macro.S | 101 
 -
  2 files changed, 56 insertions(+), 102 deletions(-)
  delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S
 
 diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
 index 6f9664a..762b3ed 100644
 --- a/arch/arm/Kconfig.debug
 +++ b/arch/arm/Kconfig.debug
 @@ -463,6 +463,30 @@ choice
 Say Y here if you want kernel low-level debugging support
 on TI-NSPIRE CX models.
  
 + config DEBUG_OMAP1UART1
 + bool Kernel low-level debugging via OMAP1 UART1
 + depends on ARCH_OMAP1
 + select DEBUG_UART_8250
 + help
 +   Say Y here if you want kernel low-level debugging support
 +   on OMAP1 based platforms (expect OMAP730) on the UART1.
^^

   This should be except, also repeated below for
   ports 2-3.

 + config DEBUG_OMAP1UART2
 + bool Kernel low-level debugging via OMAP1 UART2
 + depends on ARCH_OMAP1
 + select DEBUG_UART_8250
 + help
 +   Say Y here if you want kernel low-level debugging support
 +   on OMAP1 based platforms (expect OMAP730) on the UART2.
 +
 + config DEBUG_OMAP1UART3
 + bool Kernel low-level debugging via OMAP1 UART3
 + depends on ARCH_OMAP1
 + select DEBUG_UART_8250
 + help
 +   Say Y here if you want kernel low-level debugging support
 +   on OMAP1 based platforms (expect OMAP730) on the UART3.

A.
--
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: Nokia N900 FB regression?

[Aaro Koskinen]

Hi,

On Wed, Jul 23, 2014 at 12:37:06AM -0700, Tony Lindgren wrote:
 * Aaro Koskinen aaro.koski...@iki.fi [140722 14:25]:
  Hi,
  
  Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed
  the framebuffer stopped working on N900 (nothing on screen).
  
  I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts:
  Enable twl4030 off-idle configuration for selected omaps).
  With this commit reverted, I can see the Tux again with 3.16-rc6.
  
  Any ideas?
 
 Hmm, OK yeah that enables the deeper idle states. I have tested
 this on n900, but only have remote access to it so could not see
 the framebuffer.
 
 Sounds like there's some twl regulator that we cannot idle
 by default on n900. Here are the steps to narrow it down:
 
 1. Try ti,twl4030-power-idle in omap3-n900.dts instead of
ti,twl4030-power-idle-osc-off. This probably won't help
unless you're enabling off-idle though, so if it does not
help, just keep on using ti,twl4030-power-idle-osc-off.
 
 2. Try commenting out one or more of the TWL_REMAP_SLEEP or
TWL_REMAP_OFF lines in omap3_idle_rconfig in file
drivers/mfd/twl4030-power.c. That's the recommended init
sequence like the comments in the code mention. Chances
are we're missing a regulator_get somewhere but finding
out which one in omap3_idle_rconfig will help narrow it
down :)

It's VAUX1 - commenting that out alone fixes the issue. But I think we
are defining that one properly in the DTS (vdds_sdi-supply = vaux1),
and also I checked that sdi_init_regulator() succeeds...

BTW, this issue can be also detected without seeing the framebuffer,
from dmesg:

# dmesg|grep omapfb
[2.785705] omapfb omapfb: no displays
[2.786041] omapfb omapfb: failed to setup omapfb
[2.786102] platform omapfb: Driver omapfb requests probe deferral
[4.038055] acx565akm spi1.2: omapfb: acx565akm rev ab LCD detected
[5.421325] omapfb omapfb: Failed to enable display 'lcd'
[5.431335] omapfb omapfb: failed to initialize default display
[5.450408] omapfb omapfb: failed to setup omapfb
[5.455444] omapfb: probe of omapfb failed with error -1

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

Nokia N900 FB regression?

[Aaro Koskinen]

Hi,

Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed
the framebuffer stopped working on N900 (nothing on screen).

I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts:
Enable twl4030 off-idle configuration for selected omaps).
With this commit reverted, I can see the Tux again with 3.16-rc6.

Any ideas?

A.
--
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 CFT] arm: omap1: Migrate debug_ll macros to use 8250.S

[Aaro Koskinen]

Hi,

On Thu, Jul 17, 2014 at 11:54:04AM +0100, Daniel Thompson wrote:
 The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
 the 8520 code the omap1 macro automatically determines what UART to use
 based on breadcrumbs left by the bootloader and automatically copes with
 the eccentric register layout on OMAP7XX.

[...]

 + config DEBUG_OMAP1UART1
 + bool Kernel low-level debugging via OMAP1 UART1
 + depends on ARCH_OMAP1  !ARCH_OMAP730

Did you try this with omap1_defconfig and then running menuconfig to see
how it looks like? The patch allows to select only OMAP730 ports,
but the kernel should be bootable on all core types...

A.
--
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 PATCH] tty: serial: Add 8250-core based omap driver

[Aaro Koskinen]

Hi,

On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote:
  It has been only tested as console UART.
  The tty name is ttyS based instead of ttyO. How big is the pain here,
  what could be the easiest way to provide compatibility?
 
 have been considering that myself for months. You could pass an optional
 argument to serial8250_register_8250_port() but that only solves part of
 the problem :-(

When ttyS - ttyO change was done on OMAP, compatibility was not an issue.
Why should we care about it now?

A.
--
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/7] mailbox/omap: remove OMAP1 mailbox driver

[Aaro Koskinen]

Hi,

On Thu, Jun 26, 2014 at 03:28:14AM -0700, Tony Lindgren wrote:
 * Suman Anna s-a...@ti.com [140624 17:45]:
  There are no existing users for OMAP1 mailbox driver
  in kernel. Commit ab6f775 Removing dead OMAP_DSP
  has cleaned up all the dead code related to the only
  possible user, including the creation of the mailbox
  platform device.
  
  Remove this stale driver so that the OMAP mailbox
  driver can be simplified and streamlined better for
  converting to mailbox framework.
  
  Cc: Aaro Koskinen aaro.koski...@iki.fi
  Signed-off-by: Suman Anna s-a...@ti.com
 
 For the omap1_defconfig change:
 
 Acked-by: Tony Lindgren t...@atomide.com

I'm also OK with this change.

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
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: v3.16-rc1 default cachepolicy

[Aaro Koskinen]

Hi,

On Fri, Jun 20, 2014 at 12:36:26AM +0100, Russell King - ARM Linux wrote:
 On Fri, Jun 20, 2014 at 01:40:04AM +0300, Aaro Koskinen wrote:
  So I tried the below change. But now it hangs early, even before
  the earlyprintk is working. :-/
 
 Thanks for trying.  I notice you said write-through, so can you
 drop the PMD_SECT_BUFFERABLE flag and try again please?

Yes, that works.

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

v3.16-rc1 default cachepolicy

[Aaro Koskinen]

Hi,

When booting v3.16-rc1 on OMAP1, I noticed strange slowness.
E.g. initramfs unpack takes several minutes. This was caused by default
cachepolicy getting changed from writethrough - uncached for some reason:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.16.0-rc1-e3-los_880e+ (aaro@cooljazz) (gcc 
version 4.9.0 (GCC) ) #1 PREEMPT Thu Jun 19 22:51:42 EEST 2014
[0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Amstrad E3 (Delta)
[0.00] Ignoring memory below PHYS_OFFSET: 0x0200-0x1000
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: Data cache uncached
[...]
[4.602732] Unpacking initramfs...
[  425.125093] Freeing initrd memory: 3532K (c1c0 - c1f73000)

It seems this is caused by commit:

commit ca8f0b0a545f55b3dc6877cda24d609a8979c951
Author: Russell King rmk+ker...@arm.linux.org.uk
Date:   Tue May 27 20:34:28 2014 +0100

ARM: ensure C page table setup code follows assembly code

I can workaround this with cachepolicy=writethrough parameter.

A.
--
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: v3.16-rc1 default cachepolicy

[Aaro Koskinen]

Hi,

On Thu, Jun 19, 2014 at 09:58:53PM +0100, Russell King - ARM Linux wrote:
 On Thu, Jun 19, 2014 at 11:36:55PM +0300, Aaro Koskinen wrote:
  When booting v3.16-rc1 on OMAP1, I noticed strange slowness.
  E.g. initramfs unpack takes several minutes. This was caused by default
  cachepolicy getting changed from writethrough - uncached for some reason:
  
  [0.00] Booting Linux on physical CPU 0x0
  [0.00] Initializing cgroup subsys cpu
  [0.00] Linux version 3.16.0-rc1-e3-los_880e+ (aaro@cooljazz) (gcc 
  version 4.9.0 (GCC) ) #1 PREEMPT Thu Jun 19 22:51:42 EEST 2014
  [0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f
  [0.00] CPU: VIVT data cache, VIVT instruction cache
  [0.00] Machine: Amstrad E3 (Delta)
  [0.00] Ignoring memory below PHYS_OFFSET: 0x0200-0x1000
  [0.00] bootconsole [earlycon0] enabled
  [0.00] Memory policy: Data cache uncached
  [...]
  [4.602732] Unpacking initramfs...
  [  425.125093] Freeing initrd memory: 3532K (c1c0 - c1f73000)
  
  It seems this is caused by commit:
  
  commit ca8f0b0a545f55b3dc6877cda24d609a8979c951
  Author: Russell King rmk+ker...@arm.linux.org.uk
  Date:   Tue May 27 20:34:28 2014 +0100
  
  ARM: ensure C page table setup code follows assembly code
  
  I can workaround this with cachepolicy=writethrough parameter.
 
 It brings up the question - proc-arm925.S contains:
 
 .long   PMD_TYPE_SECT | \
 PMD_BIT4 | \
 PMD_SECT_AP_WRITE | \
 PMD_SECT_AP_READ
 .long   PMD_TYPE_SECT | \
 PMD_BIT4 | \
 PMD_SECT_AP_WRITE | \
 PMD_SECT_AP_READ
 
 In other words, it's telling the assembly code to setup uncached mappings
 for everything, even memory.  Most people want to set memory up (even at
 the assembly code time) in cacheable mode... so I'd suggest adding:
 
 PMD_SECT_BUFFERABLE | \
 PMD_SECT_CACHEABLE | \
 
 from the first.  You'll find it in the .macro at the end of proc-arm925.S.
 Please let me know if that works for you.

So I tried the below change. But now it hangs early, even before
the earlyprintk is working. :-/

A.

diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
index 97448c3..cb7c0e7 100644
--- a/arch/arm/mm/proc-arm925.S
+++ b/arch/arm/mm/proc-arm925.S
@@ -502,6 +502,8 @@ __\name\()_proc_info:
.long   \cpu_val
.long   \cpu_mask
.long   PMD_TYPE_SECT | \
+   PMD_SECT_BUFFERABLE | \
+   PMD_SECT_CACHEABLE | \
PMD_BIT4 | \
PMD_SECT_AP_WRITE | \
PMD_SECT_AP_READ
--
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] omap3-n900.dts: Rename model name to Nokia RX-51 board

[Aaro Koskinen]

On Wed, Jun 18, 2014 at 06:57:15PM +0200, Pali Rohár wrote:
 Use same name as in legacy board code. There are lot of userspace
 applications which using machine/model name for determinating device type.

Can you clarify this? Nokia kernel or userspace never had DT, so they
cannot see e.g. /proc/device-tree/model. What other APIs expose model?

A.
--
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] omap3-n900.dts: Rename model name to Nokia RX-51 board

[Aaro Koskinen]

Hi,

On Wed, Jun 18, 2014 at 10:23:03PM +0200, Pali Rohár wrote:
 On Wednesday 18 June 2014 22:12:41 Aaro Koskinen wrote:
  On Wed, Jun 18, 2014 at 06:57:15PM +0200, Pali Rohár wrote:
   Use same name as in legacy board code. There are lot of
   userspace applications which using machine/model name for
   determinating device type.
  
  Can you clarify this? Nokia kernel or userspace never had DT,
  so they cannot see e.g. /proc/device-tree/model. What other
  APIs expose model?
 
 Basically that patch export model name in Hardware /proc/cpuinfo 
 instead generic DT name. And this patch change name to what 
 legacy board code reported.

I don't like the idea of changing the model name from Nokia
marketing names to those cryptic internal names in DT files.
There also may be already some userspace relying to find current model
name from /proc/device-tree/model (e.g. I think my own OS would break).

A.
--
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: OMAP baseline test results for v3.15-rc7

[Aaro Koskinen]

Hi Paul,

On Tue, May 27, 2014 at 04:59:16PM +, Paul Walmsley wrote:
 Here are some basic OMAP test results for Linux v3.15-rc7.
 Logs and other details at:
 
 http://www.pwsan.com/omap/testlogs/test_v3.15-rc7/20140526221127/

This is great stuff, as always, but just curious, why are the N800 booting
results not reported? Based on your logs you are still booting it...?

A.
--
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: [PATCHv3 0/5] tsc2005 DT binding

[Aaro Koskinen]

Hi,

On Thu, May 15, 2014 at 04:23:16PM +0200, Sebastian Reichel wrote:
 On Sat, Apr 26, 2014 at 01:56:14AM +0200, Sebastian Reichel wrote:
  This adds device tree support for the tsc2005 touchscreen
  controller, which is currently only used by the Nokia N900
  board.
  
  The patch does not update the reset pin handling for platform
  data based probe to avoid merge conflicts. The n900 platform
  code will be removed in the near future (3.16?) and the driver
  can be simplified once that has happened.
 
 Ping. It would be nice to see this patchset in 3.16, since its
 the last important hardware component missing for N900 DT boot.

FWIW, for all these patches feel free to add:

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

Thanks for great work,

A.
--
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: remove some dead code

[Aaro Koskinen]

On Thu, May 15, 2014 at 09:16:21PM +0200, Paul Bolle wrote:
 A check for CONFIG_CBUS_TAHVO_USB was added in v2.6.17. The related
 Kconfig symbol has never been part of the tree. Remove that check.
 
 Replace the while (...) loop with a simple if (...) statement, while
 we're at it.
 
 Signed-off-by: Paul Bolle pebo...@tiscali.nl

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

 ---
 Untested, as usual.
 
 A quick search across the history of the tree suggests CBUS_TAHVO_USB
 was N770 related. Not that this matters much.

Yes, Tahvo USB is only used on Nokia 770 (which is the correct name,
not N770). The driver is nowadays behind TAHVO_USB, but like you said
the old symbol was never part of the mainline so it's OK to delete it.

A.
--
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 13/13] video: omap: allow building on !MMU

[Aaro Koskinen]

Hi,

On Thu, May 08, 2014 at 04:17:11PM -0700, Tony Lindgren wrote:
  OMAP1 fb is working very well. As a matter of fact, it's much more usable
  for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
  with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
  in mainline yet. :-(
 
 I hear you.. What do you have in the .config for omap1?
 Would be nice to enable the framebuffer in omap1_defconfig?

Looks like the needed stuff is enabled there. Unfortunately I cannot
test the full omap1_defconfig because of size limitations.

Tony, any idea of omap1's fb? Are you able to test this?
   
   I have three omap1 boards in my rack that I use for my boot
   testing. Tried to enable framebuffer but so far no luck on
   any of them. So I'm not much of a help here. Looks like the
   patch should work though..
   
   Aaro  Janusz, care to take a look at the patch in this
   thread?
  
  I couldn't figure out how to enter this code path. Amstrad E3  Nokia
  770 will take the alloc_fbmem() path  exit, and based on quick look
  I could not see way to enter mmap_kern(). Is that dead code?
 
 Could be. It may be something left from when we had code to keep
 the bootloader logo displayed while booting kernel.

The support for early fbmem alloc was removed in 2011
(1e434f9318efc3dddc0c0b8d2071712668154c2b, OMAPFB: remove early mem
alloc from old omapfb), so I think we can safely delete this code.
I can prepare  test a patch for this.

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