Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 11月, 2018 2 次提交
  3. 24 7月, 2018 1 次提交
  5. 19 7月, 2018 3 次提交
  7. 17 4月, 2018 1 次提交
  9. 20 3月, 2018 1 次提交
  11. 19 3月, 2018 2 次提交
  13. 22 2月, 2018 2 次提交
  15. 29 1月, 2018 2 次提交
  17. 22 1月, 2018 5 次提交
  19. 18 10月, 2017 3 次提交
  21. 17 10月, 2017 1 次提交
    • C
      drm/sun4i: backend: Offset layer buffer address by DRAM starting address · 4690803b
      由 Chen-Yu Tsai 提交于 
      The display backend, as well as other peripherals that have a DRAM
clock gate and access DRAM directly, bypassing the system bus,
address the DRAM starting from 0x0, while physical addresses the
system uses starts from 0x40000000 (or 0x20000000 in A80's case).

This issue was witnessed on the Cubietruck, which has 2GB of RAM.

Devices with less RAM function normally due to the DRAM address
wrapping around. CMA seems to always allocate its buffer at a
very high address, close to the end of DRAM.

On a 1GB RAM device, the physical address would be something like
0x78000000. The DRAM address 0x78000000 would access the same DRAM
region as 0x38000000 on a system, as the DRAM address would only
span 0x0 ~ 0x3fffffff. The bit 0x40000000 is non-functional in this
case.

However on the Cubietruck, the DRAM is 2GB. The physical address
is 0x40000000 ~ 0xbfffffff. The buffer would be something like
0xb8000000. But the DRAM address span 0x0 ~ 0x7fffffff, meaning
the buffer address wraps around to 0x38000000, which is wrong.
The correct DRAM address for it should be 0x78000000.

Correct the address configured into the backend layer registers
by PHYS_OFFSET to account for this.

Fixes: 9026e0d1 ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017042349.31743-6-wens@csie.org
      4690803b
  23. 16 10月, 2017 3 次提交
  25. 23 8月, 2017 1 次提交
  27. 01 6月, 2017 1 次提交
    • I
      drm/sun4i: abstract a engine type · 87969338
      由 Icenowy Zheng 提交于 
      As we are going to add support for the Allwinner DE2 engine in sun4i-drm
driver, we will finally have two types of display engines -- the DE1
backend and the DE2 mixer. They both do some display blending and feed
graphics data to TCON, and is part of the "Display Engine" called by
Allwinner, so I choose to call them both "engine" here.

Abstract the engine type to a new struct with an ops struct, which contains
functions that should be called outside the engine-specified code (in
TCON, CRTC or TV Encoder code).

In order to preserve bisectability, we also switch the backend and layer
code in its own module.
Signed-off-by: NIcenowy Zheng <icenowy@aosc.io>
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      87969338
  29. 14 5月, 2017 5 次提交
  31. 08 3月, 2017 1 次提交
  33. 03 1月, 2017 1 次提交
  35. 15 12月, 2016 2 次提交
    • V
      drm: Nuke fb->pixel_format · 438b74a5
      由 Ville Syrjälä 提交于 
      Replace uses of fb->pixel_format with fb->format->format.
Less duplicated information is a good thing.

Note that coccinelle failed to eliminate the
"/* fourcc format */" comment from drm_framebuffer.h, so I had
to do that part manually.

@@
struct drm_framebuffer *FB;
expression E;
@@
 drm_helper_mode_fill_fb_struct(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 i9xx_get_initial_plane_config(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 ironlake_get_initial_plane_config(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 skylake_get_initial_plane_config(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- a->pixel_format
+ a->format->format
|
- b.pixel_format
+ b.format->format
)

@@
struct drm_plane_state *a;
struct drm_plane_state b;
@@
(
- a->fb->pixel_format
+ a->fb->format->format
|
- b.fb->pixel_format
+ b.fb->format->format
)

@@
struct drm_crtc *CRTC;
@@
(
- CRTC->primary->fb->pixel_format
+ CRTC->primary->fb->format->format
|
- CRTC->primary->state->fb->pixel_format
+ CRTC->primary->state->fb->format->format
)

@@
struct drm_mode_set *set;
@@
(
- set->fb->pixel_format
+ set->fb->format->format
|
- set->crtc->primary->fb->pixel_format
+ set->crtc->primary->fb->format->format
)

@@
@@
 struct drm_framebuffer {
	 ...
-	 uint32_t pixel_format;
	 ...
 };

v2: Fix commit message (Laurent)
    Rebase due to earlier removal of many fb->pixel_format uses,
    including the 'fb->format = drm_format_info(fb->format->format);'
    snafu
v3: Adjusted the semantic patch a bit and regenerated due to code
    changes

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481751175-18463-1-git-send-email-ville.syrjala@linux.intel.com
      438b74a5
    • V
      drm: Replace drm_format_plane_cpp() with fb->format->cpp[] · 353c8598
      由 Ville Syrjälä 提交于 
      Replace drm_format_plane_cpp(fb->pixel_format) with just
fb->format->cpp[]. Avoids the expensive format info lookup.

@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
expression E;
@@
(
- drm_format_plane_cpp(a->pixel_format, E)
+ a->format->cpp[E]
|
- drm_format_plane_cpp(b.pixel_format, E)
+ b.format->cpp[E]
)

@@
struct drm_plane_state *a;
struct drm_plane_state b;
expression E;
@@
(
- drm_format_plane_cpp(a->fb->pixel_format, E)
+ a->fb->format->cpp[E]
|
- drm_format_plane_cpp(b.fb->pixel_format, E)
+ b.fb->format->cpp[E]
)

@@
struct drm_framebuffer *a;
identifier T;
expression E;
@@
  T = a->pixel_format
<+...
- drm_format_plane_cpp(T, E)
+ a->format->cpp[E]
...+>

@@
struct drm_framebuffer b;
identifier T;
expression E;
@@
  T = b.pixel_format
<+...
- drm_format_plane_cpp(T, E)
+ b.format->cpp[E]
...+>

v2: Rerun spatch due to code changes

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Suggested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481751057-18123-1-git-send-email-ville.syrjala@linux.intel.com
      353c8598
  37. 13 11月, 2016 1 次提交
    • J
      drm/sun4i: constify component_ops structures · dfeb693d
      由 Julia Lawall 提交于 
      These component_ops structures are only used as the second argument to
component_add and component_del, which are declared as const, so the
structures can be declared as const as well.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@

static struct component_ops i@p = { ... };

@ok1@
identifier r.i;
expression e1;
position p;
@@

component_add(e1,&i@p)

@ok2@
identifier r.i;
expression e1;
position p;
@@

component_del(e1, &i@p)

@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct component_ops e;
@@

e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@

static
+const
 struct component_ops i = { ... };
// </smpl>

The result of the size command before the change is (arm):

   text       data         bss     dec      hex filename
   5266        236           8    5510     1586 sun4i_backend.o
   6393        236           8    6637     19ed sun4i_tcon.o
   3700        368           8    4076      fec sun4i_tv.o
   1668        108           0    1776      6f0 sun6i_drc.o

and after the change:

   text       data         bss     dec     hex filename
   5274        228           8    5510    1586 sun4i_backend.o
   6401        228           8    6637    19ed sun4i_tcon.o
   3708        360           8    4076     fec sun4i_tv.o
   1676        100           0    1776     6f0 sun6i_drc.o
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478971198-3659-1-git-send-email-Julia.Lawall@lip6.fr
      dfeb693d
  39. 03 11月, 2016 1 次提交
  41. 20 10月, 2016 1 次提交