The Amlogic Meson Display controller is composed of several components :

DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
   | vd1   _______     _____________    _________________     |               |
D  |-------|      |----|            |   |                |    |   HDMI PLL    |
D  | vd2   | VIU  |    | Video Post |   | Video Encoders |<---|-----VCLK      |
R  |-------|      |----| Processing |   |                |    |               |
   | osd2  |      |    |            |---| Enci ----------|----|-----VDAC------|
R  |-------| CSC  |----| Scalers    |   | Encp ----------|----|----HDMI-TX----|
A  | osd1  |      |    | Blenders   |   | Encl ----------|----|---------------|
M  |-------|______|----|____________|   |________________|    |               |
___|__________________________________________________________|_______________|

VIU: Video Input Unit
---------------------

The Video Input Unit is in charge of the pixel scanout from the DDR memory.
It fetches the frames addresses, stride and parameters from the "Canvas" memory.
This part is also in charge of the CSC (Colorspace Conversion).
It can handle 2 OSD Planes and 2 Video Planes.

VPP: Video Post Processing
--------------------------

The Video Post Processing is in charge of the scaling and blending of the
various planes into a single pixel stream.
There is a special "pre-blending" used by the video planes with a dedicated
scaler and a "post-blending" to merge with the OSD Planes.
The OSD planes also have a dedicated scaler for one of the OSD.

VENC: Video Encoders
--------------------

The VENC is composed of the multiple pixel encoders :
 - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
 - ENCP : Progressive Video Encoder for HDMI
 - ENCL : LCD LVDS Encoder
The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
tree and provides the scanout clock to the VPP and VIU.
The ENCI is connected to a single VDAC for Composite Output.
The ENCI and ENCP are connected to an on-chip HDMI Transceiver.

This driver is a DRM/KMS driver using the following DRM components :
 - GEM-CMA
 - PRIME-CMA
 - Atomic Modesetting
 - FBDev-CMA

For the following SoCs :
 - GXBB Family (S905)
 - GXL Family (S905X, S905D)
 - GXM Family (S912)

The current driver only supports the CVBS PAL/NTSC output modes, but the
CRTC/Planes management should support bigger modes.
But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
a second time.

The Device Tree bindings makes use of the endpoints video interface definitions
to connect to the optional CVBS and in the future the HDMI Connector nodes.

HDMI Support is planned for a next release.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

For both the new degamm/lut/gamma atomic combo, and the old legacy
gamma tables.
Acked-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1474448370-32227-5-git-send-email-daniel.vetter@ffwll.ch

Just pure code movement, cleanup and polish will happen in later
patches.

v2: Don't forget all the ioctl! To extract those cleanly I decided to
put check_src_coords into drm_framebuffer.c (and give it a
drm_framebuffer_ prefix), since that just checks framebuffer
constraints.

v3: rebase over PAGE_FLIP_TARGET.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

[seanpaul]
This patch as posted on the list was rebased on:

commit 6f00975c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Aug 20 12:22:11 2016 +0200

    drm: Reject page_flip for !DRIVER_MODESET

so as a result of moving the page_flip ioctl, this fix has
been rolled into this patch.
Signed-off-by: NSean Paul <seanpaul@chromium.org>

This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.

v2: resurrect misplaced hunk (Daniel Stone)

Cc: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-7-daniel.vetter@ffwll.ch

Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.

v2:
- Also move the generic get/set property ioctls. At first this seemed
  like a bad idea since it requires making drm_mode_crtc_set_obj_prop
  non-static. But eventually that will get split away too (like
  the connector version already is) for both crtc and planes. Hence I
  reconsidered.

- drm_mode_object.[hc] instead of drm_modeset.[hc], which requires
  renaming the drm_modeset.h header I already started building up.
  This is more consistent (matches the name of the main structure),
  and I want to be able to use drm_modeset.[hc] for the basic modeset
  init/cleanup functionality like drm_mode_config_init.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-3-daniel.vetter@ffwll.ch

Same treatment as before. Only hiccup is drm_crtc_mask, which
unfortunately can't be resolved until drm_crtc.h is less of a monster.
Untangle the header loop with a forward declaration for that static
inline.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-1-daniel.vetter@ffwll.ch

Very old numbers indicate this is a 66% improvement when remapping the
entire object for fence contention - due to the elimination of
track_pfn_insert and its strcmp.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/gem_fence_upload/performance
Testcase: igt/gem_mmap_gtt
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160819155428.1670-6-chris@chris-wilson.co.uk

There's not much point in kerneldoc if it's not included:
- It won't show up in the pretty html pages.
- The comments itself won't get parsed, which means 0day won't pick up
  changes, resulting in stale docs fast.

Also, uapi really should be core, not helpers, so move drm_blend.c to
that. That also means that the zpos normilize function loses it's
helper status (and we might as well call it always). For that,
EXPORT_SYMBOL. Just spotted while integrating docs and noticing that
one was missing.

With sphinx there's really no excuse any more to not build the docs
and make sure it's all nice!

$ make DOCBOOKS="" htmldocs

Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-15-git-send-email-daniel.vetter@ffwll.ch

Pulls in quite a lot of connector related structures (cmdline mode,
force/status enums, display info), but I think that all makes perfect
sense.

Also had to move a few more core kms object stuff into drm_modeset.h.

And as a first cleanup remove the kerneldoc for the 2 connector IOCTL
- DRM core docs are aimed at drivers, no point documenting internal in
excruciating detail.

v2: And also pull in all the connector property code.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-14-git-send-email-daniel.vetter@ffwll.ch

Also start with drm_modeset.h with the core bits, since we need
to untangle this mess somehow. That allows us to move the drm_modes.h
include to the right spot, except for the temporary connector status
enum. That will get fixed as soon as drm_connector.h exists.

v2: Rebase.

v3: Move drm_crtc_force_disable_all back again, that wasn't meant to
be moved (Sean).

v4: Rebase.

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While reviewing docs I spotted that we have a few functions that
really just don't fit into their containing helper library section.
Extract them and shovel them all into a new library for random one-off
aux stuff.

v2: Remove wrongly added files for real.

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-3-git-send-email-daniel.vetter@ffwll.ch

version 8:
- move drm_blend.o from drm-y to drm_kms_helper-y to avoid
  EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos)
- remove dead function declarations in drm_crtc.h

version 7:
- remove useless EXPORT_SYMBOL()
- better z-order wording in Documentation

version 6:
- add zpos in gpu documentation file
- merge Ville patch about zpos initial value and API improvement.
  I have split Ville patch between zpos core and drivers

version 5:
- remove zpos range check and comeback to 0 to N-1
  normalization algorithm

version 4:
- make sure that normalized zpos value is stay
  in the defined property range and warn user if not

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Cc: Inki Dae <inki.dae@samsung.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: vincent.abriou@st.com
Cc: fabien.dessenne@st.com
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Provides helper functions for drivers that have a simple display
pipeline. Plane, crtc and encoder are collapsed into one entity.

Changes since v4:
- Remove drm_connector_register() call
- Forgot to assign pipe->connector

Changes since v3:
- (struct drm_simple_display_pipe *)->funcs should be const

Changes since v2:
- Drop Kconfig knob DRM_KMS_HELPER
- Expand documentation

Changes since v1:
- Add DOC header and add to gpu.tmpl
- Fix docs: @funcs is optional, "negative error code",
  "This hook is optional."
- Add checks to drm_simple_kms_plane_atomic_check()

Cc: jsarha@ti.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465570559-14238-1-git-send-email-noralf@tronnes.org

The drm_crtc.c file is a mess, making the ABI documentation confusing
since all functions are in the same bag. Split the format-related
helpers to a new drm_fourcc.c file.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465466048-2020-1-git-send-email-laurent.pinchart@ideasonboard.com

Add a helper which aids in the identification of DP dual mode
(aka. DP++) adaptors. There are several types of adaptors
specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI

Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz and they provide a register informing the
source device what the actual limit is. Supposedly also type 1 adaptors
may optionally implement this register. This TMDS clock limit is the
main reason why we need to identify these adaptors.

Type 1 adaptors provide access to their internal registers and the sink
DDC bus through I2C. Type 2 adaptors provide this access both via I2C
and I2C-over-AUX. A type 2 source device may choose to implement either
of these methods. If a source device implements the I2C-over-AUX
method, then the driver will obviously need specific support for such
adaptors since the port is driven like an HDMI port, but DDC
communication happes over the AUX channel.

This helper should be enough to identify the adaptor type (some
type 1 DVI adaptors may be a slight exception) and the maximum TMDS
clock limit. Another feature that may be available is control over
the TMDS output buffers on the adaptor, possibly allowing for some
power saving when the TMDS link is down.

Other user controllable features that may be available in the adaptors
are downstream i2c bus speed control when using i2c-over-aux, and
some control over the CEC pin. I chose not to provide any helper
functions for those since I have no use for them in i915 at this time.
The rest of the registers in the adaptor are mostly just information,
eg. IEEE OUI, hardware and firmware revision, etc.

v2: Pass adaptor type to helper functions to ease driver implementation
    Fix a bunch of typoes (Paulo)
    Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
    the type (Paulo)
    Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
    Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
    ease future LSPCON enabling
    Remove the unused DP_DUAL_MODE_LAST_RESERVED define
v3: Fix kernel doc function argument descriptions (Jani)
    s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
    Add kernel doc for enum drm_dp_dual_mode_type
    Actually build the docs
    Fix more typoes
v4: Adjust code indentation of type2 adaptor detection (Shashank)
    Add debug messages for failurs cases (Shashank)
v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)

Cc: stable@vger.kernel.org
Cc: Tore Anderson <tore@fud.no>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit ede53344)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Add a helper which aids in the identification of DP dual mode
(aka. DP++) adaptors. There are several types of adaptors
specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI

Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz and they provide a register informing the
source device what the actual limit is. Supposedly also type 1 adaptors
may optionally implement this register. This TMDS clock limit is the
main reason why we need to identify these adaptors.

Type 1 adaptors provide access to their internal registers and the sink
DDC bus through I2C. Type 2 adaptors provide this access both via I2C
and I2C-over-AUX. A type 2 source device may choose to implement either
of these methods. If a source device implements the I2C-over-AUX
method, then the driver will obviously need specific support for such
adaptors since the port is driven like an HDMI port, but DDC
communication happes over the AUX channel.

This helper should be enough to identify the adaptor type (some
type 1 DVI adaptors may be a slight exception) and the maximum TMDS
clock limit. Another feature that may be available is control over
the TMDS output buffers on the adaptor, possibly allowing for some
power saving when the TMDS link is down.

Other user controllable features that may be available in the adaptors
are downstream i2c bus speed control when using i2c-over-aux, and
some control over the CEC pin. I chose not to provide any helper
functions for those since I have no use for them in i915 at this time.
The rest of the registers in the adaptor are mostly just information,
eg. IEEE OUI, hardware and firmware revision, etc.

v2: Pass adaptor type to helper functions to ease driver implementation
    Fix a bunch of typoes (Paulo)
    Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
    the type (Paulo)
    Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
    Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
    ease future LSPCON enabling
    Remove the unused DP_DUAL_MODE_LAST_RESERVED define
v3: Fix kernel doc function argument descriptions (Jani)
    s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
    Add kernel doc for enum drm_dp_dual_mode_type
    Actually build the docs
    Fix more typoes
v4: Adjust code indentation of type2 adaptor detection (Shashank)
    Add debug messages for failurs cases (Shashank)
v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)

Cc: stable@vger.kernel.org
Cc: Tore Anderson <tore@fud.no>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com

This patch adds an initial DRM driver for the Mediatek MT8173 DISP
subsystem. It currently supports two fixed output streams from the
OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
Signed-off-by: NCK Hu <ck.hu@mediatek.com>
Signed-off-by: NYT Shen <yt.shen@mediatek.com>
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NMao Huang <littlecvr@chromium.org>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>

Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

v9: Add OF and ARM64 depends on in Kconfig
v8: None.
v7:
- Add config.mutex protection when accessing mode_config.connector_list.
- Clean up match data getting.
v6: None.
v5: None.
v4: None.
v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Replace drm_platform_init, load, unload implementation.
v2:
- Remove abtraction layer.
Signed-off-by: NXinliang Liu <xinliang.liu@linaro.org>
Signed-off-by: NXinwei Kong <kong.kongxinwei@hisilicon.com>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: NCarlos Palminha <palminha@synopsys.com>
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-snps-arc@lists.infradead.org

This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.

It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector device pointer was correctly set in the aux helper struct.

Two main operations are provided on the registers read and write. The
address of the register to be read or written is given using lseek. The
seek position is updated upon read or write.

v2:
 - lseek is used to select the register to read/write
 - read/write are used instead of ioctl
 - no blocking_notifier is used, just a direct callback

v3:
 - use drm_dp_aux_dev prefix for public functions
 - chardev is named drm_dp_auxN
 - read/write don't allocate a buffer anymore, and transfer up to 16 bytes a
   time
 - remove notifier list from the implementation
 - option on menuconfig is now a boolean
 - add inline stub functions to avoid breakage when this option is disabled

v4:
 - fix build system changes - actually disable this module when not selected.

v5:
 - Use kref to avoid device closing while still in use
 - Don't use list, use an idr for storing aux_dev
 - Remove "connector" attribute
 - set aux.dev to the connector drm_connector device, instead of
   drm_device

v6:
 - Use atomic_t for usage count
 - Use a mutex instead of spinlock for idr lock
 - Destroy chardev immediately on unregister
 - other minor suggestions from Ville

v7:
 - style fixes
 - error handling fixes

v8:
 - more error handling fixes

v9:
 - remove module_init and module_exit, and add drm_dp_aux_dev_init/exit
 to drm_kms_helper_init/exit.
Signed-off-by: NRafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-3-git-send-email-rafael.antognolli@intel.com

The module_init and module_exit functions will start here, and call the
subsequent init's and exit's.

v10:
 - Keep __init on drm_fb_helper init function.
 - Move MODULE_* macros to the common file.
Signed-off-by: NRafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-2-git-send-email-rafael.antognolli@intel.com

The HDLCD controller is a display controller that supports resolutions
up to 4096x4096 pixels. It is present on various development boards
produced by ARM Ltd and emulated by the latest Fast Models from the
company.

Cc: David Airlie <airlied@linux.ie>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
[Kconfig cleanup and !CONFIG_PM fixes]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that omapfb has its own copy of omapdss and display drivers, we can
move omapdss and display drivers which omapdrm uses to omapdrm's
directory.

We also need to change the main drm Makefile so that omapdrm directory
is always entered, because omapdss has a file that can't be built as a
module.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Acked-by: NRob Clark <robdclark@gmail.com>

This adds the etnaviv DRM driver and hooks it up in Makefiles
and Kconfig.
Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Kbuild now supports <modname>-m variables.

This reverts commit 8fa884dc.
Signed-off-by: NMichal Marek <mmarek@suse.cz>

This is enough for fbcon and bringing up X using
xf86-video-modesetting.  It doesn't support the 3D accelerator or
power management yet.

v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
    ordering instead of using the .load hook.  Structure registration
    more like tegra's, but still using the typical "component" code.
    Drop no-op hooks for atomic_begin and mode_fixup() now that
    they're optional.  Drop sentinel in Makefile.  Fix minor style
    nits I noticed on another reread.

v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
    of having a fixed video mode.  Use exynos-style component driver
    matching instead of devicetree nodes to list the component driver
    instances.  Rename compatibility strings to say bcm2835, and
    distinguish pv0/1/2.  Clean up some h/vsync code, and add in
    interlaced mode setup.  Fix up probe/bind error paths.  Use
    bitops.h macros for vc4_regs.h

v4: Include i2c.h, allow building under COMPILE_TEST, drop msleep now
    that other bugs have been fixed, add timeouts to cpu_relax()
    loops, rename hpd-gpio to hpd-gpios.
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Surprisingly kbuild can't cope with tristates in the
<module>-$(CONFIG_FOO) pattern. This patch hacks up a solution.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Michal Marek <mmarek@suse.com>
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.

Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.

v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville

v3: Polish from Ville's review.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA8888 BGRA4444 ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.
This is a simplified version, only one primary plane, one
framebuffer, one crtc, one connector and one encoder for TFT
LCD panel.
Signed-off-by: NAlison Wang <b18965@freescale.com>
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: NJianwei Wang <jianwei.wang.chn@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by
selecting KMS FB helpers. A few provide a separate Kconfig option for the
user to enable or disbale fbdev emulation.

Enabling fbdev emulation is finally a distro-level decision. Having a top
level Kconfig option for fbdev emulation helps by providing a uniform way
to enable/disable fbdev emulation for any modesetting driver. It also lets
us remove unnecessary driver specific Kconfig options that causes bloat.

With a top level Kconfig in place, we can stub out the fb helper functions
when not needed without breaking functionality. Having stub functions also
prevents drivers to require wrapping fb helper function calls with #ifdefs.

DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev
emulation by default and majority of distributions expect the fbdev
interface in the kernel.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds the non-asic specific core driver code.

v2: remove extra kconfig option
v3: implement minor fixes from Fengguang Wu
v4: fix cast in amdgpu_ucode.c
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NJammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This patch adds a kms driver for the virtio gpu.  The xorg modesetting
driver can handle the device just fine, the framebuffer for fbcon is
there too.

Qemu patches for the host side are under review currently.

The pci version of the device comes in two variants: with and without
vga compatibility.  The former has a extra memory bar for the vga
framebuffer, the later is a pure virtio device.  The only concern for
this driver is that in the virtio-vga case we have to kick out the
firmware framebuffer.

Initial revision has only 2d support, 3d (virgl) support requires
some more work on the qemu side and will be added later.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>

If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
patch should not be needed. However, without this patch the objects
needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is
built as module.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This results in a warning when building out of tree:
"cc1: warning: include/drm: No such file or directory [enabled by default]"

Most code already uses #include <drm/foo.h> correctly, so fix the
instances that don't.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch implements the virtual GEM driver with PRIME sharing which
allows vgem to import a gem object from other drivers for the purpose
of mmap-ing them to userspace. The mmap is done using the mmap
operation exported by other drivers.

v2: remove platform_device and do not attach to dma bufs
v3: use drm helpers for get/put pages
v4: correct dumb create pitch

Reviewed-by: Rob Clark <robdclark@gmail.com> (v3)
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> (v3)
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NZach Reizner <zachr@google.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.

In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
	  add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
	  for the corresponding bridge so that the bridge receives
	  drm_device pointer and continues with connector and other
	  drm initializations.

The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.

The bridge devices register themselves onto global list of bridges
when they get probed by calling "drm_bridge_add".

The parent encoder driver waits till the bridge is available
in the lookup table(by calling "of_drm_find_bridge") and then
continues with its initialization.

The encoder driver should also call "drm_bridge_attach" to pass
on the drm_device to the bridge object.

drm_bridge_attach inturn calls "bridge->funcs->attach" so that
bridge can continue with drm related initializations.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Tested-by: NRahul Sharma <rahul.sharma@samsung.com>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

At the moment, this driver only implements an RGB connector to interface
with LCD panels, but support for other kind of external devices might be
added later.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Tested-by: NAnthony Harivel <anthony.harivel@emtrion.de>
Tested-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>

When amdkfd and radeon are compiled inside the kernel image (not as modules),
radeon will load before amdkfd, which will cause a bug when radeon will probe
the GPUs.

When the two drivers are compiled as modules, amdkfd is loaded after radeon is
loaded but before radeon starts probing the GPUs. This is done because radeon
loads the amdkfd module through symbol_request function.

This patch makes amdkfd load before radeon when they are both compiled inside
the kernel image, which makes the behavior similar to the case when they are
modules, and prevents the kernel bug.
Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>