Spotted two missing spaces in comments.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Current EDID detailed timing parser errors out when either
horizontal or vertical pulse sync width is 0, thus not
allowing a display with EDID listed below work properly.
EDID below works ok within Linux although it warns about
these two fields being 0. Therefore relax the checks a bit
so we can actually use this the screen out of the box.
Of-course, this display itself is somewhat quirky display with
following anti-features:
- HPD pin is not usable
- although resolution is 640x480, only top 240 pixels are visible
$ xxd -p display.edid
00ffffffffffff0005a1e00301000000150f0103800f05780a0f6ea05748
9a2610474f200000010101010101010101010101010101012a08804520e0
0b1020004000953600000018000000fd0034441a2403000a202020202020
0000001000310a20202020202020202020200000001000002a4030701300
782d1100001e006b
$ edid-decode display.edid
EDID version: 1.3
Manufacturer: AMA Model 3e0 Serial Number 1
Digital display
Maximum image size: 15 cm x 5 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
Red: 0.6250, 0.3398
Green: 0.2841, 0.6044
Blue: 0.1494, 0.0644
White: 0.2802, 0.3105
Established timings supported:
640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Standard timings supported:
Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm
640 672 672 709 hborder 0
480 484 484 491 vborder 0
-hsync -vsync
VertFreq: 60 Hz, HorFreq: 29478 Hz
Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz
Dummy block
Dummy block
Checksum: 0x6b (valid)
Signed-off-by: Priit Laes <priit.laes@paf.com>
Signed-off-by: Priit Laes <plaes@plaes.org>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.
Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.
Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a video_edid_dtd_to_ctfb_res_modes helper function to convert an EDID
detailed timing to a struct ctfb_res_modes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add 2 helper functions to get strings, respectively integers from the options
value returned by video_get_video_mode() / video_get_ctfb_res_modes().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add a video_get_ctfb_res_modes() helper function, which uses
video_get_video_mode() to parse the 'video-mode' environment variable and then
looks up the matching mode in res_mode_init and returns the matching mode.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
The timings for the modes defined in videomodes.c differ (significantly)
from vesa standard timings for these modes.
This commit adds a version with the proper std timings for these modes,
since I do not want to cause regressions, boards which want to use the standard
timings need to define CONFIG_VIDEO_STD_TIMINGS to get the new correct timings.
Since there is no std timing for 960x720 this commit uses the timing used
by the nvidia video drivers for 960x720, which uses a standard pixelclock
of 74.25 MHz rather then the weird 76.335... clock used by the old modes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add pixelclock_khz and refresh fields to ctfb_res_modes:
1) pixelclocks are usually referred to in hz, not picoseconds, and e.g
pll-s are also typically programmed in hz, not ps. Converting between the
2 leads to rounding differences, add a pixelclock_khz field to directly
store the *exact* pixelclock for a mode, so that drivers do not need to
resort to rounding tricks to try and guess the exact pixelclock;
2) The video-mode environment variable, as parsed by video_get_video_mode
also contains the vertical refresh rate, add a refresh field, so that
the refresh-rate can be matched when parsing the video-mode environment
variable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Fix:
videomodes.c: In function 'video_get_params':
videomodes.c:162:13: warning: variable 't' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Wolfgang Denk <wd@denx.de>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add function video_get_video_mode(), which parses the "video-mode" environment
variable and returns each of its components. The format matches the video=
command-line option used for Linux:
video-mode=<driver>:<xres>x<yres>-<depth>@<freq><,option=string>
<driver> The video driver, ignored by U-Boot
<xres> The X resolution (in pixels) to use.
<yres> The Y resolution (in pixels) to use.
<depth> The color depth (in bits) to use.
<freq> The frequency (in Hz) to use.
<options> A comma-separated list of device-specific options
Signed-off-by: Timur Tabi <timur@freescale.com>
