On Wednesday 01 September 2010 07:59:00 pm Ambrose, Martin wrote:
> Can you provide the non working case with # buffers = 1?
>
They are the same:
*** 4: 0x601 ***
*** 8: 0x4 ***
*** 40: 0x2ff0c1 ***
*** 44: 0x3030fe70 ***
*** 48: 0x1f0b05df ***
*** 52: 0x270ff00 ***
*** 64: 0x45 ***
*** 68: 0xc7a00000 ***
*** 72: 0xc7a95ffc ***
*** 76: 0xc7a00000 ***
*** 80: 0xc7a95ffc ***
Although fbset shows following:
r...@hawkboard:~# fbset
mode "640x480-47"
# D: 21.429 MHz, H: 25.787 kHz, V: 47.315 Hz
geometry 640 480 640 480 16
timings 46666 64 64 32 32 63 1
accel false
rgba 5/11,6/5,5/0,0/0
endmode
While it shows following with LCD_NUM_BUFFERS = 2:
r...@hawkboard:~# fbset
mode "640x480-47"
# D: 21.429 MHz, H: 25.787 kHz, V: 47.315 Hz
geometry 640 480 640 960 16
timings 46666 64 64 32 32 63 1
accel false
rgba 5/11,6/5,5/0,0/0
endmode
BTW, these reg dumps are taken at the end of fb_probe. Let me know if there is
some better place.
Caglar
> -Martin
> ________________________________________
> From: Caglar Akyuz [[email protected]]
> Sent: Wednesday, September 01, 2010 11:57 AM
> To: Ambrose, Martin
> Cc: [email protected]
> Subject: Re: [PATCH v3 1/1] DA8XX/OMAP-L1XX: FB: Implement double buffering
>
> Forget add LCDC register values:
>
> not working:
> *** 4: 0x601 ***
> *** 8: 0x4 ***
> *** 40: 0x2ff0c1 ***
> *** 44: 0x3030fe70 ***
> *** 48: 0x1f0b05df ***
> *** 52: 0x270ff00 ***
> *** 64: 0x45 ***
> *** 68: 0xc7a00000 ***
> *** 72: 0xc7a95ffc ***
> *** 76: 0xc7a00000 ***
> *** 80: 0xc7a95ffc ***
>
> working:
> *** 4: 0x601 ***
> *** 8: 0x145 ***
> *** 40: 0xff0c1 ***
> *** 44: 0x3030fe70 ***
> *** 48: 0x1f0b05df ***
> *** 52: 0x270ff00 ***
> *** 64: 0x40 ***
> *** 68: 0xc7a00fe0 ***
> *** 72: 0xc7a96ffc ***
>
> Caglar
>
> On Wednesday 01 September 2010 07:56:29 pm Caglar Akyuz wrote:
> > 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/lin
> >u x-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
