[U-Boot] [PATCH 05/14] cfb_console: Fix function console_scrollup

Pali Rohár
2012-03-21T18:50:34Z

On Wednesday 21 March 2012 12:32:16 Anatolij Gustschin wrote:
> Hi Marek,
>
> On Wed, 21 Mar 2012 11:20:38 +0100
>
> Marek Vasut <marex@denx.de> wrote:
> > Dear Anatolij Gustschin,
> >
> > > Hi,
> > >
> > > On Tue, 24 Jan 2012 15:28:02 +0100
> > >
> > > Pali Roh?r <pali.rohar@gmail.com> wrote:
> > > > * Use correct buffer size, do not damage screen output
> > > >
> > > > Signed-off-by: Pali Roh?r <pali.rohar@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.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120321/4d9b43da/attachment.pgp>