Wookey wrote: >> +// note here that only certain values of pixclock make sense, because the pixel clock >> +// is derived by dividing LCLK (104MHz) by an integer even though it's specified down >> +// to the picosecond. >> +// The divisor integer must be even if LCCR4_PCCDIV is not set, but can be odd if >> +// LCCR4_PCDDIV is set. >> +// Divisor pixclock Pixel clock frequency >> +// 6 57600 17.333MHz >> +// 5 48000 20.8MHz *requires LCCR4_PCDDIV set* >> +// 4 38400 26MHz >> +// 3 28800 34.667MHz *requires LCCR4_PCDDIV set* >> +// 2 19200 52MHz *generally too high to be useful, leaves no DMA bandwidth for anything else * >> + >> #ifdef CONFIG_BALLOON3_TOPPOLY >> -static struct pxafb_mode_info toppoly_mode __initdata = { >> +static struct pxafb_mode_info balloon3_lcd_mode __initdata = { >> .pixclock = 38000, > > It just said above that this should be 38400 - so is 38000 right or > shouold be fixed? I assume the latter. I'd leave it as it is: 38000 was arrived at a long time ago before I fully understood the behaviour of pixclock. Which pixel clock you end up with near the boundary values is something I can't remember, so I'd leave it as 38000 for now. > I had to re-do the definition in the relevant struct in pxafb.h for > some reason. Why's that? I had to shoehorn lccr4 into at least 2 structs and go round the code looking for places that they got copied into each other to make sure the value never got dropped. > I have no idea which bits should/shouldn't be set in general pxa > terms. I've put: > /* The following should be defined in LCCR4 > * LCCR4_PCDDIV (if odd pixclock divisor required) > > seem reasonable? Yes, that seems reasonable in the context of the way the kernel works out pixclock divisors. Chris -- Chris Jones - chris@martin-jones.com Martin-Jones Technology Ltd, makers of Solidlights 148 Catharine Street, Cambridge, CB1 3AR, UK Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908 http://www.solidlights.co.uk/