<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/gpu/drm/Makefile, branch v4.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v4.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2015-08-20T02:23:04Z</updated>
<entry>
<title>drm/layerscape: Add Freescale DCU DRM driver</title>
<updated>2015-08-20T02:23:04Z</updated>
<author>
<name>Jianwei Wang</name>
<email>jianwei.wang.chn@gmail.com</email>
</author>
<published>2015-08-20T02:19:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=109eee2f2a181a89a26f6b59b83b50ebab281d4d'/>
<id>urn:sha1:109eee2f2a181a89a26f6b59b83b50ebab281d4d</id>
<content type='text'>
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: Alison Wang &lt;b18965@freescale.com&gt;
Signed-off-by: Xiubo Li &lt;lixiubo@cmss.chinamobile.com&gt;
Signed-off-by: Jianwei Wang &lt;jianwei.wang.chn@gmail.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
<entry>
<title>drm: Add top level Kconfig option for DRM fbdev emulation</title>
<updated>2015-08-06T12:13:08Z</updated>
<author>
<name>Archit Taneja</name>
<email>architt@codeaurora.org</email>
</author>
<published>2015-08-05T06:58:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a03fdcb1863297481a4b817c2a759cafcbdfa0ae'/>
<id>urn:sha1:a03fdcb1863297481a4b817c2a759cafcbdfa0ae</id>
<content type='text'>
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: Archit Taneja &lt;architt@codeaurora.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: add core driver (v4)</title>
<updated>2015-06-04T01:03:15Z</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2015-04-20T20:55:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d38ceaf99ed015f2a0b9af3499791bd3a3daae21'/>
<id>urn:sha1:d38ceaf99ed015f2a0b9af3499791bd3a3daae21</id>
<content type='text'>
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: Christian König &lt;christian.koenig@amd.com&gt;
Acked-by: Jammy Zhou &lt;Jammy.Zhou@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'virtio-gpu-drm-next' of git://git.kraxel.org/linux into drm-next</title>
<updated>2015-06-03T23:36:39Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2015-06-03T23:36:39Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=63e1456122761745082d325329ccce749a426059'/>
<id>urn:sha1:63e1456122761745082d325329ccce749a426059</id>
<content type='text'>
Yay, thanks to Gerd for pull this together.

* 'virtio-gpu-drm-next' of git://git.kraxel.org/linux:
  Add MAINTAINERS entry for virtio-gpu.
  Add virtio gpu driver.
  drm_vblank_get: don't WARN_ON in case vblanks are not initialized
  break kconfig dependency loop
</content>
</entry>
<entry>
<title>Merge branch 'linux-4.1.0-rc5-tilcdc-refactor' of https://github.com/jsarha/linux into drm-next</title>
<updated>2015-06-03T23:24:28Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2015-06-03T23:24:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6aa627250354c73ec705040b3a327b2915756fac'/>
<id>urn:sha1:6aa627250354c73ec705040b3a327b2915756fac</id>
<content type='text'>
Please pull the contents of "Use DRM component API in tilcdc to
connect to tda998x" patch series.

* 'linux-4.1.0-rc5-tilcdc-refactor' of https://github.com/jsarha/linux:
  drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
  drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support
  drm/tilcdc: use pm_runtime_irq_safe()
  drm/tilcdc: Add support for external tda998x encoder
  drm/tilcdc: Remove tilcdc slave support for tda998x driver
  drm/tilcdc: Fix module unloading
</content>
</entry>
<entry>
<title>Add virtio gpu driver.</title>
<updated>2015-06-03T12:17:38Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@gmail.com</email>
</author>
<published>2013-09-09T00:02:56Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dc5698e80cf724770283e10414054662bdf6ccfa'/>
<id>urn:sha1:dc5698e80cf724770283e10414054662bdf6ccfa</id>
<content type='text'>
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: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT</title>
<updated>2015-05-27T10:13:34Z</updated>
<author>
<name>Jyri Sarha</name>
<email>jsarha@ti.com</email>
</author>
<published>2015-02-18T10:26:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c87d2453a1c08da778103d56fd84df37920889e9'/>
<id>urn:sha1:c87d2453a1c08da778103d56fd84df37920889e9</id>
<content type='text'>
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: Jyri Sarha &lt;jsarha@ti.com&gt;
Acked-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>drm/core: get rid of -Iinclude/drm</title>
<updated>2015-05-13T09:28:22Z</updated>
<author>
<name>Maarten Lankhorst</name>
<email>maarten.lankhorst@linux.intel.com</email>
</author>
<published>2015-05-13T07:56:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f9be5f20115441488c8ef1391ef70b681135f0ad'/>
<id>urn:sha1:f9be5f20115441488c8ef1391ef70b681135f0ad</id>
<content type='text'>
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 &lt;drm/foo.h&gt; correctly, so fix the
instances that don't.

Reported-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
<entry>
<title>drm/vgem: implement virtual GEM</title>
<updated>2015-04-01T23:21:48Z</updated>
<author>
<name>Zach Reizner</name>
<email>zachr@google.com</email>
</author>
<published>2015-03-05T00:33:41Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=502e95c6678505474f1056480310cd9382bacbac'/>
<id>urn:sha1:502e95c6678505474f1056480310cd9382bacbac</id>
<content type='text'>
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 &lt;robdclark@gmail.com&gt; (v3)
Reviewed-by: Stéphane Marchesin &lt;marcheu@chromium.org&gt; (v3)
Signed-off-by: Adam Jackson &lt;ajax@redhat.com&gt;
Signed-off-by: Ben Widawsky &lt;ben@bwidawsk.net&gt;
Signed-off-by: Zach Reizner &lt;zachr@google.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/bridge: make bridge registration independent of drm flow</title>
<updated>2015-01-28T07:45:40Z</updated>
<author>
<name>Ajay Kumar</name>
<email>ajaykumar.rs@samsung.com</email>
</author>
<published>2015-01-20T16:38:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3d3f8b1f8b62c3a010976269df454baa9246fc65'/>
<id>urn:sha1:3d3f8b1f8b62c3a010976269df454baa9246fc65</id>
<content type='text'>
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-&gt;funcs-&gt;attach" so that
bridge can continue with drm related initializations.

Signed-off-by: Ajay Kumar &lt;ajaykumar.rs@samsung.com&gt;
Acked-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Tested-by: Rahul Sharma &lt;rahul.sharma@samsung.com&gt;
Tested-by: Javier Martinez Canillas &lt;javier.martinez@collabora.co.uk&gt;
Tested-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
Tested-by: Sjoerd Simons &lt;sjoerd.simons@collabora.co.uk&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
</content>
</entry>
</feed>
