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

[Hannes Schmelzer <hannes@schmelzer.or.at>]

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)
sorry, i've missed recent changes applied to master, there this was 
already fixed.
I also reviewed this ;-)
>
> 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
>