Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-24 Thread Nick Bowler
On 2012-10-23 18:42 -0500, Josh Cartwright wrote: > On Tue, Oct 23, 2012 at 04:27:03PM -0400, Nick Bowler wrote: > > Just FYI, I sent a patch to fix the same bug a while back > > > > https://patchwork.kernel.org/patch/1156361/ > > > > together with other patches to fix early printk on the ZC702 s

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Nick Bowler
On 2012-10-23 15:53 -0500, Josh Cartwright wrote: > On Tue, Oct 23, 2012 at 03:09:23PM -0500, Rob Herring wrote: > > On 10/23/2012 09:50 AM, Arnd Bergmann wrote: > > > On Monday 22 October 2012, Josh Cartwright wrote: > > >> -#define SCU_PERIPH_PHYS 0xF8F0 > > >> -#define SCU_PE

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Nick Bowler
On 2012-10-23 11:26 -0500, Josh Cartwright wrote: > On Tue, Oct 23, 2012 at 02:50:11PM +, Arnd Bergmann wrote: > > On Monday 22 October 2012, Josh Cartwright wrote: > > > Shifting them up into the vmalloc region prevents the following warning, > > > when booting a zynq qemu target with more tha

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Josh Cartwright
On Tue, Oct 23, 2012 at 04:27:03PM -0400, Nick Bowler wrote: > > Just FYI, I sent a patch to fix the same bug a while back > > https://patchwork.kernel.org/patch/1156361/ > > together with other patches to fix early printk on the ZC702 serial > console. Admittedly, I dropped the ball on these as

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Josh Cartwright
On Tue, Oct 23, 2012 at 05:17:42PM -0400, Nick Bowler wrote: > On 2012-10-23 15:53 -0500, Josh Cartwright wrote: > > On Tue, Oct 23, 2012 at 03:09:23PM -0500, Rob Herring wrote: > > > On 10/23/2012 09:50 AM, Arnd Bergmann wrote: > > > > On Monday 22 October 2012, Josh Cartwright wrote: > > > >> -#d

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Josh Cartwright
On Tue, Oct 23, 2012 at 03:09:23PM -0500, Rob Herring wrote: > On 10/23/2012 09:50 AM, Arnd Bergmann wrote: > > On Monday 22 October 2012, Josh Cartwright wrote: > >> -#define SCU_PERIPH_PHYS 0xF8F0 > >> -#define SCU_PERIPH_VIRT SCU_PERIPH_PHYS > >> +#define

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Rob Herring
On 10/23/2012 09:50 AM, Arnd Bergmann wrote: > On Monday 22 October 2012, Josh Cartwright wrote: >> Shifting them up into the vmalloc region prevents the following warning, >> when booting a zynq qemu target with more than 512mb of RAM: >> >> BUG: mapping for 0xe000 at 0xe000 out of vmall

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Arnd Bergmann
On Tuesday 23 October 2012, Josh Cartwright wrote: > On Tue, Oct 23, 2012 at 02:50:11PM +, Arnd Bergmann wrote: > > On Monday 22 October 2012, Josh Cartwright wrote: > > > > diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h > > > b/arch/arm/mach-zynq/include/mach/zynq_soc.h > > > index

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Josh Cartwright
Hey Arnd- Thanks for the review/suggestions. On Tue, Oct 23, 2012 at 02:50:11PM +, Arnd Bergmann wrote: > On Monday 22 October 2012, Josh Cartwright wrote: > > Shifting them up into the vmalloc region prevents the following warning, > > when booting a zynq qemu target with more than 512mb of

Re: [PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-23 Thread Arnd Bergmann
On Monday 22 October 2012, Josh Cartwright wrote: > Shifting them up into the vmalloc region prevents the following warning, > when booting a zynq qemu target with more than 512mb of RAM: > > BUG: mapping for 0xe000 at 0xe000 out of vmalloc space > > In addition, it allows for reuse of

[PATCH v2 2/4] zynq: move static peripheral mappings

2012-10-22 Thread Josh Cartwright
Shifting them up into the vmalloc region prevents the following warning, when booting a zynq qemu target with more than 512mb of RAM: BUG: mapping for 0xe000 at 0xe000 out of vmalloc space In addition, it allows for reuse of these mappings when the proper drivers issue requests via iore