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/
(text/plain)