tegra: Add display driver and LCD support for Seaboard
Subsystems (4)
v3 cover tegra: Add display driver and LCD support for Seaboard
This series adds support for the Tegra2x's display peripheral. This supports the LCD display on Seaboard and we use this to enable console output in U-Boot on the LCD.
Configuration is via the device tree. Proposed bindings are included in this series, taken from pwm bindings that should be in linux-next, a Tegra video binding that might be accepted in devicetree-discuss and a proposed video mode binding posted to dri-devel.
While I agree EDID is convenient for machines I would prefer to provide a user-friendly way of selecting LCD settings as well, with EDID more as a fallback and auto-detection when available.
To improve performance two optimisations are offered:
1. The LCD frame buffer is cached, with the cache being flushed after each newline sent to putc(), and in a few other situations. This dramatically increases performance (around 10x). This requires a few additions to the ARM cache support.
2. The console supports scrolling in steps of more than 1 line. This speeds up scrolling output considerably, particularly commands like 'printenv' which display a lot of output, and particular when the dcache is off. This requires a new CONFIG and a change to the console_scrollup() function.
Changes in v2:
- Add new patch to use const in pinmux_config_pingroup/table()
- Add nvidia prefix to device tree properties
- Align tegra display using new CONFIG_LCD_ALIGNMENT feature
- Put the LCD cache flush logic into lcd_putc() instead of lcd_puts()
- Update LCD driver to deal with new fdt bindings
- Update seaboard LCD definitions for new fdt binding
- Use a more generic config CONFIG_LCD_ALIGNMENT for lcd alignment
- Use const where possible in funcmux
Changes in v3:
- Add new commit for pwm binding and node
- Add new panel binding to fit with tegra display controller binding
- Add probe function to read in fdt parameters in display driver
- Add separate call to pwm_init() in board_init()
- Adjust LCD driver to use new SOC display driver structures
- Bring in proposed tegra display controller binding
- Decode fdt node within the pwm driver
- Fix tiny bug in mult-line lcd scrolling
- Handle a cached frame buffer out of normal U-Boot memory
- Introduce concept of a pwm channel, rather than separate peripherals
- Move some fdt decode code from LCD driver to SOC display driver
- Put the LCD cache flush logic back into lcd_puts()
- Remove LPW1 pin which is not needed by display
- Remove spurious newline from fdtdec_get_addr() debug output
- Rename fdt config structures
- Rename pwfm driver to pwm
- Separate display driver and LCD driver more in fdt
- Tidy up fdtdec_decode_gpios() debug output
- Use displaymode binding for fdt
- Use new proposed upstream pwm binding
- Use new pwm binding from pre-linux-next
- Use new upstream proposed LCD definitions
Mayuresh Kulkarni (1):
tegra: Enable display/lcd support on Seaboard
Simon Glass (16):
fdt: Tidy debugging, add to fdtdec_get_int/addr()
fdt: Add header guard to fdtdec.h
tegra: Use const for pinmux_config_pingroup/table()
tegra: Add display support to funcmux
tegra: fdt: Add pwm binding and node
tegra: fdt: Add LCD definitions for Tegra
tegra: Add support for PWM
tegra: Add LCD driver
tegra: Add LCD support to Nvidia boards
arm: Add control over cachability of memory regions
lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
lcd: Add support for flushing LCD fb from dcache after update
tegra: Align LCD frame buffer to section boundary
tegra: Support control of cache settings for LCD
tegra: fdt: Add LCD definitions for Seaboard
lcd: Add CONSOLE_SCROLL_LINES option to speed console
Wei Ni (1):
tegra: Add SOC support for display/lcd
README | 16 + arch/arm/cpu/armv7/cache_v7.c | 11 + arch/arm/cpu/armv7/tegra2/Makefile | 1 + arch/arm/cpu/armv7/tegra2/display.c | 389 +++++++++++++++++ arch/arm/cpu/armv7/tegra2/funcmux.c | 38 ++ arch/arm/cpu/armv7/tegra2/pinmux.c | 4 +- arch/arm/cpu/armv7/tegra2/pwm.c | 99 +++++ arch/arm/dts/tegra20.dtsi | 96 +++++ arch/arm/include/asm/arch-tegra2/dc.h | 544 ++++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/display.h | 152 +++++++ arch/arm/include/asm/arch-tegra2/pinmux.h | 4 +- arch/arm/include/asm/arch-tegra2/pwm.h | 75 ++++ arch/arm/include/asm/system.h | 30 ++ arch/arm/lib/cache-cp15.c | 62 +++- board/nvidia/common/board.c | 24 +- board/nvidia/dts/tegra2-seaboard.dts | 32 ++ common/lcd.c | 86 +++- doc/device-tree-bindings/pwm/tegra20-pwm.txt | 18 + doc/device-tree-bindings/video/displaymode.txt | 42 ++ doc/device-tree-bindings/video/tegra20-dc.txt | 89 ++++ drivers/video/Makefile | 1 + drivers/video/tegra.c | 368 ++++++++++++++++ include/configs/seaboard.h | 11 +- include/configs/tegra2-common.h | 3 + include/fdtdec.h | 5 + include/lcd.h | 11 + lib/fdtdec.c | 29 +- 27 files changed, 2199 insertions(+), 41 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/display.c create mode 100644 arch/arm/cpu/armv7/tegra2/pwm.c create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h create mode 100644 arch/arm/include/asm/arch-tegra2/display.h create mode 100644 arch/arm/include/asm/arch-tegra2/pwm.h create mode 100644 doc/device-tree-bindings/pwm/tegra20-pwm.txt create mode 100644 doc/device-tree-bindings/video/displaymode.txt create mode 100644 doc/device-tree-bindings/video/tegra20-dc.txt create mode 100644 drivers/video/tegra.c
Signature · 1 line
1.7.7.3
A message that is not in the archive (sent off-list or not yet received): 1342106718-3058-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
PATCH v3 1/18 fdt: Tidy debugging, add to fdtdec_get_int/addr()
The new debugging shows the value of integers and addresses read from the device tree and tidy up GPIO output.
---
Changes in v3:
- Remove spurious newline from fdtdec_get_addr() debug output
- Tidy up fdtdec_decode_gpios() debug output
lib/fdtdec.c | 27 +++++++++++++++++++-------- 1 files changed, 19 insertions(+), 8 deletions(-)
lib/fdtdec.c +19 -8
@@ -80,11 +80,16 @@ fdt_addr_t fdtdec_get_addr(const void *blob, int node,const fdt_addr_t *cell;int len; -debug ("get_addr: %s\n" , prop_name); +debug ("%s: %s: " , __func__, prop_name); cell =fdt_getprop (blob, node, prop_name, &len);if (cell && (len ==sizeof (fdt_addr_t) || - len ==sizeof (fdt_addr_t) *2 )) -return fdt_addr_to_cpu (*cell); + len ==sizeof (fdt_addr_t) *2 )) { +fdt_addr_t addr =fdt_addr_to_cpu (*cell); + +debug ("%p\n" , (void *)addr); +return addr; + } +debug ("(not found)\n" );return FDT_ADDR_T_NONE ; }
@@ -94,10 +99,15 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,const s32 *cell;int len; -debug ("get_size: %s\n" , prop_name); +debug ("%s: %s: " , __func__, prop_name); cell =fdt_getprop (blob, node, prop_name, &len); -if (cell && len >=sizeof (s32)) -return fdt32_to_cpu (cell[0 ]); +if (cell && len >=sizeof (s32)) { +s32 val =fdt32_to_cpu (cell[0 ]); + +debug ("%#x (%d)\n" , val, val); +return val; + } +debug ("(not found)\n" );return default_val; }
@@ -329,6 +339,7 @@ int fdtdec_lookup_phandle(const void *blob, int node, const char *prop_name)const u32 *phandle;int lookup; +debug ("%s: %s\n" , __func__, prop_name); phandle =fdt_getprop (blob, node, prop_name,NULL );if (!phandle)return -FDT_ERR_NOTFOUND ;
@@ -428,7 +439,7 @@ static int fdtdec_decode_gpios(const void *blob, int node,assert (max_count >0 ); prop =fdt_get_property (blob, node, prop_name, &len);if (!prop) { -debug ("FDT: %s: property '%s' missing\n" , __func__, prop_name); +debug ("%s: property '%s' missing\n" , __func__, prop_name);return -FDT_ERR_NOTFOUND ; }
@@ -437,7 +448,7 @@ static int fdtdec_decode_gpios(const void *blob, int node, cell = (u32 *)prop->data; len /=sizeof (u32) *3 ;/* 3 cells per GPIO record */ if (len > max_count) { -debug ("FDT: %s: too many GPIOs / cells for " +debug (" %s: too many GPIOs / cells for " "property '%s'\n" , __func__, prop_name);return -FDT_ERR_BADLAYOUT ; }
Signature · 1 line
1.7.7.3
Anatolij Gustschin
AppliedPATCH v3 1/18 fdt: Tidy debugging, add to fdtdec_get_int/addr()
Quoted 11 lines · On Thu, 12 Jul 2012 08:25:01 -0700 Simon Glass <[email protected]> wrote:
The new debugging shows the value of integers and addresses read from the device tree and tidy up GPIO output.
Signed-off-by Simon Glass <[email protected]>---
Changes in v3:
- Remove spurious newline fromfdtdec_get_addr()debug output
- Tidy upfdtdec_decode_gpios()debug outputlib/fdtdec.c | 27 +++++++++++++++++++-------- 1 files changed, 19 insertions(+), 8 deletions(-)
Applied to staging/agust at denx.de.
Thanks,
Anatolij
PATCH v3 5/18 tegra: fdt: Add pwm binding and node
In reply to a message not in the archiveThis binding will apparently soon be in linux-next. Bring it in now since we need to do something, and may as well try to target what Linux will have.
---
Changes in v3:
- Add new commit for pwm binding and node
arch/arm/dts/tegra20.dtsi | 7 +++++++ doc/device-tree-bindings/pwm/tegra20-pwm.txt | 18 ++++++++++++++++++ 2 files changed, 25 insertions(+), 0 deletions(-) create mode 100644 doc/device-tree-bindings/pwm/tegra20-pwm.txt
arch/arm/dts/tegra20.dtsi +7 -0
@@ -204,4 +204,11 @@ compatible = "nvidia,tegra20-kbc"; reg = <0x7000e200 0x0078>; }; + + pwm: pwm@7000a000 { + compatible = "nvidia,tegra20-pwm"; + reg = <0x7000a000 0x100>; + #pwm-cells = <2>; + }; + };
doc/device-tree-bindings/pwm/tegra20-pwm.txt new file +18 -0
@@ -0,0 +1,18 @@ +Tegra SoC PWFM controller + +Required properties: +- compatible: should be one of: + - "nvidia,tegra20-pwm" + - "nvidia,tegra30-pwm" +- reg: physical base address and length of the controller's registers +- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The + first cell specifies the per-chip index of the PWM to use and the second + cell is the duty cycle in nanoseconds. + +Example: + + pwm: pwm@7000a000 { + compatible = "nvidia,tegra20-pwm"; + reg = <0x7000a000 0x100>; + #pwm-cells = <2>; + };
Signature · 1 line
1.7.7.3
PATCH v3 6/18 tegra: fdt: Add LCD definitions for Tegra
In reply to a message not in the archiveAdd LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
---
Changes in v2:
- Add nvidia prefix to device tree properties
Changes in v3:
- Add new panel binding to fit with tegra display controller binding
- Bring in proposed tegra display controller binding
- Use displaymode binding for fdt
arch/arm/dts/tegra20.dtsi | 89 ++++++++++++++++++++++++ doc/device-tree-bindings/video/displaymode.txt | 42 +++++++++++ doc/device-tree-bindings/video/tegra20-dc.txt | 89 ++++++++++++++++++++++++ 3 files changed, 220 insertions(+), 0 deletions(-) create mode 100644 doc/device-tree-bindings/video/displaymode.txt create mode 100644 doc/device-tree-bindings/video/tegra20-dc.txt
arch/arm/dts/tegra20.dtsi +89 -0
@@ -211,4 +211,93 @@ #pwm-cells = <2>; }; + host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + /* video-encoding/decoding */ + mpe { + reg = <0x54040000 0x00040000>; + interrupts = <0 68 0x04>; + }; + + /* video input */ + vi { + reg = <0x54080000 0x00040000>; + interrupts = <0 69 0x04>; + }; + + /* EPP */ + epp { + reg = <0x540c0000 0x00040000>; + interrupts = <0 70 0x04>; + }; + + /* ISP */ + isp { + reg = <0x54100000 0x00040000>; + interrupts = <0 71 0x04>; + }; + + /* 2D engine */ + gr2d { + reg = <0x54140000 0x00040000>; + interrupts = <0 72 0x04>; + }; + + /* 3D engine */ + gr3d { + reg = <0x54180000 0x00040000>; + }; + + /* display controllers */ + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + + rgb { + status = "disabled"; + }; + }; + + dc@54240000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54240000 0x00040000>; + interrupts = <0 74 0x04>; + + rgb { + status = "disabled"; + }; + }; + + /* outputs */ + hdmi { + compatible = "nvidia,tegra20-hdmi"; + reg = <0x54280000 0x00040000>; + interrupts = <0 75 0x04>; + status = "disabled"; + }; + + tvo { + compatible = "nvidia,tegra20-tvo"; + reg = <0x542c0000 0x00040000>; + interrupts = <0 76 0x04>; + status = "disabled"; + }; + + dsi { + compatible = "nvidia,tegra20-dsi"; + reg = <0x54300000 0x00040000>; + status = "disabled"; + }; + }; + };
doc/device-tree-bindings/video/displaymode.txt new file +42 -0
42 lines not on this page · raw message
doc/device-tree-bindings/video/tegra20-dc.txt new file +89 -0
89 lines not on this page · raw message
Signature · 1 line
1.7.7.3
A message that is not in the archive (sent off-list or not yet received): 1342106718-3058-7-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
+Thierry
Hi,
Quoted 4 lines · Simon Glass
Add LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
Quoted 9 lines
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
Any comments on this binding please? The main addition from Thierry's one posted on LMKL is the LCD resolution selection.
Regards,
Simon
Quoted 261 lines
Signed-off-by Simon Glass <[email protected]>---
Changes in v2:
- Add nvidia prefix to device tree propertiesChanges in v3:
- Add new panel binding to fit with tegra display controller binding
- Bring in proposed tegra display controller binding
- Use displaymode binding for fdtarch/arm/dts/tegra20.dtsi | 89 ++++++++++++++++++++++++ doc/device-tree-bindings/video/displaymode.txt | 42 +++++++++++ doc/device-tree-bindings/video/tegra20-dc.txt | 89 ++++++++++++++++++++++++ 3 files changed, 220 insertions(+), 0 deletions(-) create mode 100644 doc/device-tree-bindings/video/displaymode.txt create mode 100644 doc/device-tree-bindings/video/tegra20-dc.txtarch/arm/dts/tegra20.dtsi +89
-0@@ -211,4 +211,93 @@ #pwm-cells = <2>; }; + host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + /* video-encoding/decoding */ + mpe { + reg = <0x54040000 0x00040000>; + interrupts = <0 68 0x04>; + }; + + /* video input */ + vi { + reg = <0x54080000 0x00040000>; + interrupts = <0 69 0x04>; + }; + + /* EPP */ + epp { + reg = <0x540c0000 0x00040000>; + interrupts = <0 70 0x04>; + }; + + /* ISP */ + isp { + reg = <0x54100000 0x00040000>; + interrupts = <0 71 0x04>; + }; + + /* 2D engine */ + gr2d { + reg = <0x54140000 0x00040000>; + interrupts = <0 72 0x04>; + }; + + /* 3D engine */ + gr3d { + reg = <0x54180000 0x00040000>; + }; + + /* display controllers */ + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + + rgb { + status = "disabled"; + }; + }; + + dc@54240000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54240000 0x00040000>; + interrupts = <0 74 0x04>; + + rgb { + status = "disabled"; + }; + }; + + /* outputs */ + hdmi { + compatible = "nvidia,tegra20-hdmi"; + reg = <0x54280000 0x00040000>; + interrupts = <0 75 0x04>; + status = "disabled"; + }; + + tvo { + compatible = "nvidia,tegra20-tvo"; + reg = <0x542c0000 0x00040000>; + interrupts = <0 76 0x04>; + status = "disabled"; + }; + + dsi { + compatible = "nvidia,tegra20-dsi"; + reg = <0x54300000 0x00040000>; + status = "disabled"; + }; + }; + };doc/device-tree-bindings/video/displaymode.txt new file +42
-0@@ -0,0 +1,42 @@ +videomode bindings +================== + +(from http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html) + +Required properties: + - xres, yres: Display resolution + - left-margin, right-margin, hsync-len: Horizontal Display timing + parameters in pixels + - upper-margin, lower-margin, vsync-len: Vertical display timing + parameters in lines + - clock: display clock in Hz + +Optional properties: + - width-mm, height-mm: Display dimensions in mm + - hsync-active-high (bool): Hsync pulse is active high + - vsync-active-high (bool): Vsync pulse is active high + - interlaced (bool): This is an interlaced mode + - doublescan (bool): This is a doublescan mode + +There are different ways of describing a display mode. The devicetree +representation corresponds to the one used by the Linux Framebuffer +framework described here in Documentation/fb/framebuffer.txt. This +representation has been chosen because it's the only format which does +not allow for inconsistent parameters. Unlike the Framebuffer framework +the devicetree has the clock in Hz instead of ps. + +Example: + + display@0 { + /* 1920x1080p24 */ + clock = <52000000>; + xres = <1920>; + yres = <1080>; + left-margin = <25>; + right-margin = <25>; + hsync-len = <25>; + lower-margin = <2>; + upper-margin = <2>; + vsync-len = <2>; + hsync-active-high; + };doc/device-tree-bindings/video/tegra20-dc.txt new file +89
-1@@ -0,0 +1,89 @@ +Display Controller +------------------ + +(there isn't yet a generic binding in Linux, so this describes what is in +U-Boot, and may change based on Linux activity) + +The device node for a display device is as described in the document +"Open Firmware Recommended Practice : Universal Serial Bus" with the +following modifications and additions : + +Required properties : + - compatible : Should be "nvidia,tegra20-dc" + +Required subnode 'rgb'. This has the properties listed in displaymode.txt +as well as: + +Required properties (rgb) : + - nvidia,panel : phandle of LCD panel information + - nvidia,bits-per-pixel: number of bits per pixel (depth) + +Optional properties (rgb): + - nvidia,frame-buffer: address of frame buffer (if omitted it will be + calculated) + - This may be useful to share an address between U-Boot and Linux and + avoid boot-time corruption / flicker + + +The panel node describes the panel itself. + +Required properties (panel) : + - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt) + - nvidia,panel-timings: 4 cells containing required timings in ms: + * delay between panel_vdd-rise and data-rise + * delay between data-rise and backlight_vdd-rise + * delay between backlight_vdd and pwm-rise + * delay between pwm-rise and backlight_en-rise + +Optional GPIO properies all have (phandle, GPIO number, flags): + - nvidia,backlight-enable-gpios: backlight enable GPIO + - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO + - nvidia,backlight-vdd-gpios: backlight power GPIO + - nvidia,panel-vdd-gpios: panel power GPIO + +Example: + +host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + + rgb { + status = "okay"; + /* Seaboard has 1366x768 */ + clock = <70600000>; + xres = <1366>; + yres = <768>; + left-margin = <58>; + right-margin = <58>; + hsync-len = <58>; + lower-margin = <4>; + upper-margin = <4>; + vsync-len = <4>; + hsync-active-high; + nvidia,frame-buffer = <0x2f680000>; + nvidia,bits-per-pixel = <16>; + nvidia,panel = <&lcd_panel>; + }; + }; +}; + +lcd_panel: panel { + nvidia,pwm = <&pwm 2 0>; + nvidia,backlight-enable-gpios = <&gpio 28 0>; /* PD4 */ + nvidia,lvds-shutdown-gpios = <&gpio 10 0>; /* PB2 */ + nvidia,backlight-vdd-gpios = <&gpio 176 0>; /* PW0 */ + nvidia,panel-vdd-gpios = <&gpio 22 0>; /* PC6 */ + nvidia,panel-timings = <4 203 17 15>; +}; --1.7.7.3
A message that is not in the archive (sent off-list or not yet received): CAPnjgZ2SbVVKxUdW1cvLf_9rAWLWeiVr-y6S_sz-Uw5_O_AyQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Quoted 13 lines · Simon Glass
+Thierry
Hi,
Quoted 8 lines · Simon Glass
Add LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
Quoted 8 lines
Quoted 5 lines
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
Any comments on this binding please? The main addition from Thierry's one posted on LMKL is the LCD resolution selection.
There's no such thing as the panel bindings on Linux. I think nobody's done that before, there's also no suitable software abstraction, but I suppose that should be irrelevant for this discussion.
Quoted 50 lines
Quoted 50 lines
doc/device-tree-bindings/video/tegra20-dc.txt new file +50
-0+Optional properties (rgb): + - nvidia,frame-buffer: address of frame buffer (if omitted it will be + calculated) + - This may be useful to share an address between U-Boot and Linux and + avoid boot-time corruption / flicker + + +The panel node describes the panel itself. + +Required properties (panel) : + - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt) + - nvidia,panel-timings: 4 cells containing required timings in ms: + * delay between panel_vdd-rise and data-rise + * delay between data-rise and backlight_vdd-rise + * delay between backlight_vdd and pwm-rise + * delay between pwm-rise and backlight_en-rise + +Optional GPIO properies all have (phandle, GPIO number, flags): + - nvidia,backlight-enable-gpios: backlight enable GPIO + - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO + - nvidia,backlight-vdd-gpios: backlight power GPIO + - nvidia,panel-vdd-gpios: panel power GPIO + +Example: + +host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + + rgb { + status = "okay"; + /* Seaboard has 1366x768 */ + clock = <70600000>; + xres = <1366>; + yres = <768>; + left-margin = <58>; + right-margin = <58>; + hsync-len = <58>;
Quoted 8 lines
doc/device-tree-bindings/video/tegra20-dc.txt line 78
Quoted 8 lines
doc/device-tree-bindings/video/tegra20-dc.txt new file +8
-0+ lower-margin = <4>; + upper-margin = <4>; + vsync-len = <4>; + hsync-active-high; + nvidia,frame-buffer = <0x2f680000>; + nvidia,bits-per-pixel = <16>; + nvidia,panel = <&lcd_panel>; + };
Perhaps it would be useful to add an extra node for the mode definition, if only to keep the data separate from that of the rgb node. I know that there currently are no other properties, but the rgb node was supposed to define the output or connector. If ever the same needs to be done for any of the TVO or DSI outputs, more properties may be needed.
Furthermore the code to parse this would be more generic because you could pass it any DT node. Of course the nvidia,-prefixed properties wouldn't be part of that subnode because they don't define the mode as such.
Thinking about it some more, maybe the mode information should really be part of the panel description below.
Quoted 11 lines
doc/device-tree-bindings/video/tegra20-dc.txt line 89
Quoted 11 lines
doc/device-tree-bindings/video/tegra20-dc.txt new file +11
-0+ }; +}; + +lcd_panel: panel { + nvidia,pwm = <&pwm 2 0>; + nvidia,backlight-enable-gpios = <&gpio 28 0>; /* PD4 */ + nvidia,lvds-shutdown-gpios = <&gpio 10 0>; /* PB2 */ + nvidia,backlight-vdd-gpios = <&gpio 176 0>; /* PW0 */ + nvidia,panel-vdd-gpios = <&gpio 22 0>; /* PC6 */ + nvidia,panel-timings = <4 203 17 15>; +};
If we can reach some kind of agreement on the power-sequencing code that Alexandre (Cc'ed) is working on, then this can be replaced with a more generic description. This also has the usual problem of being a non- addressable top-level node...
Thierry
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
A message that is not in the archive (sent off-list or not yet received): 20120731095116.GA16155-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Thierry,
Quoted 92 lines · Thierry Reding
Quoted 13 lines · Simon Glass
+Thierry
Hi,
Quoted 8 lines · Simon Glass
Add LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
Quoted 8 lines
Quoted 5 lines
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
Any comments on this binding please? The main addition from Thierry's one posted on LMKL is the LCD resolution selection.
There's no such thing as the panel bindings on Linux. I think nobody's done that before, there's also no suitable software abstraction, but I suppose that should be irrelevant for this discussion.
Quoted 50 lines
Quoted 50 lines
doc/device-tree-bindings/video/tegra20-dc.txt new file +50
-0+Optional properties (rgb): + - nvidia,frame-buffer: address of frame buffer (if omitted it will be + calculated) + - This may be useful to share an address between U-Boot and Linux and + avoid boot-time corruption / flicker + + +The panel node describes the panel itself. + +Required properties (panel) : + - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt) + - nvidia,panel-timings: 4 cells containing required timings in ms: + * delay between panel_vdd-rise and data-rise + * delay between data-rise and backlight_vdd-rise + * delay between backlight_vdd and pwm-rise + * delay between pwm-rise and backlight_en-rise + +Optional GPIO properies all have (phandle, GPIO number, flags): + - nvidia,backlight-enable-gpios: backlight enable GPIO + - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO + - nvidia,backlight-vdd-gpios: backlight power GPIO + - nvidia,panel-vdd-gpios: panel power GPIO + +Example: + +host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + + rgb { + status = "okay"; + /* Seaboard has 1366x768 */ + clock = <70600000>; + xres = <1366>; + yres = <768>; + left-margin = <58>; + right-margin = <58>; + hsync-len = <58>;Quoted 8 lines
doc/device-tree-bindings/video/tegra20-dc.txt line 78
Quoted 8 lines
doc/device-tree-bindings/video/tegra20-dc.txt new file +8
-0+ lower-margin = <4>; + upper-margin = <4>; + vsync-len = <4>; + hsync-active-high; + nvidia,frame-buffer = <0x2f680000>; + nvidia,bits-per-pixel = <16>; + nvidia,panel = <&lcd_panel>; + };Perhaps it would be useful to add an extra node for the mode definition, if only to keep the data separate from that of the rgb node. I know that there currently are no other properties, but the rgb node was supposed to define the output or connector. If ever the same needs to be done for any of the TVO or DSI outputs, more properties may be needed.
Quoted 7 lines
Furthermore the code to parse this would be more generic because you could pass it any DT node. Of course the nvidia,-prefixed properties wouldn't be part of that subnode because they don't define the mode as such.
Thinking about it some more, maybe the mode information should really be part of the panel description below.
OK I will move it there, thanks.
Quoted 17 lines
Quoted 12 lines
doc/device-tree-bindings/video/tegra20-dc.txt line 89
Quoted 12 lines
doc/device-tree-bindings/video/tegra20-dc.txt new file +11
-0+ }; +}; + +lcd_panel: panel { + nvidia,pwm = <&pwm 2 0>; + nvidia,backlight-enable-gpios = <&gpio 28 0>; /* PD4 */ + nvidia,lvds-shutdown-gpios = <&gpio 10 0>; /* PB2 */ + nvidia,backlight-vdd-gpios = <&gpio 176 0>; /* PW0 */ + nvidia,panel-vdd-gpios = <&gpio 22 0>; /* PC6 */ + nvidia,panel-timings = <4 203 17 15>; +};If we can reach some kind of agreement on the power-sequencing code that Alexandre (Cc'ed) is working on, then this can be replaced with a more generic description. This also has the usual problem of being a non- addressable top-level node...
Yes, I have been following that. However, it would need quite a bit of code to be written. I would like to leave this for a future owner if possible.
Regards,
Simon
Quoted 2 lines
Thierry
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
In reply to a message not in the archiveQuoted 9 lines · Simon Glass
Quoted 8 lines · Simon Glass
Add LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
Quoted 7 lines
Quoted 4 lines
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
Any comments on this binding please? The main addition from Thierry's one posted on LMKL is the LCD resolution selection.
I have some concerns about the way the mode is represented in the binding; the timing parameters are quite different to how e.g. an EDID DTD would represent them, which I think will lead to conversion mistakes when writing the DT.
I'm trying to get along of Sascha's original email so I can join in on that discussion.
Quoted 7 lines
doc/device-tree-bindings/video/tegra20-dc.txt line 25
Quoted 7 lines
doc/device-tree-bindings/video/tegra20-dc.txt +5
-0+Optional properties (rgb): + - nvidia,frame-buffer: address of frame buffer (if omitted it will be + calculated) + - This may be useful to share an address between U-Boot and Linux and + avoid boot-time corruption / flicker
Why can't the display driver read this out of the display registers, instead of requiring the same information to be passed using DT too?
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Stephen,
Quoted 18 lines · Stephen Warren
Quoted 9 lines · Simon Glass
Quoted 8 lines · Simon Glass
Add LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
Quoted 7 lines
Quoted 4 lines
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
Any comments on this binding please? The main addition from Thierry's one posted on LMKL is the LCD resolution selection.
Quoted 7 lines
I have some concerns about the way the mode is represented in the binding; the timing parameters are quite different to how e.g. an EDID DTD would represent them, which I think will lead to conversion mistakes when writing the DT.
I'm trying to get along of Sascha's original email so I can join in on that discussion.
Did you get any resolution here?
Quoted 11 lines
Quoted 8 lines
doc/device-tree-bindings/video/tegra20-dc.txt line 25
Quoted 8 lines
doc/device-tree-bindings/video/tegra20-dc.txt +5
-0+Optional properties (rgb): + - nvidia,frame-buffer: address of frame buffer (if omitted it will be + calculated) + - This may be useful to share an address between U-Boot and Linux and + avoid boot-time corruption / flickerWhy can't the display driver read this out of the display registers, instead of requiring the same information to be passed using DT too?
The U-Boot display driver needs to set this value in the display registers - at reset I don't think we can rely on any particular value.
Do you mean the kernel display driver? Well it could, but it doesn't. Really this is just a way of getting U-Boot and Linux to agree on the address, by having U-Boot know the address that the kernel will happen to use. It isn't very robust, but we have found it useful as a means of avoiding problems in this area.
Regards,
Simon
A message that is not in the archive (sent off-list or not yet received): CAPnjgZ2NAf4PF0_U9hQeJzpdL87ZNq+WpxsbFJQHbh4rY2MoEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Quoted 26 lines · Simon Glass
Hi Stephen,
Quoted 23 lines · Stephen Warren
Quoted 9 lines · Simon Glass
Quoted 8 lines · Simon Glass
Add LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
Quoted 7 lines
Quoted 4 lines
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
Any comments on this binding please? The main addition from Thierry's one posted on LMKL is the LCD resolution selection.
I have some concerns about the way the mode is represented in the binding; the timing parameters are quite different to how e.g. an EDID DTD would represent them, which I think will lead to conversion mistakes when writing the DT.
Quoted 4 lines
Quoted 2 lines
I'm trying to get along of Sascha's original email so I can join in on that discussion.
Did you get any resolution here?
I think an updated version of those patches was published.
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
doc/device-tree-bindings/video/tegra20-dc.txt +5
-0+Optional properties (rgb): + - nvidia,frame-buffer: address of frame buffer (if omitted it will be + calculated) + - This may be useful to share an address between U-Boot and Linux and + avoid boot-time corruption / flicker
Quoted 8 lines
Quoted 2 lines
Why can't the display driver read this out of the display registers, instead of requiring the same information to be passed using DT too?
The U-Boot display driver needs to set this value in the display registers - at reset I don't think we can rely on any particular value.
Do you mean the kernel display driver?
Yes.
Quoted 1 line
Well it could, but it doesn't.
Well, there is no display driver in the upstream kernel at the moment, so it's not possible to make assertions about what it does or not.
Any downstream kernels aren't relevant, since their DT bindings and/or behaviour have not been through public review.
Quoted 4 lines
Really this is just a way of getting U-Boot and Linux to agree on the address, by having U-Boot know the address that the kernel will happen to use. It isn't very robust, but we have found it useful as a means of avoiding problems in this area.
Right, but again, why can't the display driver simply read the address out of the register; why is there a need to duplicate the data?
I guess one possibility is that the register only gives the base address and not the size/mode of the allocated surface, but I don't recall if this proposed binding did that either?
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Stephen,
Quoted 53 lines · Stephen Warren
Quoted 26 lines · Simon Glass
Hi Stephen,
Quoted 23 lines · Stephen Warren
Quoted 9 lines · Simon Glass
Quoted 8 lines · Simon Glass
Add LCD definitions and also a proposed binding for LCD displays.
The PWM is as per what will likely be committed to linux-next soon.
The displaymode binding comes from a proposal here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
Quoted 7 lines
Quoted 4 lines
The panel binding is new, and fills a need to specify the panel timings and other tegra-specific information. Should a binding appear that allows the pwm to handle this automatically, we can revisit this.
Any comments on this binding please? The main addition from Thierry's one posted on LMKL is the LCD resolution selection.
I have some concerns about the way the mode is represented in the binding; the timing parameters are quite different to how e.g. an EDID DTD would represent them, which I think will lead to conversion mistakes when writing the DT.
Quoted 4 lines
Quoted 2 lines
I'm trying to get along of Sascha's original email so I can join in on that discussion.
Did you get any resolution here?
I think an updated version of those patches was published.
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
doc/device-tree-bindings/video/tegra20-dc.txt +5
-0+Optional properties (rgb): + - nvidia,frame-buffer: address of frame buffer (if omitted it will be + calculated) + - This may be useful to share an address between U-Boot and Linux and + avoid boot-time corruption / flickerQuoted 8 lines
Quoted 2 lines
Why can't the display driver read this out of the display registers, instead of requiring the same information to be passed using DT too?
The U-Boot display driver needs to set this value in the display registers - at reset I don't think we can rely on any particular value.
Do you mean the kernel display driver?
Yes.
Quoted 7 lines
Quoted 1 line
Well it could, but it doesn't.
Well, there is no display driver in the upstream kernel at the moment, so it's not possible to make assertions about what it does or not.
Any downstream kernels aren't relevant, since their DT bindings and/or behaviour have not been through public review.
OK, but typically the kernel selects its own address for the display. It might be quite hard for the kernel to use the one defined by U-Boot.
Quoted 6 lines
Quoted 5 lines
Really this is just a way of getting U-Boot and Linux to agree on the address, by having U-Boot know the address that the kernel will happen to use. It isn't very robust, but we have found it useful as a means of avoiding problems in this area.
Quoted 6 lines
Right, but again, why can't the display driver simply read the address out of the register; why is there a need to duplicate the data?
I guess one possibility is that the register only gives the base address and not the size/mode of the allocated surface, but I don't recall if this proposed binding did that either?
So here is my explanation:
1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address.
2. That means that U-Boot will now have the display exactly where the kernel wants it.
3. When U-Boot boots the kernel, it leaves the display running, knowing that the kernel will not overwrite the frame buffer with its own code / data.
4. The effect is that there is a seamless display transition from U-Boot to the kernel.
Note this is only a hint - it can be omitted i.w.c. it isn't used.
So what do you think? Should we remove this entirely, or is it a useful hack?
Regards,
Simon
A message that is not in the archive (sent off-list or not yet received): CAPnjgZ2R=G=xmjdoP74JeAknwH9QGx8+mED7TQ8Kd_zEmcVwtQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Quoted 2 lines · Simon Glass
Quoted 1 line · Stephen Warren
On 09/27/2012 07:58 AM, Simon Glass wrote:
...
Quoted 12 lines
Quoted 11 lines
Quoted 4 lines
Really this is just a way of getting U-Boot and Linux to agree on the address, by having U-Boot know the address that the kernel will happen to use. It isn't very robust, but we have found it useful as a means of avoiding problems in this area.
Right, but again, why can't the display driver simply read the address out of the register; why is there a need to duplicate the data?
I guess one possibility is that the register only gives the base address and not the size/mode of the allocated surface, but I don't recall if this proposed binding did that either?
Quoted 8 lines
So here is my explanation:
1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address.
2. That means that U-Boot will now have the display exactly where the kernel wants it.
Oh, the DT property is telling U-Boot where to put the surface so that when the kernel determines where to put it, it'll already be there?
That seems completely backwards. It's also extremely fragile; what if the kernel suddenly starts allocating at some other random address, which stops matching what U-Boot expects?
Far better would be for U-Boot to put the surface wherever it wants, then manipulate the DT that's passed to the kernel to:
a) Add a /memreserve/ so that memory doesn't get re-used for anything else during boot.
b) Add a property to the display node indicating which memreserve represents the frame-buffer location.
When the kernel boots, it can:
* Copy the content from the U-Boot-allocated buffer to whatever display buffer the kernel allocated before writing the new address to the HW.
* Undo the memory reservation triggered by the /memreserve/ to allow the memory to be re-used.
Quoted 1 line
So what do you think? Should we remove this entirely, or is it a useful hack?
Yes, I think in its current form, it isn't useful.
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Stephen,
Quoted 25 lines · Stephen Warren
Quoted 2 lines · Simon Glass
Quoted 1 line · Stephen Warren
On 09/27/2012 07:58 AM, Simon Glass wrote:
...
Quoted 12 lines
Quoted 11 lines
Quoted 4 lines
Really this is just a way of getting U-Boot and Linux to agree on the address, by having U-Boot know the address that the kernel will happen to use. It isn't very robust, but we have found it useful as a means of avoiding problems in this area.
Right, but again, why can't the display driver simply read the address out of the register; why is there a need to duplicate the data?
I guess one possibility is that the register only gives the base address and not the size/mode of the allocated surface, but I don't recall if this proposed binding did that either?
Quoted 8 lines
So here is my explanation:
1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address.
2. That means that U-Boot will now have the display exactly where the kernel wants it.
Quoted 6 lines
Oh, the DT property is telling U-Boot where to put the surface so that when the kernel determines where to put it, it'll already be there?
That seems completely backwards. It's also extremely fragile; what if the kernel suddenly starts allocating at some other random address, which stops matching what U-Boot expects?
The screen will flicker, or may fill up with junk as the kernel boots. We did have that happen once when the driver changed.
Quoted 9 lines
Far better would be for U-Boot to put the surface wherever it wants, then manipulate the DT that's passed to the kernel to:
a) Add a /memreserve/ so that memory doesn't get re-used for anything else during boot.
b) Add a property to the display node indicating which memreserve represents the frame-buffer location.
Yes, I believe the Tegra video driver we used (and I take your point that it doesn't exist upstream so there is no point in discussing it :-) always had to use the same frame buffer address. The memory was statically allocated. Certainly this could be encoded in the fdt.
Quoted 6 lines
When the kernel boots, it can:
* Copy the content from the U-Boot-allocated buffer to whatever display buffer the kernel allocated before writing the new address to the HW.
Quoted 6 lines
* Undo the memory reservation triggered by the /memreserve/ to allow the memory to be re-used.
Quoted 1 line
So what do you think? Should we remove this entirely, or is it a useful hack?
Yes, I think in its current form, it isn't useful.
Thanks for the thorough response. Let's remove it, particularly as there isn't even a kernel driver upstream yet.
I will do that before sending out the LCD v4 series. Thanks for your timely comments.
Regards,
Simon
A message that is not in the archive (sent off-list or not yet received): CAPnjgZ3JuE_jiSRGW6o3eCbp4cLCf1uenKz4kPCpfqLJ3Mdmjw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Quoted 62 lines · Simon Glass
Hi Stephen,
Quoted 25 lines · Stephen Warren
Quoted 2 lines · Simon Glass
Quoted 1 line · Stephen Warren
On 09/27/2012 07:58 AM, Simon Glass wrote:
...
Quoted 12 lines
Quoted 11 lines
Quoted 4 lines
Really this is just a way of getting U-Boot and Linux to agree on the address, by having U-Boot know the address that the kernel will happen to use. It isn't very robust, but we have found it useful as a means of avoiding problems in this area.
Right, but again, why can't the display driver simply read the address out of the register; why is there a need to duplicate the data?
I guess one possibility is that the register only gives the base address and not the size/mode of the allocated surface, but I don't recall if this proposed binding did that either?
Quoted 8 lines
So here is my explanation:
1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address.
2. That means that U-Boot will now have the display exactly where the kernel wants it.
Quoted 6 lines
Oh, the DT property is telling U-Boot where to put the surface so that when the kernel determines where to put it, it'll already be there?
That seems completely backwards. It's also extremely fragile; what if the kernel suddenly starts allocating at some other random address, which stops matching what U-Boot expects?
The screen will flicker, or may fill up with junk as the kernel boots. We did have that happen once when the driver changed.
Quoted 9 lines
Far better would be for U-Boot to put the surface wherever it wants, then manipulate the DT that's passed to the kernel to:
a) Add a /memreserve/ so that memory doesn't get re-used for anything else during boot.
b) Add a property to the display node indicating which memreserve represents the frame-buffer location.
Yes, I believe the Tegra video driver we used (and I take your point that it doesn't exist upstream so there is no point in discussing it :-) always had to use the same frame buffer address. The memory was statically allocated. Certainly this could be encoded in the fdt.
Quoted 9 lines
When the kernel boots, it can:
* Copy the content from the U-Boot-allocated buffer to whatever display buffer the kernel allocated before writing the new address to the HW.
* Undo the memory reservation triggered by the /memreserve/ to allow the memory to be re-used.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
So what do you think? Should we remove this entirely, or is it a useful hack?
Yes, I think in its current form, it isn't useful.
Thanks for the thorough response. Let's remove it, particularly as there isn't even a kernel driver upstream yet.
We've been discussing some of these issues for quite some time and came to the conclusion that the Tegra DRM driver should not be using static allocations like the previous drivers did. One of the reasons is that the amount of carveout memory needs to be fixed at boot time, which isn't going to suit a wide range of devices well. Another, perhaps more important reason is that starting with Tegra30 that's no longer necessary because of the SMMU.
So in the end it wouldn't be possible to reliably determine the memory area where the kernel will put the framebuffer. If we want a flicker- free boot then we need to go with something more elaborate like what Stephen suggested.
Thierry
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
PATCH v3 16/18 tegra: fdt: Add LCD definitions for Seaboard
In reply to a message not in the archiveThe Seaboard has a 1366x768 16bpp LCD. The backlight is controlled by one of the PWMs.
---
Changes in v2:
- Update seaboard LCD definitions for new fdt binding
Changes in v3:
- Use new upstream proposed LCD definitions
board/nvidia/dts/tegra2-seaboard.dts | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-)
board/nvidia/dts/tegra2-seaboard.dts +32 -0
@@ -153,4 +153,36 @@ 0x1f04008a>; linux,fn-keymap = <0x05040002>; }; + + host1x { + dc@54200000 { + rgb { + status = "okay"; + /* Seaboard has 1366x768 */ + clock = <70600000>; + xres = <1366>; + yres = <768>; + left-margin = <58>; + right-margin = <58>; + hsync-len = <58>; + lower-margin = <4>; + upper-margin = <4>; + vsync-len = <4>; + hsync-active-high; + nvidia,frame-buffer = <0x2f680000>; + nvidia,bits-per-pixel = <16>; + nvidia,panel = <&lcd_panel>; + }; + }; + }; + + lcd_panel: panel { + nvidia,pwm = <&pwm 2 0>; + nvidia,backlight-enable-gpios = <&gpio 28 0>; /* PD4 */ + nvidia,lvds-shutdown-gpios = <&gpio 10 0>; /* PB2 */ + nvidia,backlight-vdd-gpios = <&gpio 176 0>; /* PW0 */ + nvidia,panel-vdd-gpios = <&gpio 22 0>; /* PC6 */ + nvidia,panel-timings = <4 203 17 15>; + }; + };
Signature · 1 line
1.7.7.3
PATCH v3 2/18 fdt: Add header guard to fdtdec.h
In reply to Simon GlassThis makes it easier to include this header from other headers.
---
include/fdtdec.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
include/fdtdec.h +3 -0
@@ -19,6 +19,8 @@* MA 02111-1307 USA */ +#ifndef __fdtdec_h +#define __fdtdec_h/* * This file contains convenience functions for decoding useful and
@@ -382,3 +384,4 @@ int fdtdec_get_byte_array(const void *blob, int node, const char *prop_name,*/ const u8 *fdtdec_locate_byte_array (const void *blob,int node,const char *prop_name,int count); +#endif
Signature · 1 line
1.7.7.3
Re: [PATCH v3 02/18] fdt: Add header guard to fdtdec.h
Quoted 1 line · On Thursday 12 July 2012 11:25:02 Simon Glass wrote:
This makes it easier to include this header from other headers.
include/fdtdec.h int fdtdec_get_byte_array(const void *blob, int node, const char *prop_name, · line 387
Quoted 6 lines
include/fdtdec.h +1
-0const u8 *fdtdec_locate_byte_array (const void *blob,int node,const char *prop_name,int count); +#endif
personally, i like seeing a blank line before the final #endif -mike
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
Anatolij Gustschin
AppliedPATCH v3 2/18 fdt: Add header guard to fdtdec.h
In reply to Simon GlassQuoted 7 lines · On Thu, 12 Jul 2012 08:25:02 -0700 Simon Glass <[email protected]> wrote:
This makes it easier to include this header from other headers.
Signed-off-by Simon Glass <[email protected]>---
include/fdtdec.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
Applied to staging/agust at denx.de.
Thanks,
Anatolij
PATCH v3 3/18 tegra: Use const for pinmux_config_pingroup/table()
In reply to Simon GlassThese two functions don't actually modify their arguments so add a const keyword.
---
Changes in v2:
- Add new patch to use const in pinmux_config_pingroup/table()
arch/arm/cpu/armv7/tegra2/pinmux.c | 4 ++-- arch/arm/include/asm/arch-tegra2/pinmux.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
arch/arm/cpu/armv7/tegra2/pinmux.c +2 -2
@@ -554,7 +554,7 @@ void pinmux_set_func(enum pmux_pingrp pin, enum pmux_func func)writel (reg, muxctl); } -void pinmux_config_pingroup (struct pingroup_config *config) +void pinmux_config_pingroup (const struct pingroup_config *config) {enum pmux_pingrp pin = config->pingroup;
@@ -563,7 +563,7 @@ void pinmux_config_pingroup(struct pingroup_config *config)pinmux_set_tristate (pin, config->tristate); } -void pinmux_config_table (struct pingroup_config *config,int len) +void pinmux_config_table (const struct pingroup_config *config,int len) {int i;
arch/arm/include/asm/arch-tegra2/pinmux.h +2 -2
@@ -339,7 +339,7 @@ void pinmux_set_pullupdown(enum pmux_pingrp pin, enum pmux_pull pupd);void pinmux_set_func (enum pmux_pingrp pin,enum pmux_func func);/* Set the complete configuration for a pin group */ -void pinmux_config_pingroup (struct pingroup_config *config); +void pinmux_config_pingroup (const struct pingroup_config *config);void pinmux_set_tristate (enum pmux_pingrp pin,int enable);
@@ -349,6 +349,6 @@ void pinmux_set_tristate(enum pmux_pingrp pin, int enable);* @param config List of config items * @param len Number of config items in list */ -void pinmux_config_table (struct pingroup_config *config,int len); +void pinmux_config_table (const struct pingroup_config *config,int len);#endif /* PINMUX_H */
Signature · 1 line
1.7.7.3
PATCH v3 3/18 tegra: Use const for pinmux_config_pingroup/table()
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/3cbce2c6/attachment.pgp>
PATCH v3 4/18 tegra: Add display support to funcmux
In reply to Simon GlassAdd support for a default pin mapping for display1.
---
Changes in v2:
- Use const where possible in funcmux
Changes in v3:
- Remove LPW1 pin which is not needed by display
arch/arm/cpu/armv7/tegra2/funcmux.c | 38 +++++++++++++++++++++++++++++++++++ 1 files changed, 38 insertions(+), 0 deletions(-)
arch/arm/cpu/armv7/tegra2/funcmux.c +38 -0
@@ -25,6 +25,30 @@#include <asm/arch/funcmux.h> #include <asm/arch/pinmux.h> +/* +* The PINMUX macro is used to set up pinmux tables. +*/ +#define PINMUX (grp, mux, pupd, tri) \ + {PINGRP_##grp, PMUX_FUNC_##mux, PMUX_PULL_##pupd, PMUX_TRI_##tri} + +static const struct pingroup_config disp1_default[] = { +PINMUX (LDI ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LHP0 ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LHP1 ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LHP2 ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LHS ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LM0 ,RSVD4 ,NORMAL ,NORMAL ), +PINMUX (LPP ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LPW0 ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LPW2 ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LSC0 ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LSPI ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LVP1 ,DISPA ,NORMAL ,NORMAL ), +PINMUX (LVS ,DISPA ,NORMAL ,NORMAL ), +PINMUX (SLXD ,SPDIF ,NORMAL ,NORMAL ), +}; + +int funcmux_select (enum periph_id id,int config) {int bad_config = config !=FUNCMUX_DEFAULT ;
@@ -234,6 +258,20 @@ int funcmux_select(enum periph_id id, int config) }break ; +case PERIPH_ID_DISP1 : +if (config ==FUNCMUX_DEFAULT ) { +int i; + +for (i =PINGRP_LD0 ; i <=PINGRP_LD17 ; i++) { +pinmux_set_func (i,PMUX_FUNC_DISPA ); +pinmux_tristate_disable (i); +pinmux_set_pullupdown (i,PMUX_PULL_NORMAL ); + } +pinmux_config_table (disp1_default, +ARRAY_SIZE (disp1_default)); + } +break ; +default :debug ("%s: invalid periph_id %d" , __func__, id);return -1 ;
Signature · 1 line
1.7.7.3
PATCH v3 4/18 tegra: Add display support to funcmux
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/6112a6c2/attachment.pgp>
PATCH v3 7/18 tegra: Add support for PWM
In reply to Simon GlassThe pulse width/frequency modulation peripheral supports generating a repeating pulse. It is useful for controlling LCD brightness.
---
Changes in v3:
- Decode fdt node within the pwm driver
- Introduce concept of a pwm channel, rather than separate peripherals
- Rename pwfm driver to pwm
- Use new proposed upstream pwm binding
arch/arm/cpu/armv7/tegra2/Makefile | 1 + arch/arm/cpu/armv7/tegra2/pwm.c | 99 ++++++++++++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/pwm.h | 75 ++++++++++++++++++++++++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + 5 files changed, 177 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/pwm.c create mode 100644 arch/arm/include/asm/arch-tegra2/pwm.h
arch/arm/cpu/armv7/tegra2/Makefile +1 -0
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_TEGRA_PMU) += pmu.o COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o COBJS-$(CONFIG_TEGRA2_LP0) += crypto.o warmboot.o warmboot_avp.o COBJS-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o +COBJS-$(CONFIG_VIDEO_TEGRA) += pwm.o COBJS := $(COBJS-y) SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
arch/arm/cpu/armv7/tegra2/pwm.c new file +99 -0
99 lines not on this page · raw message
arch/arm/include/asm/arch-tegra2/pwm.h new file +75 -0
75 lines not on this page · raw message
include/fdtdec.h +1 -0
@@ -65,6 +65,7 @@ enum fdt_compat_id {COMPAT_NVIDIA_TEGRA20_EMC ,/* Tegra2 memory controller */ COMPAT_NVIDIA_TEGRA20_EMC_TABLE ,/* Tegra2 memory timing table */ COMPAT_NVIDIA_TEGRA20_KBC ,/* Tegra2 Keyboard */ +COMPAT_NVIDIA_TEGRA20_PWM ,/* Tegra 2 PWM controller */ COMPAT_COUNT, };
lib/fdtdec.c +1 -0
@@ -43,6 +43,7 @@ static const char * const compat_names[COMPAT_COUNT] = {COMPAT (NVIDIA_TEGRA20_EMC ,"nvidia,tegra20-emc" ),COMPAT (NVIDIA_TEGRA20_EMC_TABLE ,"nvidia,tegra20-emc-table" ),COMPAT (NVIDIA_TEGRA20_KBC ,"nvidia,tegra20-kbc" ), + COMPAT(NVIDIA_TEGRA20_PWM, "nvidia,tegra20-pwm"), };const char *fdtdec_get_compatible (enum fdt_compat_id id)
Signature · 1 line
1.7.7.3
PATCH v3 7/18 tegra: Add support for PWM
arch/arm/cpu/armv7/tegra2/Makefile
Quoted 4 lines · On Thursday 12 July 2012 11:25:07 Simon Glass wrote:
arch/arm/cpu/armv7/tegra2/Makefile +1
-0+COBJS-$(CONFIG_VIDEO_TEGRA) += pwm.o
should this get its own knob ? PWM isn't video specific ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/d3f353d0/attachment.pgp>
PATCH v3 7/18 tegra: Add support for PWM
Hi Mike,
Quoted 7 lines · Mike Frysinger
arch/arm/cpu/armv7/tegra2/Makefile
Quoted 4 lines · On Thursday 12 July 2012 11:25:07 Simon Glass wrote:
arch/arm/cpu/armv7/tegra2/Makefile +1
-0+COBJS-$(CONFIG_VIDEO_TEGRA) += pwm.oshould this get its own knob ? PWM isn't video specific ...
Probably a good idea, will do.
Regards,
Simon
Quoted 1 line
-mike
PATCH v3 8/18 tegra: Add SOC support for display/lcd
In reply to Simon GlassFrom: Wei Ni <[email protected]>
Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.
Mayuresh Kulkarni:
- changes to remove bitfields and clean up for submission
Simon Glass:
- simplify code, move clock control into here, clean-up
---
Changes in v3:
- Add probe function to read in fdt parameters in display driver
- Separate display driver and LCD driver more in fdt
arch/arm/cpu/armv7/tegra2/Makefile | 2 +- arch/arm/cpu/armv7/tegra2/display.c | 389 ++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/dc.h | 544 ++++++++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/display.h | 152 ++++++++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + 6 files changed, 1088 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/display.c create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h create mode 100644 arch/arm/include/asm/arch-tegra2/display.h
arch/arm/cpu/armv7/tegra2/Makefile +1 -1
@@ -40,7 +40,7 @@ COBJS-$(CONFIG_TEGRA_PMU) += pmu.o COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o COBJS-$(CONFIG_TEGRA2_LP0) += crypto.o warmboot.o warmboot_avp.o COBJS-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o -COBJS-$(CONFIG_VIDEO_TEGRA) += pwm.o +COBJS-$(CONFIG_VIDEO_TEGRA) += display.o pwm.o COBJS := $(COBJS-y) SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
arch/arm/cpu/armv7/tegra2/display.c new file +389 -0
389 lines not on this page · raw message
arch/arm/include/asm/arch-tegra2/dc.h new file +544 -0
544 lines not on this page · raw message
arch/arm/include/asm/arch-tegra2/display.h new file +152 -0
152 lines not on this page · raw message
include/fdtdec.h +1 -0
@@ -66,6 +66,7 @@ enum fdt_compat_id {COMPAT_NVIDIA_TEGRA20_EMC_TABLE ,/* Tegra2 memory timing table */ COMPAT_NVIDIA_TEGRA20_KBC ,/* Tegra2 Keyboard */ COMPAT_NVIDIA_TEGRA20_PWM ,/* Tegra 2 PWM controller */ +COMPAT_NVIDIA_TEGRA20_DC ,/* Tegra 2 Display controller */ COMPAT_COUNT, };
lib/fdtdec.c +1 -0
@@ -44,6 +44,7 @@ static const char * const compat_names[COMPAT_COUNT] = {COMPAT (NVIDIA_TEGRA20_EMC_TABLE ,"nvidia,tegra20-emc-table" ),COMPAT (NVIDIA_TEGRA20_KBC ,"nvidia,tegra20-kbc" ),COMPAT (NVIDIA_TEGRA20_PWM ,"nvidia,tegra20-pwm" ), + COMPAT(NVIDIA_TEGRA20_DC, "nvidia,tegra20-dc"), };const char *fdtdec_get_compatible (enum fdt_compat_id id)
Signature · 1 line
1.7.7.3
PATCH v3 8/18 tegra: Add SOC support for display/lcd
Quoted 29 lines · Simon Glass
From: Wei Ni <[email protected]>
Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.
Mayuresh Kulkarni:
- changes to remove bitfields and clean up for submissionSimon Glass:
- simplify code, move clock control into here, clean-upSigned-off-by Mayuresh Kulkarni <[email protected]>Signed-off-by Simon Glass <[email protected]>---
Changes in v3:
- Add probe function to read in fdt parameters in display driver
- Separate display driver and LCD driver more in fdtarch/arm/cpu/armv7/tegra2/Makefile | 2 +- arch/arm/cpu/armv7/tegra2/display.c | 389 ++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/dc.h | 544 ++++++++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/display.h | 152 ++++++++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + 6 files changed, 1088 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/display.c create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h create mode 100644 arch/arm/include/asm/arch-tegra2/display.h
[...]
Quoted 1 line
arch/arm/cpu/armv7/tegra2/display.c +0
-0
[...]
Quoted 6 lines
arch/arm/cpu/armv7/tegra2/display.c +6
-0+int setup_window (struct disp_ctl_win *win,struct fdt_disp_config *config) +{ + win->x =0 ; + win->y =0 ; + win->w = config->width; + win->h = config->height;
arch/arm/cpu/armv7/tegra2/display.c line 229
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c +10
-0+ win->out_x =0 ; + win->out_y =0 ; + win->out_w = config->width; + win->out_h = config->height; + win->phys_addr = config->frame_buffer; + win->stride = config->width * (1 << config->log2_bpp) /8 ; +debug ("%s: depth = %d\n" , __func__, config->log2_bpp); +switch (config->log2_bpp) { +case 5 : +case 24 :
What's the 24 doing here?
[...]
Quoted 38 lines
arch/arm/cpu/armv7/tegra2/display.c +38
-0+static int tegra_display_decode_config (const void *blob, +struct fdt_disp_config *config) +{ +int front, back, ref; +int node, rgb; +int bpp, bit; + + node =fdtdec_next_compatible (blob,0 ,COMPAT_NVIDIA_TEGRA20_DC ); +if (node <0 ) { +debug ("%s: Cannot find display controller node in fdt\n" , + __func__); +return node; + } + config->disp = (struct disp_ctlr *)fdtdec_get_addr (blob, node,"reg" ); +if (!config->disp) { +debug ("%s: No display controller address\n" , __func__); +return -1 ; + } + + rgb =fdt_subnode_offset (blob, node,"rgb" ); + + config->frame_buffer =fdtdec_get_addr (blob, rgb, +"nvidia,frame-buffer" ); + config->width =fdtdec_get_int (blob, rgb,"xres" ,-1 ); + config->height =fdtdec_get_int (blob, rgb,"yres" ,-1 ); + bpp =fdtdec_get_int (blob, rgb,"nvidia,bits-per-pixel" ,-1 ); + bit =ffs (bpp) -1 ; +if (bpp == (1 << bit)) + config->log2_bpp = bit; +else + config->log2_bpp = bpp; + config->bpp = bpp; + config->pixel_clock =fdtdec_get_int (blob, rgb,"clock" ,0 ); +if (!config->pixel_clock || bpp ==-1 || + config->width ==-1 || config->height ==-1 ) { +debug ("%s: Pixel parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + }
arch/arm/cpu/armv7/tegra2/display.c line 317
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c +10
-0+ +/* Use a ref-to-sync of 1 always, and take this from the front porch */ + back =fdtdec_get_int (blob, rgb,"left-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"right-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"hsync-len" ,-1 ); +if ((back | front | ref) ==-1 ) { +debug ("%s: Horizontal parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =11 ;
The comment above says this should be 1.
Quoted 9 lines
arch/arm/cpu/armv7/tegra2/display.c +9
-0+ config->horiz_timing[FDT_LCD_TIMING_SYNC_WIDTH ] = ref; + config->horiz_timing[FDT_LCD_TIMING_BACK_PORCH ] = back; + config->horiz_timing[FDT_LCD_TIMING_FRONT_PORCH ] = front - + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ]; +debug_timing ("horiz" , config->horiz_timing); + + back =fdtdec_get_int (blob, rgb,"upper-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"lower-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"vsync-len" ,-1 );
arch/arm/cpu/armv7/tegra2/display.c line 336
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c +10
-0+if ((back | front | ref) ==-1 ) { +debug ("%s: Vertical parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->vert_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =1 ; + config->vert_timing[FDT_LCD_TIMING_SYNC_WIDTH ] = ref; + config->vert_timing[FDT_LCD_TIMING_BACK_PORCH ] = back; + config->vert_timing[FDT_LCD_TIMING_FRONT_PORCH ] = front - + config->vert_timing[FDT_LCD_TIMING_REF_TO_SYNC ]; +debug_timing ("vert" , config->horiz_timing);
This should probably be config->vert_timing.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/4e7a7949/attachment.pgp>
PATCH v3 8/18 tegra: Add SOC support for display/lcd
Quoted 45 lines · Thierry Reding
* PGP Signed by an unknown key
Quoted 29 lines · Simon Glass
From: Wei Ni <[email protected]>
Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.
Mayuresh Kulkarni:
- changes to remove bitfields and clean up for submissionSimon Glass:
- simplify code, move clock control into here, clean-upSigned-off-by Mayuresh Kulkarni <[email protected]>Signed-off-by Simon Glass <[email protected]>---
Changes in v3:
- Add probe function to read in fdt parameters in display driver
- Separate display driver and LCD driver more in fdtarch/arm/cpu/armv7/tegra2/Makefile | 2 +- arch/arm/cpu/armv7/tegra2/display.c | 389 ++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/dc.h | 544 ++++++++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/display.h | 152 ++++++++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + 6 files changed, 1088 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/display.c create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h create mode 100644 arch/arm/include/asm/arch-tegra2/display.h[...]
Quoted 1 line
arch/arm/cpu/armv7/tegra2/display.c +0
-0[...]
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c +10
-0+int setup_window (struct disp_ctl_win *win,struct fdt_disp_config *config) +{ + win->x =0 ; + win->y =0 ; + win->w = config->width; + win->h = config->height; + win->out_x =0 ; + win->out_y =0 ; + win->out_w = config->width; + win->out_h = config->height;
Quoted 8 lines
arch/arm/cpu/armv7/tegra2/display.c line 229
Quoted 6 lines
arch/arm/cpu/armv7/tegra2/display.c +6
-0+ win->phys_addr = config->frame_buffer; + win->stride = config->width * (1 << config->log2_bpp) /8 ; +debug ("%s: depth = %d\n" , __func__, config->log2_bpp); +switch (config->log2_bpp) { +case 5 : +case 24 :What's the 24 doing here?
This has been explained in the definition of the log2_bpp. When bpp is 24, the integer holds 24 itself because there is no 2^N expression for it.
/Adam
Quoted 77 lines
[...]
Quoted 38 lines
arch/arm/cpu/armv7/tegra2/display.c +38
-0+static int tegra_display_decode_config (const void *blob, +struct fdt_disp_config *config) +{ +int front, back, ref; +int node, rgb; +int bpp, bit; + + node =fdtdec_next_compatible (blob,0 ,COMPAT_NVIDIA_TEGRA20_DC ); +if (node <0 ) { +debug ("%s: Cannot find display controller node in fdt\n" , + __func__); +return node; + } + config->disp = (struct disp_ctlr *)fdtdec_get_addr (blob, node,"reg" ); +if (!config->disp) { +debug ("%s: No display controller address\n" , __func__); +return -1 ; + } + + rgb =fdt_subnode_offset (blob, node,"rgb" ); + + config->frame_buffer =fdtdec_get_addr (blob, rgb, +"nvidia,frame-buffer" ); + config->width =fdtdec_get_int (blob, rgb,"xres" ,-1 ); + config->height =fdtdec_get_int (blob, rgb,"yres" ,-1 ); + bpp =fdtdec_get_int (blob, rgb,"nvidia,bits-per-pixel" ,-1 ); + bit =ffs (bpp) -1 ; +if (bpp == (1 << bit)) + config->log2_bpp = bit; +else + config->log2_bpp = bpp; + config->bpp = bpp; + config->pixel_clock =fdtdec_get_int (blob, rgb,"clock" ,0 ); +if (!config->pixel_clock || bpp ==-1 || + config->width ==-1 || config->height ==-1 ) { +debug ("%s: Pixel parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + }arch/arm/cpu/armv7/tegra2/display.c line 317
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c +10
-0+ +/* Use a ref-to-sync of 1 always, and take this from the front porch */ + back =fdtdec_get_int (blob, rgb,"left-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"right-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"hsync-len" ,-1 ); +if ((back | front | ref) ==-1 ) { +debug ("%s: Horizontal parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =11 ;The comment above says this should be 1.
Quoted 9 lines
arch/arm/cpu/armv7/tegra2/display.c +9
-0+ config->horiz_timing[FDT_LCD_TIMING_SYNC_WIDTH ] = ref; + config->horiz_timing[FDT_LCD_TIMING_BACK_PORCH ] = back; + config->horiz_timing[FDT_LCD_TIMING_FRONT_PORCH ] = front - + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ]; +debug_timing ("horiz" , config->horiz_timing); + + back =fdtdec_get_int (blob, rgb,"upper-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"lower-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"vsync-len" ,-1 );arch/arm/cpu/armv7/tegra2/display.c line 336
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c +10
-0+if ((back | front | ref) ==-1 ) { +debug ("%s: Vertical parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->vert_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =1 ; + config->vert_timing[FDT_LCD_TIMING_SYNC_WIDTH ] = ref; + config->vert_timing[FDT_LCD_TIMING_BACK_PORCH ] = back; + config->vert_timing[FDT_LCD_TIMING_FRONT_PORCH ] = front - + config->vert_timing[FDT_LCD_TIMING_REF_TO_SYNC ]; +debug_timing ("vert" , config->horiz_timing);This should probably be
config->vert_timing.Thierry
Quoted 7 lines
* Unknown Key
*0x7F3EB3A1_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
PATCH v3 8/18 tegra: Add SOC support for display/lcd
Quoted 55 lines · Adam Jiang
Quoted 45 lines · Thierry Reding
* PGP Signed by an unknown key
Quoted 29 lines · Simon Glass
From: Wei Ni <[email protected]>
Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.
Mayuresh Kulkarni:
- changes to remove bitfields and clean up for submissionSimon Glass:
- simplify code, move clock control into here, clean-upSigned-off-by Mayuresh Kulkarni <[email protected]>Signed-off-by Simon Glass <[email protected]>---
Changes in v3:
- Add probe function to read in fdt parameters in display driver
- Separate display driver and LCD driver more in fdtarch/arm/cpu/armv7/tegra2/Makefile | 2 +- arch/arm/cpu/armv7/tegra2/display.c | 389 ++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/dc.h | 544 ++++++++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/display.h | 152 ++++++++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + 6 files changed, 1088 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/display.c create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h create mode 100644 arch/arm/include/asm/arch-tegra2/display.h[...]
Quoted 1 line
arch/arm/cpu/armv7/tegra2/display.c +0
-0[...]
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c +10
-0+int setup_window (struct disp_ctl_win *win,struct fdt_disp_config *config) +{ + win->x =0 ; + win->y =0 ; + win->w = config->width; + win->h = config->height; + win->out_x =0 ; + win->out_y =0 ; + win->out_w = config->width; + win->out_h = config->height;Quoted 8 lines
arch/arm/cpu/armv7/tegra2/display.c line 229
Quoted 6 lines
arch/arm/cpu/armv7/tegra2/display.c +6
-0+ win->phys_addr = config->frame_buffer; + win->stride = config->width * (1 << config->log2_bpp) /8 ; +debug ("%s: depth = %d\n" , __func__, config->log2_bpp); +switch (config->log2_bpp) { +case 5 : +case 24 :What's the 24 doing here?
Quoted 3 lines
This has been explained in the definition of the
log2_bpp. When bpp is 24, the integer holds 24 itself because there is no 2^N expression for it.
Right, I missed that. Thanks.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/9b3edaf0/attachment.pgp>
PATCH v3 8/18 tegra: Add SOC support for display/lcd
In reply to Simon GlassQuoted 347 lines · Simon Glass
From: Wei Ni <[email protected]>
Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.
Mayuresh Kulkarni:
- changes to remove bitfields and clean up for submissionSimon Glass:
- simplify code, move clock control into here, clean-upSigned-off-by Mayuresh Kulkarni <[email protected]>Signed-off-by Simon Glass <[email protected]>---
Changes in v3:
- Add probe function to read in fdt parameters in display driver
- Separate display driver and LCD driver more in fdtarch/arm/cpu/armv7/tegra2/Makefile | 2 +- arch/arm/cpu/armv7/tegra2/display.c | 389 ++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/dc.h | 544 ++++++++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/display.h | 152 ++++++++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + 6 files changed, 1088 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/display.c create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h create mode 100644 arch/arm/include/asm/arch-tegra2/display.harch/arm/cpu/armv7/tegra2/Makefile +1
-1@@ -40,7 +40,7 @@ COBJS-$(CONFIG_TEGRA_PMU) += pmu.o COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o COBJS-$(CONFIG_TEGRA2_LP0) += crypto.o warmboot.o warmboot_avp.o COBJS-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o -COBJS-$(CONFIG_VIDEO_TEGRA) += pwm.o +COBJS-$(CONFIG_VIDEO_TEGRA) += display.o pwm.o COBJS := $(COBJS-y) SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)arch/arm/cpu/armv7/tegra2/display.c new file +299
-0@@ -0,0 +1,389 @@ +/* +* (C) Copyright 2010 +* NVIDIA Corporation <www.nvidia.com> +* +* See file CREDITS for list of people who contributed to this +* project. +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#include <common.h> +#include <asm/io.h> +#include <asm/arch/clk_rst.h> +#include <asm/arch/clock.h> +#include <asm/arch/timer.h> +#include <asm/arch/tegra2.h> +#include <asm/arch/display.h> +#include <asm/arch/dc.h> + +static struct fdt_disp_config config; + +static void update_window (struct dc_ctlr *dc,struct disp_ctl_win *win) +{ +unsigned h_dda, v_dda; +unsigned long val; + + val =readl (&dc->cmd.disp_win_header); + val |=WINDOW_A_SELECT ; +writel (val, &dc->cmd.disp_win_header); + +writel (win->fmt, &dc->win.color_depth); + + val =readl (&dc->win.byte_swap); + val |=BYTE_SWAP_NOSWAP <<BYTE_SWAP_SHIFT ; +writel (val, &dc->win.byte_swap); + + val = win->out_x <<H_POSITION_SHIFT ; + val |= win->out_y <<V_POSITION_SHIFT ; +writel (val, &dc->win.pos); + + val = win->out_w <<H_SIZE_SHIFT ; + val |= win->out_h <<V_SIZE_SHIFT ; +writel (val, &dc->win.size); + + val = (win->w * win->bpp /8 ) <<H_PRESCALED_SIZE_SHIFT ; + val |= win->h <<V_PRESCALED_SIZE_SHIFT ; +writel (val, &dc->win.prescaled_size); + +writel (0 , &dc->win.h_initial_dda); +writel (0 , &dc->win.v_initial_dda); + + h_dda = (win->w *0x1000 ) /max (win->out_w -1 ,1 ); + v_dda = (win->h *0x1000 ) /max (win->out_h -1 ,1 ); + + val = h_dda <<H_DDA_INC_SHIFT ; + val |= v_dda <<V_DDA_INC_SHIFT ; +writel (val, &dc->win.dda_increment); + +writel (win->stride, &dc->win.line_stride); +writel (0 , &dc->win.buf_stride); + + val =WIN_ENABLE ; +if (win->bpp <24 ) + val |=COLOR_EXPAND ; +writel (val, &dc->win.win_opt); + +writel ((unsigned long )win->phys_addr, &dc->winbuf.start_addr); +writel (win->x, &dc->winbuf.addr_h_offset); +writel (win->y, &dc->winbuf.addr_v_offset); + +writel (0xff00 , &dc->win.blend_nokey); +writel (0xff00 , &dc->win.blend_1win); + + val =GENERAL_ACT_REQ |WIN_A_ACT_REQ ; + val |=GENERAL_UPDATE |WIN_A_UPDATE ; +writel (val, &dc->cmd.state_ctrl); +} + +static void write_pair (struct fdt_disp_config *config,int item,u32 *reg) +{ +writel (config->horiz_timing[item] | + (config->vert_timing[item] <<16 ), reg); +} + +static int update_display_mode (struct dc_disp_reg *disp, +struct fdt_disp_config *config) +{ +unsigned long val; +unsigned long rate; +unsigned long div; + +writel (0x0 , &disp->disp_timing_opt); +write_pair (config,FDT_LCD_TIMING_REF_TO_SYNC , &disp->ref_to_sync); +write_pair (config,FDT_LCD_TIMING_SYNC_WIDTH , &disp->sync_width); +write_pair (config,FDT_LCD_TIMING_BACK_PORCH , &disp->back_porch); +write_pair (config,FDT_LCD_TIMING_FRONT_PORCH , &disp->front_porch); + +writel (config->width | (config->height <<16 ), &disp->disp_active); + + val =DE_SELECT_ACTIVE <<DE_SELECT_SHIFT ; + val |=DE_CONTROL_NORMAL <<DE_CONTROL_SHIFT ; +writel (val, &disp->data_enable_opt); + + val =DATA_FORMAT_DF1P1C <<DATA_FORMAT_SHIFT ; + val |=DATA_ALIGNMENT_MSB <<DATA_ALIGNMENT_SHIFT ; + val |=DATA_ORDER_RED_BLUE <<DATA_ORDER_SHIFT ; +writel (val, &disp->disp_interface_ctrl); + +/* +* The pixel clock divider is in 7.1 format (where the bottom bit +* represents 0.5). Here we calculate the divider needed to get from +* the display clock (typically 600MHz) to the pixel clock. We round +* up or down as requried. +*/ + rate =clock_get_periph_rate (PERIPH_ID_DISP1 ,CLOCK_ID_CGENERAL ); + div = ((rate *2 + config->pixel_clock /2 ) / config->pixel_clock) -2 ; +debug ("Display clock %lu, divider %lu\n" , rate, div); + +writel (0x00010001 , &disp->shift_clk_opt); + + val =PIXEL_CLK_DIVIDER_PCD1 <<PIXEL_CLK_DIVIDER_SHIFT ; + val |= div <<SHIFT_CLK_DIVIDER_SHIFT ; +writel (val, &disp->disp_clk_ctrl); + +return 0 ; +} + +/* Start up the display and turn on power to PWMs */ +static void basic_init (struct dc_cmd_reg *cmd) +{ +u32 val; + +writel (0x00000100 , &cmd->gen_incr_syncpt_ctrl); +writel (0x0000011a , &cmd->cont_syncpt_vsync); +writel (0x00000000 , &cmd->int_type); +writel (0x00000000 , &cmd->int_polarity); +writel (0x00000000 , &cmd->int_mask); +writel (0x00000000 , &cmd->int_enb); + + val =PW0_ENABLE |PW1_ENABLE |PW2_ENABLE ; + val |=PW3_ENABLE |PW4_ENABLE |PM0_ENABLE ; + val |=PM1_ENABLE ; +writel (val, &cmd->disp_pow_ctrl); + + val =readl (&cmd->disp_cmd); + val |=CTRL_MODE_C_DISPLAY <<CTRL_MODE_SHIFT ; +writel (val, &cmd->disp_cmd); +} + +static void basic_init_timer (struct dc_disp_reg *disp) +{ +writel (0x00000020 , &disp->mem_high_pri); +writel (0x00000001 , &disp->mem_high_pri_timer); +} + +static const u32 rgb_enb_tab[PIN_REG_COUNT ] = { +0x00000000 , +0x00000000 , +0x00000000 , +0x00000000 , +}; + +static const u32 rgb_polarity_tab[PIN_REG_COUNT ] = { +0x00000000 , +0x01000000 , +0x00000000 , +0x00000000 , +}; + +static const u32 rgb_data_tab[PIN_REG_COUNT ] = { +0x00000000 , +0x00000000 , +0x00000000 , +0x00000000 , +}; + +static const u32 rgb_sel_tab[PIN_OUTPUT_SEL_COUNT ] = { +0x00000000 , +0x00000000 , +0x00000000 , +0x00000000 , +0x00210222 , +0x00002200 , +0x00020000 , +}; + +static void rgb_enable (struct dc_com_reg *com) +{ +int i; + +for (i =0 ; i <PIN_REG_COUNT ; i++) { +writel (rgb_enb_tab[i], &com->pin_output_enb[i]); +writel (rgb_polarity_tab[i], &com->pin_output_polarity[i]); +writel (rgb_data_tab[i], &com->pin_output_data[i]); + } + +for (i =0 ; i <PIN_OUTPUT_SEL_COUNT ; i++) +writel (rgb_sel_tab[i], &com->pin_output_sel[i]); +} + +int setup_window (struct disp_ctl_win *win,struct fdt_disp_config *config) +{ + win->x =0 ; + win->y =0 ; + win->w = config->width; + win->h = config->height; + win->out_x =0 ; + win->out_y =0 ; + win->out_w = config->width; + win->out_h = config->height; + win->phys_addr = config->frame_buffer; + win->stride = config->width * (1 << config->log2_bpp) /8 ; +debug ("%s: depth = %d\n" , __func__, config->log2_bpp); +switch (config->log2_bpp) { +case 5 : +case 24 : + win->fmt =COLOR_DEPTH_R8G8B8A8 ; + win->bpp =32 ; +break ; +case 4 : + win->fmt =COLOR_DEPTH_B5G6R5 ; + win->bpp =16 ; +break ; + +default : +debug ("Unsupported LCD bit depth" ); +return -1 ; + } + +return 0 ; +} + +struct fdt_disp_config *tegra_display_get_config (void ) +{ +return config.valid ? &config :NULL ; +} + +static void debug_timing (const char *name,unsigned int timing[]) +{ +#ifdef DEBUG +int i; + +debug ("%s timing: " , name); +for (i =0 ; i <FDT_LCD_TIMING_COUNT ; i++) +debug ("%d " , timing[i]); +debug ("\n" ); +#endif +} + +/** +* Decode the display controller information from the fdt. +* +* @param blob fdt blob +* @param config structure to store fdt config into +* @return 0 if ok, -ve on error +*/ +static int tegra_display_decode_config (const void *blob, +struct fdt_disp_config *config) +{ +int front, back, ref; +int node, rgb; +int bpp, bit; + + node =fdtdec_next_compatible (blob,0 ,COMPAT_NVIDIA_TEGRA20_DC ); +if (node <0 ) { +debug ("%s: Cannot find display controller node in fdt\n" , + __func__); +return node; + } + config->disp = (struct disp_ctlr *)fdtdec_get_addr (blob, node,"reg" ); +if (!config->disp) { +debug ("%s: No display controller address\n" , __func__); +return -1 ; + } + + rgb =fdt_subnode_offset (blob, node,"rgb" ); + + config->frame_buffer =fdtdec_get_addr (blob, rgb, +"nvidia,frame-buffer" ); + config->width =fdtdec_get_int (blob, rgb,"xres" ,-1 ); + config->height =fdtdec_get_int (blob, rgb,"yres" ,-1 ); + bpp =fdtdec_get_int (blob, rgb,"nvidia,bits-per-pixel" ,-1 ); + bit =ffs (bpp) -1 ; +if (bpp == (1 << bit)) + config->log2_bpp = bit; +else
arch/arm/cpu/armv7/tegra2/display.c line 309
Quoted 10 lines
arch/arm/cpu/armv7/tegra2/display.c new file +10
-0+ config->log2_bpp = bpp; + config->bpp = bpp; + config->pixel_clock =fdtdec_get_int (blob, rgb,"clock" ,0 ); +if (!config->pixel_clock || bpp ==-1 || + config->width ==-1 || config->height ==-1 ) { +debug ("%s: Pixel parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + +/* Use a ref-to-sync of 1 always, and take this from the front porch */
ref-to-sync is supposed to be 1 here.
arch/arm/cpu/armv7/tegra2/display.c line 317
Quoted 8 lines
arch/arm/cpu/armv7/tegra2/display.c new file +8
-0+ back =fdtdec_get_int (blob, rgb,"left-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"right-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"hsync-len" ,-1 ); +if ((back | front | ref) ==-1 ) { +debug ("%s: Horizontal parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =11 ;
It is assigned to 11.
/Adam
Quoted 807 lines
arch/arm/cpu/armv7/tegra2/display.c new file +72
-0+ config->horiz_timing[FDT_LCD_TIMING_SYNC_WIDTH ] = ref; + config->horiz_timing[FDT_LCD_TIMING_BACK_PORCH ] = back; + config->horiz_timing[FDT_LCD_TIMING_FRONT_PORCH ] = front - + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ]; +debug_timing ("horiz" , config->horiz_timing); + + back =fdtdec_get_int (blob, rgb,"upper-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"lower-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"vsync-len" ,-1 ); +if ((back | front | ref) ==-1 ) { +debug ("%s: Vertical parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->vert_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =1 ; + config->vert_timing[FDT_LCD_TIMING_SYNC_WIDTH ] = ref; + config->vert_timing[FDT_LCD_TIMING_BACK_PORCH ] = back; + config->vert_timing[FDT_LCD_TIMING_FRONT_PORCH ] = front - + config->vert_timing[FDT_LCD_TIMING_REF_TO_SYNC ]; +debug_timing ("vert" , config->horiz_timing); + + config->panel_node =fdtdec_lookup_phandle (blob, rgb,"nvidia,panel" ); + + config->valid =1 ;/* we have a valid configuration */ + +return 0 ; +} + +int tegra_display_probe (const void *blob,void *default_lcd_base) +{ +struct disp_ctl_win window; +struct dc_ctlr *dc; + +if (tegra_display_decode_config (blob, &config)) +return -1 ; + +/* +* The framebuffer address should be specified in the device tree. +* This FDT value should be the same as the one defined in Linux kernel; +* otherwise, it causes screen flicker. The FDT value overrides the +* framebuffer allocated at the top of memory by board_init_f(). +* +* If the framebuffer address is not defined in the FDT, falls back to +* use the address allocated by board_init_f(). +*/ +if (config.frame_buffer ==FDT_ADDR_T_NONE ) + config.frame_buffer = (u32 )default_lcd_base; + + dc = (struct dc_ctlr *)config.disp; + +/* +* A header file for clock constants was NAKed upstream. +* TODO: Put this into the FDT and fdt_lcd struct when we have clock +* support there +*/ +clock_start_periph_pll (PERIPH_ID_HOST1X ,CLOCK_ID_PERIPH , +144 *1000000 ); +clock_start_periph_pll (PERIPH_ID_DISP1 ,CLOCK_ID_CGENERAL , +600 *1000000 ); +basic_init (&dc->cmd); +basic_init_timer (&dc->disp); +rgb_enable (&dc->com); + +if (config.pixel_clock) +update_display_mode (&dc->disp, &config); + +if (setup_window (&window, &config)) +return -1 ; + +update_window (dc, &window); + +return 0 ; +}arch/arm/include/asm/arch-tegra2/dc.h new file +544
-0@@ -0,0 +1,544 @@ +/* +* (C) Copyright 2010 +* NVIDIA Corporation <www.nvidia.com> +* +* See file CREDITS for list of people who contributed to this +* project. +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __ASM_ARCH_TEGRA_DC_H +#define __ASM_ARCH_TEGRA_DC_H + +/* Register definitions for the Tegra display controller */ + +/* CMD register 0x000 ~ 0x43 */ +struct dc_cmd_reg { +/* Address 0x000 ~ 0x002 */ +uint gen_incr_syncpt;/* _CMD_GENERAL_INCR_SYNCPT_0 */ +uint gen_incr_syncpt_ctrl;/* _CMD_GENERAL_INCR_SYNCPT_CNTRL_0 */ +uint gen_incr_syncpt_err;/* _CMD_GENERAL_INCR_SYNCPT_ERROR_0 */ + +uint reserved0[5 ];/* reserved_0[5] */ + +/* Address 0x008 ~ 0x00a */ +uint win_a_incr_syncpt;/* _CMD_WIN_A_INCR_SYNCPT_0 */ +uint win_a_incr_syncpt_ctrl;/* _CMD_WIN_A_INCR_SYNCPT_CNTRL_0 */ +uint win_a_incr_syncpt_err;/* _CMD_WIN_A_INCR_SYNCPT_ERROR_0 */ + +uint reserved1[5 ];/* reserved_1[5] */ + +/* Address 0x010 ~ 0x012 */ +uint win_b_incr_syncpt;/* _CMD_WIN_B_INCR_SYNCPT_0 */ +uint win_b_incr_syncpt_ctrl;/* _CMD_WIN_B_INCR_SYNCPT_CNTRL_0 */ +uint win_b_incr_syncpt_err;/* _CMD_WIN_B_INCR_SYNCPT_ERROR_0 */ + +uint reserved2[5 ];/* reserved_2[5] */ + +/* Address 0x018 ~ 0x01a */ +uint win_c_incr_syncpt;/* _CMD_WIN_C_INCR_SYNCPT_0 */ +uint win_c_incr_syncpt_ctrl;/* _CMD_WIN_C_INCR_SYNCPT_CNTRL_0 */ +uint win_c_incr_syncpt_err;/* _CMD_WIN_C_INCR_SYNCPT_ERROR_0 */ + +uint reserved3[13 ];/* reserved_3[13] */ + +/* Address 0x028 */ +uint cont_syncpt_vsync;/* _CMD_CONT_SYNCPT_VSYNC_0 */ + +uint reserved4[7 ];/* reserved_4[7] */ + +/* Address 0x030 ~ 0x033 */ +uint ctxsw;/* _CMD_CTXSW_0 */ +uint disp_cmd_opt0;/* _CMD_DISPLAY_COMMAND_OPTION0_0 */ +uint disp_cmd;/* _CMD_DISPLAY_COMMAND_0 */ +uint sig_raise;/* _CMD_SIGNAL_RAISE_0 */ + +uint reserved5[2 ];/* reserved_0[2] */ + +/* Address 0x036 ~ 0x03e */ +uint disp_pow_ctrl;/* _CMD_DISPLAY_POWER_CONTROL_0 */ +uint int_stat;/* _CMD_INT_STATUS_0 */ +uint int_mask;/* _CMD_INT_MASK_0 */ +uint int_enb;/* _CMD_INT_ENABLE_0 */ +uint int_type;/* _CMD_INT_TYPE_0 */ +uint int_polarity;/* _CMD_INT_POLARITY_0 */ +uint sig_raise1;/* _CMD_SIGNAL_RAISE1_0 */ +uint sig_raise2;/* _CMD_SIGNAL_RAISE2_0 */ +uint sig_raise3;/* _CMD_SIGNAL_RAISE3_0 */ + +uint reserved6;/* reserved_6 */ + +/* Address 0x040 ~ 0x043 */ +uint state_access;/* _CMD_STATE_ACCESS_0 */ +uint state_ctrl;/* _CMD_STATE_CONTROL_0 */ +uint disp_win_header;/* _CMD_DISPLAY_WINDOW_HEADER_0 */ +uint reg_act_ctrl;/* _CMD_REG_ACT_CONTROL_0 */ +}; + +enum { +PIN_REG_COUNT =4 , +PIN_OUTPUT_SEL_COUNT =7 , +}; + +/* COM register 0x300 ~ 0x329 */ +struct dc_com_reg { +/* Address 0x300 ~ 0x301 */ +uint crc_ctrl;/* _COM_CRC_CONTROL_0 */ +uint crc_checksum;/* _COM_CRC_CHECKSUM_0 */ + +/* _COM_PIN_OUTPUT_ENABLE0/1/2/3_0: Address 0x302 ~ 0x305 */ +uint pin_output_enb[PIN_REG_COUNT ]; + +/* _COM_PIN_OUTPUT_POLARITY0/1/2/3_0: Address 0x306 ~ 0x309 */ +uint pin_output_polarity[PIN_REG_COUNT ]; + +/* _COM_PIN_OUTPUT_DATA0/1/2/3_0: Address 0x30a ~ 0x30d */ +uint pin_output_data[PIN_REG_COUNT ]; + +/* _COM_PIN_INPUT_ENABLE0_0: Address 0x30e ~ 0x311 */ +uint pin_input_enb[PIN_REG_COUNT ]; + +/* Address 0x312 ~ 0x313 */ +uint pin_input_data0;/* _COM_PIN_INPUT_DATA0_0 */ +uint pin_input_data1;/* _COM_PIN_INPUT_DATA1_0 */ + +/* _COM_PIN_OUTPUT_SELECT0/1/2/3/4/5/6_0: Address 0x314 ~ 0x31a */ +uint pin_output_sel[PIN_OUTPUT_SEL_COUNT ]; + +/* Address 0x31b ~ 0x329 */ +uint pin_misc_ctrl;/* _COM_PIN_MISC_CONTROL_0 */ +uint pm0_ctrl;/* _COM_PM0_CONTROL_0 */ +uint pm0_duty_cycle;/* _COM_PM0_DUTY_CYCLE_0 */ +uint pm1_ctrl;/* _COM_PM1_CONTROL_0 */ +uint pm1_duty_cycle;/* _COM_PM1_DUTY_CYCLE_0 */ +uint spi_ctrl;/* _COM_SPI_CONTROL_0 */ +uint spi_start_byte;/* _COM_SPI_START_BYTE_0 */ +uint hspi_wr_data_ab;/* _COM_HSPI_WRITE_DATA_AB_0 */ +uint hspi_wr_data_cd;/* _COM_HSPI_WRITE_DATA_CD */ +uint hspi_cs_dc;/* _COM_HSPI_CS_DC_0 */ +uint scratch_reg_a;/* _COM_SCRATCH_REGISTER_A_0 */ +uint scratch_reg_b;/* _COM_SCRATCH_REGISTER_B_0 */ +uint gpio_ctrl;/* _COM_GPIO_CTRL_0 */ +uint gpio_debounce_cnt;/* _COM_GPIO_DEBOUNCE_COUNTER_0 */ +uint crc_checksum_latched;/* _COM_CRC_CHECKSUM_LATCHED_0 */ +}; + +enum dc_disp_h_pulse_pos { +H_PULSE0_POSITION_A , +H_PULSE0_POSITION_B , +H_PULSE0_POSITION_C , +H_PULSE0_POSITION_D , +H_PULSE0_POSITION_COUNT , +}; + +struct _disp_h_pulse { +/* _DISP_H_PULSE0/1/2_CONTROL_0 */ +uint h_pulse_ctrl; +/* _DISP_H_PULSE0/1/2_POSITION_A/B/C/D_0 */ +uint h_pulse_pos[H_PULSE0_POSITION_COUNT ]; +}; + +enum dc_disp_v_pulse_pos { +V_PULSE0_POSITION_A , +V_PULSE0_POSITION_B , +V_PULSE0_POSITION_C , +V_PULSE0_POSITION_COUNT , +}; + +struct _disp_v_pulse0 { +/* _DISP_H_PULSE0/1_CONTROL_0 */ +uint v_pulse_ctrl; +/* _DISP_H_PULSE0/1_POSITION_A/B/C_0 */ +uint v_pulse_pos[V_PULSE0_POSITION_COUNT ]; +}; + +struct _disp_v_pulse2 { +/* _DISP_H_PULSE2/3_CONTROL_0 */ +uint v_pulse_ctrl; +/* _DISP_H_PULSE2/3_POSITION_A_0 */ +uint v_pulse_pos_a; +}; + +enum dc_disp_h_pulse_reg { +H_PULSE0 , +H_PULSE1 , +H_PULSE2 , +H_PULSE_COUNT , +}; + +enum dc_disp_pp_select { +PP_SELECT_A , +PP_SELECT_B , +PP_SELECT_C , +PP_SELECT_D , +PP_SELECT_COUNT , +}; + +/* DISP register 0x400 ~ 0x4c1 */ +struct dc_disp_reg { +/* Address 0x400 ~ 0x40a */ +uint disp_signal_opt0;/* _DISP_DISP_SIGNAL_OPTIONS0_0 */ +uint disp_signal_opt1;/* _DISP_DISP_SIGNAL_OPTIONS1_0 */ +uint disp_win_opt;/* _DISP_DISP_WIN_OPTIONS_0 */ +uint mem_high_pri;/* _DISP_MEM_HIGH_PRIORITY_0 */ +uint mem_high_pri_timer;/* _DISP_MEM_HIGH_PRIORITY_TIMER_0 */ +uint disp_timing_opt;/* _DISP_DISP_TIMING_OPTIONS_0 */ +uint ref_to_sync;/* _DISP_REF_TO_SYNC_0 */ +uint sync_width;/* _DISP_SYNC_WIDTH_0 */ +uint back_porch;/* _DISP_BACK_PORCH_0 */ +uint disp_active;/* _DISP_DISP_ACTIVE_0 */ +uint front_porch;/* _DISP_FRONT_PORCH_0 */ + +/* Address 0x40b ~ 0x419: _DISP_H_PULSE0/1/2_ */ +struct _disp_h_pulse h_pulse[H_PULSE_COUNT ]; + +/* Address 0x41a ~ 0x421 */ +struct _disp_v_pulse0 v_pulse0;/* _DISP_V_PULSE0_ */ +struct _disp_v_pulse0 v_pulse1;/* _DISP_V_PULSE1_ */ + +/* Address 0x422 ~ 0x425 */ +struct _disp_v_pulse2 v_pulse3;/* _DISP_V_PULSE2_ */ +struct _disp_v_pulse2 v_pulse4;/* _DISP_V_PULSE3_ */ + +/* Address 0x426 ~ 0x429 */ +uint m0_ctrl;/* _DISP_M0_CONTROL_0 */ +uint m1_ctrl;/* _DISP_M1_CONTROL_0 */ +uint di_ctrl;/* _DISP_DI_CONTROL_0 */ +uint pp_ctrl;/* _DISP_PP_CONTROL_0 */ + +/* Address 0x42a ~ 0x42d: _DISP_PP_SELECT_A/B/C/D_0 */ +uint pp_select[PP_SELECT_COUNT ]; + +/* Address 0x42e ~ 0x435 */ +uint disp_clk_ctrl;/* _DISP_DISP_CLOCK_CONTROL_0 */ +uint disp_interface_ctrl;/* _DISP_DISP_INTERFACE_CONTROL_0 */ +uint disp_color_ctrl;/* _DISP_DISP_COLOR_CONTROL_0 */ +uint shift_clk_opt;/* _DISP_SHIFT_CLOCK_OPTIONS_0 */ +uint data_enable_opt;/* _DISP_DATA_ENABLE_OPTIONS_0 */ +uint serial_interface_opt;/* _DISP_SERIAL_INTERFACE_OPTIONS_0 */ +uint lcd_spi_opt;/* _DISP_LCD_SPI_OPTIONS_0 */ +uint border_color;/* _DISP_BORDER_COLOR_0 */ + +/* Address 0x436 ~ 0x439 */ +uint color_key0_lower;/* _DISP_COLOR_KEY0_LOWER_0 */ +uint color_key0_upper;/* _DISP_COLOR_KEY0_UPPER_0 */ +uint color_key1_lower;/* _DISP_COLOR_KEY1_LOWER_0 */ +uint color_key1_upper;/* _DISP_COLOR_KEY1_UPPER_0 */ + +uint reserved0[2 ];/* reserved_0[2] */ + +/* Address 0x43c ~ 0x442 */ +uint cursor_foreground;/* _DISP_CURSOR_FOREGROUND_0 */ +uint cursor_background;/* _DISP_CURSOR_BACKGROUND_0 */ +uint cursor_start_addr;/* _DISP_CURSOR_START_ADDR_0 */ +uint cursor_start_addr_ns;/* _DISP_CURSOR_START_ADDR_NS_0 */ +uint cursor_pos;/* _DISP_CURSOR_POSITION_0 */ +uint cursor_pos_ns;/* _DISP_CURSOR_POSITION_NS_0 */ +uint seq_ctrl;/* _DISP_INIT_SEQ_CONTROL_0 */ + +/* Address 0x442 ~ 0x446 */ +uint spi_init_seq_data_a;/* _DISP_SPI_INIT_SEQ_DATA_A_0 */ +uint spi_init_seq_data_b;/* _DISP_SPI_INIT_SEQ_DATA_B_0 */ +uint spi_init_seq_data_c;/* _DISP_SPI_INIT_SEQ_DATA_C_0 */ +uint spi_init_seq_data_d;/* _DISP_SPI_INIT_SEQ_DATA_D_0 */ + +uint reserved1[0x39 ];/* reserved1[0x39], */ + +/* Address 0x480 ~ 0x484 */ +uint dc_mccif_fifoctrl;/* _DISP_DC_MCCIF_FIFOCTRL_0 */ +uint mccif_disp0a_hyst;/* _DISP_MCCIF_DISPLAY0A_HYST_0 */ +uint mccif_disp0b_hyst;/* _DISP_MCCIF_DISPLAY0B_HYST_0 */ +uint mccif_disp0c_hyst;/* _DISP_MCCIF_DISPLAY0C_HYST_0 */ +uint mccif_disp1b_hyst;/* _DISP_MCCIF_DISPLAY1B_HYST_0 */ + +uint reserved2[0x3b ];/* reserved2[0x3b] */ + +/* Address 0x4c0 ~ 0x4c1 */ +uint dac_crt_ctrl;/* _DISP_DAC_CRT_CTRL_0 */ +uint disp_misc_ctrl;/* _DISP_DISP_MISC_CONTROL_0 */ +}; + +enum dc_winc_filter_p { +WINC_FILTER_COUNT =0x10 , +}; + +/* Window A/B/C register 0x500 ~ 0x628 */ +struct dc_winc_reg { + +/* Address 0x500 */ +uint color_palette;/* _WINC_COLOR_PALETTE_0 */ + +uint reserved0[0xff ];/* reserved_0[0xff] */ + +/* Address 0x600 */ +uint palette_color_ext;/* _WINC_PALETTE_COLOR_EXT_0 */ + +/* _WINC_H_FILTER_P00~0F_0 */ +/* Address 0x601 ~ 0x610 */ +uint h_filter_p[WINC_FILTER_COUNT ]; + +/* Address 0x611 ~ 0x618 */ +uint csc_yof;/* _WINC_CSC_YOF_0 */ +uint csc_kyrgb;/* _WINC_CSC_KYRGB_0 */ +uint csc_kur;/* _WINC_CSC_KUR_0 */ +uint csc_kvr;/* _WINC_CSC_KVR_0 */ +uint csc_kug;/* _WINC_CSC_KUG_0 */ +uint csc_kvg;/* _WINC_CSC_KVG_0 */ +uint csc_kub;/* _WINC_CSC_KUB_0 */ +uint csc_kvb;/* _WINC_CSC_KVB_0 */ + +/* Address 0x619 ~ 0x628: _WINC_V_FILTER_P00~0F_0 */ +uint v_filter_p[WINC_FILTER_COUNT ]; +}; + +/* WIN A/B/C Register 0x700 ~ 0x714*/ +struct dc_win_reg { +/* Address 0x700 ~ 0x714 */ +uint win_opt;/* _WIN_WIN_OPTIONS_0 */ +uint byte_swap;/* _WIN_BYTE_SWAP_0 */ +uint buffer_ctrl;/* _WIN_BUFFER_CONTROL_0 */ +uint color_depth;/* _WIN_COLOR_DEPTH_0 */ +uint pos;/* _WIN_POSITION_0 */ +uint size;/* _WIN_SIZE_0 */ +uint prescaled_size;/* _WIN_PRESCALED_SIZE_0 */ +uint h_initial_dda;/* _WIN_H_INITIAL_DDA_0 */ +uint v_initial_dda;/* _WIN_V_INITIAL_DDA_0 */ +uint dda_increment;/* _WIN_DDA_INCREMENT_0 */ +uint line_stride;/* _WIN_LINE_STRIDE_0 */ +uint buf_stride;/* _WIN_BUF_STRIDE_0 */ +uint uv_buf_stride;/* _WIN_UV_BUF_STRIDE_0 */ +uint buffer_addr_mode;/* _WIN_BUFFER_ADDR_MODE_0 */ +uint dv_ctrl;/* _WIN_DV_CONTROL_0 */ +uint blend_nokey;/* _WIN_BLEND_NOKEY_0 */ +uint blend_1win;/* _WIN_BLEND_1WIN_0 */ +uint blend_2win_x;/* _WIN_BLEND_2WIN_X_0 */ +uint blend_2win_y;/* _WIN_BLEND_2WIN_Y_0 */ +uint blend_3win_xy;/* _WIN_BLEND_3WIN_XY_0 */ +uint hp_fetch_ctrl;/* _WIN_HP_FETCH_CONTROL_0 */ +}; + +/* WINBUF A/B/C Register 0x800 ~ 0x80a */ +struct dc_winbuf_reg { +/* Address 0x800 ~ 0x80a */ +uint start_addr;/* _WINBUF_START_ADDR_0 */ +uint start_addr_ns;/* _WINBUF_START_ADDR_NS_0 */ +uint start_addr_u;/* _WINBUF_START_ADDR_U_0 */ +uint start_addr_u_ns;/* _WINBUF_START_ADDR_U_NS_0 */ +uint start_addr_v;/* _WINBUF_START_ADDR_V_0 */ +uint start_addr_v_ns;/* _WINBUF_START_ADDR_V_NS_0 */ +uint addr_h_offset;/* _WINBUF_ADDR_H_OFFSET_0 */ +uint addr_h_offset_ns;/* _WINBUF_ADDR_H_OFFSET_NS_0 */ +uint addr_v_offset;/* _WINBUF_ADDR_V_OFFSET_0 */ +uint addr_v_offset_ns;/* _WINBUF_ADDR_V_OFFSET_NS_0 */ +uint uflow_status;/* _WINBUF_UFLOW_STATUS_0 */ +}; + +/* Display Controller (DC_) regs */ +struct dc_ctlr { +struct dc_cmd_reg cmd;/* CMD register 0x000 ~ 0x43 */ +uint reserved0[0x2bc ]; + +struct dc_com_reg com;/* COM register 0x300 ~ 0x329 */ +uint reserved1[0xd6 ]; + +struct dc_disp_reg disp;/* DISP register 0x400 ~ 0x4c1 */ +uint reserved2[0x3e ]; + +struct dc_winc_reg winc;/* Window A/B/C 0x500 ~ 0x628 */ +uint reserved3[0xd7 ]; + +struct dc_win_reg win;/* WIN A/B/C 0x700 ~ 0x714*/ +uint reserved4[0xeb ]; + +struct dc_winbuf_reg winbuf;/* WINBUF A/B/C 0x800 ~ 0x80a */ +}; + +#define BIT (pos) (1U << pos) + +/* DC_CMD_DISPLAY_COMMAND 0x032 */ +#define CTRL_MODE_SHIFT 5 +#define CTRL_MODE_MASK (0x3 << CTRL_MODE_SHIFT) +enum { +CTRL_MODE_STOP , +CTRL_MODE_C_DISPLAY , +CTRL_MODE_NC_DISPLAY , +}; + +/* _WIN_COLOR_DEPTH_0 */ +enum win_color_depth_id { +COLOR_DEPTH_P1 , +COLOR_DEPTH_P2 , +COLOR_DEPTH_P4 , +COLOR_DEPTH_P8 , +COLOR_DEPTH_B4G4R4A4 , +COLOR_DEPTH_B5G5R5A , +COLOR_DEPTH_B5G6R5 , +COLOR_DEPTH_AB5G5R5 , +COLOR_DEPTH_B8G8R8A8 =12 , +COLOR_DEPTH_R8G8B8A8 , + COLOR_DEPTH_B6x2G6x2R6x2A8, + COLOR_DEPTH_R6x2G6x2B6x2A8, + COLOR_DEPTH_YCbCr422, +COLOR_DEPTH_YUV422 , + COLOR_DEPTH_YCbCr420P, +COLOR_DEPTH_YUV420P , + COLOR_DEPTH_YCbCr422P, +COLOR_DEPTH_YUV422P , + COLOR_DEPTH_YCbCr422R, +COLOR_DEPTH_YUV422R , + COLOR_DEPTH_YCbCr422RA, +COLOR_DEPTH_YUV422RA , +}; + +/* DC_CMD_DISPLAY_POWER_CONTROL 0x036 */ +#define PW0_ENABLE BIT(0) +#define PW1_ENABLE BIT(2) +#define PW2_ENABLE BIT(4) +#define PW3_ENABLE BIT(6) +#define PW4_ENABLE BIT(8) +#define PM0_ENABLE BIT(16) +#define PM1_ENABLE BIT(18) +#define SPI_ENABLE BIT(24) +#define HSPI_ENABLE BIT(25) + +/* DC_CMD_STATE_CONTROL 0x041 */ +#define GENERAL_ACT_REQ BIT(0) +#define WIN_A_ACT_REQ BIT(1) +#define WIN_B_ACT_REQ BIT(2) +#define WIN_C_ACT_REQ BIT(3) +#define GENERAL_UPDATE BIT(8) +#define WIN_A_UPDATE BIT(9) +#define WIN_B_UPDATE BIT(10) +#define WIN_C_UPDATE BIT(11) + +/* DC_CMD_DISPLAY_WINDOW_HEADER 0x042 */ +#define WINDOW_A_SELECT BIT(4) +#define WINDOW_B_SELECT BIT(5) +#define WINDOW_C_SELECT BIT(6) + +/* DC_DISP_DISP_CLOCK_CONTROL 0x42e */ +#define SHIFT_CLK_DIVIDER_SHIFT 0 +#define SHIFT_CLK_DIVIDER_MASK (0xff << SHIFT_CLK_DIVIDER_SHIFT) +#define PIXEL_CLK_DIVIDER_SHIFT 8 +#define PIXEL_CLK_DIVIDER_MSK (0xf << PIXEL_CLK_DIVIDER_SHIFT) +enum { +PIXEL_CLK_DIVIDER_PCD1 , +PIXEL_CLK_DIVIDER_PCD1H , +PIXEL_CLK_DIVIDER_PCD2 , +PIXEL_CLK_DIVIDER_PCD3 , +PIXEL_CLK_DIVIDER_PCD4 , +PIXEL_CLK_DIVIDER_PCD6 , +PIXEL_CLK_DIVIDER_PCD8 , +PIXEL_CLK_DIVIDER_PCD9 , +PIXEL_CLK_DIVIDER_PCD12 , +PIXEL_CLK_DIVIDER_PCD16 , +PIXEL_CLK_DIVIDER_PCD18 , +PIXEL_CLK_DIVIDER_PCD24 , +PIXEL_CLK_DIVIDER_PCD13 , +}; + +/* DC_DISP_DISP_INTERFACE_CONTROL 0x42f */ +#define DATA_FORMAT_SHIFT 0 +#define DATA_FORMAT_MASK (0xf << DATA_FORMAT_SHIFT) +enum { +DATA_FORMAT_DF1P1C , +DATA_FORMAT_DF1P2C24B , +DATA_FORMAT_DF1P2C18B , +DATA_FORMAT_DF1P2C16B , +DATA_FORMAT_DF2S , +DATA_FORMAT_DF3S , +DATA_FORMAT_DFSPI , +DATA_FORMAT_DF1P3C24B , +DATA_FORMAT_DF1P3C18B , +}; +#define DATA_ALIGNMENT_SHIFT 8 +enum { +DATA_ALIGNMENT_MSB , +DATA_ALIGNMENT_LSB , +}; +#define DATA_ORDER_SHIFT 9 +enum { +DATA_ORDER_RED_BLUE , +DATA_ORDER_BLUE_RED , +}; + +/* DC_DISP_DATA_ENABLE_OPTIONS 0x432 */ +#define DE_SELECT_SHIFT 0 +#define DE_SELECT_MASK (0x3 << DE_SELECT_SHIFT) +#define DE_SELECT_ACTIVE_BLANK 0x0 +#define DE_SELECT_ACTIVE 0x1 +#define DE_SELECT_ACTIVE_IS 0x2 +#define DE_CONTROL_SHIFT 2 +#define DE_CONTROL_MASK (0x7 << DE_CONTROL_SHIFT) +enum { +DE_CONTROL_ONECLK , +DE_CONTROL_NORMAL , +DE_CONTROL_EARLY_EXT , +DE_CONTROL_EARLY , +DE_CONTROL_ACTIVE_BLANK , +}; + +/* DC_WIN_WIN_OPTIONS 0x700 */ +#define H_DIRECTION BIT(0) +enum { +H_DIRECTION_INCREMENT , +H_DIRECTION_DECREMENT , +}; +#define V_DIRECTION BIT(2) +enum { +V_DIRECTION_INCREMENT , +V_DIRECTION_DECREMENT , +}; +#define COLOR_EXPAND BIT(6) +#define CP_ENABLE BIT(16) +#define DV_ENABLE BIT(20) +#define WIN_ENABLE BIT(30) + +/* DC_WIN_BYTE_SWAP 0x701 */ +#define BYTE_SWAP_SHIFT 0 +enum { +BYTE_SWAP_NOSWAP , +BYTE_SWAP_SWAP2 , +BYTE_SWAP_SWAP4 , +BYTE_SWAP_SWAP4HW +}; + +/* DC_WIN_POSITION 0x704 */ +#define H_POSITION_SHIFT 0 +#define H_POSITION_MASK (0x1FFF << H_POSITION_SHIFT) +#define V_POSITION_SHIFT 16 +#define V_POSITION_MASK (0x1FFF << V_POSITION_SHIFT) + +/* DC_WIN_SIZE 0x705 */ +#define H_SIZE_SHIFT 0 +#define H_SIZE_MASK (0x1FFF << H_SIZE_SHIFT) +#define V_SIZE_SHIFT 16 +#define V_SIZE_MASK (0x1FFF << V_SIZE_SHIFT) + +/* DC_WIN_PRESCALED_SIZE 0x706 */ +#define H_PRESCALED_SIZE_SHIFT 0 +#define H_PRESCALED_SIZE_MASK (0x7FFF << H_PRESCALED_SIZE) +#define V_PRESCALED_SIZE_SHIFT 16 +#define V_PRESCALED_SIZE_MASK (0x1FFF << V_PRESCALED_SIZE) + +/* DC_WIN_DDA_INCREMENT 0x709 */ +#define H_DDA_INC_SHIFT 0 +#define H_DDA_INC_MASK (0xFFFF << H_DDA_INC_SHIFT) +#define V_DDA_INC_SHIFT 16 +#define V_DDA_INC_MASK (0xFFFF << V_DDA_INC_SHIFT) + +#endif /* __ASM_ARCH_TEGRA_DC_H */ arch/arm/include/asm/arch-tegra2/display.h new file +152
-0@@ -0,0 +1,152 @@ +/* +* (C) Copyright 2010 +* NVIDIA Corporation <www.nvidia.com> +* +* See file CREDITS for list of people who contributed to this +* project. +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __ASM_ARCH_TEGRA_DISPLAY_H +#define __ASM_ARCH_TEGRA_DISPLAY_H + +#include <asm/arch-tegra2/dc.h> +#include <fdtdec.h> + +/* This holds information about a window which can be displayed */ +struct disp_ctl_win { +enum win_color_depth_id fmt;/* Color depth/format */ +unsigned bpp;/* Bits per pixel */ +phys_addr_t phys_addr;/* Physical address in memory */ +unsigned x;/* Horizontal address offset (bytes) */ +unsigned y;/* Veritical address offset (bytes) */ +unsigned w;/* Width of source window */ +unsigned h;/* Height of source window */ +unsigned stride;/* Number of bytes per line */ +unsigned out_x;/* Left edge of output window (col) */ +unsigned out_y;/* Top edge of output window (row) */ +unsigned out_w;/* Width of output window in pixels */ +unsigned out_h;/* Height of output window in pixels */ +}; + +#define FDT_LCD_TIMINGS 4 + +enum { +FDT_LCD_TIMING_REF_TO_SYNC , +FDT_LCD_TIMING_SYNC_WIDTH , +FDT_LCD_TIMING_BACK_PORCH , +FDT_LCD_TIMING_FRONT_PORCH , + +FDT_LCD_TIMING_COUNT , +}; + +enum lcd_cache_t { +FDT_LCD_CACHE_OFF =0 , +FDT_LCD_CACHE_WRITE_THROUGH =1 <<0 , +FDT_LCD_CACHE_WRITE_BACK =1 <<1 , +FDT_LCD_CACHE_FLUSH =1 <<2 , +FDT_LCD_CACHE_WRITE_BACK_FLUSH =FDT_LCD_CACHE_WRITE_BACK | +FDT_LCD_CACHE_FLUSH , +}; + +/* Information about the display controller */ +struct fdt_disp_config { +int valid;/* config is valid */ +int width;/* width in pixels */ +int height;/* height in pixels */ +int bpp;/* number of bits per pixel */ + +/* +* log2 of number of bpp, in general, unless it bpp is 24 in which +* case this field holds 24 also! This is a U-Boot thing. +*/ +int log2_bpp; +struct disp_ctlr *disp;/* Display controller to use */ +fdt_addr_t frame_buffer;/* Address of frame buffer */ +unsigned pixel_clock;/* Pixel clock in Hz */ +uint horiz_timing[FDT_LCD_TIMING_COUNT ];/* Horizontal timing */ +uint vert_timing[FDT_LCD_TIMING_COUNT ];/* Vertical timing */ +int panel_node;/* node offset of panel information */ +}; + +/* Information about the LCD panel */ +struct fdt_panel_config { +int pwm_channel;/* PWM channel to use for backlight */ +enum lcd_cache_t cache_type; + +struct fdt_gpio_state backlight_en;/* GPIO for backlight enable */ +struct fdt_gpio_state lvds_shutdown;/* GPIO for lvds shutdown */ +struct fdt_gpio_state backlight_vdd;/* GPIO for backlight vdd */ +struct fdt_gpio_state panel_vdd;/* GPIO for panel vdd */ +/* +* Panel required timings +* Timing 1: delay between panel_vdd-rise and data-rise +* Timing 2: delay between data-rise and backlight_vdd-rise +* Timing 3: delay between backlight_vdd and pwm-rise +* Timing 4: delay between pwm-rise and backlight_en-rise +*/ +uint panel_timings[FDT_LCD_TIMINGS ]; +}; + +/** +* Register a new display based on device tree configuration. +* +* The frame buffer can be positioned by U-Boot or overriden by the fdt. +* You should pass in the U-Boot address here, and check the contents of +* struct fdt_disp_config to see what was actually chosen. +* +* @param blob Device tree blob +* @param default_lcd_base Default address of LCD frame buffer +* @return 0 if ok, -1 on error (unsupported bits per pixel) +*/ +int tegra_display_probe (const void *blob,void *default_lcd_base); + +/** +* Return the current display configuration +* +* @return pointer to display configuration, or NULL if there is no valid +* config +*/ +struct fdt_disp_config *tegra_display_get_config (void ); + +/** +* Perform the next stage of the LCD init if it is time to do so. +* +* LCD init can be time-consuming because of the number of delays we need +* while waiting for the backlight power supply, etc. This function can +* be called at various times during U-Boot operation to advance the +* initialization of the LCD to the next stage if sufficient time has +* passed since the last stage. It keeps track of what stage it is up to +* and the time that it is permitted to move to the next stage. +* +* The final call should have wait=1 to complete the init. +* +* @param blob fdt blob containing LCD information +* @param wait 1 to wait until all init is complete, and then return +* 0 to return immediately, potentially doing nothing if it is +* not yet time for the next init. +*/ +int tegra_lcd_check_next_stage (const void *blob,int wait); + +/** +* Set up the maximum LCD size so we can size the frame buffer. +* +* @param blob fdt blob containing LCD information +*/ +void tegra_lcd_early_init (const void *blob); + +#endif /*__ASM_ARCH_TEGRA_DISPLAY_H*/ include/fdtdec.h +1
-0@@ -66,6 +66,7 @@ enum fdt_compat_id {COMPAT_NVIDIA_TEGRA20_EMC_TABLE ,/* Tegra2 memory timing table */ COMPAT_NVIDIA_TEGRA20_KBC ,/* Tegra2 Keyboard */ COMPAT_NVIDIA_TEGRA20_PWM ,/* Tegra 2 PWM controller */ +COMPAT_NVIDIA_TEGRA20_DC ,/* Tegra 2 Display controller */ COMPAT_COUNT, };lib/fdtdec.c +1
-1@@ -44,6 +44,7 @@ static const char * const compat_names[COMPAT_COUNT] = {COMPAT (NVIDIA_TEGRA20_EMC_TABLE ,"nvidia,tegra20-emc-table" ),COMPAT (NVIDIA_TEGRA20_KBC ,"nvidia,tegra20-kbc" ),COMPAT (NVIDIA_TEGRA20_PWM ,"nvidia,tegra20-pwm" ), + COMPAT(NVIDIA_TEGRA20_DC, "nvidia,tegra20-dc"), };const char *fdtdec_get_compatible (enum fdt_compat_id id) --1.7.7.3
Quoted 4 lines
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
PATCH v3 8/18 tegra: Add SOC support for display/lcd
Quoted 15 lines · On Thursday 19 July 2012 04:03:04 Adam Jiang wrote:
Quoted 2 lines · Simon Glass
+ /* Use a ref-to-sync of 1 always, and take this from the front
porch */ref-to-sync is supposed to be 1 here.
arch/arm/cpu/armv7/tegra2/display.c line 317
Quoted 8 lines
arch/arm/cpu/armv7/tegra2/display.c new file +8
-0+ back =fdtdec_get_int (blob, rgb,"left-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"right-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"hsync-len" ,-1 ); +if ((back | front | ref) ==-1 ) { +debug ("%s: Horizontal parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =11 ;
Quoted 1 line
It is assigned to 11.
when replying, please delete anything you aren't quoting. in this case, there was over 1000 lines of content that was just noise. it makes it hard to see what your responses are if you don't clip.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/464fa53e/attachment.pgp>
PATCH v3 8/18 tegra: Add SOC support for display/lcd
In reply to Adam JiangHi,
Quoted 40 lines · Adam Jiang
Quoted 20 lines · Simon Glass
From: Wei Ni <[email protected]>
Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.
Mayuresh Kulkarni:
- changes to remove bitfields and clean up for submissionSimon Glass:
- simplify code, move clock control into here, clean-upSigned-off-by Mayuresh Kulkarni <[email protected]>Signed-off-by Simon Glass <[email protected]>---
Changes in v3:
- Add probe function to read in fdt parameters in display driver
- Separate display driver and LCD driver more in fdtarch/arm/cpu/armv7/tegra2/display.c | 389 ++++++++++++++++++++arch/arm/cpu/armv7/tegra2/display.c line 309
Quoted 7 lines
arch/arm/cpu/armv7/tegra2/display.c new file +7
-0+if (!config->pixel_clock || bpp ==-1 || + config->width ==-1 || config->height ==-1 ) { +debug ("%s: Pixel parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + +/* Use a ref-to-sync of 1 always, and take this from the front porch */ ref-to-sync is supposed to be 1 here.
arch/arm/cpu/armv7/tegra2/display.c line 317
Quoted 8 lines
arch/arm/cpu/armv7/tegra2/display.c new file +8
-0+ back =fdtdec_get_int (blob, rgb,"left-margin" ,-1 ); + front =fdtdec_get_int (blob, rgb,"right-margin" ,-1 ); + ref =fdtdec_get_int (blob, rgb,"hsync-len" ,-1 ); +if ((back | front | ref) ==-1 ) { +debug ("%s: Horizontal parameters missing\n" , __func__); +return -FDT_ERR_NOTFOUND ; + } + config->horiz_timing[FDT_LCD_TIMING_REF_TO_SYNC ] =11 ;
Quoted 1 line
It is assigned to 11.
Thanks - have updated that.
Quoted 2 lines
/Adam
Regards,
Simon
PATCH v3 9/18 tegra: Add LCD driver
In reply to Simon GlassThis driver supports driving a single LCD and providing a U-Boot console on it.
---
Changes in v2:
- Update LCD driver to deal with new fdt bindings
Changes in v3:
- Adjust LCD driver to use new SOC display driver structures
- Move some fdt decode code from LCD driver to SOC display driver
- Rename fdt config structures
- Use new pwm binding from pre-linux-next
drivers/video/Makefile | 1 + drivers/video/tegra.c | 357 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 358 insertions(+), 0 deletions(-) create mode 100644 drivers/video/tegra.c
drivers/video/Makefile +1 -0
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o COBJS-$(CONFIG_VIDEO_SM501) += sm501.o COBJS-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o +COBJS-$(CONFIG_VIDEO_TEGRA) += tegra.o COBJS-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o COBJS := $(sort $(COBJS-y))
drivers/video/tegra.c new file +357 -0
357 lines not on this page · raw message
Signature · 1 line
1.7.7.3
PATCH v3 9/18 tegra: Add LCD driver
Quoted 19 lines · Simon Glass
This driver supports driving a single LCD and providing a U-Boot console on it.
Signed-off-by Simon Glass <[email protected]>---
Changes in v2:
- Update LCD driver to deal with new fdt bindingsChanges in v3:
- Adjust LCD driver to use new SOC display driver structures
- Move some fdt decode code from LCD driver to SOC display driver
- Rename fdt config structures
- Use new pwm binding from pre-linux-nextdrivers/video/Makefile | 1 + drivers/video/tegra.c | 357 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 358 insertions(+), 0 deletions(-) create mode 100644 drivers/video/tegra.c
[...]
Quoted 1 line
drivers/video/tegra.c +0
-0
[...]
Quoted 27 lines
drivers/video/tegra.c +27
-0+static int fdt_decode_lcd (const void *blob,struct fdt_panel_config *config) +{ +int err; +int display_node; + + disp_config =tegra_display_get_config (); +if (!disp_config) { +debug ("%s: Display controller is not configured\n" , __func__); +return -1 ; + } + display_node = disp_config->panel_node; +if (display_node <0 ) { +debug ("%s: No panel configuration available\n" , __func__); +return -1 ; + } + + config->pwm_channel =pwm_request (blob, display_node,"nvidia,pwm" ); +if (config->pwm_channel <0 ) { +debug ("%s: Unable to request PWM channel\n" , __func__); +return -1 ; + } + + config->cache_type =fdtdec_get_int (blob, display_node, +"nvidia,cache-type" , +FDT_LCD_CACHE_WRITE_BACK_FLUSH ); + + err = fdtdec_decode_gpio(blob, display_node,
drivers/video/tegra.c line 230
Quoted 10 lines
drivers/video/tegra.c +10
-0+"nvidia,backlight-enable-gpios" , + &config->backlight_en); + err |=fdtdec_decode_gpio (blob, display_node, +"nvidia,lvds-shutdown-gpios" , &config->lvds_shutdown); +fdtdec_decode_gpio (blob, display_node,"nvidia,backlight-vdd-gpios" , + &config->backlight_vdd); + err |=fdtdec_decode_gpio (blob, display_node,"nvidia,panel-vdd-gpios" , + &config->panel_vdd); +if (err) +return -FDT_ERR_NOTFOUND ;
This effectively makes those GPIOs mandatory. The Medcom, however, doesn't have any of these, so I had to comment this return out to test the series. I know that this might be an unusual setup, but it's something that needs to be supported anyway.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/59692bf3/attachment.pgp>
PATCH v3 9/18 tegra: Add LCD driver
Hi Thierry,
Quoted 57 lines · Thierry Reding
Quoted 19 lines · Simon Glass
This driver supports driving a single LCD and providing a U-Boot console on it.
Signed-off-by Simon Glass <[email protected]>---
Changes in v2:
- Update LCD driver to deal with new fdt bindingsChanges in v3:
- Adjust LCD driver to use new SOC display driver structures
- Move some fdt decode code from LCD driver to SOC display driver
- Rename fdt config structures
- Use new pwm binding from pre-linux-nextdrivers/video/Makefile | 1 + drivers/video/tegra.c | 357 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 358 insertions(+), 0 deletions(-) create mode 100644 drivers/video/tegra.c[...]
Quoted 1 line
drivers/video/tegra.c +0
-0[...]
Quoted 34 lines
drivers/video/tegra.c +34
-0+static int fdt_decode_lcd (const void *blob,struct fdt_panel_config *config) +{ +int err; +int display_node; + + disp_config =tegra_display_get_config (); +if (!disp_config) { +debug ("%s: Display controller is not configured\n" , __func__); +return -1 ; + } + display_node = disp_config->panel_node; +if (display_node <0 ) { +debug ("%s: No panel configuration available\n" , __func__); +return -1 ; + } + + config->pwm_channel =pwm_request (blob, display_node,"nvidia,pwm" ); +if (config->pwm_channel <0 ) { +debug ("%s: Unable to request PWM channel\n" , __func__); +return -1 ; + } + + config->cache_type =fdtdec_get_int (blob, display_node, +"nvidia,cache-type" , +FDT_LCD_CACHE_WRITE_BACK_FLUSH ); + + err =fdtdec_decode_gpio (blob, display_node, +"nvidia,backlight-enable-gpios" , + &config->backlight_en); + err |=fdtdec_decode_gpio (blob, display_node, +"nvidia,lvds-shutdown-gpios" , &config->lvds_shutdown); +fdtdec_decode_gpio (blob, display_node,"nvidia,backlight-vdd-gpios" , + &config->backlight_vdd); + err |= fdtdec_decode_gpio(blob, display_node, "nvidia,panel-vdd-gpios",
Quoted 8 lines
drivers/video/tegra.c line 230
Quoted 3 lines
drivers/video/tegra.c +3
-0+ &config->panel_vdd); +if (err) +return -FDT_ERR_NOTFOUND ;This effectively makes those GPIOs mandatory. The Medcom, however, doesn't have any of these, so I had to comment this return out to test the series. I know that this might be an unusual setup, but it's something that needs to be supported anyway.
I am taking another look at this. I will make these GPIOs optional.
Regards,
Simon
Quoted 2 lines
Thierry
PATCH v3 10/18 tegra: Add LCD support to Nvidia boards
In reply to Simon GlassAdd calls to the LCD driver from Nvidia board code.
---
Changes in v3:
- Add separate call to pwm_init() in board_init()
board/nvidia/common/board.c | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
board/nvidia/common/board.c +23 -1
@@ -29,12 +29,14 @@#include <asm/arch/sys_proto.h> #include <asm/arch/board.h> +#include <asm/arch/display.h> #include <asm/arch/clk_rst.h> #include <asm/arch/clock.h> #include <asm/arch/emc.h> #include <asm/arch/pinmux.h> #include <asm/arch/pmc.h> #include <asm/arch/pmu.h> +#include <asm/arch/pwm.h> #include <asm/arch/uart.h> #include <asm/arch/warmboot.h> #include <spi.h>
@@ -93,6 +95,9 @@ int board_init(void) {__maybe_unused int err; +#ifdef CONFIG_VIDEO_TEGRA2 +tegra_lcd_check_next_stage (gd->blob,0 ); +#endif /* Do clocks and UART first so that printf() works */ clock_init ();clock_verify ();
@@ -129,6 +134,11 @@ int board_init(void)pin_mux_usb ();board_usb_init (gd->fdt_blob);#endif +#if defined(CONFIG_VIDEO_TEGRA ) +if (pwm_init (gd->fdt_blob)) +debug ("%s: Failed to init pwm\n" , __func__); +tegra_lcd_check_next_stage (gd->fdt_blob,0 ); +#endif #ifdef CONFIG_TEGRA2_LP0 /* prepare the WB code to LP0 location */
@@ -156,6 +166,18 @@ int board_early_init_f(void)#else gpio_config_uart ();#endif - return 0; +#if defined(CONFIG_VIDEO_TEGRA ) +tegra_lcd_early_init (gd->fdt_blob); +#endif +return 0; }#endif /* EARLY_INIT */ + +int board_late_init (void ) +{ +#ifdef CONFIG_VIDEO_TEGRA +/* Make sure we finish initing the LCD */ +tegra_lcd_check_next_stage (gd->fdt_blob,1 ); +#endif +return 0 ; +}
Signature · 1 line
1.7.7.3
PATCH v3 11/18 arm: Add control over cachability of memory regions
In reply to Simon GlassAdd support for adjusting the cachability of an L1 section by updating the MMU. The mmu_set_region_dcache() function allows drivers to make these changes after the MMU is set up.
It is implemented only for ARMv7 at present.
This is needed for LCD support, where we want to make the LCD frame buffer write-through (or off) rather than write-back.
---
arch/arm/cpu/armv7/cache_v7.c | 11 +++++++ arch/arm/include/asm/system.h | 30 ++++++++++++++++++++ arch/arm/lib/cache-cp15.c | 62 +++++++++++++++++++++++++++++++++------- 3 files changed, 92 insertions(+), 11 deletions(-)
arch/arm/cpu/armv7/cache_v7.c +11 -0
@@ -297,6 +297,12 @@ void arm_init_before_mmu(void)v7_inval_tlb (); } +void mmu_page_table_flush (unsigned long start,unsigned long stop) +{ +flush_dcache_range (start, stop); +v7_inval_tlb (); +} +/* * Flush range from all levels of d-cache/unified-cache used: * Affects the range [start, start + size - 1]
@@ -329,6 +335,11 @@ void arm_init_before_mmu(void)void flush_cache (unsigned long start,unsigned long size) { } + +void mmu_page_table_flush (unsigned long start,unsigned long stop) +{ +} +#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */ #ifndef CONFIG_SYS_ICACHE_OFF
arch/arm/include/asm/system.h +30 -0
@@ -75,6 +75,36 @@ static inline void set_cr(unsigned int val) isb(); } +/* options available for data cache on each page */ +enum dcache_option { +DCACHE_OFF , +DCACHE_WRITETHROUGH , +DCACHE_WRITEBACK , +}; + +/* Size of an MMU section */ +enum { +MMU_SECTION_SHIFT =20 , +MMU_SECTION_SIZE =1 <<MMU_SECTION_SHIFT , +}; + +/** +* Change the cache settings for a region. +* +* \param start start address of memory region to change +* \param size size of memory region to change +* \param option dcache option to select +*/ +void mmu_set_region_dcache (u32 start,int size,enum dcache_option option); + +/** +* Register an update to the page tables, and flush the TLB +* +* \param start start address of update in page table +* \param stop stop address of update in page table +*/ +void mmu_page_table_flush (unsigned long start,unsigned long stop); +#endif /* __ASSEMBLY__ */ #define arch_align_stack (x) (x)
arch/arm/lib/cache-cp15.c +51 -11
100 lines not on this page · raw message
Signature · 1 line
1.7.7.3
PATCH v3 11/18 arm: Add control over cachability of memory regions
Hi Simon,
Quoted 117 lines · Simon Glass
Add support for adjusting the cachability of an L1 section by updating the MMU. The
mmu_set_region_dcache()function allows drivers to make these changes after the MMU is set up.It is implemented only for ARMv7 at present.
This is needed for LCD support, where we want to make the LCD frame buffer write-through (or off) rather than write-back.
Signed-off-by Simon Glass <[email protected]>---
arch/arm/cpu/armv7/cache_v7.c | 11 +++++++ arch/arm/include/asm/system.h | 30 ++++++++++++++++++++ arch/arm/lib/cache-cp15.c | 62 +++++++++++++++++++++++++++++++++------- 3 files changed, 92 insertions(+), 11 deletions(-)arch/arm/cpu/armv7/cache_v7.c +11
-0@@ -297,6 +297,12 @@ void arm_init_before_mmu(void)v7_inval_tlb (); } +void mmu_page_table_flush (unsigned long start,unsigned long stop) +{ +flush_dcache_range (start, stop); +v7_inval_tlb (); +} +/* * Flush range from all levels of d-cache/unified-cache used: * Affects the range [start, start + size - 1] @@ -329,6 +335,11 @@ void arm_init_before_mmu(void)void flush_cache (unsigned long start,unsigned long size) { } + +void mmu_page_table_flush (unsigned long start,unsigned long stop) +{ +} +#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */ #ifndef CONFIG_SYS_ICACHE_OFF arch/arm/include/asm/system.h +30
-0@@ -75,6 +75,36 @@ static inline void set_cr(unsigned int val) isb(); } +/* options available for data cache on each page */ +enum dcache_option { +DCACHE_OFF , +DCACHE_WRITETHROUGH , +DCACHE_WRITEBACK , +}; + +/* Size of an MMU section */ +enum { +MMU_SECTION_SHIFT =20 , +MMU_SECTION_SIZE =1 <<MMU_SECTION_SHIFT , +}; + +/** +* Change the cache settings for a region. +* +* \param start start address of memory region to change +* \param size size of memory region to change +* \param option dcache option to select +*/ +void mmu_set_region_dcache (u32 start,int size,enum dcache_option option); + +/** +* Register an update to the page tables, and flush the TLB +* +* \param start start address of update in page table +* \param stop stop address of update in page table +*/ +void mmu_page_table_flush (unsigned long start,unsigned long stop); +#endif /* __ASSEMBLY__ */ #define arch_align_stack (x) (x)arch/arm/lib/cache-cp15.c +6
-7@@ -26,12 +26,6 @@#if !(defined(CONFIG_SYS_ICACHE_OFF ) && defined(CONFIG_SYS_DCACHE_OFF )) -#if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH ) -#define CACHE_SETUP 0x1a -#else -#define CACHE_SETUP 0x1e -#endif -DECLARE_GLOBAL_DATA_PTR ;void __arm_init_before_mmu (void )@@ -50,9 +44,52 @@ static void cp_delay (void) asmvolatile ("" : : :"memory" ); } -static inline void dram_bank_mmu_setup (int bank) +void set_section_dcache (int section,enum dcache_option option) { +u32 value = section <<MMU_SECTION_SHIFT | (3 <<10 );u32 *page_table = (u32 *)gd->tlb_addr; + +switch (option) { +case DCACHE_WRITETHROUGH : + value |=0x1a ;
arch/arm/lib/cache-cp15.c static void cp_delay (void) · line 64
Quoted 10 lines
arch/arm/lib/cache-cp15.c +10
-0+break ; + +case DCACHE_WRITEBACK : + value |=0x1e ; +break ; + +case DCACHE_OFF : + value |=0x12 ; +break ; + }
what's the benefit of introducing an arbitrary enum rather than defining DCACHE_WRITETHROUGH, DCACHE_WRITEBACK and DCACHE_OFF equal respecitvely to 0x1a, 0x1e and 0x12? All it does is force this switch case instead of a simple 'value |= option;' statement.
Quoted 59 lines
arch/arm/lib/cache-cp15.c +33
-3+ page_table[section] = value; +} + +void __mmu_page_table_flush (unsigned long start,unsigned long stop) +{ +debug ("%s: Warning: not implemented\n" , __func__); +} + +void mmu_page_table_flush (unsigned long start,unsigned long stop) + __attribute__((weak,alias ("__mmu_page_table_flush" ))); + +void mmu_set_region_dcache (u32 start,int size,enum dcache_option option) +{ +u32 *page_table = (u32 *)gd->tlb_addr; +u32 upto, end; + + end =ALIGN (start + size,MMU_SECTION_SIZE ) >>MMU_SECTION_SHIFT ; + start = start >>MMU_SECTION_SHIFT ; +debug ("mmu_set_region_dcache start=%x, size=%x, option=%d\n" , + start, size, option); +for (upto = start; upto < end; upto++) +set_section_dcache (upto, option); +mmu_page_table_flush ((u32)&page_table[start], (u32)&page_table[end]); +} + +static inline void dram_bank_mmu_setup (int bank) +{bd_t *bd = gd->bd;int i;@@ -60,21 +97,24 @@ static inline void dram_bank_mmu_setup(int bank)for (i = bd->bi_dram[bank].start >>20 ; i < (bd->bi_dram[bank].start + bd->bi_dram[bank].size) >>20 ; i++) { - page_table[i] = i <<20 | (3 <<10 ) |CACHE_SETUP ; +#if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH ) +set_section_dcache (i,DCACHE_WRITETHROUGH ); +#else +set_section_dcache (i,DCACHE_WRITEBACK ); +#endif } }/* to activate the MMU we need to set up virtual memory: use 1M areas */ static inline void mmu_setup (void ) { -u32 *page_table = (u32 *)gd->tlb_addr;int i;u32 reg;arm_init_before_mmu ();/* Set up an identity-mapping for all 4GB, rw for everyone */ for (i =0 ; i <4096 ; i++) - page_table[i] = i <<20 | (3 <<10 ) |0x12 ; +set_section_dcache (i,DCACHE_OFF );for (i =0 ; i <CONFIG_NR_DRAM_BANKS ; i++) {dram_bank_mmu_setup (i);
arch/arm/lib/cache-cp15.c static inline void mmu_setup(void) · line 128
Quoted 8 lines
arch/arm/lib/cache-cp15.c +1
-1@@ -82,7 +122,7 @@ static inline void mmu_setup(void)/* Copy the page table address to cp15 */ asmvolatile ("mcr p15, 0, %0, c2, c0, 0" - : :"r" (page_table) :"memory" ); + : :"r" (gd->tlb_addr) :"memory" );/* Set the access control to all-supervisor */ asmvolatile ("mcr p15, 0, %0, c3, c0, 0" : :"r" (~0 ));
Amicalement,
Signature · 1 line
Albert.
PATCH v3 11/18 arm: Add control over cachability of memory regions
Quoted 30 lines · On Thursday 12 July 2012 14:12:41 Albert ARIBAUD wrote:
Quoted 29 lines · Simon Glass
arch/arm/include/asm/system.h +6
-0+/* options available for data cache on each page */ +enum dcache_option { +DCACHE_OFF , +DCACHE_WRITETHROUGH , +DCACHE_WRITEBACK , +};arch/arm/lib/cache-cp15.c +13
-1-static inline void dram_bank_mmu_setup (int bank) +void set_section_dcache (int section,enum dcache_option option) { +u32 value = section <<MMU_SECTION_SHIFT | (3 <<10 );u32 *page_table = (u32 *)gd->tlb_addr; + +switch (option) { +case DCACHE_WRITETHROUGH : + value |=0x1a ; +break ; + +case DCACHE_WRITEBACK : + value |=0x1e ; +break ; + +case DCACHE_OFF :
Quoted 8 lines
arch/arm/lib/cache-cp15.c static void cp_delay (void) · line 64
Quoted 3 lines
arch/arm/lib/cache-cp15.c +3
-0+ value |=0x12 ; +break ; + }what's the benefit of introducing an arbitrary enum rather than defining
DCACHE_WRITETHROUGH,DCACHE_WRITEBACKandDCACHE_OFFequal respecitvely to0x1a,0x1eand0x12? All it does is force this switch case instead of a simple 'value |= option;' statement.
if these magic bitmasks are going to be the same for all arm cores (the enum is in common arm header), then you can get the advantages of both:
enum dcache_option {
DCACHE_OFF = 0x12,
DCACHE_WRITETHROUGH = 0x1a,
DCACHE_WRITEBACK = 0x1e,
};then just do:
value |= option;
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/e7c46fe8/attachment.pgp>
PATCH v3 11/18 arm: Add control over cachability of memory regions
Hi Albert and Mike,
Quoted 42 lines · Mike Frysinger
Quoted 30 lines · On Thursday 12 July 2012 14:12:41 Albert ARIBAUD wrote:
Quoted 29 lines · Simon Glass
arch/arm/include/asm/system.h +6
-0+/* options available for data cache on each page */ +enum dcache_option { +DCACHE_OFF , +DCACHE_WRITETHROUGH , +DCACHE_WRITEBACK , +};arch/arm/lib/cache-cp15.c +13
-1-static inline void dram_bank_mmu_setup (int bank) +void set_section_dcache (int section,enum dcache_option option) { +u32 value = section <<MMU_SECTION_SHIFT | (3 <<10 );u32 *page_table = (u32 *)gd->tlb_addr; + +switch (option) { +case DCACHE_WRITETHROUGH : + value |=0x1a ; +break ; + +case DCACHE_WRITEBACK : + value |=0x1e ; +break ; + +case DCACHE_OFF :Quoted 8 lines
arch/arm/lib/cache-cp15.c static void cp_delay (void) · line 64
Quoted 3 lines
arch/arm/lib/cache-cp15.c +3
-0+ value |=0x12 ; +break ; + }what's the benefit of introducing an arbitrary enum rather than defining
DCACHE_WRITETHROUGH,DCACHE_WRITEBACKandDCACHE_OFFequal respecitvely to0x1a,0x1eand0x12? All it does is force this switch case instead of a simple 'value |= option;' statement.if these magic bitmasks are going to be the same for all arm cores (the enum is in common arm header), then you can get the advantages of both:
Quoted 8 lines
enum dcache_option { DCACHE_OFF = 0x12, DCACHE_WRITETHROUGH = 0x1a, DCACHE_WRITEBACK = 0x1e, };then just do:
value |= option;
Yes you are both saying the same thing - sounds good. I will change it.
Regards,
Simon
Quoted 1 line
-mike
PATCH v3 12/18 lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
In reply to Simon GlassThe normal alignment is PAGE_SIZE, but if this is defined, we can support other alignments.
The motivation for this change is to make the display section-aligned on ARM so that we can easily turn off data caching for the frame buffer region without resorting to level 2 page tables.
---
Changes in v2:
- Use a more generic config CONFIG_LCD_ALIGNMENT for lcd alignment
README | 10 ++++++++++ common/lcd.c | 24 +++++++++++++++++++----- include/lcd.h | 3 +++ 3 files changed, 32 insertions(+), 5 deletions(-)
README +10 -0
@@ -1407,6 +1407,16 @@ The following options need to be configured: Normally display is black on white background; define CONFIG_SYS_WHITE_ON_BLACK to get it inverted. + + CONFIG_LCD_ALIGNMENT + + Normally the LCD is page-aligned (tyically 4KB). If this is + defined then the LCD will be aligned to this value instead. + For ARM it is sometimes useful to use MMU_SECTION_SIZE + here, since it is cheaper to change data cache settings on + a per-section basis. + + - Splash Screen Support: CONFIG_SPLASH_SCREEN If this option is set, the environment is checked for
common/lcd.c +19 -5
@@ -35,6 +35,9 @@#include <stdarg.h> #include <linux/types.h> #include <stdio_dev.h> +#ifdef CONFIG_ARM +#include <asm/system.h> +#endif #if defined(CONFIG_POST )#include <post.h> #endif
@@ -72,6 +75,10 @@# endif #endif +#ifndef CONFIG_LCD_ALIGNMENT +#define CONFIG_LCD_ALIGNMENT PAGE_SIZE +#endif +DECLARE_GLOBAL_DATA_PTR ;ulong lcd_setmem (ulong addr);
@@ -326,6 +333,12 @@ static void test_pattern (void)/* ** GENERIC Initialization Routines */ /************************************************************************/ +int lcd_get_size (int *line_length) +{ + *line_length = (panel_info.vl_col *NBITS (panel_info.vl_bpix)) /8 ; +return *line_length * panel_info.vl_row; +} +int drv_lcd_init (void ) {struct stdio_dev lcddev;
@@ -333,7 +346,7 @@ int drv_lcd_init (void) lcd_base = (void *)(gd->fb_base); - lcd_line_length = (panel_info.vl_col *NBITS (panel_info.vl_bpix)) /8 ; +lcd_get_size (&lcd_line_length);lcd_init (lcd_base);/* LCD initialization */
@@ -445,15 +458,16 @@ static int lcd_init (void *lcdbase)ulong lcd_setmem (ulong addr) {ulong size; -int line_length = (panel_info.vl_col *NBITS (panel_info.vl_bpix)) /8 ; +int line_length;debug ("LCD panel info: %d x %d, %d bit/pix\n" , panel_info.vl_col, panel_info.vl_row,NBITS (panel_info.vl_bpix) ); - size = line_length * panel_info.vl_row; + size =lcd_get_size (&line_length); -/* Round up to nearest full page */ - size = (size + (PAGE_SIZE -1 )) & ~(PAGE_SIZE -1 ); +/* Round up to nearest full page, or MMU section if defined */ + size =ALIGN (size,CONFIG_LCD_ALIGNMENT ); + addr =ALIGN (addr -CONFIG_LCD_ALIGNMENT +1 ,CONFIG_LCD_ALIGNMENT );/* Allocate pages for the frame buffer. */ addr -= size;
include/lcd.h +3 -0
@@ -296,6 +296,9 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y);/* Allow boards to customize the information displayed */ void lcd_show_board_info (void ); +/* Return the size of the LCD frame buffer, and the line length */ +int lcd_get_size (int *line_length); +/************************************************************************/ /* ** BITMAP DISPLAY SUPPORT */ /************************************************************************/
Signature · 1 line
1.7.7.3
PATCH v3 12/18 lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
common/lcd.c line 40
Quoted 6 lines · On Thursday 12 July 2012 11:25:12 Simon Glass wrote:
common/lcd.c +3
-0+#ifdef CONFIG_ARM +#include <asm/system.h> +#endif
this header isn't ARM specific. also, i think most arches just include this in their "main" points rather than any non-arch places including it explicitly. -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/e9cd97b0/attachment.pgp>
PATCH v3 12/18 lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
Hi Mike,
Quoted 10 lines · Mike Frysinger
common/lcd.c line 40
Quoted 6 lines · On Thursday 12 July 2012 11:25:12 Simon Glass wrote:
common/lcd.c +3
-0+#ifdef CONFIG_ARM +#include <asm/system.h> +#endif this header isn't ARM specific. also, i think most arches just include this in their "main" points rather than any non-arch places including it explicitly.
Yes, I will remove this, thanks.
Quoted 1 line
-mike
Regards,
SImon
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
In reply to Simon GlassThis provides an option for the LCD to flush the dcache after each update (puts, scroll or clear).
---
Changes in v2:
- Put the LCD cache flush logic into lcd_putc() instead of lcd_puts()
Changes in v3:
- Put the LCD cache flush logic back into lcd_puts()
common/lcd.c | 46 +++++++++++++++++++++++++++++++++++++++------- include/lcd.h | 8 ++++++++ 2 files changed, 47 insertions(+), 7 deletions(-)
common/lcd.c +39 -7
@@ -97,6 +97,9 @@ static void lcd_setbgcolor (int color);char lcd_is_enabled =0 ; +static char lcd_flush_dcache;/* 1 to flush dcache after each lcd update */ + +#ifdef NOT_USED_SO_FAR static void lcd_getcolreg (ushort regno,ushort *red,ushort *green,ushort *blue);
@@ -105,6 +108,28 @@ static int lcd_getfgcolor (void);/************************************************************************/ +/* Flush LCD activity to the caches */ +void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some +* architectures do not actually implement it. Is there a way to find +* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) +flush_dcache_range ((u32 )lcd_base, + (u32)(lcd_base +lcd_get_size (&line_length))); +#endif +} + +void lcd_set_flush_dcache (int flush) +{ + lcd_flush_dcache = (flush !=0 ); +} +/*----------------------------------------------------------------------*/ static void console_scrollup (void )
@@ -114,6 +139,7 @@ static void console_scrollup (void)/* Clear the last one */ memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +lcd_sync (); }/*----------------------------------------------------------------------*/
@@ -144,6 +170,8 @@ static inline void console_newline (void)/* Scroll everything up */ console_scrollup () ; --console_row; + }else { +lcd_sync (); } }
@@ -198,6 +226,7 @@ void lcd_puts (const char *s)while (*s) {lcd_putc (*s++); } +lcd_sync (); }/*----------------------------------------------------------------------*/
@@ -365,13 +394,6 @@ int drv_lcd_init (void) }/*----------------------------------------------------------------------*/ -static -int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) -{ -lcd_clear (); -return 0 ; -} -void lcd_clear (void ) {#if LCD_BPP ==LCD_MONOCHROME
@@ -413,6 +435,14 @@ void lcd_clear(void) console_col =0 ; console_row =0 ; +lcd_sync (); +} + +static int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc, +char *const argv[]) +{ +lcd_clear (); +return 0 ; } U_BOOT_CMD(
@@ -607,6 +637,7 @@ void bitmap_plot (int x, int y) }WATCHDOG_RESET (); +lcd_sync (); }#else static inline void bitmap_plot (int x,int y) {}
@@ -820,6 +851,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) break; }; +lcd_sync ();return (0 ); }#endif
include/lcd.h +8 -0
@@ -57,6 +57,14 @@ extern void lcd_initcolregs (void);extern struct bmp_image *gunzip_bmp (unsigned long addr,unsigned long *lenp);extern int bmp_display (ulong addr,int x,int y); +/** +* Set whether we need to flush the dcache when changing the LCD image. This +* defaults to off. +* +* @param flush non-zero to flush cache after update, 0 to skip +*/ +void lcd_set_flush_dcache (int flush); +#if definedCONFIG_MPC823 /* * LCD controller stucture for MPC823 CPU
Signature · 1 line
1.7.7.3
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Quoted 9 lines · On Thursday 12 July 2012 11:25:13 Simon Glass wrote:
common/lcd.c +6
-0+/* Flush LCD activity to the caches */ +void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some +* architectures do not actually implement it. Is there a way to find
common/lcd.c static int lcd_getfgcolor (void); · line 126
Quoted 10 lines
common/lcd.c +10
-0+* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) +flush_dcache_range ((u32 )lcd_base, + (u32)(lcd_base +lcd_get_size (&line_length))); +#endif +}
we should just let those people build fail imo so they'll be forced to add this
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/7d261710/attachment.pgp>
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
In reply to Simon GlassQuoted 5 lines · On Thursday 12 July 2012 11:25:13 Simon Glass wrote:
common/lcd.c +5
-0+void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some +* architectures do not actually implement it. Is there a way to find
common/lcd.c static int lcd_getfgcolor (void); · line 126
Quoted 10 lines
common/lcd.c +10
-0+* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) +flush_dcache_range ((u32 )lcd_base, + (u32)(lcd_base +lcd_get_size (&line_length))); +#endif +}
hmm, i think this should be more fine grained
common/lcd.c static void console_scrollup (void) · line 143
Quoted 4 lines
common/lcd.c +1
-0/* Clear the last one */ memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +lcd_sync (); }
this requires only updating one row and not the entire display right ? so we should only flush that one line. seems like other parts suffer similar over- flushing behavior.
Quoted 3 lines
+/**
+ * Set whether we need to flush the dcache when changing the LCD image.
+ * This defaults to off.
i wonder if this default is correct. perhaps it should default to 1 since setting up custom memory maps to disable cache is fairly specially.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/fbbd86f2/attachment.pgp>
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
In reply to Simon GlassHi Simon,
Quoted 49 lines
This provides an option for the LCD to flush the dcache after each update (puts, scroll or clear).
Signed-off-by Simon Glass <[email protected]>---
Changes in v2:
- Put the LCD cache flush logic intolcd_putc()instead oflcd_puts()Changes in v3:
- Put the LCD cache flush logic back intolcd_puts()common/lcd.c | 46 +++++++++++++++++++++++++++++++++++++++------- include/lcd.h | 8 ++++++++ 2 files changed, 47 insertions(+), 7 deletions(-)common/lcd.c +1
-0@@ -97,6 +97,9 @@ static void lcd_setbgcolor (int color);char lcd_is_enabled =0 ; +static char lcd_flush_dcache;/* 1 to flush dcache after each lcd update */ +
common/lcd.c +1
-0+#ifdef NOT_USED_SO_FAR static void lcd_getcolreg (ushort regno, ushort *red, ushort *green, ushort*blue); @@ -105,6 +108,28 @@ static int
lcd_getfgcolor(void);/************************************************************************/
common/lcd.c +5
-0+/* Flush LCD activity to the caches */ +void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some
common/lcd.c +1
-0+* architectures do not actually implement it. Is there a way to find
common/lcd.c +8
-0+* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) + flush_dcache_range((u32)lcd_base, + (u32)(lcd_base +
Quoted 1 line
lcd_get_size(&line_length))); +#endif
I'm struggling with a similar problem - but not in console putc, but at lcd_display_bitmap().
The solution (in mine case) is:
flush_dcache_range((unsigned long) fb,
(unsigned long) fb + (lcd_line_length * height));
which takes the "real" image range (as it is defined by fb).
Flushing the lcd_base based range is a bit overkill for me.
common/lcd.c static int lcd_getfgcolor (void); · line 132
Quoted 7 lines
common/lcd.c +7
-0+} + +void lcd_set_flush_dcache (int flush) +{ + lcd_flush_dcache = (flush !=0 ); +} +
I'm wondering if this flush_dcache_range cannot be added directly to relevant places in the code?
flush_dcache_* calls are either defined (for a relevant - cache aware archs) or are dummy.
Quoted 90 lines
/*----------------------------------------------------------------------*/
static void
console_scrollup(void)common/lcd.c +1
-0@@ -114,6 +139,7 @@ static void console_scrollup (void)/* Clear the last one */ memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +lcd_sync (); }/*----------------------------------------------------------------------*/
common/lcd.c +13
-6@@ -144,6 +170,8 @@ static inline void console_newline (void)/* Scroll everything up */ console_scrollup () ; --console_row; + }else { +lcd_sync (); } }@@ -198,6 +226,7 @@ void lcd_puts (const char *s)while (*s) {lcd_putc (*s++); } +lcd_sync (); }/*----------------------------------------------------------------------*/ @@ -365,13 +394,6 @@ int drv_lcd_init (void) }/*----------------------------------------------------------------------*/ -static -int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) -{ -lcd_clear (); -return 0 ; -} -void lcd_clear (void ) {#if LCD_BPP ==LCD_MONOCHROME @@ -413,6 +435,14 @@ void lcd_clear(void) console_col =0 ; console_row =0 ; +lcd_sync (); +} + +static int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc, +char *const argv[]) +{ +lcd_clear (); +return 0 ; } U_BOOT_CMD(@@ -607,6 +637,7 @@ void bitmap_plot (int x, int y) }WATCHDOG_RESET (); +lcd_sync (); }#else static inline void bitmap_plot (int x,int y) {}@@ -820,6 +851,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) break; }; +lcd_sync ();return (0 ); }#endif include/lcd.h +2
-0@@ -57,6 +57,14 @@ extern void lcd_initcolregs (void);extern struct bmp_image *gunzip_bmp (unsigned long addr,unsigned long *lenp);extern int bmp_display (ulong addr,int x,int y); +/** +* Set whether we need to flush the dcache when changing the LCD image. This
+ * defaults to off.
+ *
+ * @param flush non-zero to flush cache after update,
0 to skip
+ */
include/lcd.h extern void lcd_initcolregs (void); · line 70
Quoted 5 lines
include/lcd.h +2
-0+void lcd_set_flush_dcache (int flush); +#if definedCONFIG_MPC823 /* * LCD controller stucture for MPC823 CPU
Anyway, I'm looking forward for v4 version of this patch.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Hi,
Quoted 160 lines · Lukasz Majewski
Hi Simon,
Quoted 49 lines
This provides an option for the LCD to flush the dcache after each update (puts, scroll or clear).
Signed-off-by Simon Glass <[email protected]>---
Changes in v2:
- Put the LCD cache flush logic intolcd_putc()instead oflcd_puts()Changes in v3:
- Put the LCD cache flush logic back intolcd_puts()common/lcd.c | 46 +++++++++++++++++++++++++++++++++++++++------- include/lcd.h | 8 ++++++++ 2 files changed, 47 insertions(+), 7 deletions(-)common/lcd.c +1
-0@@ -97,6 +97,9 @@ static void lcd_setbgcolor (int color);char lcd_is_enabled =0 ; +static char lcd_flush_dcache;/* 1 to flush dcache after each lcd update */ +
+
#ifdefNOT_USED_SO_FAR
static voidlcd_getcolreg(ushort regno,
ushort *red, ushort *green, ushort
*blue); @@ -105,6 +108,28 @@ static intlcd_getfgcolor(void);/************************************************************************/
common/lcd.c +5
-0+/* Flush LCD activity to the caches */ +void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some
+ * architectures do not actually implement it. Is there a
way to findcommon/lcd.c +8
-0+* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) + flush_dcache_range((u32)lcd_base, + (u32)(lcd_base +Quoted 1 line
lcd_get_size(&line_length))); +#endifI'm struggling with a similar problem - but not in console putc, but at
lcd_display_bitmap().The solution (in mine case) is:
flush_dcache_range((unsigned long) fb,
(unsigned long) fb + (lcd_line_length* height));
which takes the "real" image range (as it is defined by fb).Flushing the
lcd_basebased range is a bit overkill for me.common/lcd.c static int lcd_getfgcolor (void); · line 132
Quoted 7 lines
common/lcd.c +7
-0+} + +void lcd_set_flush_dcache (int flush) +{ + lcd_flush_dcache = (flush !=0 ); +} +I'm wondering if this
flush_dcache_rangecannot be added directly to relevant places in the code?flush_dcache_* calls are either defined (for a relevant - cache aware archs) or are dummy.
Quoted 82 lines
/*----------------------------------------------------------------------*/
static void
console_scrollup(void)common/lcd.c +1
-0@@ -114,6 +139,7 @@ static void console_scrollup (void)/* Clear the last one */ memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +lcd_sync (); }/*----------------------------------------------------------------------*/
common/lcd.c +13
-6@@ -144,6 +170,8 @@ static inline void console_newline (void)/* Scroll everything up */ console_scrollup () ; --console_row; + }else { +lcd_sync (); } }@@ -198,6 +226,7 @@ void lcd_puts (const char *s)while (*s) {lcd_putc (*s++); } +lcd_sync (); }/*----------------------------------------------------------------------*/ @@ -365,13 +394,6 @@ int drv_lcd_init (void) }/*----------------------------------------------------------------------*/ -static -int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) -{ -lcd_clear (); -return 0 ; -} -void lcd_clear (void ) {#if LCD_BPP ==LCD_MONOCHROME @@ -413,6 +435,14 @@ void lcd_clear(void) console_col =0 ; console_row =0 ; +lcd_sync (); +} + +static int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc, +char *const argv[]) +{ +lcd_clear (); +return 0 ; } U_BOOT_CMD(@@ -607,6 +637,7 @@ void bitmap_plot (int x, int y) }WATCHDOG_RESET (); +lcd_sync (); }#else static inline void bitmap_plot (int x,int y) {}@@ -820,6 +851,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) break; }; +lcd_sync ();return (0 ); }#endif include/lcd.h +0
-0@@ -57,6 +57,14 @@ extern void lcd_initcolregs (void);extern struct bmp_image *gunzip_bmp (unsigned long addr,unsigned long *lenp);extern int bmp_display (ulong addr,int x,int y);
Quoted 15 lines
include/lcd.h extern void lcd_initcolregs (void); · line 70
Quoted 13 lines
include/lcd.h +2
-0+/** +* Set whether we need to flush the dcache when changing the LCD image. This
+ * defaults to off.
+ *
+ * @param flush non-zero to flush cache after update,
0 to skip
+ */include/lcd.h +2
-0+void lcd_set_flush_dcache (int flush); +#if definedCONFIG_MPC823 /* * LCD controller stucture for MPC823 CPU Anyway, I'm looking forward for v4 version of this patch.
Sorry I don't think I replied to this.
Certainly we could make the flushing more fine grained. My reasons for not (so far) are:
1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.
Certainly we could enhance this code. I wonder though whether a generic flushing mechanism may need to be added to support LCD and also video drivers.
Regards,
Simon
Quoted 7 lines
--
Best regards,Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Hi Simon,
Quoted 181 lines
Hi,
Quoted 161 lines · Lukasz Majewski
Hi Simon,
Quoted 50 lines
This provides an option for the LCD to flush the dcache after each update (puts, scroll or clear).
Signed-off-by Simon Glass <[email protected]>---
Changes in v2:
- Put the LCD cache flush logic intolcd_putc()instead oflcd_puts()Changes in v3:
- Put the LCD cache flush logic back intolcd_puts()common/lcd.c | 46+++++++++++++++++++++++++++++++++++++++-------
include/lcd.h| 8 ++++++++ 2 files changed, 47 insertions(+), 7 deletions(-)common/lcd.c +1
-0@@ -97,6 +97,9 @@ static void lcd_setbgcolor (int color);char lcd_is_enabled =0 ; +static char lcd_flush_dcache;/* 1 to flush dcache after each lcd update */ +
+
#ifdefNOT_USED_SO_FAR
static voidlcd_getcolreg(ushort regno,
ushort *red, ushort *green, ushort
*blue); @@ -105,6 +108,28 @@ static intlcd_getfgcolor(void);/************************************************************************/
common/lcd.c +5
-0+/* Flush LCD activity to the caches */ +void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some
+ * architectures do not actually implement it. Is there a
way to findcommon/lcd.c +8
-0+* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) + flush_dcache_range((u32)lcd_base, + (u32)(lcd_base +Quoted 1 line
lcd_get_size(&line_length))); +#endifI'm struggling with a similar problem - but not in console putc, but at
lcd_display_bitmap().The solution (in mine case) is:
flush_dcache_range((unsigned long) fb,
(unsigned long) fb + (lcd_line_length* height));
which takes the "real" image range (as it is defined by fb).Flushing the
lcd_basebased range is a bit overkill for me.common/lcd.c static int lcd_getfgcolor (void); · line 132
Quoted 7 lines
common/lcd.c +7
-0+} + +void lcd_set_flush_dcache (int flush) +{ + lcd_flush_dcache = (flush !=0 ); +} +I'm wondering if this
flush_dcache_rangecannot be added directly to relevant places in the code?flush_dcache_* calls are either defined (for a relevant - cache aware archs) or are dummy.
Quoted 82 lines
/*----------------------------------------------------------------------*/
static void
console_scrollup(void)common/lcd.c +1
-0@@ -114,6 +139,7 @@ static void console_scrollup (void)/* Clear the last one */ memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +lcd_sync (); }/*----------------------------------------------------------------------*/
common/lcd.c +13
-6@@ -144,6 +170,8 @@ static inline void console_newline (void)/* Scroll everything up */ console_scrollup () ; --console_row; + }else { +lcd_sync (); } }@@ -198,6 +226,7 @@ void lcd_puts (const char *s)while (*s) {lcd_putc (*s++); } +lcd_sync (); }/*----------------------------------------------------------------------*/ @@ -365,13 +394,6 @@ int drv_lcd_init (void) }/*----------------------------------------------------------------------*/ -static -int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) -{ -lcd_clear (); -return 0 ; -} -void lcd_clear (void ) {#if LCD_BPP ==LCD_MONOCHROME @@ -413,6 +435,14 @@ void lcd_clear(void) console_col =0 ; console_row =0 ; +lcd_sync (); +} + +static int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc, +char *const argv[]) +{ +lcd_clear (); +return 0 ; } U_BOOT_CMD(@@ -607,6 +637,7 @@ void bitmap_plot (int x, int y) }WATCHDOG_RESET (); +lcd_sync (); }#else static inline void bitmap_plot (int x,int y) {}@@ -820,6 +851,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) break; }; +lcd_sync ();return (0 ); }#endif include/lcd.h +0
-0@@ -57,6 +57,14 @@ extern void lcd_initcolregs (void);extern struct bmp_image *gunzip_bmp (unsigned long addr,unsigned long *lenp);extern int bmp_display (ulong addr,int x,int y);Quoted 15 lines
include/lcd.h extern void lcd_initcolregs (void); · line 70
Quoted 13 lines
include/lcd.h +2
-0+/** +* Set whether we need to flush the dcache when changing the LCD image. This
+ * defaults to off.
+ *
+ * @param flush non-zero to flush cache after update,
0 to skip
+ */include/lcd.h +2
-0+void lcd_set_flush_dcache (int flush); +#if definedCONFIG_MPC823 /* * LCD controller stucture for MPC823 CPU Anyway, I'm looking forward for v4 version of this patch.
Quoted 2 lines
Sorry I don't think I replied to this.
Yes, this is still open issue. (not fixed I mean) I maintain the patch locally.
Quoted 7 lines
Certainly we could make the flushing more fine grained. My reasons for not (so far) are:
1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.
From the sake of "SW engineering" I would opt for fine grained flushing. But if it turns out, that it costs too much, we can flush everything.
Quoted 4 lines
Certainly we could enhance this code. I wonder though whether a generic flushing mechanism may need to be added to support LCD and also video drivers.
We can add a generic mechanism to LCD and video.
Simon, do you plan to post some code in a near future? Or we are now just "gathering requirements"?
Quoted 11 lines
Regards,
SimonQuoted 7 lines
--
Best regards,Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Quoted 191 lines · Lukasz Majewski
Hi Simon,
Quoted 181 lines
Hi,
Quoted 161 lines · Lukasz Majewski
Hi Simon,
Quoted 50 lines
This provides an option for the LCD to flush the dcache after each update (puts, scroll or clear).
Signed-off-by Simon Glass<[email protected]>---
Changes in v2:
- Put the LCD cache flush logic intolcd_putc()instead oflcd_puts()Changes in v3:
- Put the LCD cache flush logic back intolcd_puts()common/lcd.c | 46+++++++++++++++++++++++++++++++++++++++-------
include/lcd.h| 8 ++++++++ 2 files changed, 47 insertions(+), 7 deletions(-)common/lcd.c +1
-0@@ -97,6 +97,9 @@ static void lcd_setbgcolor (int color);char lcd_is_enabled =0 ; +static char lcd_flush_dcache;/* 1 to flush dcache after each lcd update */ +
+
#ifdefNOT_USED_SO_FAR
static voidlcd_getcolreg(ushort regno,
ushort *red, ushort *green, ushort
*blue); @@ -105,6 +108,28 @@ static intlcd_getfgcolor(void);/************************************************************************/
common/lcd.c +5
-0+/* Flush LCD activity to the caches */ +void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some
+ * architectures do not actually implement it. Is there a
way to findcommon/lcd.c +8
-0+* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) + flush_dcache_range((u32)lcd_base, + (u32)(lcd_base +Quoted 1 line
lcd_get_size(&line_length))); +#endifI'm struggling with a similar problem - but not in console putc, but at
lcd_display_bitmap().The solution (in mine case) is:
flush_dcache_range((unsigned long) fb,
(unsigned long) fb + (lcd_line_length* height));
which takes the "real" image range (as it is defined by fb).Flushing the
lcd_basebased range is a bit overkill for me.common/lcd.c static int lcd_getfgcolor (void); · line 132
Quoted 7 lines
common/lcd.c +7
-0+} + +void lcd_set_flush_dcache (int flush) +{ + lcd_flush_dcache = (flush !=0 ); +} +I'm wondering if this
flush_dcache_rangecannot be added directly to relevant places in the code?flush_dcache_* calls are either defined (for a relevant - cache aware archs) or are dummy.
Quoted 82 lines
/*----------------------------------------------------------------------*/
static void
console_scrollup(void)common/lcd.c +1
-0@@ -114,6 +139,7 @@ static void console_scrollup (void)/* Clear the last one */ memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +lcd_sync (); }/*----------------------------------------------------------------------*/
common/lcd.c +13
-6@@ -144,6 +170,8 @@ static inline void console_newline (void)/* Scroll everything up */ console_scrollup () ; --console_row; + }else { +lcd_sync (); } }@@ -198,6 +226,7 @@ void lcd_puts (const char *s)while (*s) {lcd_putc (*s++); } +lcd_sync (); }/*----------------------------------------------------------------------*/ @@ -365,13 +394,6 @@ int drv_lcd_init (void) }/*----------------------------------------------------------------------*/ -static -int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) -{ -lcd_clear (); -return 0 ; -} -void lcd_clear (void ) {#if LCD_BPP ==LCD_MONOCHROME @@ -413,6 +435,14 @@ void lcd_clear(void) console_col =0 ; console_row =0 ; +lcd_sync (); +} + +static int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc, +char *const argv[]) +{ +lcd_clear (); +return 0 ; } U_BOOT_CMD(@@ -607,6 +637,7 @@ void bitmap_plot (int x, int y) }WATCHDOG_RESET (); +lcd_sync (); }#else static inline void bitmap_plot (int x,int y) {}@@ -820,6 +851,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) break; }; +lcd_sync ();return (0 ); }#endif include/lcd.h +0
-0@@ -57,6 +57,14 @@ extern void lcd_initcolregs (void);extern struct bmp_image *gunzip_bmp (unsigned long addr,unsigned long *lenp);extern int bmp_display (ulong addr,int x,int y);Quoted 15 lines
include/lcd.h extern void lcd_initcolregs (void); · line 70
Quoted 13 lines
include/lcd.h +2
-0+/** +* Set whether we need to flush the dcache when changing the LCD image. This
+ * defaults to off.
+ *
+ * @param flush non-zero to flush cache after update,
0 to skip
+ */include/lcd.h +2
-0+void lcd_set_flush_dcache (int flush); +#if definedCONFIG_MPC823 /* * LCD controller stucture for MPC823 CPU Anyway, I'm looking forward for v4 version of this patch.
Quoted 2 lines
Sorry I don't think I replied to this.
Yes, this is still open issue. (not fixed I mean) I maintain the patch locally.
Quoted 3 lines
Certainly we could make the flushing more fine grained. My reasons for not (so far) are:
Quoted 9 lines
Quoted 4 lines
1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.From the sake of "SW engineering" I would opt for fine grained
flushing. But if it turns out, that it costs too much, we can flush everything.
Is anybody else in a position to get some numbers about how/if performance is better when flushing at the more granular level?
Before deciding it wasn't worth the code, I implemented granular flushing and didn't see any noticeable degradation when just flushing at the end of all public functions as in this patch.
http://lists.denx.de/pipermail/u-boot/2012-September/134979.html
It seems that performance is the only reason for fine-grained cache flush operations
Quoted 24 lines
Quoted 4 lines
Certainly we could enhance this code. I wonder though whether a generic flushing mechanism may need to be added to support LCD and also video drivers.
We can add a generic mechanism to LCD and video.
Simon, do you plan to post some code in a near future? Or we are now just "gathering requirements"?
Quoted 11 lines
Regards,
SimonQuoted 7 lines
--
Best regards,Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Hi Eric,
Quoted 217 lines · Eric Nelson
Quoted 208 lines · Lukasz Majewski
Hi Simon,
Quoted 191 lines
Hi,
Quoted 169 lines · Lukasz Majewski
Hi Simon,
Quoted 51 lines
This provides an option for the LCD to flush the dcache after each update (puts, scroll or clear).
Signed-off-by Simon Glass<[email protected]>---
Changes in v2:
- Put the LCD cache flush logic intolcd_putc()instead oflcd_puts()Changes in v3:
- Put the LCD cache flush logic back intolcd_puts()common/lcd.c | 46+++++++++++++++++++++++++++++++++++++++-------
include/lcd.h| 8 ++++++++ 2 files changed, 47 insertions(+), 7 deletions(-)common/lcd.c +1
-0@@ -97,6 +97,9 @@ static void lcd_setbgcolor (int color);char lcd_is_enabled =0 ; +static char lcd_flush_dcache;/* 1 to flush dcache after each lcd update */ +
+
#ifdefNOT_USED_SO_FAR
static voidlcd_getcolreg(ushort regno,
ushort *red, ushort *green, ushort
*blue); @@ -105,6 +108,28 @@ static intlcd_getfgcolor(void);/************************************************************************/
common/lcd.c +5
-0+/* Flush LCD activity to the caches */ +void lcd_sync (void ) +{ +/* +* flush_dcache_range() is declared in common.h but it seems that some
+ * architectures do not actually implement it. Is there a
way to findcommon/lcd.c +8
-0+* out whether it exists? For now, ARM is safe. +*/ +#ifdef CONFIG_ARM +int line_length; + +if (lcd_flush_dcache) + flush_dcache_range((u32)lcd_base, + (u32)(lcd_base +Quoted 1 line
lcd_get_size(&line_length))); +#endifI'm struggling with a similar problem - but not in console putc, but at
lcd_display_bitmap().The solution (in mine case) is:
flush_dcache_range((unsigned long) fb,
(unsigned long) fb + (lcd_line_length* height));
which takes the "real" image range (as it is defined by fb).Flushing the
lcd_basebased range is a bit overkill for me.common/lcd.c static int lcd_getfgcolor (void); · line 132
Quoted 7 lines
common/lcd.c +7
-0+} + +void lcd_set_flush_dcache (int flush) +{ + lcd_flush_dcache = (flush !=0 ); +} +I'm wondering if this
flush_dcache_rangecannot be added directly to relevant places in the code?flush_dcache_* calls are either defined (for a relevant - cache aware archs) or are dummy.
Quoted 86 lines
/*----------------------------------------------------------------------*/
static void
console_scrollup(void)common/lcd.c +1
-0@@ -114,6 +139,7 @@ static void console_scrollup (void)/* Clear the last one */ memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +lcd_sync (); }/*----------------------------------------------------------------------*/
common/lcd.c +3
-0@@ -144,6 +170,8 @@ static inline void console_newline (void)/* Scroll everything up */ console_scrollup () ; --console_row; + }else { +lcd_sync (); } }@@ -198,6 +226,7 @@ void lcd_puts (const char *s)while (*s) {lcd_putc (*s++); } +lcd_sync (); }/*----------------------------------------------------------------------*/
common/lcd.c +10
-6@@ -365,13 +394,6 @@ int drv_lcd_init (void) }/*----------------------------------------------------------------------*/ -static -int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) -{ -lcd_clear (); -return 0 ; -} -void lcd_clear (void ) {#if LCD_BPP ==LCD_MONOCHROME @@ -413,6 +435,14 @@ void lcd_clear(void) console_col =0 ; console_row =0 ; +lcd_sync (); +} + +static int do_lcd_clear (cmd_tbl_t *cmdtp,int flag,int argc, +char *const argv[]) +{ +lcd_clear (); +return 0 ; } U_BOOT_CMD(@@ -607,6 +637,7 @@ void bitmap_plot (int x, int y) }WATCHDOG_RESET (); +lcd_sync (); }#else static inline void bitmap_plot (int x,int y) {}@@ -820,6 +851,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) break; }; +lcd_sync ();return (0 ); }#endif include/lcd.h +0
-0@@ -57,6 +57,14 @@ extern void lcd_initcolregs (void);extern struct bmp_image *gunzip_bmp (unsigned long addr,unsigned long *lenp);extern int bmp_display (ulong addr,int x,int y);Quoted 16 lines
include/lcd.h extern void lcd_initcolregs (void); · line 70
Quoted 13 lines
include/lcd.h +2
-0+/** +* Set whether we need to flush the dcache when changing the LCD image. This
+ * defaults to off.
+ *
+ * @param flush non-zero to flush cache after update,
0 to skip
+ */include/lcd.h +2
-0+void lcd_set_flush_dcache (int flush); +#if definedCONFIG_MPC823 /* * LCD controller stucture for MPC823 CPU Anyway, I'm looking forward for v4 version of this patch.
Quoted 2 lines
Sorry I don't think I replied to this.
Yes, this is still open issue. (not fixed I mean) I maintain the patch locally.
Quoted 7 lines
Certainly we could make the flushing more fine grained. My reasons for not (so far) are:
1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.Quoted 4 lines
From the sake of "SW engineering" I would opt for fine grained
flushing. But if it turns out, that it costs too much, we can flush everything.Is anybody else in a position to get some numbers about how/if performance is better when flushing at the more granular level?
Quoted 8 lines
Before deciding it wasn't worth the code, I implemented granular flushing and didn't see any noticeable degradation when just flushing at the end of all public functions as in this patch.
http://lists.denx.de/pipermail/u-boot/2012-September/134979.htmlIt seems that performance is the only reason for fine-grained cache flush operations
Also we might be talking about different things. I have taken the approach of flushing the whole display, but only after some display functions. We could flush only what has changed, which is what I was referring to as 'fine-grained'. You may have meant the idea of flushing after every function that touches the display, or a 'fine-grained' approach of only flushing after some functions.
My testing shows that flushing is pretty fast, but I was reluctant to flush after every putc() as it seemed egregiously inefficient.
Regards,
Simon
Quoted 29 lines
Quoted 28 lines
Quoted 6 lines
Certainly we could enhance this code. I wonder though whether a generic flushing mechanism may need to be added to support LCD and also video drivers.
We can add a generic mechanism to LCD and video.
Simon, do you plan to post some code in a near future? Or we are now just "gathering requirements"?
Quoted 11 lines
Regards,
SimonQuoted 7 lines
--
Best regards,Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Hi Simon,
Quoted 34 lines · Simon Glass
Hi Eric,
Quoted 21 lines · Eric Nelson
Quoted 12 lines · Lukasz Majewski
<snip>
Quoted 7 lines
Certainly we could make the flushing more fine grained. My reasons for not (so far) are:
1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.Quoted 4 lines
From the sake of "SW engineering" I would opt for fine grained
flushing. But if it turns out, that it costs too much, we can flush everything.Is anybody else in a position to get some numbers about how/if performance is better when flushing at the more granular level?
Quoted 8 lines
Before deciding it wasn't worth the code, I implemented granular flushing and didn't see any noticeable degradation when just flushing at the end of all public functions as in this patch.
http://lists.denx.de/pipermail/u-boot/2012-September/134979.htmlIt seems that performance is the only reason for fine-grained cache flush operations
Quoted 7 lines
Also we might be talking about different things. I have taken the approach of flushing the whole display, but only after some display functions. We could flush only what has changed, which is what I was referring to as 'fine-grained'. You may have meant the idea of flushing after every function that touches the display, or a 'fine-grained' approach of only flushing after some functions.
You're right. That's what I get for chiming in quickly before attending a customer meeting: I jump to conclusions.
I thought 'finer-grained' referred to the way Anatolij originally did things:
http://git.denx.de/?p=u-boot.git;a=commit;h=bfd4be803bbb7d122c2e3aaf6eaf987efa8d69da
I tried to follow that lead, but it degenerated into a horrible mess of alignment checking.
Quoted 3 lines
My testing shows that flushing is pretty fast, but I was reluctant to flush after every
putc()as it seemed egregiously inefficient.
I need to spend some time with the patch to figure out how you get around cache issues for keystroke echo.
Regards,
Eric
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Hi Eric,
Quoted 64 lines · Eric Nelson
Hi Simon,
Quoted 40 lines · Simon Glass
Hi Eric,
Quoted 25 lines · Eric Nelson
Quoted 15 lines · Lukasz Majewski
<snip>
Quoted 7 lines
Certainly we could make the flushing more fine grained. My reasons for not (so far) are:
1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.Quoted 4 lines
From the sake of "SW engineering" I would opt for fine grained
flushing. But if it turns out, that it costs too much, we can flush everything.Is anybody else in a position to get some numbers about how/if performance is better when flushing at the more granular level?
Quoted 8 lines
Before deciding it wasn't worth the code, I implemented granular flushing and didn't see any noticeable degradation when just flushing at the end of all public functions as in this patch.
http://lists.denx.de/pipermail/u-boot/2012-September/134979.htmlIt seems that performance is the only reason for fine-grained cache flush operations
Quoted 7 lines
Also we might be talking about different things. I have taken the approach of flushing the whole display, but only after some display functions. We could flush only what has changed, which is what I was referring to as 'fine-grained'. You may have meant the idea of flushing after every function that touches the display, or a 'fine-grained' approach of only flushing after some functions.
You're right. That's what I get for chiming in quickly before attending a customer meeting: I jump to conclusions.
I thought 'finer-grained' referred to the way Anatolij originally did things:
http://git.denx.de/?p=u-boot.git;a=commit;h=bfd4be803bbb7d122c2e3aaf6eaf987efa8d69da
I tried to follow that lead, but it degenerated into a horrible mess of alignment checking.
Quoted 6 lines
Quoted 3 lines
My testing shows that flushing is pretty fast, but I was reluctant to flush after every
putc()as it seemed egregiously inefficient.I need to spend some time with the patch to figure out how you get around cache issues for keystroke echo.
Well my less-than-lovely approach was to use puts() for all character echo. That has a flush.
Regards,
Simon
Quoted 5 lines
Regards,
Eric
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Hi Simon,
Quoted 72 lines · Simon Glass
Hi Eric,
Quoted 68 lines · Eric Nelson
Hi Simon,
Quoted 40 lines · Simon Glass
Hi Eric,
Quoted 25 lines · Eric Nelson
Quoted 15 lines · Lukasz Majewski
<snip>
Quoted 7 lines
Certainly we could make the flushing more fine grained. My reasons for not (so far) are:
1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.Quoted 4 lines
From the sake of "SW engineering" I would opt for fine grained
flushing. But if it turns out, that it costs too much, we can flush everything.Is anybody else in a position to get some numbers about how/if performance is better when flushing at the more granular level?
Quoted 8 lines
Before deciding it wasn't worth the code, I implemented granular flushing and didn't see any noticeable degradation when just flushing at the end of all public functions as in this patch.
http://lists.denx.de/pipermail/u-boot/2012-September/134979.htmlIt seems that performance is the only reason for fine-grained cache flush operations
Quoted 7 lines
Also we might be talking about different things. I have taken the approach of flushing the whole display, but only after some display functions. We could flush only what has changed, which is what I was referring to as 'fine-grained'. You may have meant the idea of flushing after every function that touches the display, or a 'fine-grained' approach of only flushing after some functions.
You're right. That's what I get for chiming in quickly before attending a customer meeting: I jump to conclusions.
I thought 'finer-grained' referred to the way Anatolij originally did things:
http://git.denx.de/?p=u-boot.git;a=commit;h=bfd4be803bbb7d122c2e3aaf6eaf987efa8d69da
I tried to follow that lead, but it degenerated into a horrible mess of alignment checking.
Quoted 3 lines
My testing shows that flushing is pretty fast, but I was reluctant to flush after every
putc()as it seemed egregiously inefficient.
Quoted 6 lines
Quoted 2 lines
I need to spend some time with the patch to figure out how you get around cache issues for keystroke echo.
Well my less-than-lovely approach was to use
puts()for all character echo. That has a flush.
I just read through that and it makes perfect sense.
I'm anxious to test this and your CONFIG_CONSOLE_SCROLL_LINES patch to see how it operates at 1080P.
Without the CONFIG_CONSOLE_SCROLL_LINES patch, scrolling was incredibly slow.
Regards,
Eric
PATCH v3 13/18 lcd: Add support for flushing LCD fb from dcache after update
Hi Eric,
Quoted 94 lines · Eric Nelson
Hi Simon,
Quoted 82 lines · Simon Glass
Hi Eric,
Quoted 77 lines · Eric Nelson
Hi Simon,
Quoted 47 lines · Simon Glass
Hi Eric,
Quoted 34 lines · Eric Nelson
Quoted 18 lines · Lukasz Majewski
<snip>
Quoted 8 lines
Certainly we could make the flushing more fine grained. My reasons for
not (so far) are:1. It is simpler to flush everything (no need to figure out what part of display has changed)
2. The performance difference is likely to be small since flushing an already-flushed range should be fast.Quoted 4 lines
From the sake of "SW engineering" I would opt for fine grained
flushing. But if it turns out, that it costs too much, we can flush everything.Is anybody else in a position to get some numbers about how/if performance is better when flushing at the more granular level?
Before deciding it wasn't worth the code, I implemented granular flushing and didn't see any noticeable degradation when just flushing at the end of all public functions as in this patch.
Quoted 4 lines
http://lists.denx.de/pipermail/u-boot/2012-September/134979.html
It seems that performance is the only reason for fine-grained cache flush operations
Quoted 7 lines
Also we might be talking about different things. I have taken the approach of flushing the whole display, but only after some display functions. We could flush only what has changed, which is what I was referring to as 'fine-grained'. You may have meant the idea of flushing after every function that touches the display, or a 'fine-grained' approach of only flushing after some functions.
You're right. That's what I get for chiming in quickly before attending a customer meeting: I jump to conclusions.
I thought 'finer-grained' referred to the way Anatolij originally did things:
http://git.denx.de/?p=u-boot.git;a=commit;h=bfd4be803bbb7d122c2e3aaf6eaf987efa8d69da
I tried to follow that lead, but it degenerated into a horrible mess of alignment checking.
Quoted 3 lines
My testing shows that flushing is pretty fast, but I was reluctant to flush after every
putc()as it seemed egregiously inefficient.Quoted 7 lines
Quoted 2 lines
I need to spend some time with the patch to figure out how you get around cache issues for keystroke echo.
Well my less-than-lovely approach was to use
puts()for all character echo. That has a flush.
Quoted 7 lines
I just read through that and it makes perfect sense.
I'm anxious to test this and your
CONFIG_CONSOLE_SCROLL_LINESpatch to see how it operates at 1080P.Without the
CONFIG_CONSOLE_SCROLL_LINESpatch, scrolling was incredibly slow.
Yes, it makes a big difference. Another option would be to enable the L2 cache.
Regards,
Simon
Quoted 5 lines
Regards,
Eric
PATCH v3 14/18 tegra: Align LCD frame buffer to section boundary
In reply to Simon GlassFor tegra we want to enable the cache for the LCD. This is easier if we can avoid using L2 page tages, so align the LCD to a section boundary.
---
Changes in v2:
- Align tegra display using new CONFIG_LCD_ALIGNMENT feature
include/configs/tegra2-common.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
include/configs/tegra2-common.h +3 -0
@@ -45,6 +45,9 @@#define CONFIG_ARCH_CPU_INIT /* Fire up the A9 core */ +/* Align LCD to 1MB boundary */ +#define CONFIG_LCD_ALIGNMENT MMU_SECTION_SIZE +#include <asm/arch/tegra2.h> /* get chip and board defs */ /*
Signature · 1 line
1.7.7.3
PATCH v3 14/18 tegra: Align LCD frame buffer to section boundary
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/0c1fdc4d/attachment.pgp>
PATCH v3 15/18 tegra: Support control of cache settings for LCD
In reply to Simon GlassAdd support for selecting the required cache mode for the LCD:
off, write-through or write-back.
---
Changes in v3:
- Handle a cached frame buffer out of normal U-Boot memory
drivers/video/tegra.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
drivers/video/tegra.c +11 -0
@@ -145,6 +145,7 @@ static void update_panel_size(struct fdt_disp_config *config)void lcd_ctrl_init (void *lcdbase) {int line_length, size; +int type =DCACHE_OFF ;assert (disp_config);
@@ -160,6 +161,16 @@ void lcd_ctrl_init(void *lcdbase)update_panel_size (disp_config); size =lcd_get_size (&line_length); +/* Set up the LCD caching as requested */ +if (config.cache_type &FDT_LCD_CACHE_WRITE_THROUGH ) + type =DCACHE_WRITETHROUGH ; +else if (config.cache_type &FDT_LCD_CACHE_WRITE_BACK ) + type =DCACHE_WRITEBACK ; +mmu_set_region_dcache (disp_config->frame_buffer, size, type); + +/* Enable flushing after LCD writes if requested */ +lcd_set_flush_dcache (config.cache_type &FDT_LCD_CACHE_FLUSH ); +debug ("LCD frame buffer at %p\n" , lcd_base); }
Signature · 1 line
1.7.7.3
PATCH v3 17/18 lcd: Add CONSOLE_SCROLL_LINES option to speed console
In reply to Simon GlassWhen the cursor position gets to the end of the LCD console we normally scroll by one line. This adds an option to increase that value.
Console scrolling is often slow, and if a large amount of output is being sent, increasing this option to 10 or so will speed things up considerably.
---
Changes in v3:
- Fix tiny bug in mult-line lcd scrolling
README | 6 ++++++ common/lcd.c | 16 +++++++++++++--- 2 files changed, 19 insertions(+), 3 deletions(-)
README +6 -0
@@ -1416,6 +1416,12 @@ The following options need to be configured: here, since it is cheaper to change data cache settings on a per-section basis. + CONSOLE_SCROLL_LINES + + When the console need to be scrolled, this is the number of + lines to scroll by. It defaults to 1. Increasing this makes + the console jump but can help speed up operation when scrolling + is slow. - Splash Screen Support: CONFIG_SPLASH_SCREEN
common/lcd.c +13 -3
@@ -134,12 +134,23 @@ void lcd_set_flush_dcache(int flush)static void console_scrollup (void ) { +int rows =1 ; + +#ifdef CONSOLE_SCROLL_LINES + rows =CONSOLE_SCROLL_LINES ; +#endif /* Copy up rows ignoring the first one */ -memcpy (CONSOLE_ROW_FIRST ,CONSOLE_ROW_SECOND ,CONSOLE_SCROLL_SIZE ); +memcpy (CONSOLE_ROW_FIRST , + lcd_console_address +CONSOLE_ROW_SIZE * rows, +CONSOLE_SIZE -CONSOLE_ROW_SIZE * rows);/* Clear the last one */ -memset (CONSOLE_ROW_LAST ,COLOR_MASK (lcd_color_bg),CONSOLE_ROW_SIZE ); +memset (lcd_console_address +CONSOLE_SIZE -CONSOLE_ROW_SIZE * rows, +COLOR_MASK (lcd_color_bg), +CONSOLE_ROW_SIZE * rows); +lcd_sync (); + console_row -= rows; }/*----------------------------------------------------------------------*/
@@ -169,7 +180,6 @@ static inline void console_newline (void)if (console_row >=CONSOLE_ROWS ) {/* Scroll everything up */ console_scrollup () ; - --console_row; }else {lcd_sync (); }
Signature · 1 line
1.7.7.3
PATCH v3 17/18 lcd: Add CONSOLE_SCROLL_LINES option to speed console
README The following options need to be configured: · line 1424
Quoted 9 lines · On Thursday 12 July 2012 11:25:17 Simon Glass wrote:
README +6
-0+ CONSOLE_SCROLL_LINES + + When the console need to be scrolled, this is the number of + lines to scroll by. It defaults to 1. Increasing this makes + the console jump but can help speed up operation when scrolling + is slow.
board knobs should be CONFIG_xxx
common/lcd.c void lcd_set_flush_dcache(int flush) · line 141
Quoted 10 lines
common/lcd.c +5
-0static void console_scrollup (void ) { +int rows =1 ; + +#ifdef CONSOLE_SCROLL_LINES + rows =CONSOLE_SCROLL_LINES ; +#endif
seems like this should be at the top of the file:
#ifndef CONSOLE_SCROLL_LINES
# define CONSOLE_SCROLL_LINES 1 #endif -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/856ad090/attachment.pgp>
PATCH v3 17/18 lcd: Add CONSOLE_SCROLL_LINES option to speed console
Hi Mike,
Quoted 26 lines · Mike Frysinger
README The following options need to be configured: · line 1424
Quoted 9 lines · On Thursday 12 July 2012 11:25:17 Simon Glass wrote:
README +6
-0+ CONSOLE_SCROLL_LINES + + When the console need to be scrolled, this is the number of + lines to scroll by. It defaults to 1. Increasing this makes + the console jump but can help speed up operation when scrolling + is slow.board knobs should be
CONFIG_xxxcommon/lcd.c void lcd_set_flush_dcache(int flush) · line 141
Quoted 10 lines
common/lcd.c +5
-0static void console_scrollup (void ) { +int rows =1 ; + +#ifdef CONSOLE_SCROLL_LINES + rows =CONSOLE_SCROLL_LINES ; +#endif seems like this should be at the top of the file:
#ifndefCONSOLE_SCROLL_LINES
Quoted 2 lines
# define CONSOLE_SCROLL_LINES 1 #endif
Yes, both done, thanks.
Quoted 1 line
-mike
Regards,
Simon
PATCH v3 18/18 tegra: Enable display/lcd support on Seaboard
In reply to Simon GlassFrom: Mayuresh Kulkarni <[email protected]>
Enable the Seaboard's 16-bit LCD and use it as the console.
---
include/configs/seaboard.h | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-)
include/configs/seaboard.h +9 -2
@@ -105,8 +105,15 @@#undef TEGRA2_DEVICE_SETTINGS#define TEGRA2_DEVICE_SETTINGS "stdin=serial,tegra-kbc\0" \ - "stdout=serial\0" \ - "stderr=serial\0" + "stdout=serial,lcd\0" \ + "stderr=serial,lcd\0" + +/* LCD support */ +#define CONFIG_LCD +#define CONFIG_VIDEO_TEGRA +#define LCD_BPP LCD_COLOR16 +#define CONFIG_SYS_WHITE_ON_BLACK +#define CONSOLE_SCROLL_LINES 10#include "tegra2-common-post.h"
Signature · 1 line
1.7.7.3
v3 cover tegra: Add display driver and LCD support for Seaboard
In reply to Simon GlassQuoted 81 lines · Simon Glass
This series adds support for the Tegra2x's display peripheral. This supports the LCD display on Seaboard and we use this to enable console output in U-Boot on the LCD.
Configuration is via the device tree. Proposed bindings are included in this series, taken from pwm bindings that should be in linux-next, a Tegra video binding that might be accepted in devicetree-discuss and a proposed video mode binding posted to dri-devel.
While I agree EDID is convenient for machines I would prefer to provide a user-friendly way of selecting LCD settings as well, with EDID more as a fallback and auto-detection when available.
To improve performance two optimisations are offered:
1. The LCD frame buffer is cached, with the cache being flushed after each newline sent to
putc(), and in a few other situations. This dramatically increases performance (around 10x). This requires a few additions to the ARM cache support.2. The console supports scrolling in steps of more than 1 line. This speeds up scrolling output considerably, particularly commands like 'printenv' which display a lot of output, and particular when the dcache is off. This requires a new CONFIG and a change to the
console_scrollup()function.Changes in v2:
- Add new patch to use const in pinmux_config_pingroup/table()
- Add nvidia prefix to device tree properties
- Align tegra display using newCONFIG_LCD_ALIGNMENTfeature
- Put the LCD cache flush logic intolcd_putc()instead oflcd_puts()
- Update LCD driver to deal with new fdt bindings
- Update seaboard LCD definitions for new fdt binding
- Use a more generic configCONFIG_LCD_ALIGNMENTfor lcd alignment
- Use const where possible in funcmuxChanges in v3:
- Add new commit for pwm binding and node
- Add new panel binding to fit with tegra display controller binding
- Add probe function to read in fdt parameters in display driver
- Add separate call topwm_init()inboard_init()
- Adjust LCD driver to use new SOC display driver structures
- Bring in proposed tegra display controller binding
- Decode fdt node within the pwm driver
- Fix tiny bug in mult-line lcd scrolling
- Handle a cached frame buffer out of normal U-Boot memory
- Introduce concept of a pwm channel, rather than separate peripherals
- Move some fdt decode code from LCD driver to SOC display driver
- Put the LCD cache flush logic back intolcd_puts()
- Remove LPW1 pin which is not needed by display
- Remove spurious newline fromfdtdec_get_addr()debug output
- Rename fdt config structures
- Rename pwfm driver to pwm
- Separate display driver and LCD driver more in fdt
- Tidy upfdtdec_decode_gpios()debug output
- Use displaymode binding for fdt
- Use new proposed upstream pwm binding
- Use new pwm binding from pre-linux-next
- Use new upstream proposed LCD definitionsMayuresh Kulkarni (1):
tegra: Enable display/lcd support on SeaboardSimon Glass (16):
fdt: Tidy debugging, add to fdtdec_get_int/addr()
fdt: Add header guard tofdtdec.h
tegra: Use const for pinmux_config_pingroup/table()
tegra: Add display support to funcmux
tegra: fdt: Add pwm binding and node
tegra: fdt: Add LCD definitions for Tegra
tegra: Add support for PWM
tegra: Add LCD driver
tegra: Add LCD support to Nvidia boards
arm: Add control over cachability of memory regions
lcd: AddCONFIG_LCD_ALIGNMENTto select frame buffer alignment
lcd: Add support for flushing LCD fb from dcache after update
tegra: Align LCD frame buffer to section boundary
tegra: Support control of cache settings for LCD
tegra: fdt: Add LCD definitions for Seaboard
lcd: AddCONSOLE_SCROLL_LINESoption to speed console
Quoted 2 lines
Wei Ni (1):
tegra: Add SOC support for display/lcd
I was able to make this work on the Medcom with the one workaround to make backlight and panel GPIOs optional and adding the corresponding DTS and configuration entries for Medcom, so:
The display corruption does no longer seem to happen. While I haven't thoroughly reviewed, I think this is in pretty good shape. Thanks Simon.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/ffc24a8c/attachment.pgp>
v3 cover tegra: Add display driver and LCD support for Seaboard
Hi Thierry,
Quoted 82 lines · Thierry Reding
Quoted 81 lines · Simon Glass
This series adds support for the Tegra2x's display peripheral. This supports the LCD display on Seaboard and we use this to enable console output in U-Boot on the LCD.
Configuration is via the device tree. Proposed bindings are included in this series, taken from pwm bindings that should be in linux-next, a Tegra video binding that might be accepted in devicetree-discuss and a proposed video mode binding posted to dri-devel.
While I agree EDID is convenient for machines I would prefer to provide a user-friendly way of selecting LCD settings as well, with EDID more as a fallback and auto-detection when available.
To improve performance two optimisations are offered:
1. The LCD frame buffer is cached, with the cache being flushed after each newline sent to
putc(), and in a few other situations. This dramatically increases performance (around 10x). This requires a few additions to the ARM cache support.2. The console supports scrolling in steps of more than 1 line. This speeds up scrolling output considerably, particularly commands like 'printenv' which display a lot of output, and particular when the dcache is off. This requires a new CONFIG and a change to the
console_scrollup()function.Changes in v2:
- Add new patch to use const in pinmux_config_pingroup/table()
- Add nvidia prefix to device tree properties
- Align tegra display using newCONFIG_LCD_ALIGNMENTfeature
- Put the LCD cache flush logic intolcd_putc()instead oflcd_puts()
- Update LCD driver to deal with new fdt bindings
- Update seaboard LCD definitions for new fdt binding
- Use a more generic configCONFIG_LCD_ALIGNMENTfor lcd alignment
- Use const where possible in funcmuxChanges in v3:
- Add new commit for pwm binding and node
- Add new panel binding to fit with tegra display controller binding
- Add probe function to read in fdt parameters in display driver
- Add separate call topwm_init()inboard_init()
- Adjust LCD driver to use new SOC display driver structures
- Bring in proposed tegra display controller binding
- Decode fdt node within the pwm driver
- Fix tiny bug in mult-line lcd scrolling
- Handle a cached frame buffer out of normal U-Boot memory
- Introduce concept of a pwm channel, rather than separate peripherals
- Move some fdt decode code from LCD driver to SOC display driver
- Put the LCD cache flush logic back intolcd_puts()
- Remove LPW1 pin which is not needed by display
- Remove spurious newline fromfdtdec_get_addr()debug output
- Rename fdt config structures
- Rename pwfm driver to pwm
- Separate display driver and LCD driver more in fdt
- Tidy upfdtdec_decode_gpios()debug output
- Use displaymode binding for fdt
- Use new proposed upstream pwm binding
- Use new pwm binding from pre-linux-next
- Use new upstream proposed LCD definitionsMayuresh Kulkarni (1):
tegra: Enable display/lcd support on SeaboardSimon Glass (16):
fdt: Tidy debugging, add to fdtdec_get_int/addr()
fdt: Add header guard tofdtdec.h
tegra: Use const for pinmux_config_pingroup/table()
tegra: Add display support to funcmux
tegra: fdt: Add pwm binding and node
tegra: fdt: Add LCD definitions for Tegra
tegra: Add support for PWM
tegra: Add LCD driver
tegra: Add LCD support to Nvidia boards
arm: Add control over cachability of memory regions
lcd: AddCONFIG_LCD_ALIGNMENTto select frame buffer alignment
lcd: Add support for flushing LCD fb from dcache after update
tegra: Align LCD frame buffer to section boundary
tegra: Support control of cache settings for LCD
tegra: fdt: Add LCD definitions for Seaboard
lcd: AddCONSOLE_SCROLL_LINESoption to speed console
Quoted 8 lines
Quoted 2 lines
Wei Ni (1):
tegra: Add SOC support for display/lcdI was able to make this work on the Medcom with the one workaround to make backlight and panel GPIOs optional and adding the corresponding DTS and configuration entries for Medcom, so:
Tested-by Thierry Reding <[email protected]>
Thanks, I am waiting until the binding is agreed before addressing comments and sending a new version.
Quoted 5 lines
The display corruption does no longer seem to happen. While I haven't thoroughly reviewed, I think this is in pretty good shape. Thanks Simon.
Thierry
Regards,
Simon