Re: [PATCHv2 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
On 05/21/2015 01:40 AM, Paul Walmsley wrote: On Tue, 19 May 2015, Tero Kristo wrote: Any news on this? As noted previously, I am not able to reproduce the issue you are seeing currently, can you give DEBUG_LL a shot? Yeah I just bisected it, it was caused by this: commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e Author: Felipe Balbi ba...@ti.com Date: Fri Jan 30 11:18:56 2015 -0600 arm: config: omap2plus_defconfig: switch over to LZMA compression LZMA compression makes about 33% smaller zImage with just a slight extra decompression time. Before this patch, zImage built with o2+_dc is 4.5MiB and after it's about 3.3MiB. Suggested-by: David Cohen david.a.co...@linux.intel.com Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com and the timeouts on the testbed being set to fail if a kernel takes longer than five seconds to start. Seems that the part about a slight extra decompression time probably only applies to relatively recent chips. - Paul Oh, so this explains why I was thinking it took very long time to boot the recent kernels also. The boot lag is clearly noticeable without any measurement. I wonder if we should probably revert this patch. -Tero -- 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 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
On 05/21/2015 01:38 AM, Tero Kristo wrote: On 05/21/2015 01:40 AM, Paul Walmsley wrote: On Tue, 19 May 2015, Tero Kristo wrote: Any news on this? As noted previously, I am not able to reproduce the issue you are seeing currently, can you give DEBUG_LL a shot? Yeah I just bisected it, it was caused by this: commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e Author: Felipe Balbi ba...@ti.com Date: Fri Jan 30 11:18:56 2015 -0600 arm: config: omap2plus_defconfig: switch over to LZMA compression LZMA compression makes about 33% smaller zImage with just a slight extra decompression time. Before this patch, zImage built with o2+_dc is 4.5MiB and after it's about 3.3MiB. Suggested-by: David Cohen david.a.co...@linux.intel.com Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com and the timeouts on the testbed being set to fail if a kernel takes longer than five seconds to start. Seems that the part about a slight extra decompression time probably only applies to relatively recent chips. - Paul Oh, so this explains why I was thinking it took very long time to boot the recent kernels also. The boot lag is clearly noticeable without any measurement. I wonder if we should probably revert this patch. we already have issues with zImage size bloating up and running headlong into dtb - esp on platforms like N900. Felipe spend quiet some time getting things into a manageable size here - loosing 33% sounds like bad idea to me :( -- Regards, Nishanth Menon -- 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 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
* Nishanth Menon n...@ti.com [150521 00:03]: On 05/21/2015 01:38 AM, Tero Kristo wrote: On 05/21/2015 01:40 AM, Paul Walmsley wrote: On Tue, 19 May 2015, Tero Kristo wrote: Any news on this? As noted previously, I am not able to reproduce the issue you are seeing currently, can you give DEBUG_LL a shot? Yeah I just bisected it, it was caused by this: commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e Author: Felipe Balbi ba...@ti.com Date: Fri Jan 30 11:18:56 2015 -0600 arm: config: omap2plus_defconfig: switch over to LZMA compression LZMA compression makes about 33% smaller zImage with just a slight extra decompression time. Before this patch, zImage built with o2+_dc is 4.5MiB and after it's about 3.3MiB. Suggested-by: David Cohen david.a.co...@linux.intel.com Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com and the timeouts on the testbed being set to fail if a kernel takes longer than five seconds to start. Seems that the part about a slight extra decompression time probably only applies to relatively recent chips. - Paul Oh, so this explains why I was thinking it took very long time to boot the recent kernels also. The boot lag is clearly noticeable without any measurement. I wonder if we should probably revert this patch. we already have issues with zImage size bloating up and running headlong into dtb - esp on platforms like N900. Felipe spend quiet some time getting things into a manageable size here - loosing 33% sounds like bad idea to me :( If it affects people using the slower 34xx systems we should probably revert it though. Or make the uncompress somehow faster :) Regards, Tony -- 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 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
On Tue, 19 May 2015, Tero Kristo wrote: Any news on this? As noted previously, I am not able to reproduce the issue you are seeing currently, can you give DEBUG_LL a shot? Yeah I just bisected it, it was caused by this: commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e Author: Felipe Balbi ba...@ti.com Date: Fri Jan 30 11:18:56 2015 -0600 arm: config: omap2plus_defconfig: switch over to LZMA compression LZMA compression makes about 33% smaller zImage with just a slight extra decompression time. Before this patch, zImage built with o2+_dc is 4.5MiB and after it's about 3.3MiB. Suggested-by: David Cohen david.a.co...@linux.intel.com Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com and the timeouts on the testbed being set to fail if a kernel takes longer than five seconds to start. Seems that the part about a slight extra decompression time probably only applies to relatively recent chips. - Paul -- 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
