On Wednesday 01 September 2010 06:16:21 pm Ambrose, Martin wrote:
> On Wed, Sep 01, 2010 at 09:44:48, Caglar Akyuz wrote:
> > On Wednesday 01 September 2010 05:33:00 pm Ambrose, Martin wrote:
> > > On Wed, Sep 01, 2010 at 05:01:38, Caglar Akyuz wrote:
> > > > On Tuesday 06 April 2010 12:54:59 am Ambrose, Martin wrote:
> > > > > This work includes the following:
> > > > > . Implement handler for FBIO_WAITFORVSYNC ioctl.
> > > > >
> > > > > . Allocate the data and palette buffers separately.
> > > > > A consequence of this is that the palette and data loading is
> > > > > now done in different phases. And that the LCD must be disabled
> > > > > temporarily after the palette is loaded but this will only happen
> > > > > once after init and each time the palette is changed. I think this
> > > > > is OK.
> > > > >
> > > > > . Allocate two (ping and pong) framebuffers from memory.
> > > > >
> > > > > . Add pan_display handler which toggles the LCDC DMA registers
> > > > > between the ping and pong buffers.
> > > >
> > > > Hello,
> > > >
> > > > This patch breaks driver for a VGA display. After reverting this
> > > > patch, display works as expected. Do you have any idea what may be
> > > > the cause? I'm testing it on L-138 based Hawkboard.
> > >
> > > What is the nature of the error? Does the driver fail to
> > > load/initialize? Does the user space API still work but the display is
> > > corrupted? Something else?
> > >
> > > Regards,
> > > Martin
> >
> > There is no error in log messages, but display is showing total garbage.
> >
> > I'm trying with framebuffer console but copying known patterns to fb0
> > also shows garbage. I prepared 3 raw images (red, green, blue) all having
> > the same size as framebuffer. Then:
> >
> > $cp {red|green|blue} /dev/fb0
> >
> > shows garbage for all three.
> >
> > I compared hsync, vsync, pclk video signals with the working case and all
> > are the same.
>
> Hmm. I really have no idea what's wrong.
> I've used the same code on with a DVI output patch (not in tree) which
> works for me so I think the resolution portion should be ok.
>
What happens if userspace doesn't use FBIO_WAITFORVSYNC?
Is it supposed to work without using FBIOPAN_DISPLAY and
FBIO_WAITFORVSYNC ioctls?
> There is a build control in the source drivers/video/da8xx-fb.c
>
> #define LCD_NUM_BUFFERS 2
>
> You could try changing this to 1 to see if there is a difference.
> Although not sure how much information about the root cause this would
> generate.
>
Tried, nothing changed.
I tried various other things, as well as diff'ing LCD register values,
but I couldn't find anything. At the end of this mail I'm giving 2 different
register sets, one is with your patch reverted and the other one is
with your patch. Maybe it helps.
> I couldn't find reference to the Hawkboard in the mainline.
> Is there a git repo which I could use as a remote to look at diffs?
>
I'm currently working on adding support to mainline for that. That's why
I'm tackling with this. Roger Monk gathered all the pieces together but
his patch is based on Arago OMAP-L1 tree [1]. I'm trying to adopt it to
mainline. Also yesterday Victor Rodriguez submitted a simple patch
which has only UART support.
Best Regards,
Caglar
[1]
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-davinci/hawkboard/patch-2.6.33rc4-psp-to-hawkboard.patch
> Regards,
> Martin
>
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
