* regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
@ 2014-12-05 16:10 Nishanth Menon
2014-12-05 16:13 ` Nishanth Menon
0 siblings, 1 reply; 18+ messages in thread
From: Nishanth Menon @ 2014-12-05 16:10 UTC (permalink / raw)
To: Kevin Hilman, Tomasz Figa, Marek Szyprowski, Russell King
Cc: linux-omap, tony, linux-arm-kernel, linux-next
next-20141204 fails to boot, but next-20141203 boots fine with
omap2plus_defconfig.
Panda-ES(4460):
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt
Panda(4430):
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt
at the point of hang (JTAG):
pandaboard-es:
cpu0: http://slexy.org/view/s2eIFqkRd5
cpu1: http://slexy.org/view/s2Tysb6gpL
Case #1:
Disabling CPUIDLE allows boot to proceed. there does not seem to have
been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this.
Case #2: Reverting the following allows boot.
>From next-20141204
10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings
revert this -> boot still fails
d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from
mach_desc only if not NULL
revert this -> boot still fails
46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C
revert this -> boot still fails
c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like
revert this -> boot passed (first bad commit).
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-05 16:10 regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) Nishanth Menon @ 2014-12-05 16:13 ` Nishanth Menon 2014-12-05 16:23 ` Russell King - ARM Linux 2014-12-09 16:57 ` Nishanth Menon 0 siblings, 2 replies; 18+ messages in thread From: Nishanth Menon @ 2014-12-05 16:13 UTC (permalink / raw) To: Kevin Hilman, Tomasz Figa, Marek Szyprowski, Russell King Cc: linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On 12/05/2014 10:10 AM, Nishanth Menon wrote: > next-20141204 fails to boot, but next-20141203 boots fine with > omap2plus_defconfig. > > Panda-ES(4460): > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt > Panda(4430): > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt > > at the point of hang (JTAG): > pandaboard-es: > cpu0: http://slexy.org/view/s2eIFqkRd5 > cpu1: http://slexy.org/view/s2Tysb6gpL > > Case #1: > Disabling CPUIDLE allows boot to proceed. there does not seem to have > been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this. > > Case #2: Reverting the following allows boot. > > From next-20141204 > 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings > revert this -> boot still fails > > d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from > mach_desc only if not NULL > revert this -> boot still fails > > 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C > revert this -> boot still fails > > c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like > revert this -> boot passed (first bad commit). > > + linux-samsung soc and updated Thomaz's mail ID (gmail now). -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-05 16:13 ` Nishanth Menon @ 2014-12-05 16:23 ` Russell King - ARM Linux 2014-12-08 11:54 ` Tomasz Figa 2014-12-09 16:57 ` Nishanth Menon 1 sibling, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2014-12-05 16:23 UTC (permalink / raw) To: Nishanth Menon Cc: Kevin Hilman, Tomasz Figa, Marek Szyprowski, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On Fri, Dec 05, 2014 at 10:13:51AM -0600, Nishanth Menon wrote: > On 12/05/2014 10:10 AM, Nishanth Menon wrote: > > Case #2: Reverting the following allows boot. > > > > From next-20141204 > > 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings > > revert this -> boot still fails > > > > d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from > > mach_desc only if not NULL > > revert this -> boot still fails > > > > 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C > > revert this -> boot still fails > > > > c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like > > revert this -> boot passed (first bad commit). > > > > > > + linux-samsung soc and updated Thomaz's mail ID (gmail now). Given where we are in the cycle (-final likely this weekend) the only thing we can do right now is to drop the patch set; exynos (and mvebu) will have to wait another cycle until this patch set (hopefully in a revised form) can be merged. I think we need 8208/1 split up into smaller changes so that the cause of this regression can be found. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-05 16:23 ` Russell King - ARM Linux @ 2014-12-08 11:54 ` Tomasz Figa 2014-12-08 12:22 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Tomasz Figa @ 2014-12-08 11:54 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nishanth Menon, Kevin Hilman, Marek Szyprowski, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux <linux@arm.linux.org.uk>: > On Fri, Dec 05, 2014 at 10:13:51AM -0600, Nishanth Menon wrote: >> On 12/05/2014 10:10 AM, Nishanth Menon wrote: >> > Case #2: Reverting the following allows boot. >> > >> > From next-20141204 >> > 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings >> > revert this -> boot still fails >> > >> > d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from >> > mach_desc only if not NULL >> > revert this -> boot still fails >> > >> > 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C >> > revert this -> boot still fails >> > >> > c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like >> > revert this -> boot passed (first bad commit). >> > >> > >> >> + linux-samsung soc and updated Thomaz's mail ID (gmail now). > > Given where we are in the cycle (-final likely this weekend) the only > thing we can do right now is to drop the patch set; exynos (and mvebu) > will have to wait another cycle until this patch set (hopefully in a > revised form) can be merged. Or a fix could be queued on top of this. Since (I believe) this series has been queued for 3.19, we have 6 or 7 RC releases ahead, which could be used for the purpose of fixing things (as they are supposed to?). > > I think we need 8208/1 split up into smaller changes so that the cause > of this regression can be found. I'm afraid we need more than that. First of all, this series has been in the wild for more than 3 months already, without any serious changes. Need not to mention that mailing lists and maintainers of all potentially affected platforms had been added. It had been noted in cover letter that the only platform I (and Marek later) could test on was Exynos and that it would be good if somebody working with other platforms could test the patches. Looks like nobody cared back then, so why should we care that much now, especially that we have several RC releases ahead and we can still fix this? Best regards, Tomasz ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-08 11:54 ` Tomasz Figa @ 2014-12-08 12:22 ` Russell King - ARM Linux 2014-12-08 13:54 ` Nishanth Menon 0 siblings, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2014-12-08 12:22 UTC (permalink / raw) To: Tomasz Figa Cc: Nishanth Menon, Kevin Hilman, Marek Szyprowski, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: > 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux <linux@arm.linux.org.uk>: > > Given where we are in the cycle (-final likely this weekend) the only > > thing we can do right now is to drop the patch set; exynos (and mvebu) > > will have to wait another cycle until this patch set (hopefully in a > > revised form) can be merged. > > Or a fix could be queued on top of this. Since (I believe) this series > has been queued for 3.19, we have 6 or 7 RC releases ahead, which > could be used for the purpose of fixing things (as they are supposed > to?). They were merged on 27th November, so they would've been in linux-next from about last Monday. Nishanth reported a failure on Friday, the last week day before the merge window opens. There's no time to try and fix this before the merge window, which is why I decided to drop it. They have already been dropped. They were dropped immediately after my message on Friday was sent. So they've not been in linux-next over this past weekend. We don't push known broken code in during the merge window. The merge window is the exact time when subtle bugs are likely to be introduced, and is the exact time that you want bisect to work. If we push known broken patches into the kernel during that period, we break the ability to use bisect to find problems, especially where it causes a platform to become unbootable. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-08 12:22 ` Russell King - ARM Linux @ 2014-12-08 13:54 ` Nishanth Menon 2014-12-08 15:11 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Nishanth Menon @ 2014-12-08 13:54 UTC (permalink / raw) To: Russell King - ARM Linux, Tomasz Figa Cc: Kevin Hilman, Marek Szyprowski, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On 12/08/2014 06:22 AM, Russell King - ARM Linux wrote: > On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: >> 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux <linux@arm.linux.org.uk>: >>> Given where we are in the cycle (-final likely this weekend) the only >>> thing we can do right now is to drop the patch set; exynos (and mvebu) >>> will have to wait another cycle until this patch set (hopefully in a >>> revised form) can be merged. >> >> Or a fix could be queued on top of this. Since (I believe) this series >> has been queued for 3.19, we have 6 or 7 RC releases ahead, which >> could be used for the purpose of fixing things (as they are supposed >> to?). > > They were merged on 27th November, so they would've been in linux-next > from about last Monday. Nishanth reported a failure on Friday, the For what ever it is worth, the l2c changes actually appeared on Thursday CST (next-20141204). Found the regression against next-20141203 tag and it took me a day to track it down (after looking at a few other regressions as well).. Anyways... -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-08 13:54 ` Nishanth Menon @ 2014-12-08 15:11 ` Russell King - ARM Linux 0 siblings, 0 replies; 18+ messages in thread From: Russell King - ARM Linux @ 2014-12-08 15:11 UTC (permalink / raw) To: Nishanth Menon Cc: Tomasz Figa, Kevin Hilman, Marek Szyprowski, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On Mon, Dec 08, 2014 at 07:54:08AM -0600, Nishanth Menon wrote: > On 12/08/2014 06:22 AM, Russell King - ARM Linux wrote: > > On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: > >> 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux <linux@arm.linux.org.uk>: > >>> Given where we are in the cycle (-final likely this weekend) the only > >>> thing we can do right now is to drop the patch set; exynos (and mvebu) > >>> will have to wait another cycle until this patch set (hopefully in a > >>> revised form) can be merged. > >> > >> Or a fix could be queued on top of this. Since (I believe) this series > >> has been queued for 3.19, we have 6 or 7 RC releases ahead, which > >> could be used for the purpose of fixing things (as they are supposed > >> to?). > > > > They were merged on 27th November, so they would've been in linux-next > > from about last Monday. Nishanth reported a failure on Friday, the > > For what ever it is worth, the l2c changes actually appeared on > Thursday CST (next-20141204). Found the regression against > next-20141203 tag and it took me a day to track it down (after looking > at a few other regressions as well).. I wonder if that's because I didn't push my tree out until Tuesday-ish. It takes around 48 hours between when I push stuff out to it appearing in linux-next, which is not particularly desirable, but unavoidable due to timezone differences. I did decide that I wouldn't push it out the same day I merged it because I wanted it to run through my build/boot system, which it did successfully, but then my OMAP4 build doesn't have CPU idle enabled (and as you've identified, when CPU idle is disabled, it works.) The problem there is that if I decide not to push some merged changes out, it takes several days before I get around to touching the kernel tree again. Hence why it took from Thursday until Tuesday for it to eventually get pushed out. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-05 16:13 ` Nishanth Menon 2014-12-05 16:23 ` Russell King - ARM Linux @ 2014-12-09 16:57 ` Nishanth Menon 2014-12-10 9:42 ` Marek Szyprowski 1 sibling, 1 reply; 18+ messages in thread From: Nishanth Menon @ 2014-12-09 16:57 UTC (permalink / raw) To: Kevin Hilman, Tomasz Figa, Marek Szyprowski, Russell King Cc: linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On 10:13-20141205, Nishanth Menon wrote: > On 12/05/2014 10:10 AM, Nishanth Menon wrote: > > next-20141204 fails to boot, but next-20141203 boots fine with > > omap2plus_defconfig. > > > > Panda-ES(4460): > > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt > > Panda(4430): > > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt > > > > at the point of hang (JTAG): > > pandaboard-es: > > cpu0: http://slexy.org/view/s2eIFqkRd5 > > cpu1: http://slexy.org/view/s2Tysb6gpL > > > > Case #1: > > Disabling CPUIDLE allows boot to proceed. there does not seem to have > > been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this. > > > > Case #2: Reverting the following allows boot. > > > > From next-20141204 > > 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings > > revert this -> boot still fails > > > > d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from > > mach_desc only if not NULL > > revert this -> boot still fails > > > > 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C > > revert this -> boot still fails > > > > c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like > > revert this -> boot passed (first bad commit). > > > > > > + linux-samsung soc and updated Thomaz's mail ID (gmail now). Spend a few mins trying to track this down and it does look like commit c94e325 does a kmemdup for the data as part of l2x0_of_init->__l2c_init This fails since the invocation is in early_init. doing it a bit later as the following hack makes it work diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 608079a..0bc6bd9 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -170,12 +170,19 @@ static const char *const omap4_boards_compat[] __initconst = { NULL, }; + +static void tmp_init_irq(void) +{ + omap_l2_cache_init(); + omap_gic_of_init(); +} + DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device Tree)") .reserve = omap_reserve, .smp = smp_ops(omap4_smp_ops), .map_io = omap4_map_io, .init_early = omap4430_init_early, - .init_irq = omap_gic_of_init, + .init_irq = tmp_init_irq, .init_machine = omap_generic_init, .init_late = omap4430_init_late, .init_time = omap4_local_timer_init, diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 03cbb16..f97847d 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -627,7 +627,6 @@ void __init omap4430_init_early(void) omap44xx_clockdomains_init(); omap44xx_hwmod_init(); omap_hwmod_init_postsetup(); - omap_l2_cache_init(); omap_clk_soc_init = omap4xxx_dt_clk_init; } diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index e5948c5..0ca90db 100644 --- a/arch/arm/mm/cache-l2x0.c +++ b/arch/arm/mm/cache-l2x0.c @@ -848,8 +848,11 @@ static int __init __l2c_init(const struct l2c_init_data *data, * context from callers can access the structure. */ l2x0_data = kmemdup(data, sizeof(*data), GFP_KERNEL); - if (!l2x0_data) + if (!l2x0_data) { + pr_err("%s no mem %d\n", __func__, sizeof(*data)); + dump_stack(); return -ENOMEM; + } /* * Sanity check the aux values. aux_mask is the bits we preserve @@ -1647,6 +1650,7 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask) struct device_node *np; struct resource res; u32 cache_id, old_aux; + int r; np = of_find_matching_node(NULL, l2x0_ids); if (!np) @@ -1693,6 +1697,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask) else cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID); - return __l2c_init(data, aux_val, aux_mask, cache_id); + r = __l2c_init(data, aux_val, aux_mask, cache_id); + pr_err("%s: %d\n", __func__, r); + return r; } -- Regards, Nishanth Menon ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-09 16:57 ` Nishanth Menon @ 2014-12-10 9:42 ` Marek Szyprowski 2014-12-11 9:29 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Marek Szyprowski @ 2014-12-10 9:42 UTC (permalink / raw) To: Nishanth Menon, Kevin Hilman, Tomasz Figa, Russell King, Arnd Bergmann Cc: linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc Hello, On 2014-12-09 17:57, Nishanth Menon wrote: > On 10:13-20141205, Nishanth Menon wrote: >> On 12/05/2014 10:10 AM, Nishanth Menon wrote: >>> next-20141204 fails to boot, but next-20141203 boots fine with >>> omap2plus_defconfig. >>> >>> Panda-ES(4460): >>> https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt >>> Panda(4430): >>> https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt >>> >>> at the point of hang (JTAG): >>> pandaboard-es: >>> cpu0: http://slexy.org/view/s2eIFqkRd5 >>> cpu1: http://slexy.org/view/s2Tysb6gpL >>> >>> Case #1: >>> Disabling CPUIDLE allows boot to proceed. there does not seem to have >>> been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this. >>> >>> Case #2: Reverting the following allows boot. >>> >>> From next-20141204 >>> 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings >>> revert this -> boot still fails >>> >>> d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from >>> mach_desc only if not NULL >>> revert this -> boot still fails >>> >>> 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C >>> revert this -> boot still fails >>> >>> c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like >>> revert this -> boot passed (first bad commit). >>> >>> >> + linux-samsung soc and updated Thomaz's mail ID (gmail now). > Spend a few mins trying to track this down and it does look like commit > c94e325 does a kmemdup for the data as part of l2x0_of_init->__l2c_init > > This fails since the invocation is in early_init. doing it a bit later > as the following hack makes it work > diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c > index 608079a..0bc6bd9 100644 > --- a/arch/arm/mach-omap2/board-generic.c > +++ b/arch/arm/mach-omap2/board-generic.c > @@ -170,12 +170,19 @@ static const char *const omap4_boards_compat[] __initconst = { > NULL, > }; > > + > +static void tmp_init_irq(void) > +{ > + omap_l2_cache_init(); > + omap_gic_of_init(); > +} > + > DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device Tree)") > .reserve = omap_reserve, > .smp = smp_ops(omap4_smp_ops), > .map_io = omap4_map_io, > .init_early = omap4430_init_early, > - .init_irq = omap_gic_of_init, > + .init_irq = tmp_init_irq, > .init_machine = omap_generic_init, > .init_late = omap4430_init_late, > .init_time = omap4_local_timer_init, > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c > index 03cbb16..f97847d 100644 > --- a/arch/arm/mach-omap2/io.c > +++ b/arch/arm/mach-omap2/io.c > @@ -627,7 +627,6 @@ void __init omap4430_init_early(void) > omap44xx_clockdomains_init(); > omap44xx_hwmod_init(); > omap_hwmod_init_postsetup(); > - omap_l2_cache_init(); > omap_clk_soc_init = omap4xxx_dt_clk_init; > } > Please note that am43xx_init_early() also calls omap_l2_cache_init(), so similar fix is needed for "Generic AM43 (Flattened Device Tree)" machines. I've briefly looked how the initialization is done on various omap platforms, but I don't see the good generic place for omap_l2_cache_init(). IMHO the best solution will be to completely switch to generic/common l2c initialization and provide ".l2c_aux_val" and ".l2c_aux_mask" in machine descriptor. For the time being something like proposed above can be used. I assume that now it won't be possible to get l2c patches back to -next, so I will resend them (again...) with the omap related fix. > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c > index e5948c5..0ca90db 100644 > --- a/arch/arm/mm/cache-l2x0.c > +++ b/arch/arm/mm/cache-l2x0.c > @@ -848,8 +848,11 @@ static int __init __l2c_init(const struct l2c_init_data *data, > * context from callers can access the structure. > */ > l2x0_data = kmemdup(data, sizeof(*data), GFP_KERNEL); > - if (!l2x0_data) > + if (!l2x0_data) { > + pr_err("%s no mem %d\n", __func__, sizeof(*data)); > + dump_stack(); > return -ENOMEM; > + } > > /* > * Sanity check the aux values. aux_mask is the bits we preserve > @@ -1647,6 +1650,7 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask) > struct device_node *np; > struct resource res; > u32 cache_id, old_aux; > + int r; > > np = of_find_matching_node(NULL, l2x0_ids); > if (!np) > @@ -1693,6 +1697,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask) > else > cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID); > > - return __l2c_init(data, aux_val, aux_mask, cache_id); > + r = __l2c_init(data, aux_val, aux_mask, cache_id); > + pr_err("%s: %d\n", __func__, r); > + return r; > } > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-10 9:42 ` Marek Szyprowski @ 2014-12-11 9:29 ` Russell King - ARM Linux 2014-12-11 10:42 ` Marek Szyprowski 0 siblings, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2014-12-11 9:29 UTC (permalink / raw) To: Marek Szyprowski Cc: Nishanth Menon, Kevin Hilman, Tomasz Figa, Arnd Bergmann, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: > I assume that now it won't be possible to get l2c patches back to -next, > so I will resend them (again...) with the omap related fix. What, you mean you don't know the fundamental rules of kernel development? No one should ever dump any new code into linux-next during a merge window which is not a fix for a regression or a bug fix, period. Linus has in the past taken a snapshot of linux-next at the beginning of a merge window, and then threatened to refuse to merge anything that wasn't in his local snapshot, or which doesn't qualify as the above. So no, it won't be possible, because I play by the community rules when it comes to what gets merged and at what time in the cycle. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-11 9:29 ` Russell King - ARM Linux @ 2014-12-11 10:42 ` Marek Szyprowski 2014-12-22 17:04 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Marek Szyprowski @ 2014-12-11 10:42 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nishanth Menon, Kevin Hilman, Tomasz Figa, Arnd Bergmann, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On 2014-12-11 10:29, Russell King - ARM Linux wrote: > On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: >> I assume that now it won't be possible to get l2c patches back to -next, >> so I will resend them (again...) with the omap related fix. > What, you mean you don't know the fundamental rules of kernel development? > > No one should ever dump any new code into linux-next during a merge > window which is not a fix for a regression or a bug fix, period. > > Linus has in the past taken a snapshot of linux-next at the beginning > of a merge window, and then threatened to refuse to merge anything that > wasn't in his local snapshot, or which doesn't qualify as the above. > > So no, it won't be possible, because I play by the community rules when > it comes to what gets merged and at what time in the cycle. I know the rules. It was just my whining, that it is yet another release cycle that got missed. It is really disappointing, that those patches have been floating for months and noone found issues related to different order of initialization. It took way to long to get them scheduled for testing in -next. Exynos4 platform cannot be considered as fully functional without proper l2cache support, but I assume that this is once again our fault that we had to modify the common l2c code. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-11 10:42 ` Marek Szyprowski @ 2014-12-22 17:04 ` Russell King - ARM Linux 2014-12-22 17:08 ` Tony Lindgren 2014-12-22 17:12 ` Nishanth Menon 0 siblings, 2 replies; 18+ messages in thread From: Russell King - ARM Linux @ 2014-12-22 17:04 UTC (permalink / raw) To: Marek Szyprowski Cc: Nishanth Menon, Kevin Hilman, Tomasz Figa, Arnd Bergmann, linux-omap, tony, linux-arm-kernel, linux-next, linux-samsung-soc On Thu, Dec 11, 2014 at 11:42:48AM +0100, Marek Szyprowski wrote: > On 2014-12-11 10:29, Russell King - ARM Linux wrote: > >On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: > >>I assume that now it won't be possible to get l2c patches back to -next, > >>so I will resend them (again...) with the omap related fix. > >What, you mean you don't know the fundamental rules of kernel development? > > > >No one should ever dump any new code into linux-next during a merge > >window which is not a fix for a regression or a bug fix, period. > > > >Linus has in the past taken a snapshot of linux-next at the beginning > >of a merge window, and then threatened to refuse to merge anything that > >wasn't in his local snapshot, or which doesn't qualify as the above. > > > >So no, it won't be possible, because I play by the community rules when > >it comes to what gets merged and at what time in the cycle. > > I know the rules. It was just my whining, that it is yet another release > cycle > that got missed. It is really disappointing, that those patches have been > floating for months and noone found issues related to different order of > initialization. It took way to long to get them scheduled for testing in > -next. Right, so - we're now at -rc1, and we should see about queuing this up sooner rather than later - in its fixed form. From what I can see, there's been little progress on the OMAP problem. Nishanth - can we push OMAP over to using the generic DT L2C initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ? >From what I can see, in the DT case, the only thing which is used there is the ioremap() to provide omap4_get_l2cache_base() with something to return. Everything else - the initialisation of the l2c_write_sec pointer, and the aux mask and values - can be specified via the machine_desc struct. That only leaves the non-DT stuff to worry about this, and from what I understand, that's going to be removed soon. If we're going to keep the non-DT stuff, we should implement a new machine_desc hook for it instead of hijacking one of the existing callbacks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-22 17:04 ` Russell King - ARM Linux @ 2014-12-22 17:08 ` Tony Lindgren 2014-12-22 17:12 ` Nishanth Menon 1 sibling, 0 replies; 18+ messages in thread From: Tony Lindgren @ 2014-12-22 17:08 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Marek Szyprowski, Nishanth Menon, Kevin Hilman, Tomasz Figa, Arnd Bergmann, linux-omap, linux-arm-kernel, linux-next, linux-samsung-soc * Russell King - ARM Linux <linux@arm.linux.org.uk> [141222 09:06]: > On Thu, Dec 11, 2014 at 11:42:48AM +0100, Marek Szyprowski wrote: > > On 2014-12-11 10:29, Russell King - ARM Linux wrote: > > >On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: > > >>I assume that now it won't be possible to get l2c patches back to -next, > > >>so I will resend them (again...) with the omap related fix. > > >What, you mean you don't know the fundamental rules of kernel development? > > > > > >No one should ever dump any new code into linux-next during a merge > > >window which is not a fix for a regression or a bug fix, period. > > > > > >Linus has in the past taken a snapshot of linux-next at the beginning > > >of a merge window, and then threatened to refuse to merge anything that > > >wasn't in his local snapshot, or which doesn't qualify as the above. > > > > > >So no, it won't be possible, because I play by the community rules when > > >it comes to what gets merged and at what time in the cycle. > > > > I know the rules. It was just my whining, that it is yet another release > > cycle > > that got missed. It is really disappointing, that those patches have been > > floating for months and noone found issues related to different order of > > initialization. It took way to long to get them scheduled for testing in > > -next. > > Right, so - we're now at -rc1, and we should see about queuing this up > sooner rather than later - in its fixed form. From what I can see, > there's been little progress on the OMAP problem. > > Nishanth - can we push OMAP over to using the generic DT L2C > initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and > kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ? > > From what I can see, in the DT case, the only thing which is used > there is the ioremap() to provide omap4_get_l2cache_base() with > something to return. Everything else - the initialisation of the > l2c_write_sec pointer, and the aux mask and values - can be specified > via the machine_desc struct. > > That only leaves the non-DT stuff to worry about this, and from what I > understand, that's going to be removed soon. If we're going to keep > the non-DT stuff, we should implement a new machine_desc hook for it > instead of hijacking one of the existing callbacks. For omap4 and later we've been DT only for about 1.5 years now so that should not be an issue here. Regards, Tony ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-22 17:04 ` Russell King - ARM Linux 2014-12-22 17:08 ` Tony Lindgren @ 2014-12-22 17:12 ` Nishanth Menon 2014-12-22 17:28 ` Russell King - ARM Linux 1 sibling, 1 reply; 18+ messages in thread From: Nishanth Menon @ 2014-12-22 17:12 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Marek Szyprowski, Kevin Hilman, Arnd Bergmann, tony, Tomasz Figa, linux-samsung-soc, linux-next, linux-omap, linux-arm-kernel On Mon, Dec 22, 2014 at 11:04 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > > > Nishanth - can we push OMAP over to using the generic DT L2C > initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and > kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ? > > From what I can see, in the DT case, the only thing which is used > there is the ioremap() to provide omap4_get_l2cache_base() with > something to return. Everything else - the initialisation of the > l2c_write_sec pointer, and the aux mask and values - can be specified > via the machine_desc struct. I think this is what Marek proposed. I had requested for patches to be reposted with linux-omap in CC so that we can test and provide feedback. > > That only leaves the non-DT stuff to worry about this, and from what I > understand, that's going to be removed soon. If we're going to keep > the non-DT stuff, we should implement a new machine_desc hook for it > instead of hijacking one of the existing callbacks. none of the PL310 support requires non-DT. PL310 is needed for OMAP4 and AM437x both of which are DT only. -- --- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-22 17:12 ` Nishanth Menon @ 2014-12-22 17:28 ` Russell King - ARM Linux 2014-12-23 11:00 ` Marek Szyprowski 0 siblings, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2014-12-22 17:28 UTC (permalink / raw) To: Nishanth Menon Cc: Marek Szyprowski, Kevin Hilman, Arnd Bergmann, tony, Tomasz Figa, linux-samsung-soc, linux-next, linux-omap, linux-arm-kernel On Mon, Dec 22, 2014 at 11:12:42AM -0600, Nishanth Menon wrote: > On Mon, Dec 22, 2014 at 11:04 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > That only leaves the non-DT stuff to worry about this, and from what I > > understand, that's going to be removed soon. If we're going to keep > > the non-DT stuff, we should implement a new machine_desc hook for it > > instead of hijacking one of the existing callbacks. > > none of the PL310 support requires non-DT. PL310 is needed for OMAP4 > and AM437x both of which are DT only. Right, so the simple answer for the time being is to kill most of omap_l2_cache_init(), leaving just the ioremap() behind. Everything else can go into the machine_desc structures, and OMAP4 and AM437x can both benefit from initialising the L2 cache at exactly the same point as most other platforms. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-22 17:28 ` Russell King - ARM Linux @ 2014-12-23 11:00 ` Marek Szyprowski 2014-12-23 11:10 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Marek Szyprowski @ 2014-12-23 11:00 UTC (permalink / raw) To: Russell King - ARM Linux, Nishanth Menon Cc: Kevin Hilman, Arnd Bergmann, tony, Tomasz Figa, linux-samsung-soc, linux-next, linux-omap, linux-arm-kernel Hello, On 2014-12-22 18:28, Russell King - ARM Linux wrote: > On Mon, Dec 22, 2014 at 11:12:42AM -0600, Nishanth Menon wrote: >> On Mon, Dec 22, 2014 at 11:04 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >>> That only leaves the non-DT stuff to worry about this, and from what I >>> understand, that's going to be removed soon. If we're going to keep >>> the non-DT stuff, we should implement a new machine_desc hook for it >>> instead of hijacking one of the existing callbacks. >> none of the PL310 support requires non-DT. PL310 is needed for OMAP4 >> and AM437x both of which are DT only. > Right, so the simple answer for the time being is to kill most of > omap_l2_cache_init(), leaving just the ioremap() behind. Everything > else can go into the machine_desc structures, and OMAP4 and AM437x > can both benefit from initialising the L2 cache at exactly the same > point as most other platforms. I hope I did it right: https://lkml.org/lkml/2014/12/23/158 Please test, because I have no access to Omap hardware. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-23 11:00 ` Marek Szyprowski @ 2014-12-23 11:10 ` Russell King - ARM Linux 2014-12-23 16:05 ` Nishanth Menon 0 siblings, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2014-12-23 11:10 UTC (permalink / raw) To: Marek Szyprowski Cc: Nishanth Menon, Kevin Hilman, Arnd Bergmann, tony, Tomasz Figa, linux-samsung-soc, linux-next, linux-omap, linux-arm-kernel On Tue, Dec 23, 2014 at 12:00:00PM +0100, Marek Szyprowski wrote: > I hope I did it right: https://lkml.org/lkml/2014/12/23/158 > Please test, because I have no access to Omap hardware. Patch 1/8 looks like I'd expect it to. Nishanth, please test with your failing scenario, thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) 2014-12-23 11:10 ` Russell King - ARM Linux @ 2014-12-23 16:05 ` Nishanth Menon 0 siblings, 0 replies; 18+ messages in thread From: Nishanth Menon @ 2014-12-23 16:05 UTC (permalink / raw) To: Russell King - ARM Linux, Marek Szyprowski Cc: Kevin Hilman, Arnd Bergmann, tony, Tomasz Figa, linux-samsung-soc, linux-next, linux-omap, linux-arm-kernel On 12/23/2014 05:10 AM, Russell King - ARM Linux wrote: > On Tue, Dec 23, 2014 at 12:00:00PM +0100, Marek Szyprowski wrote: >> I hope I did it right: https://lkml.org/lkml/2014/12/23/158 >> Please test, because I have no access to Omap hardware. > > Patch 1/8 looks like I'd expect it to. Nishanth, please test with your > failing scenario, thanks. > 3.19-rc1 1: am437x-sk: BOOT: PASS: http://slexy.org/raw/s2ARFeCcDp 2: am43xx-epos: BOOT: PASS: http://slexy.org/raw/s2Kzli0GYS 3: am43xx-gpevm: BOOT: PASS: http://slexy.org/raw/s2DMkJGmdF 4: pandaboard-es: BOOT: PASS: http://slexy.org/raw/s204jfptrr 5: pandaboard-vanilla: BOOT: PASS: http://slexy.org/raw/s2cbd82pMI 6: sdp4430: BOOT: PASS: http://slexy.org/raw/s21bzlzUNr TOTAL = 6 boards, Booted Boards = 6, No Boot boards = 0 against the patch series: (all am437x platforms fail) testing 1: am437x-sk: BOOT: FAIL: http://slexy.org/raw/s2yhDXyF7o 2: am43xx-epos: BOOT: FAIL: http://slexy.org/raw/s2m9cSdt55 3: am43xx-gpevm: BOOT: FAIL: http://slexy.org/raw/s2MqFFBuIl 4: pandaboard-es: BOOT: PASS: http://slexy.org/raw/s2XwggyB0a 5: pandaboard-vanilla: BOOT: PASS: http://slexy.org/raw/s25WDvtbob 6: sdp4430: BOOT: PASS: http://slexy.org/raw/s2gjynR1Co TOTAL = 6 boards, Booted Boards = 3, No Boot boards = 3 I am trying to understand what is different in AM437x except that it is a single A9 instead of OMAP4 style dual A9s. -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-12-23 16:05 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-05 16:10 regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like) Nishanth Menon 2014-12-05 16:13 ` Nishanth Menon 2014-12-05 16:23 ` Russell King - ARM Linux 2014-12-08 11:54 ` Tomasz Figa 2014-12-08 12:22 ` Russell King - ARM Linux 2014-12-08 13:54 ` Nishanth Menon 2014-12-08 15:11 ` Russell King - ARM Linux 2014-12-09 16:57 ` Nishanth Menon 2014-12-10 9:42 ` Marek Szyprowski 2014-12-11 9:29 ` Russell King - ARM Linux 2014-12-11 10:42 ` Marek Szyprowski 2014-12-22 17:04 ` Russell King - ARM Linux 2014-12-22 17:08 ` Tony Lindgren 2014-12-22 17:12 ` Nishanth Menon 2014-12-22 17:28 ` Russell King - ARM Linux 2014-12-23 11:00 ` Marek Szyprowski 2014-12-23 11:10 ` Russell King - ARM Linux 2014-12-23 16:05 ` Nishanth Menon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).