AM35xx DSS display driver for 320x240

did you set up correctly leftmargin rightmargin?

I am not sure where you would do that for an fbdev device.  I think that is for V4L2 devices?

Sorry I just realized you meant through fbset - the margins are 0,0.

your margins are wrong anyway. They just can't be zero.

so, what driver did you write? When I wrote drivers for TFT panels for omap3 that driver had a structure where all TFT parameters were described

please read my post to beagleboard group and have a look at a attached patch

https://groups.google.com/d/msg/beagleboard/JwRQphtJ8mU/L70srR_V2fQJ

I wrote a panel driver in the display directory of the drivers/video/omap2 directory in linux for a FEMA GM320240D panel.  This panel uses an HX8238 controller, so I set the interface for 24 data lines and the timings per the data sheet for the panel.  

static const struct omap_video_timings fema_gm320240d_timings = {
.x_res = 320,
.y_res = 240,

.pixel_clock = 6000,

.hsw = 1,
.hfp = 19,
.hbp = 67,
.vsw = 1,
.vfp = 4,
.vbp = 18,
};

and

static struct omap_dss_device fema_lcd_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = "lcd",
.driver_name = "fema_gm320240d_panel",
.phy.dpi.data_lines = 24,
.reset_gpio = LCD_RESET,
.platform_enable = am3517_dssdummy_enable,
.platform_disable = am3517_dssdummy_disable,
};

The enable and disable are dummy functions that don't really do anything.  The enable returns a 0, the disable is a void.  The default DSS driver is set to the LCD device, so I don't set the omapfb variables in the UBoot boot string.  I did try omapfb.mode=320x240MR-24@60 but it didn't change anything.  It seems that the indent is about 1/4 of the screen so I am beginning to believe it has to do with the 32 to 24 bit mapping somewhere?

where did you get these numbers?

.hsw = 1,
.hfp = 19,
.hbp = 67,
.vsw = 1,
.vfp = 4,
.vbp = 18,

here are margins digged in

hbp = horisontal back porch

hfp = horisontal front porch

etc..

Those numbers are directly from the FEMA data sheet, and therefore from the HX8238 controller data sheet.  I have used this controller in another board I designed using an ATMEL AT91SAM9263 with the same timings and it works perfectly.  Of course the display subsystem on the ATMEL chip is much different and the fb driver I wrote was very straightforward (single module fbdev).  I can't seem to decipher the DSS driver with all of its parts so I was hoping there was something obvious.  I don't understand why the margins are coming up blank in the fbdev ioctl but they are clearly being set in the driver.

You are right! There is somethig else: in your bootargs parameters remove everything about resolution and all DSS stuff. Just have something like this:

setenv bootargs console=${console} mpurate=${mpurate} vram=${vram} omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}

so, only omapdss.def_disp=${defaultdisplay} is ebout a display. No a kernel will let your own driver to rule things, not DSS. Just try and you will be convinced. I spent about 3 days on this problem a yeah ago :)

I added the omapdss.def_display to the bootargs.  I didn't originally include anything in the bootargs for DSS.  Still doing the same thing.  It seems that something isn't getting set in the DSS stack correctly.  When I do an FBIOGET_VSCREENINFO ioctl and check the pixclock value I get 0.  I wrote a little app that loads color bars into the frame buffer, each of them is 1/8 of the screen width.  The colors are accurate, but the last bar comes out in the beginning and is repeated once so instead of being on the end it takes up the first 1/4 of the screen.  It seems like an indexing issue or an overlay?

Bob,

Where you able to solve your problem? I have exact same issue.

Could you help me resolve this!

Thanks

Ahmad

Hi !

I have same problem but i don't understand what you say.

When i pull de to 1 or to 0, screen is blinking, changing color beetween rgb...

Can you help me please?