Re: Problems with framebuffer in 2.6.22-git17

["Antonino A. Daplas" <adaplas@gmail.com>]

On Sat, 2007-07-28 at 01:32 +0100, Adrian McMenamin wrote:
> On 28/07/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote:
> > > On 27/07/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > > > On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote:
> > > > > On 27/07/07, Adrian McMenamin <adrianmcmenamin@gmail.com> wrote:
> > > > >
> > > > > > With the patch reverted and 24bpp, it oopses before freezing (with two
> > > > > > odd looking boot logos on the screen):
> > > > > >
> > > > > Tested this further and it fails on:
> > > > >
> > > > > rev = fb_readl(par->mmio_base + 0x04);
> > > >
> > > > Doubtful if this line is the point of failure, this line is executed
> > > > only once, on initialization.
> > >
> > >
> > > par->mmio_base is corrupted in some way during the call to
> > > register_framebuffer - still investigating how/why.
> >
> > Possible, par->mmio_base is the last field in struct pvr2fb_par,
> > after that is the pseudo_palette. The oops did not manifest when the
> > pseudo_palette was written as u16, but oops'ed when written as u32.
> > Memory alignment problems?
> >
> > Try the patch I posted before, might help.
> >
> Apologies, missed the patch before.
> 
> With the patch applied the Dreamcast no longer crashes or locks with
> either 16, 24 or 32 bpp, so that's good.
> 
> With 24bpp everything is doubled up (eg two boot logos on screen) and
> about twice (?) the size it should be - though with a black screen.
> 
> With 32 bpp everything is about 4 (?) times the size it should be and
> all on a yellow background.
> 
> With 16bpp then everything is on a blue background as before, but is
> also the correct size (as before).

Is this with commit a66ad56eb2c9644717da4d7f05f971d6786145e3 reverted?
Reapply this commit again, it might (fingers crossed) correct the color
problem.

As to your display doubling/quadrupling with bpp 24/32, I don't have any
answers (no hardware) though it seems to be a framebuffer pitch/display
width mismatch.

Tony