On Wednesday 21 March 2012 12:32:16 Anatolij Gustschin wrote:
> Hi Marek,
>
> On Wed, 21 Mar 2012 11:20:38 +0100
>
> Marek Vasut <ma...@denx.de> wrote:
> > Dear Anatolij Gustschin,
> >
> > > Hi,
> > >
> > > On Tue, 24 Jan 2012 15:28:02 +0100
> > >
> > > Pali Rohár <pali.ro...@gmail.com> wrote:
> > > >  * Use correct buffer size, do not damage screen output
> > > >
> > > > Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
> > > > ---
> > > >
> > > > Changes since original version:
> > > >    - Fixed commit message
> > > >
> > > >  drivers/video/cfb_console.c |    2 +-
> > > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/drivers/video/cfb_console.c
> > > > b/drivers/video/cfb_console.c index 904caf7..9092399 100644
> > > > --- a/drivers/video/cfb_console.c
> > > > +++ b/drivers/video/cfb_console.c
> > > > @@ -701,7 +701,7 @@ static void console_scrollup(void)
> > > >
> > > >                 );
> > > >
> > > >  #else
> > > >
> > > >         memcpyl(CONSOLE_ROW_FIRST, CONSOLE_ROW_SECOND,
> > > >
> > > > -               CONSOLE_SCROLL_SIZE >> 2);
> > > > +               CONSOLE_SCROLL_SIZE);
> > >
> > > NAK. This change is wrong. CONSOLE_SCROLL_SIZE is the size of
> > > the
> > > visible frame buffer - size of one row in bytes. We are using
> > > memcpyl() here, so the division by 4 (size >> 2) is correct.
> > > With your change we end up copying 4 times more data then
> > > needed.
> >
> > What kind of a problem are we fixing here? And what are the
> > symptoms of it?
> Actually I'm not aware of any problem in current
> console_scrollup(). At least on two test setups with different
> framebuffer drivers and in one setup with HW accelerated scrolling
> I didn't see any problems with current code.
>
> The description in the commit log of this patch:
> "Use correct buffer size, do not damage screen output"
> doesn't say much about the problem. If the GraphicDevice structure
> returned by video_hw_init() is setup correctly, the scrolling
> should be working fine. From the other patch [1] I can see that
> the structure is setup as follows:
>
>         /* fill in Graphic Device */
>         gdev.frameAdrs = 0x8f9c0000;
>         gdev.winSizeX = 800;
>         gdev.winSizeY = 480;
>         gdev.gdfBytesPP = 2;
>         gdev.gdfIndex = GDF_16BIT_565RGB;
>         memset((void *)gdev.frameAdrs, 0, 0xbb800);
>         return (void *) &gdev;
>
> Most likely using 0x8f9c0000 as framebuffer address is the first
> _big_ problem. The framebuffer address range is not allocated
> properly and could be used by malloc area. The board has 256 MB of
> RAM starting at 0x80000000, if U-Boot relocated itself to the
> upper RAM, the problems should be expected.
>
> AFAIK the N900 port doesn't use a framebuffer driver but probably
> uses pre-initialized display controller configuration. This should
> be fixed first.
>
> Thanks,
> Anatolij

Hi, can you show me how to fix this? How to correctly use
framebuffer?

--
Pali Rohár
pali.ro...@gmail.com

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to