Re: Problems with framebuffer in 2.6.22-git17

Adrian McMenamin
2007-07-28T00:32:46Z

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).

So, it's better certainly, but there are still a few issues with the
driver, though nothing that takes down the box.

So thanks!

Adrian