Re: bbb kexec bug: Unhandled fault external abort on non-linefetch (0x1028) at 0xfa1ac140

2016-01-01 Thread Dave Young 
Hi, Grygorii

Thanks fot your reply.

On 12/28/15 at 02:15pm, Grygorii Strashko wrote:
> On 12/28/2015 09:18 AM, Dave Young wrote:
> > On 12/27/15 at 03:38pm, Dave Young wrote:
> >> Here is what I get when I test kdump on Beagle bone black:
> >>
> >> Added a printk line at the begin of function omap_gpio_rmw:
> >> printk("## %lx, %x, %x\n", base, reg, mask);
> >>
> >> Any hints how to fix it? I tried call the machine_kexec_mask_interrupts
> >> at runtime kernel also panics so it may not limit to kdump case.
> >>
> >> [   66.340168] ## fa1ac000, 140, 1
> >> [   66.344456] Unhandled fault: external abort on non-linefetch (0x1028) 
> >> at 0xfa1ac140
> >> [   66.352142] pgd = dd9f
> 
> [...]
> 
> >> [   66.727278] [] (omap_set_gpio_triggering) from [] 
> >> (omap_gpio_mask_irq+0x29/0x34)
> 
> Usually such back-trace means that you are trying to access HW
> which is disabled (powered off) already. Or this HW IP has never been enabled.

It is possible, but how to detect such disabled gpio in this for_each_irq_desc
loop? I tried below, it works for me but I'm not sure if it is a right fix.

---
 arch/arm/kernel/machine_kexec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux.orig/arch/arm/kernel/machine_kexec.c
+++ linux/arch/arm/kernel/machine_kexec.c
@@ -106,7 +106,7 @@ static void machine_kexec_mask_interrupt
if (chip->irq_eoi && irqd_irq_inprogress(>irq_data))
chip->irq_eoi(>irq_data);
 
-   if (chip->irq_mask)
+   if ((chip->irq_mask) && !irqd_irq_masked(>irq_data))
chip->irq_mask(>irq_data);
 
if (chip->irq_disable && !irqd_irq_disabled(>irq_data))

> 
> >> [   66.736457] [] (omap_gpio_mask_irq) from [] 
> >> (machine_crash_shutdown+0xb9/0x104)
> >> [   66.745551] [] (machine_crash_shutdown) from [] 
> >> (crash_kexec+0x35/0x68)
> >> [   66.753942] [] (crash_kexec) from [] 
> >> (die+0x1b9/0x390)
> >> [   66.760859] [] (die) from [] 
> >> (__do_kernel_fault.part.0+0x4f/0x1cc)
> >> [   66.768824] [] (__do_kernel_fault.part.0) from [] 
> >> (do_page_fault+0x155/0x29c)
> >> [   66.40] [] (do_page_fault) from [] 
> >> (do_DataAbort+0x2f/0x88)
> >> [   66.785432] [] (do_DataAbort) from [] 
> >> (__dabt_svc+0x3b/0x80)
> >> [   66.792858] Exception stack(0xddc39e58 to 0xddc39ea0)
> >> [   66.797929] 9e40:   
> >> 0063 df93647c
> >> [   66.806144] 9e60: 1f26a000  0001 0063 0007 c0702e3c 
> >>  ddc38000
> >> [   66.814359] 9e80:  7f70d614 0030 ddc39ea8 c021e54b c021e54c 
> >> 600e0033 
> >> [   66.822575] [] (__dabt_svc) from [] 
> >> (sysrq_handle_crash+0x18/0x1c)
> >> [   66.830530] [] (sysrq_handle_crash) from [] 
> >> (__handle_sysrq+0x79/0x10c)
> >> [   66.838919] [] (__handle_sysrq) from [] 
> >> (write_sysrq_trigger+0x45/0x50)
> >> [   66.847310] [] (write_sysrq_trigger) from [] 
> >> (proc_reg_write+0x43/0x68)
> >> [   66.855700] [] (proc_reg_write) from [] 
> >> (__vfs_write+0xf/0x8c)
> >> [   66.863304] [] (__vfs_write) from [] 
> >> (vfs_write+0x5f/0x128)
> >> [   66.870646] [] (vfs_write) from [] 
> >> (SyS_write+0x2b/0x68)
> >> [   66.877729] [] (SyS_write) from [] 
> >> (ret_fast_syscall+0x1/0x4c)
> >> [   66.885332] Code: 443c 4643 f6a9 f9a1 (6823) 0732
> >> [   66.890145] ---[ end trace 5a39094ece4dc200 ]---
> >> [   66.894782] Kernel panic - not syncing: Fatal exception
> >> [   66.900033] ---[ end Kernel panic - not syncing: Fatal exception
> >>
> 
> 
> -- 
> regards,
> -grygorii

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2016-01-01 Thread Ivaylo Dimitrov 

Hi Tony,

On 21.05.2015 00:21, Tony Lindgren wrote:

We support decoding the bootloader values if DEBUG is defined.
But we also need to change the struct omap_hwmod flags to have
HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
boot. Otherwise just the default timings will be displayed
instead of the bootloader configured timings.

This also allows us to clean up the various GPMC related
hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
and HWMOD_INIT_NO_IDLE is not needed.

Cc: Brian Hutchinson 
Cc: Paul Walmsley 
Cc: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
  drivers/memory/Kconfig  |  8 
  drivers/memory/omap-gpmc.c  |  6 +++---
  9 files changed, 29 insertions(+), 35 deletions(-)



1. Happy new year :)

2. It was a while I tested upstream on N900 but I had some spare time 
during the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To 
my surprise, after that try, Maemo 5 rootfs, which is located on onenand 
became irreversibly corrupted. I bisected the tree to the $subject 
commit and after restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod 
flags, the problem was solved. It seems that GPMC is either incorrectly 
or incompletely setup by the kernel, leading to failed onenand 
reads/writes and whatnot. Unfortunately, what I have here is a release 
device, so I am unable to capture any logs through the serial port. BTW 
keep in mind that rootfs corruption happens as soon as a boot is 
attempted, even after a freshly flashed rootfs.


Please advice on how to proceed.

Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] OMAP: RX51: save ATAGS data in the early boot stage

2016-01-01 Thread Ivaylo Dimitrov 

Hi,

On 24.12.2015 20:56, Tony Lindgren wrote:


Maybe update the description to say "This fixes a regression with
device tree based booting compared to legacy booting for n900 to
make the n900 legacy user space to also work with device tree based
booting".



OK, will do.


It would be nice to get these two in as fixes after -rc1 assuming
people have no objections to it. So please upload this one also
into Russell's patch system after no more comments:



Seems there are no more comments (and objections) so I will *try* to 
upload the patches in Russell's patch system. Will pester you to do it 
for me if I fail to do so :)



Acked-by: Tony Lindgren 



Thanks,
Ivo
--
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: omapfb: Add early framebuffer memory allocator

2016-01-01 Thread Pali Rohár 
Hi Tomi! Can you review this patch? It is waiting here for two years!

On Thursday 26 December 2013 00:12:39 Ivaylo Dimitrov wrote:
> From: Ivaylo Dimitrov 
> 
> On memory limited devices, CMA fails easily when asked to allocate
> big chunks of memory like framebuffer memory needed for video
> playback.
> 
> Add boot parameter "omapfb_memsize" which allocates memory to be used
> as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator
> when trying to allocate memory for the framebuffers
> 
> Signed-off-by: Ivaylo Dimitrov 
> ---
>  arch/arm/mach-omap2/common.c |1 +
>  arch/arm/mach-omap2/common.h |2 +
>  arch/arm/mach-omap2/fb.c |   46
> +- 3 files changed, 48
> insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/common.c
> b/arch/arm/mach-omap2/common.c index 2dabb9e..9beecde 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -33,4 +33,5 @@ void __init omap_reserve(void)
>   omap_dsp_reserve_sdram_memblock();
>   omap_secure_ram_reserve_memblock();
>   omap_barrier_reserve_memblock();
> + omap_fb_reserve_memblock();
>  }
> diff --git a/arch/arm/mach-omap2/common.h
> b/arch/arm/mach-omap2/common.h index e30ef67..21afdc0 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -304,6 +304,8 @@ extern void omap_reserve(void);
>  struct omap_hwmod;
>  extern int omap_dss_reset(struct omap_hwmod *);
> 
> +extern void omap_fb_reserve_memblock(void);
> +
>  /* SoC specific clock initializer */
>  extern int (*omap_clk_init)(void);
> 
> diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
> index 26e28e9..0eacbe9 100644
> --- a/arch/arm/mach-omap2/fb.c
> +++ b/arch/arm/mach-omap2/fb.c
> @@ -30,6 +30,7 @@
>  #include 
> 
>  #include 
> +#include 
> 
>  #include "soc.h"
>  #include "display.h"
> @@ -106,10 +107,53 @@ static struct platform_device omap_fb_device =
> { .num_resources = 0,
>  };
> 
> +static phys_addr_t omapfb_mem_base __initdata;
> +static phys_addr_t omapfb_mem_size __initdata;
> +
> +void __init omap_fb_reserve_memblock(void)
> +{
> + if (omapfb_mem_size) {
> + omapfb_mem_base = arm_memblock_steal(omapfb_mem_size, SZ_1M);
> + if (omapfb_mem_base)
> + pr_info("omapfb: reserved %u bytes at %x\n",
> + omapfb_mem_size, omapfb_mem_base);
> + else
> + pr_err("omapfb: arm_memblock_steal failed\n");
> + }
> +}
> +
>  int __init omap_init_fb(void)
>  {
> - return platform_device_register(_fb_device);
> + int ret;
> +
> + ret = platform_device_register(_fb_device);
> +
> + if (ret)
> + return ret;
> +
> + if (!omapfb_mem_base)
> + return 0;
> +
> + ret = dma_declare_coherent_memory(_fb_device.dev,
> +   omapfb_mem_base, omapfb_mem_base,
> +   omapfb_mem_size, DMA_MEMORY_MAP |
> +   DMA_MEMORY_EXCLUSIVE);
> + if (!(ret & DMA_MEMORY_MAP))
> + pr_err("omapfb: dma_declare_coherent_memory failed\n");
> +
> + return 0;
> +}
> +
> +static int __init early_omapfb_memsize(char *p)
> +{
> + omapfb_mem_size = ALIGN(memparse(p, ), SZ_1M);
> +
> + if(!omapfb_mem_size)
> + pr_err("omapfb: bad memsize parameter\n");
> +
> + return 0;
>  }
> +early_param("omapfb_memsize", early_omapfb_memsize);
>  #else
>  int __init omap_init_fb(void) { return 0; }
>  #endif

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

2016-01-01 Thread Ivaylo Dimitrov 



On 29.12.2015 09:46, Tomi Valkeinen wrote:


Oh, I'm sorry, I must have forgotten about that. Please, send a new patch.

  Tomi



Actually it is me to be sorry for making noise, I've missed 
0eb0dafb674cd6bfac2e3204b2f8b907e26b1138 with all those patches moving 
files around.


Ivo
--
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: OMAP2+: LogicPD Torpedo: Revert Duplicative Entries

2016-01-01 Thread Adam Ford 
Revert commit 7cd6ca770d1b ("ARM: dts: Change I2C2 and I2C3 to 400KHz
for LogicPD Torpedo DM3730 devkit")  It was already done and it is
just a duplicate.

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 7fed0bd..78c5243 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -112,14 +112,6 @@
clock-frequency = <40>;
 };
 
- {
-   clock-frequency = <40>;
-};
-
- {
-   clock-frequency = <40>;
-};
-
 /*
  * Only found on the wireless SOM. For the SOM without wireless, the pins for
  * MMC3 can be routed with jumpers to the second MMC slot on the devkit and
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html