summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/sun4i/sun4i_backend.c
AgeCommit message (Collapse)Author
2018-02-22drm/sun4i: backend: Remove ARGB spoofingMaxime Ripard
We've had some code for quite some time to prevent the alpha bug from happening on the lowest primary plane. Since we now check for this in our atomic_check, we can simply remove it. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/965180afd8169ccaa848f061d16a2c1a9ec4d289.1518802627.git-series.maxime.ripard@bootlin.com
2018-02-22drm/sun4i: backend: Assign the pipes automaticallyMaxime Ripard
Since we now have a way to enforce the zpos, check for the number of alpha planes, the only missing part is to assign our pipe automatically instead of hardcoding it. The algorithm is quite simple, but requires two iterations over the list of planes. In the first one (which is the same one that we've had to check for alpha, the frontend usage, and so on), we order the planes by their zpos. We can then do a second iteration over that array by ascending zpos starting with the pipe 0. When and if we encounter our alpha plane, we put it and all the other subsequent planes in the second pipe. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e9caf21d831438d36a3ccc7cef229c9a7ea7f69f.1518802627.git-series.maxime.ripard@bootlin.com
2018-01-29drm/sun4i: backend: Check for the number of alpha planesMaxime Ripard
Due to the way the composition is done in hardware, we can only have a single alpha-enabled plane active at a time, placed in the second (highest priority) pipe. Make sure of that in our atomic_check to not end up in an impossible scenario. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/7371f62a1385f2cbe3ed75dfca2e746338eb2286.1516617243.git-series.maxime.ripard@free-electrons.com
2018-01-29drm/sun4i: backend: Add support for zposMaxime Ripard
Our various planes have a configurable zpos, that combined with the pipes allow to configure the composition. Since the interaction between the pipes, zpos and alphas framebuffers is not trivial, let's just enable the zpos as an immutable property for now, and use that zpos in our atomic_update part. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/b006853e908bd06661c5bc1f2191121523bce0e4.1516617243.git-series.maxime.ripard@free-electrons.com
2018-01-22drm/sun4i: backend: Make sure we don't have a commit pendingMaxime Ripard
If we try to read the backend registers while it fetches the new values, we end up with the value of some random register instead of the one we asked for. In order to prevent that, let's make sure that the very first thing we do during our atomic modesetting is to let the commit bit come to a rest. We don't have to worry about anything else since the only time we will trigger a new transaction is during the atomic_commit which comes much later. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/35604307e5bde2b85c674de79fa7c4d55700f085.1516613040.git-series.maxime.ripard@free-electrons.com
2018-01-22drm/sun4i: backend: Add a custom atomic_check for the frontendMaxime Ripard
Now that we have everything in place, we can start enabling the frontend. This is more difficult than one would assume since there can only be one plane using the frontend per-backend. We therefore need to make sure that the userspace will not try to setup multiple planes using it, since that would be impossible. In order to prevent that, we can create an atomic_check callback that will check that only one plane will effectively make use of the frontend in a given configuration, and will toggle the switch in that plane state so that the proper setup function can do their role. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/278e6c514a8311750fe627c7f28d58b3e2cbd825.1516613040.git-series.maxime.ripard@free-electrons.com
2018-01-22drm/sun4i: backend: Wire in the frontendMaxime Ripard
Now that we have a driver, we can make use of it. This is done by adding a flag to our custom plane state that will trigger whether we should use the frontend on that particular plane or not. The rest is just plumbing to set up the backend to not perform the DMA but receive its data from the frontend. Note that we're still not making any use of the frontend itself, as no one is setting the flag yet. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/cdffc25eab2d817820cc78cbd24f1f4b99902014.1516613040.git-series.maxime.ripard@free-electrons.com
2018-01-22drm/sun4i: backend: Allow a NULL plane pointer to retrieve the formatMaxime Ripard
The function converting the DRM format to its equivalent in the backend registers was assuming that we were having a plane. However, we might want to use that function when setting up a plane using the frontend, in which case we will not have a plane associated to the backend's layer. Yet, we still need to setup the format to the one output by the frontend. Test for NULL plane pointers before referencing them, so that we can work around it. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/bfbe4c2e8525a7542526b648d59a8f3546e905f1.1516613040.git-series.maxime.ripard@free-electrons.com
2018-01-22drm/sun4i: backend: Move line stride setup to buffer setup functionMaxime Ripard
Setup the line stride in the buffer setup function, since it's tied to the buffer itself, and is not needed when we do not set the buffer in the backend. This is for example the case when using the frontend and then routing its output to the backend. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/cbec84125bc0d5a6cf1d856b8291fbf77b138881.1516613040.git-series.maxime.ripard@free-electrons.com
2017-10-17drm/sun4i: Add support for A20 display pipeline componentsJonathan Liu
The A20 display pipeline has 2 frontends, 2 backends, and 2 TCONs. This patch adds support (or a compatible string in the frontend's case) for these components. The TCONs support directly outputting to CPU/RGB/LVDS LCD panels, or it can output to HDMI via an on-chip HDMI controller, or CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional encoders are not covered in this patch. Signed-off-by: Jonathan Liu <net147@gmail.com> [wens@csie.org: Expand commit message] Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-6-wens@csie.org
2017-10-17drm/sun4i: Add support for A10 display pipeline componentsChen-Yu Tsai
The A10 display pipeline has 2 frontends, 2 backends, and 2 TCONs. This patch adds support (or a compatible string in the frontend's case) for these components. The TCONs support directly outputting to CPU/RGB/LVDS LCD panels, or it can output to HDMI via an on-chip HDMI controller, or CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional encoders are not covered in this patch. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-5-wens@csie.org
2017-10-17drm/sun4i: backend: Support output muxingChen-Yu Tsai
The backend has a mux to select the destination of the data to output to. It can select the TCON or the frontends. On the A20, it includes an option to output to the second TCON. This is not documented in the user manual, but the vendor kernel uses it nevertheless, so the second backend outputs to the second TCON. Although the muxing can be changed on the fly, DRM needs to be able to group a bunch of layers such that they get switched to another crtc together. This is because the display backend does the layer compositing, while the TCON generates the display timings. This constraint is not supported by DRM. Here we simply pair up backends and TCONs with the same ID. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-2-wens@csie.org
2017-10-17drm/sun4i: backend: Offset layer buffer address by DRAM starting addressChen-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: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171017042349.31743-6-wens@csie.org
2017-10-16drm/sun4i: backend: Add comment explaining why registers are clearedChen-Yu Tsai
Many of the backend's layer configuration registers have undefined default values. This poses a risk as we use regmap_update_bits in some places, and don't overwrite the whole register. At probe/bind time we explicitly clear all the control registers by writing 0 to them. This patch adds a more detailed explanation on why we're doing this. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-5-wens@csie.org
2017-10-16drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memoryChen-Yu Tsai
Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()") adds a new helper, which covers fetching a drm_framebuffer's GEM object and calculating the buffer address for a given plane. This patch uses this helper to replace our own open coded version of the same function. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-4-wens@csie.org
2017-10-16drm/sun4i: backend: Create regmap after access is possibleChen-Yu Tsai
The backend has various clocks and reset controls that need to be enabled and deasserted before register access is possible. Move the creation of the regmap to after the clocks and reset controls have been configured where it makes more sense. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-3-wens@csie.org
2017-08-23drm/sun4i: use of_graph_get_remote_endpoint()Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-06-01drm/sun4i: abstract a engine typeIcenowy 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: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-05-14drm/sun4i: backend: Clarify sun4i_backend_layer_enable debug messageChen-Yu Tsai
sun4i_backend_layer_enable can be called to enable or disable a layer. However the debug message always says "Enable", which is confusing. This patch makes the debug message vary according to the enable state. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-05-14drm/sun4i: backend: Save pointer to device tree nodeChen-Yu Tsai
Save a pointer to the backend's underlying device tree node in its data structure. This will be used later for downstream tcons to find and match their respective upstream backends. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-05-14drm/sun4i: backend: Fetch backend ID from device treeChen-Yu Tsai
Some Allwinner SoCs have 2 display pipelines, as in 2 of each components, including the frontend, backend, TCON, and any other extras. As the backend and TCON are always paired together and form the CRTC, we need to know which backend or TCON we are currently probing, so we can pair them when initializing the CRTC. This patch figures out the backend's ID from the device tree and stores it in the backend's data structure. It does this by looking at the "reg" property of any remote endpoints connected to the backend's input port. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-05-14drm/sun4i: backend: Drop trailing 0 from backend in error messageChen-Yu Tsai
Now that we support multiple instances of backends, the trailing 0 implying only one backend no longer makes sense. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-05-14drm/sun4i: Use lists to track registered display backends and TCONsChen-Yu Tsai
To support multiple display pipelines, we need to keep track of the multiple display backends and TCONs registered with the driver. Switch to lists to track registered components. Components are only appended to their respective lists if the bind process was successful. The TCON bind function now defers if a backend was not registered. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-03-07drm/sun4i: Make sunxi_rgb2yuv_coef constantChen-Yu Tsai
sunxi_rgb2yuv_coef is a table of RGB-to-YUV conversion coefficients. They are programmed into the hardware, and can be declared constant. Reported-by: Priit Laes <plaes@plaes.org> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-02-01Merge tag 'sunxi-drm-for-4.11' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next Allwinner DRM changes for 4.11 Just one minor fix. * tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: drm/sun4i: Fix a return value in case of error
2017-01-02drm/sun4i: Fix a return value in case of errorChristophe JAILLET
If 'sun4i_backend_drm_format_to_layer()' does not return 0, then 'val' is left unmodified. As it is not initialized either, the return value can be anything. It is likely that returning the error code was expected here. As the only caller of 'sun4i_backend_update_layer_formats()' does not check the return value, this fix is purely theorical. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-12-15drm: Nuke fb->pixel_formatVille 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481751175-18463-1-git-send-email-ville.syrjala@linux.intel.com
2016-12-15drm: Replace drm_format_plane_cpp() with fb->format->cpp[]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: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481751057-18123-1-git-send-email-ville.syrjala@linux.intel.com
2016-11-17Merge tag 'drm-misc-next-2016-11-16' of ↵Dave Airlie
git://anongit.freedesktop.org/git/drm-misc into drm-next Another pile of misc: - Explicit fencing for atomic! Big thanks to Gustavo, Sean, Rob 3x, Brian and anyone else I've forgotten to make this happen. - roll out fbdev helper ops to drivers (Stefan Christ) - last bits of drm_crtc split-up&kerneldoc - some drm_irq.c crtc functions cleanup - prepare_fb helper for cma, works correctly with explicit fencing (Marek Vasut) - misc small patches all over * tag 'drm-misc-next-2016-11-16' of git://anongit.freedesktop.org/git/drm-misc: (51 commits) drm/fence: add out-fences support drm/fence: add fence timeline to drm_crtc drm/fence: add in-fences support drm/bridge: analogix_dp: return error if transfer none byte drm: drm_irq.h header cleanup drm/irq: Unexport drm_vblank_on/off drm/irq: Unexport drm_vblank_count drm/irq: Make drm_vblank_pre/post_modeset internal drm/nouveau: Use drm_crtc_vblank_off/on drm/amdgpu: Use drm_crtc_vblank_on/off for dce6 drm/color: document NULL values and default settings better drm: Drop externs from drm_crtc.h drm: Move tile group code into drm_connector.c drm: Extract drm_mode_config.[hc] Revert "drm: Add aspect ratio parsing in DRM layer" Revert "drm: Add and handle new aspect ratios in DRM layer" drm/print: Move kerneldoc next to definition drm: Consolidate dumb buffer docs drm: Clean up kerneldoc for struct drm_driver drm: Extract drm_drv.h ...
2016-11-13drm/sun4i: constify component_ops structuresJulia 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: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478971198-3659-1-git-send-email-Julia.Lawall@lip6.fr
2016-11-02drm/sun4i: Add a few formatsMaxime Ripard
The planes can do more than what was previously exposed. Add support for them. Since we still have the issue that the primary plane cannot have any alpha component, we will expose only the non-alpha formats in the primary formats, and the alpha formats will be exposed in the overlays. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
2016-10-20drm/sun4i: Add compatible strings for A31/A31s display pipelinesChen-Yu Tsai
The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It also has new display enhancement blocks, such as the DRC (Dynamic Range Controller), the DEU (Display Enhancement Unit), and the CMU (Color Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels. The A31s display pipeline is almost the same, just without MIPI DSI. Only the TCON seems to be different, due to the missing mux for MIPI DSI. Add compatible strings for both of them. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-09-22drm/sun4i: Fix formats usable by the primary planeMaxime Ripard
Even though all our planes can support the ARGB formats, the lowest plane (ie the primary plane) cannot use the alpha component, otherwise it will just result in the transparent area being entirely black. Since some applications will still require the ARGB format, let's force the format to XRGB to drop the alpha component entirely. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-09-18drm/sun4i: backend: remove redundant dev_err call in sun4i_backend_bind()Wei Yongjun
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-09-08drm/sun4i: backend: Handle the SATMaxime Ripard
The A33 has an block called SAT that is part of the backend that needs to be clocked and out of reset to be able for the backend to operate properly. Extend the binding to have the SAT resources listed, and claim them when the backend probes. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
2016-09-08drm/sun4i: support A33 tconMaxime Ripard
The A33 has a significantly different pipeline, with components that differ too. Make sure we had compatible for them. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
2016-05-30drm: sun4i: print DMA address correctlyArnd Bergmann
The newly added sun4i drm driver prints a dma address using the %x format string, which cannot work when dma_addr_t is 64 bit, and gcc warns about this configuration: drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer': drm/sun4i/sun4i_backend.c:193:84: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=] DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr); drm/sun4i/sun4i_backend.c:201:84: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=] DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr); This changes the code to use the explicit %pad format string, which always prints the right length. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-04-28drm: Add Allwinner A10 Display Engine supportMaxime Ripard
The Allwinner A10 and subsequent SoCs share the same display pipeline, with variations in the number of controllers (1 or 2), or the presence or not of some output (HDMI, TV, VGA) or not. Add a driver with a limited set of features for now, and we will hopefully support all of them eventually Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-04-05 15:54:31 +0000