From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Mon, 05 Jan 2015 17:21:31 +0100 Subject: [U-Boot] [PATCH v2 1/2] sunxi: video: Add lcd output support In-Reply-To: <20150101222152.65f78215@i7> References: <1420027641-11613-1-git-send-email-hdegoede@redhat.com> <20150101222152.65f78215@i7> Message-ID: <54AABA0B.6080808@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 01-01-15 21:21, Siarhei Siamashka wrote: > On Wed, 31 Dec 2014 13:07:20 +0100 > Hans de Goede wrote: > >> Add lcd output support, see the new Kconfig entries and doc/README.video for >> how to enable / configure this. >> >> Signed-off-by: Hans de Goede >> @@ -179,7 +178,21 @@ struct sunxi_hdmi_reg { >> #define SUNXI_LCDC_CTRL_IO_MAP_TCON0 (0 << 0) >> #define SUNXI_LCDC_CTRL_IO_MAP_TCON1 (1 << 0) >> #define SUNXI_LCDC_CTRL_TCON_ENABLE (1 << 31) >> +#define SUNXI_LCDC_FRAME_CTRL0_RGB666 ((1 << 31) | (0 << 4)) >> +#define SUNXI_LCDC_FRAME_CTRL0_RGB656 ((1 << 31) | (5 << 4)) > > This would be probably SUNXI_LCDC_FRAME_CTRL0_RGB565 according to > the Allwinner documentation of the TCON0_FRM_CTL_REG register: > > 0: 6bit frm output > 1: 5bit frm output > > Since we have 5 there (101 bit pattern), it simply means RGB565. You're completely right, I took over the weird RGB656 naming from the allwinner kernel code without thinking things through properly. >> + bp = mode->vsync_len + mode->upper_margin; >> + total = mode->yres + mode->lower_margin + bp; >> + writel(SUNXI_LCDC_TCON0_TIMING_V_TOTAL(total) | >> + SUNXI_LCDC_TCON0_TIMING_V_BP(bp), &lcdc->tcon0_timing_v); >> + >> + writel(SUNXI_LCDC_X(mode->hsync_len) | SUNXI_LCDC_Y(mode->vsync_len), >> + &lcdc->tcon0_timing_sync); >> + >> + /* We only support hv-sync parallel lcd-s for now */ >> + writel(0, &lcdc->tcon0_hv_intf); >> + writel(0, &lcdc->tcon0_cpu_intf); >> + >> + if (sunxi_display.depth == 18 || sunxi_display.depth == 17) { > > Here 17 is not quite correct for RGB565. Right, this should be 16 meaning plain old RGB565, I've fixed both in my personal tree. Thanks for pointing this out! > > Also these are dithering settings, and this code just unconditionally > enables the right dithering for 16-bit LCD displays (this seems to > be never used in any real device from the sunxi-boards repository) or > 18-bit LCD displays, which are very common. > > Because 32-bit framebuffers support more colors than the 18-bit LCD > hardware can show, dithering is needed and used: > http://en.wikipedia.org/wiki/Frame_rate_control > > Do we want to have a separate option to enable/disable dithering? Or > just keep it always enabled until somebody complains? > > A simple program for testing dithering effects/usefulness can be found > here: > http://lists.denx.de/pipermail/u-boot/2015-January/200031.html Regards, Hans