From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anatolij Gustschin Date: Fri, 30 Apr 2010 17:00:51 +0000 Subject: Re: [PATCH 3/5] powerpc/mpc5121: shared DIU framebuffer support Message-Id: <20100430190051.3a5ba058@wker> List-Id: References: <1272584978-19063-1-git-send-email-agust@denx.de> <1272584978-19063-4-git-send-email-agust@denx.de> <20100430121947.1d265ca6@wker> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Timur Tabi Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, wd-ynQEQJNshbs@public.gmane.org, dzu-ynQEQJNshbs@public.gmane.org, John Rigby , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, yorksun-KZfg59tc24xl57MIdRCFDg@public.gmane.org On Fri, 30 Apr 2010 10:08:45 -0500 Timur Tabi wrote: > On Fri, Apr 30, 2010 at 5:19 AM, Anatolij Gustschin wrote: > > >> How about just doing this? > >> > >> .init_early             = mpc512x_init_diu, > > > > I thought it should be prepared for adding other code here. > > mpc5121_ads_init_early() is generic and could contain other > > things as well. I would vote for current version. > > Do you have any plans to add any additional code? If not, then I say > skip the middle-man. If someone ever needs to do more, he can always > put that function back. Currently I do not have such plans. Ok will skip them. ... > >> Do you really need to use reserve_bootmem?  Have you tried kmalloc or > >> alloc_pages_exact()? > > > > Yes. No, it is too early to use them here. > > There was a recent change in the kernel that allows kmalloc to work > earlier than before. Take a look at commit > 85355bb272db31a3f2dd99d547eef794805e1319 ("powerpc: Fix mpic alloc > warning"). Thanks. Sorry for my wrong answer above, now I remember the logic behind this and will try to explain. Actually the reason I do not use kmalloc() here is that I do not want to _copy_ bitmap data to newly allocated frame buffer area (It will negatively affect boot time). Instead I reserve the already configured frame buffer area so that it won't be destroyed. The starting address of the area to reserve and also the lenght is passed to reserve_bootmem(). This is the real reason for using reserve_bootmem() here. I could alloc new bitmap area using allocators, but then I have to copy the bitmap data (splash image) to newly allocated area and have to re-configure the descriptors to display from new bitmap buffer. Anatolij From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by ozlabs.org (Postfix) with ESMTP id 72427B7D2F for ; Sat, 1 May 2010 03:00:54 +1000 (EST) Date: Fri, 30 Apr 2010 19:00:51 +0200 From: Anatolij Gustschin To: Timur Tabi Subject: Re: [PATCH 3/5] powerpc/mpc5121: shared DIU framebuffer support Message-ID: <20100430190051.3a5ba058@wker> In-Reply-To: References: <1272584978-19063-1-git-send-email-agust@denx.de> <1272584978-19063-4-git-send-email-agust@denx.de> <20100430121947.1d265ca6@wker> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: linux-fbdev@vger.kernel.org, wd@denx.de, dzu@denx.de, John Rigby , devicetree-discuss@lists.ozlabs.org, linuxppc-dev@ozlabs.org, yorksun@freescale.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 30 Apr 2010 10:08:45 -0500 Timur Tabi wrote: > On Fri, Apr 30, 2010 at 5:19 AM, Anatolij Gustschin wrote: >=20 > >> How about just doing this? > >> > >> .init_early =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D mpc512x_init= _diu, > > > > I thought it should be prepared for adding other code here. > > mpc5121_ads_init_early() is generic and could contain other > > things as well. I would vote for current version. >=20 > Do you have any plans to add any additional code? If not, then I say > skip the middle-man. If someone ever needs to do more, he can always > put that function back. Currently I do not have such plans. Ok will skip them. ... > >> Do you really need to use reserve_bootmem? =C2=A0Have you tried kmallo= c or > >> alloc_pages_exact()? > > > > Yes. No, it is too early to use them here. >=20 > There was a recent change in the kernel that allows kmalloc to work > earlier than before. Take a look at commit > 85355bb272db31a3f2dd99d547eef794805e1319 ("powerpc: Fix mpic alloc > warning"). Thanks. Sorry for my wrong answer above, now I remember the logic behind this and will try to explain. Actually the reason I do not use kmalloc() here is that I do not want to _copy_ bitmap data to newly allocated frame buffer area (It will negatively affect boot time). Instead I reserve the already configured frame buffer area so that it won't be destroyed. The starting address of the area to reserve and also the lenght is passed to reserve_bootmem(). This is the real reason for using reserve_bootmem() here. I could alloc new bitmap area using allocators, but then I have to copy the bitmap data (splash image) to newly allocated area and have to re-configure the descriptors to display from new bitmap buffer. Anatolij From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anatolij Gustschin Subject: Re: [PATCH 3/5] powerpc/mpc5121: shared DIU framebuffer support Date: Fri, 30 Apr 2010 19:00:51 +0200 Message-ID: <20100430190051.3a5ba058@wker> References: <1272584978-19063-1-git-send-email-agust@denx.de> <1272584978-19063-4-git-send-email-agust@denx.de> <20100430121947.1d265ca6@wker> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Timur Tabi Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, wd-ynQEQJNshbs@public.gmane.org, dzu-ynQEQJNshbs@public.gmane.org, John Rigby , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, yorksun-KZfg59tc24xl57MIdRCFDg@public.gmane.org List-Id: devicetree@vger.kernel.org T24gRnJpLCAzMCBBcHIgMjAxMCAxMDowODo0NSAtMDUwMApUaW11ciBUYWJpIDx0aW11ci50YWJp QGdtYWlsLmNvbT4gd3JvdGU6Cgo+IE9uIEZyaSwgQXByIDMwLCAyMDEwIGF0IDU6MTkgQU0sIEFu YXRvbGlqIEd1c3RzY2hpbiA8YWd1c3RAZGVueC5kZT4gd3JvdGU6Cj4gCj4gPj4gSG93IGFib3V0 IGp1c3QgZG9pbmcgdGhpcz8KPiA+Pgo+ID4+IC5pbml0X2Vhcmx5IMKgIMKgIMKgIMKgIMKgIMKg ID0gbXBjNTEyeF9pbml0X2RpdSwKPiA+Cj4gPiBJIHRob3VnaHQgaXQgc2hvdWxkIGJlIHByZXBh cmVkIGZvciBhZGRpbmcgb3RoZXIgY29kZSBoZXJlLgo+ID4gbXBjNTEyMV9hZHNfaW5pdF9lYXJs eSgpIGlzIGdlbmVyaWMgYW5kIGNvdWxkIGNvbnRhaW4gb3RoZXIKPiA+IHRoaW5ncyBhcyB3ZWxs LiBJIHdvdWxkIHZvdGUgZm9yIGN1cnJlbnQgdmVyc2lvbi4KPiAKPiBEbyB5b3UgaGF2ZSBhbnkg cGxhbnMgdG8gYWRkIGFueSBhZGRpdGlvbmFsIGNvZGU/ICAgSWYgbm90LCB0aGVuIEkgc2F5Cj4g c2tpcCB0aGUgbWlkZGxlLW1hbi4gIElmIHNvbWVvbmUgZXZlciBuZWVkcyB0byBkbyBtb3JlLCBo ZSBjYW4gYWx3YXlzCj4gcHV0IHRoYXQgZnVuY3Rpb24gYmFjay4KCkN1cnJlbnRseSBJIGRvIG5v dCBoYXZlIHN1Y2ggcGxhbnMuIE9rIHdpbGwgc2tpcCB0aGVtLgoKLi4uCj4gPj4gRG8geW91IHJl YWxseSBuZWVkIHRvIHVzZSByZXNlcnZlX2Jvb3RtZW0/IMKgSGF2ZSB5b3UgdHJpZWQga21hbGxv YyBvcgo+ID4+IGFsbG9jX3BhZ2VzX2V4YWN0KCk/Cj4gPgo+ID4gWWVzLiBObywgaXQgaXMgdG9v IGVhcmx5IHRvIHVzZSB0aGVtIGhlcmUuCj4gCj4gVGhlcmUgd2FzIGEgcmVjZW50IGNoYW5nZSBp biB0aGUga2VybmVsIHRoYXQgYWxsb3dzIGttYWxsb2MgdG8gd29yawo+IGVhcmxpZXIgdGhhbiBi ZWZvcmUuICBUYWtlIGEgbG9vayBhdCBjb21taXQKPiA4NTM1NWJiMjcyZGIzMWEzZjJkZDk5ZDU0 N2VlZjc5NDgwNWUxMzE5ICgicG93ZXJwYzogRml4IG1waWMgYWxsb2MKPiB3YXJuaW5nIikuCgpU aGFua3MuIFNvcnJ5IGZvciBteSB3cm9uZyBhbnN3ZXIgYWJvdmUsIG5vdyBJIHJlbWVtYmVyIHRo ZSBsb2dpYwpiZWhpbmQgdGhpcyBhbmQgd2lsbCB0cnkgdG8gZXhwbGFpbi4gQWN0dWFsbHkgdGhl IHJlYXNvbiBJIGRvIG5vdAp1c2Uga21hbGxvYygpIGhlcmUgaXMgdGhhdCBJIGRvIG5vdCB3YW50 IHRvIF9jb3B5XyBiaXRtYXAgZGF0YSB0bwpuZXdseSBhbGxvY2F0ZWQgZnJhbWUgYnVmZmVyIGFy ZWEgKEl0IHdpbGwgbmVnYXRpdmVseSBhZmZlY3QgYm9vdAp0aW1lKS4gSW5zdGVhZCBJIHJlc2Vy dmUgdGhlIGFscmVhZHkgY29uZmlndXJlZCBmcmFtZSBidWZmZXIgYXJlYQpzbyB0aGF0IGl0IHdv bid0IGJlIGRlc3Ryb3llZC4gVGhlIHN0YXJ0aW5nIGFkZHJlc3Mgb2YgdGhlIGFyZWEKdG8gcmVz ZXJ2ZSBhbmQgYWxzbyB0aGUgbGVuZ2h0IGlzIHBhc3NlZCB0byByZXNlcnZlX2Jvb3RtZW0oKS4K VGhpcyBpcyB0aGUgcmVhbCByZWFzb24gZm9yIHVzaW5nIHJlc2VydmVfYm9vdG1lbSgpIGhlcmUu CkkgY291bGQgYWxsb2MgbmV3IGJpdG1hcCBhcmVhIHVzaW5nIGFsbG9jYXRvcnMsIGJ1dCB0aGVu IEkgaGF2ZQp0byBjb3B5IHRoZSBiaXRtYXAgZGF0YSAoc3BsYXNoIGltYWdlKSB0byBuZXdseSBh bGxvY2F0ZWQgYXJlYQphbmQgaGF2ZSB0byByZS1jb25maWd1cmUgdGhlIGRlc2NyaXB0b3JzIHRv IGRpc3BsYXkgZnJvbSBuZXcKYml0bWFwIGJ1ZmZlci4KCkFuYXRvbGlqCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRldmljZXRyZWUtZGlzY3VzcyBtYWls aW5nIGxpc3QKZGV2aWNldHJlZS1kaXNjdXNzQGxpc3RzLm96bGFicy5vcmcKaHR0cHM6Ly9saXN0 cy5vemxhYnMub3JnL2xpc3RpbmZvL2RldmljZXRyZWUtZGlzY3Vzcwo=