Commit db2395eccf08i ("drm: Convert drm_vma_manager to embedded
interval-tree in drm_mm") removed a line in drm_vma_offset_add() function that
makes checking the result of calling drm_mm_insert_node() and the goto
call redundant. Rework the function (as suggested by Chris Wilson) to
eliminate the need for the goto and associated label.
v2: rewrite function to remove all goto statements.
Fixes: db2395eccf08i ("drm: Convert drm_vma_manager to embedded interval-tree in drm_mm")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171101144458.5353-1-Liviu.Dudau@arm.com
drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
struct drm_device. This makes it possible to add callback helpers for
.last_close and .output_poll_changed further reducing fbdev emulation
footprint in drivers. The pointer is set by drm_fb_helper_init() and
cleared by drm_fb_helper_fini().
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171030153951.56269-3-noralf@tronnes.org
DRM core uses reference/unreference suffixes for refcounting
functions, but kernel uses get/put (e.g. kref_get/put()).
Replace reference/unreference with get/put for consistency
and also it's shorter.
The following cocci script was used to generate the patch:
@@
expression e;
@@
(
-drm_gem_object_reference(e);
+drm_gem_object_get(e);
|
-drm_gem_object_unreference(e);
+drm_gem_object_put(e);
|
-drm_gem_object_unreference_unlocked(e);
+drm_gem_object_put_unlocked(e);
)
Signed-off-by: Aastha Gupta <aastha.gupta4104@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1508776686-29664-1-git-send-email-aastha.gupta4104@gmail.com
VC4's DSI1 has a bug where the AXI connection is broken for 32-bit
writes from the CPU, so we use the DMA engine to DMA 32-bit values
into registers instead. That sleeps, so we can't do it from the top
half.
As a solution, use an interrupt thread so that all our writes happen
when sleeping is is allowed.
v2: Use IRQF_ONESHOT (suggested by Boris)
v3: Style nitpicks.
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014001255.32005-1-eric@anholt.net
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> (v2)
This ioctl will allow us to purge inactive userspace buffers when the
system is running out of contiguous memory.
For now, the purge logic is rather dumb in that it does not try to
release only the amount of BO needed to meet the last CMA alloc request
but instead purges all objects placed in the purgeable pool as soon as
we experience a CMA allocation failure.
Note that the in-kernel BO cache is always purged before the purgeable
cache because those objects are known to be unused while objects marked
as purgeable by a userspace application/library might have to be
restored when they are marked back as unpurgeable, which can be
expensive.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019125748.3152-1-boris.brezillon@free-electrons.com
At least when they have vblank support they need to call this, or the
vblank core will happily call into their crtc->enable_vblank callback
even when the crtc is off. Which leads to a boom when the clocks are
off on most hardware (besides the inevitable confusion in the
book-keeping).
The consistency checks in drm_vblank.c will then make sure that
vblank_off/on calls are balanced, and if drivers forget to re-enable
it all the commits will stall, so I think we're covered.
It'd be nice to be able to place this check outside of commit helpers,
but tha's not really possible (due to nonblocking commits and all
that). Placing it into atomic helpers should at least cover most
drivers.
Also note that vblank support is still optional (for virtual drivers,
which tend to not have this), check for that.
v2: Fixup the handling for vblank_put (Rob).
Cc: Rob Clark <robdclark@gmail.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017152714.6849-1-daniel.vetter@ffwll.ch
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
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
The A10 has two TCONs that are similar to the ones found on other SoCs.
Like the A31, TCON0 has a register used to mux the TCON outputs to the
downstream encoders. The bit fields are slightly different.
Signed-off-by: Jonathan Liu <net147@gmail.com>
[wens@csie.org: Reworked for A10 and fixed up 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-3-wens@csie.org
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
So far, we've required all the TCON-connected encoders to call the TCON
enable and disable functions.
This was made this way because in the RGB/LVDS case, the TCON is the CRTC
and the encoder. However, in all the other cases (HDMI, TV, DSI, etc.), we
have another encoder down the road that needs to be programmed.
We also needed to know which channel the encoder is connected to, which is
encoder-specific.
The CRTC's enable and disable callbacks can work just fine for our use
case, and we can get the channel to use just by looking at the type of
encoder, since that is fixed. Implement those callbacks, which will
remove some of the encoder boilerplate.
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/90b4396e19b3eca61b2ebfdae0672074b88ad74d.1508231063.git-series.maxime.ripard@free-electrons.com
The commit da82b8785e ("drm/sun4i: add components in breadth first
traversal order") implemented a breadth first traversal of our device tree
nodes graph. However, it was relying on the kernel linked lists, and those
are not really safe for addition.
Indeed, in a single pipeline stage, your first stage (ie, the mixer or
fronted) will be queued, and it will be the final iteration of that list as
far as list_for_each_entry_safe is concerned. Then, during that final
iteration, we'll queue another element (the TCON or the backend) that
list_for_each_entry_safe will not account for, and we will leave the loop
without having iterated over all the elements. And since we won't have
built our components list properly, the DRM driver will be left
non-functional.
We can instead use a kfifo to queue and enqueue components in-order, as was
the original intention. This also has the benefit of removing any dynamic
allocation, making the error handling path simpler too. The only thing
we're losing is the ability to tell whether an element has already been
queued, but that was only needed to remove spurious logs, and therefore
purely cosmetic.
This means that this commit effectively reverses e8afb7b67f ("drm/sun4i:
don't add components that are already in the queue").
Fixes: da82b8785e ("drm/sun4i: add components in breadth first traversal order")
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/4ecb323e787918208f6a5d9f0ebba12c62583c98.1508231063.git-series.maxime.ripard@free-electrons.com
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: 9026e0d122 ("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
This patch replace instances of drm_gem_object_reference/unreference with
*_get/put() suffixes, because get/put is shorter and consistent with the
kernel use of *_get/put() suffixes.
This was done with the following Coccinelle script:
@r1@
expression e;
@@
(
-drm_gem_object_reference(e);
+drm_gem_object_get(e);
|
-drm_gem_object_unreference(e);
+drm_gem_object_put(e);
|
-drm_gem_object_unreference_unlocked(e);
+drm_gem_object_put_unlocked(e);
)
Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
[resolved small conflict with removed armada_gem_dumb_map_offset]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/a59ef1ed109ade897bcffcb01b33214262db8942.1505932812.git.hamohammed.sa@gmail.com
Initially we configured the PAD_CTRL1 register at probe/bind time.
However it seems the HDMI controller will modify some of the bits
in this register by itself. On the A10 it is particularly annoying
as it toggles the output invert bits, which inverts the colors on
the display output.
The U-boot driver this driver is based on sets this register twice,
though it seems it's only needed for actual display output. Hence
we move it to the mode_set 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-8-wens@csie.org
While debugging inverted color from the HDMI output on the A10, I
found that the lowest 3 bits were set. These were cleared on A20
boards that had normal display output. By manually toggling these
bits the mapping of the color components to these bits was found.
While these are not used anywhere, it would be nice to document
them somewhere.
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-7-wens@csie.org
