On Fri, 30 Apr 2010 10:08:45 -0500
Timur Tabi <timur.tabi@xxxxxxxxx> wrote:
> On Fri, Apr 30, 2010 at 5:19 AM, Anatolij Gustschin <agust@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
