Re: [U-Boot] [PATCH 05/18] dm: video: Add a video uclass

2016-01-17 Thread Anatolij Gustschin 
Hi Simon,

Some minor comments below. Otherwise

Acked-by: Anatolij Gustschin 


On Tue,  5 Jan 2016 09:31:01 -0700
Simon Glass  wrote:
...
> +config VIDEO_BPP8
> + bool "Support 8-bit-per-pixel displays"
> + depends on DM_VIDEO
> + default y if DM_VIDEO
> + help
> +   Support drawing text and bitmaps onto a 8-bit-per-pixel display.
> +   Ebabling this will include code to support this display. Without

s/Ebabling/Enabling/


> +config VIDEO_BPP16
> + bool "Support 16-bit-per-pixel displays"
> + depends on DM_VIDEO
> + default y if DM_VIDEO
> + help
> +   Support drawing text and bitmaps onto a 16-bit-per-pixel display.
> +   Ebabling this will include code to support this display. Without

same typo here.

> +config VIDEO_BPP32
> + bool "Support 32-bit-per-pixel displays"
> + depends on DM_VIDEO
> + default y if DM_VIDEO
> + help
> +   Support drawing text and bitmaps onto a 32-bit-per-pixel display.
> +   Ebabling this will include code to support this display. Without

s/Ebabling/Enabling/

...
> +/**
> + * struct video_priv - Device information used by the video uclass
> + *
> + * @xsize:   Number of pixel columns (e.g. 1366)
> + * @ysize:   Number of pixels rows (e.g.. 768)
> + * @tor: Display rotation (0=none, 1=90 degrees clockwise, etc.)
> + * @bpix:Encoded bits per pixel
> + * @fb:  Frame buffer
> + * @fb_size: Frame buffer size
> + * @fb_size: Frame buffer size

Please remove duplicated line here.

...
> +/**
> + * video_get_xsize() - Get the height of the display in pixels

s/_xsize/_ysize/

Thanks,

Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 05/18] dm: video: Add a video uclass

2016-01-05 Thread Simon Glass 
U-Boot has separate code for LCDs and 'video' devices. Both now use a
very similar API thanks to earlier work by Nikita Kiryanov. With the driver-
model conversion we should unify these into a single uclass.

Unfortunately there are different features supported by each. This
implementation provides for a common set of features which should serve
most purposes. The intent is to support:

- bitmap devices with 8, 16 and 32 bits per pixel
- text console wih white on black or vice versa
- rotated text console
- bitmap display (BMP format)

More can be added as additional boards are ported over to use driver model
for video.

The name 'video' is chosen for the uclass since it is more generic than LCD.
Another option would be 'display' but that would introduce a third concept
to U-Boot which seems like the wrong approach.

The existing LCD and video init functions are not needed now, so this uclass
makes no attempt to implement them.

Signed-off-by: Simon Glass 
---

 drivers/video/Kconfig|  40 
 drivers/video/Makefile   |   1 +
 drivers/video/video-uclass.c | 228 +++
 include/dm/uclass-id.h   |   1 +
 include/video.h  | 169 ++--
 5 files changed, 433 insertions(+), 6 deletions(-)
 create mode 100644 drivers/video/video-uclass.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index caf1efc..f17eb0a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -4,6 +4,46 @@
 
 menu "Graphics support"
 
+config DM_VIDEO
+   bool "Enable driver model support for LCD/video"
+   depends on DM
+   help
+ This enables driver model for LCD and video devices. These support
+ a bitmap display of various sizes and depths which can be drawn on
+ to display a command-line console or splash screen. Enabling this
+ option compiles in the video uclass and routes all LCD/video access
+ through this.
+
+config VIDEO_BPP8
+   bool "Support 8-bit-per-pixel displays"
+   depends on DM_VIDEO
+   default y if DM_VIDEO
+   help
+ Support drawing text and bitmaps onto a 8-bit-per-pixel display.
+ Ebabling this will include code to support this display. Without
+ this option, such displays will not be supported and console output
+ will be empty.
+
+config VIDEO_BPP16
+   bool "Support 16-bit-per-pixel displays"
+   depends on DM_VIDEO
+   default y if DM_VIDEO
+   help
+ Support drawing text and bitmaps onto a 16-bit-per-pixel display.
+ Ebabling this will include code to support this display. Without
+ this option, such displays will not be supported and console output
+ will be empty.
+
+config VIDEO_BPP32
+   bool "Support 32-bit-per-pixel displays"
+   depends on DM_VIDEO
+   default y if DM_VIDEO
+   help
+ Support drawing text and bitmaps onto a 32-bit-per-pixel display.
+ Ebabling this will include code to support this display. Without
+ this option, such displays will not be supported and console output
+ will be empty.
+
 config VIDEO_VESA
bool "Enable VESA video driver support"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e85fd8a..7192013 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -7,6 +7,7 @@
 
 ifdef CONFIG_DM
 obj-$(CONFIG_DISPLAY_PORT) += dp-uclass.o
+obj-$(CONFIG_DM_VIDEO) += video-uclass.o
 endif
 
 obj-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o videomodes.o
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
new file mode 100644
index 000..1615889
--- /dev/null
+++ b/drivers/video/video-uclass.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright (c) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_SANDBOX
+#include 
+#endif
+
+/*
+ * Theory of operation:
+ *
+ * Before relocation each device is bound. The driver for each device must
+ * set the @align and @size values in struct video_uc_platdata. This
+ * information represents the requires size and alignment of the frame buffer
+ * for the device. The values can be an over-estimate but cannot be too
+ * small. The actual values will be suppled (in the same manner) by the bind()
+ * method after relocation.
+ *
+ * This information is then picked up by video_reserve() which works out how
+ * much memory is needed for all devices. This is allocated between
+ * gd->video_bottom and gd->video_top.
+ *
+ * After relocation the same process occurs. The driver supplies the same
+ * @size and @align information and this time video_post_bind() checks that
+ * the drivers does not overflow the allocated memory.
+ *
+ * The frame buffer address is actually set (to plat->base) in
+ * video_post_probe(). This function also clears the frame