[U-Boot] [PATCH 2/2] drivers/video/am335x-fb: Properly point framebuffer behind palette

[Martin Pietryka]

Hi Hannes,

On 04/27/2016 08:43 AM, Hannes Schmelzer wrote:
> On 04/27/2016 01:21 AM, Martin Pietryka wrote:
>> The DMA was outputting the palette on the screen because the base
>> for the DMA was not after the palette. In addition to that, the 
>> ceiling was
>> also too high, this led that the output on the screen was shifted.
>>
>> NOTE: According to the TRM, even in 16/24bit mode a palette is required
>> in the first 32 bytes of the framebuffer.
>>
>> See also:
>> https://e2e.ti.com/support/arm/sitara_arm/f/791/p/234967/834483#834483
>>
>> "In this mode, the LCDC will assume all information is data and thus you
>> need to ensure that the DMA points to the first pixel of data and not 
>> the
>> first entry in the frame buffer which is the beginning of the 512 byte
>> palette."
> Hi Martin,
> many thanks for working on this.
>
> I'm just reviewing the stuff, you're right it shouldn't work right now.
> But it does ?! Perhaps it does because there is another issue.
>
> DMA today fetches palette also, but the Bit 21..20 in RASTER_CTRL 
> aren't set correctly.
>
> We do:
>     lcdhw->raster_ctrl =    LCD_TFT_24BPP_MODE |
>                 LCD_TFT_24BPP_UNPACK |
>                 LCD_PALMODE_RAWDATA |
>                 LCD_TFT_MODE |
>                 LCD_RASTER_ENABLE;
>
> with
>
> #define LCD_PALMODE_RAWDATA            (0x10 << 20)
>
> this doesn't set palmode as excepted to raw data, instead this sets 
> 'stn565, bit24'.
>
> I will investigate a bit on this now, testing your patches and fixup 
> my mistakes.
>
> best regards,
> Hannes
>
>

regarding the bits in the palmode in RASTER_CTRL, I already made a patch 
yesterday which fixes this:

ac5c61b drivers/video/am335x-fb: Fix bits for LCD_PALMODE_RAWDATA definition

That might explain why no one saw DMA issues before because setting it 
to stn565 mode might have not show any issues with the DMA (but that's 
just a guess).

But I'm sure it was the wrong setting, I also crosschecked the 
RASTER_CTRL register value with a running kernel (4.4) and the stn565
bit is also not set for 16bpp mode.

I tested it only on a 16bpp screen, it would be nice if someone could 
confirm that it works on a 24/32bpp screen.

Martin