From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Schmelzer Date: Wed, 27 Apr 2016 08:43:14 +0200 Subject: [U-Boot] [PATCH 2/2] drivers/video/am335x-fb: Properly point framebuffer behind palette In-Reply-To: <1461712873-6190-2-git-send-email-martin.pietryka@chello.at> References: <1461712873-6190-1-git-send-email-martin.pietryka@chello.at> <1461712873-6190-2-git-send-email-martin.pietryka@chello.at> Message-ID: <57205F82.9020302@schmelzer.or.at> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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