Re: [PATCH RE-SEND] ARM: S5P: Move OneNAND device definitions in plat-s5p

2010-08-22 Thread Kyungmin Park
On Mon, Aug 23, 2010 at 11:35 AM, Kukjin Kim wrote: > Kyungmin Park wrote: >> >> " Note: S5PC110 and S5PC210 have same OneNAND driver." >> >> Yes I also think it's same device. At least Spec is same. But I heard it > has >> some different feature related with DMA operation. >> I'm not yet receive

Re: [PATCH 2/3] ARM: S5P: Add initial map for GPIO2 and GPIO3

2010-08-22 Thread Kyungmin Park
On Mon, Aug 23, 2010 at 11:15 AM, Kukjin Kim wrote: > Kyungmin Park wrote: >> >> On Mon, Aug 23, 2010 at 9:18 AM, Kukjin Kim wrote: >> > Kyungmin Park wrote: >> >> >> >> NAK. >> >> >> > I don't know why I need your ack for this...if any opinions, just > comments >> > is enough. >> >> Okay I said

RE: [PATCH RE-SEND] ARM: S5P: Move OneNAND device definitions in plat-s5p

2010-08-22 Thread Kukjin Kim
Kyungmin Park wrote: > > " Note: S5PC110 and S5PC210 have same OneNAND driver." > > Yes I also think it's same device. At least Spec is same. But I heard it has > some different feature related with DMA operation. > I'm not yet receive the official release from LSI. So I can't tell the exact > on

RE: [PATCH 00/14] ARM: S5PV310: Updates clock

2010-08-22 Thread Kukjin Kim
Kyungmin Park wrote: > > Well, > > The current V310 clock codes don't work. I wonder these codes are > should be tested by your team. but it's just hang at clock init. > > With this patch, it's also don't boot. We also fixed the wrong uart > clock bit. but same. don't works. > > Question? Do yo

RE: [PATCH 2/3] ARM: S5P: Add initial map for GPIO2 and GPIO3

2010-08-22 Thread Kukjin Kim
Kyungmin Park wrote: > > On Mon, Aug 23, 2010 at 9:18 AM, Kukjin Kim wrote: > > Kyungmin Park wrote: > >> > >> NAK. > >> > > I don't know why I need your ack for this...if any opinions, just comments > > is enough. > > Okay I said in other word, I can't agree this patch. > > > > >> This approac

RE: [PATCH RE-SEND] ARM: S5P: Move OneNAND device definitions in plat-s5p

2010-08-22 Thread Kyungmin Park
" Note: S5PC110 and S5PC210 have same OneNAND driver." Yes I also think it's same device. At least Spec is same. But I heard it has some different feature related with DMA operation. I'm not yet receive the official release from LSI. So I can't tell the exact one. If it's true. we need to separat

Re: [PATCH 00/14] ARM: S5PV310: Updates clock

2010-08-22 Thread Kyungmin Park
Well, The current V310 clock codes don't work. I wonder these codes are should be tested by your team. but it's just hang at clock init. With this patch, it's also don't boot. We also fixed the wrong uart clock bit. but same. don't works. Question? Do you can boot with this codes at your board?

Re: [PATCH 2/3] ARM: S5P: Add initial map for GPIO2 and GPIO3

2010-08-22 Thread Kyungmin Park
On Mon, Aug 23, 2010 at 9:18 AM, Kukjin Kim wrote: > Kyungmin Park wrote: >> >> NAK. >> > I don't know why I need your ack for this...if any opinions, just comments > is enough. Okay I said in other word, I can't agree this patch. > >> This approach don't make a common GPIO framework. I already

[PATCH v2] ARM: SAMSUNG: Fix on build warning regarding VMALLOC_END type

2010-08-22 Thread Kukjin Kim
Fix this warning: arch/arm/mm/init.c: In function 'mem_init': arch/arm/mm/init.c:644: warning: format '%08lx' expects type 'long unsigned int', but argument 12 has type 'unsigned int' And removes the useless parens and white space. Reported-by: Kyungmin Park Signed-off-by: Kukjin Kim Cc: Ben D

RE: [PATCH] ARM: SAMSUNG: Fix on build warning regarding VMALLOC_END type

2010-08-22 Thread Kukjin Kim
Sergei Shtylyov wrote: > > Hello. > Hi ;-) > Kukjin Kim wrote: > > > Fix this warning: > > > arch/arm/mm/init.c: In function 'mem_init': > > arch/arm/mm/init.c:644: warning: format '%08lx' expects type > > 'long unsigned int', but argument 12 has type 'unsigned int' > > > Reported-by: Kyungmi

RE: [PATCH 2/3] ARM: S5P: Add initial map for GPIO2 and GPIO3

2010-08-22 Thread Kukjin Kim
Kyungmin Park wrote: > > NAK. > I don't know why I need your ack for this...if any opinions, just comments is enough. > This approach don't make a common GPIO framework. I already send the > common GPIO framework which send the base address to GPIO framework > and handle it regradless GPIO is on