Dave Airlie [Tue, 3 Jan 2012 09:25:18 +0000 (09:25 +0000)]
Merge branch 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung into drm-core-next
these patch sets include the following features:
- add Samsung SoC Exynos based HDMI support.
- add pm feature for fimd driver.
- add multi buffer plane pixel formats to drm/drm_fourcc.h.
multi buffer plane pixel format has seperated memory spaces for each
plane. for exampme, NV12M has Y plane and CbCr plane and these are in
non-continuous memory region. compared with NV12, NV12M's memory shape
is like following.
NV12 : ______(Y)(CbCr)_______
NV12M : __(Y)_ ..... _(CbCr)__
- bug fix to vblank.
- code clean to exynos gem framework.
* 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung:
drm/exynos: added hdmi display support
drm/exynos: added mutex lock and code clean.
drm/exynos: extend vblank off delay time.
drm/exynos: change driver name.
drm/exynos: Support multi buffers
drm: Add multi buffer plane pixel formats
drm/exynos: added pm support.
drm/exynos: remove buffer creation of fbdev from drm framebuffer creation
drm/exynos: Split creation of gem object and gem handle
drm/exynos: Fix a fake mmap offset creation
drm/exynos: gem code cleanup
Seung-Woo Kim [Wed, 21 Dec 2011 08:39:39 +0000 (17:39 +0900)]
drm/exynos: added hdmi display support
This patch is hdmi display support for exynos drm driver.
There is already v4l2 based exynos hdmi driver in drivers/media/video/s5p-tv
and some low level code is already in s5p-tv and even headers for register
define are almost same. but in this patch, we decide not to consider separated
common code with s5p-tv.
Exynos HDMI is composed of 5 blocks, mixer, vp, hdmi, hdmiphy and ddc.
1. mixer. The piece of hardware responsible for mixing and blending multiple
data inputs before passing it to an output device. The mixer is capable of
handling up to three image layers. One is the output of VP. Other two are
images in RGB format. The blending factor, and layers' priority are controlled
by mixer's registers. The output is passed to HDMI.
2. vp (video processor). It is used for processing of NV12/NV21 data. An image
stored in RAM is accessed by DMA. The output in YCbCr444 format is send to
mixer.
3. hdmi. The piece of HW responsible for generation of HDMI packets. It takes
pixel data from mixer and transforms it into data frames. The output is send
to HDMIPHY interface.
4. hdmiphy. Physical interface for HDMI. Its duties are sending HDMI packets to
HDMI connector. Basically, it contains a PLL that produces source clock for
mixer, vp and hdmi.
5. ddc (display data channel). It is dedicated i2c channel to exchange display
information as edid with display monitor.
With plane support, exynos hdmi driver fully supports two mixer layes and vp
layer. Also vp layer supports multi buffer plane pixel formats having non
contigus memory spaces.
In exynos drm driver, common drm_hdmi driver to interface with drm framework
has opertion pointers for mixer and hdmi. this drm_hdmi driver is registered as
sub driver of exynos_drm. hdmi has hdmiphy and ddc i2c clients and controls
them. mixer controls all overlay layers in both mixer and vp.
Vblank interrupts for hdmi are handled by mixer internally because drm
framework cannot support multiple irq id. And pipe number is used to check
which display device irq happens.
History
v2: this version
- drm plane feature support to handle overlay layers.
- multi buffer plane pixel format support for vp layer.
- vp layer support
RFCv1: original
- at https://lkml.org/lkml/2011/11/4/164
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Inki Dae [Fri, 16 Dec 2011 12:31:12 +0000 (21:31 +0900)]
drm/exynos: extend vblank off delay time.
some platform could be entering to sleep after short time once lcd panel off
but before that vblank could be off by vblank off delay feature. at that time,
vblank doesn't have the pair between vblank_get/put. so this path makes vblank
off delay to have enough.
Seung-Woo Kim [Thu, 15 Dec 2011 05:36:22 +0000 (14:36 +0900)]
drm/exynos: Support multi buffers
These formats(NV12M, NV12MT and YUV420M) have non contiguous multi
planes, so each plane uses different buffer. The exynos drm should
support multi buffer for them.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Seung-Woo Kim [Thu, 15 Dec 2011 06:40:55 +0000 (15:40 +0900)]
drm: Add multi buffer plane pixel formats
Multi buffer plane pixel format has seperated memory spaces for each
plane. For example, NV12M has Y plane and CbCr plane and these are in
non contiguous memory region. Compared with NV12, NV12M's memory shape
is like following.
NV12 : ______(Y)(CbCr)_______
NV12M : __(Y)_ ..... _(CbCr)__
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Joonyoung Shim [Tue, 13 Dec 2011 05:46:57 +0000 (14:46 +0900)]
drm/exynos: remove buffer creation of fbdev from drm framebuffer creation
The fbdev fb and the user fb is created from same function -
exynos_drm_fb_create, but this function creates not only drm framebuffer
but buffer of fbdev. Remove it because it complicates codes and use
exynos_drm_gem_create() than exynos_drm_buf_create() to create buffer of
fbdev, it give better consistency of codes and more clear
implementation.
Daniel Vetter [Sun, 30 Oct 2011 11:44:56 +0000 (12:44 +0100)]
drm/i810: don't acces hw regs in lastclose
i810 uses a userspace provided mmio map using the drm core map
infrastructure. By the time we reach lastclose, this is all gone
and our mmio_map pointer points at freed memory. Depending upon
luck that still works, most often it just oopses.
Aside: drm maps aren't refcounted, so userspace can essentially oops
the kernel any time it wants to. Who cares.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 25 Oct 2011 21:51:24 +0000 (23:51 +0200)]
drm/i810: cleanup reclaim_buffers
My dear old i815 always hits the deadlocked on reclaim_buffers
warning. Switch over to the idlelock duct-tape on hope that
works better. I've fired up my i815 and now closing glxgears doesn't
take 5 seconds anymore. \o/
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Thu, 22 Dec 2011 11:02:06 +0000 (11:02 +0000)]
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-core-next
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (102 commits)
drm/nouveau/ttm: fix crash as a result of a recent ttm change
drm/nouveau: Fix notifier blocks over the 4GB mark.
drm/nouveau: Fix pushbufs over the 4GB mark.
drm/nvc0/pm: initial engine reclocking
drm/nouveau: move hpd enable/disable to common code
drm/nv40/disp: implement support for hotplug irq
drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues
drm/nouveau: just pass gpio line to pwm_*, not entire gpio struct
drm/nouveau/hwsq: remove some magic, give proper opcode names
drm/nv50/pm: introduce hwsq-based memory reclocking
drm/nv04/disp: handle dual-link spwg panels without needing quirks
drm/nouveau/dp: remove broken display depth function, use the improved one
drm/nouveau/mxm: implement ROM shadow method
drm/nouveau/mxm: implement _DSM shadow method
drm/nouveau/mxm: implement wmi shadow method
drm/nouveau/mxm: initial implementation of dcb sanitisation
drm/nouveau/disp: parse connector info directly in nouveau_connector.c
drm/nouveau/i2c: handle bit-banging ourselves
drm/nouveau/i2c: fix debug message
drm/nouveau/i2c: tidy up bit-bang helpers, also fixing nv50 setsda bug
...
Ben Skeggs [Thu, 22 Dec 2011 05:20:21 +0000 (15:20 +1000)]
drm/nouveau/ttm: fix crash as a result of a recent ttm change
"drm/ttm: callback move_notify any time bo placement change v4" failed to
avoid a NULL pointer dereference in nouveau caused by move_notify being
expected to handle that case now.
Daniel Vetter [Wed, 26 Oct 2011 20:21:13 +0000 (22:21 +0200)]
drm/via: use drm_mm instead of drm_sman
To make the transition in a piece-wise and bisectable way possible,
I've hijacked the ->owner_list from drm_sman. While transitioning, the
list_add was done by the driver, while the list_del was still done by
the dying sman code.
Now that we are in full control of ->owner_list, do the list_del
ourselves.
v2: Better explain the list_del trickery as suggested by Chris Wilson.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 26 Oct 2011 20:28:07 +0000 (22:28 +0200)]
drm/sman: rip out owner tracking
In contrast to kms drivers, sis/via _always_ associated a buffer with
a drm fd. So by the time we reach lastclose, all open drm fds are gone
and with them their associated objects.
So when sis/via call drm_sman_cleanup in their lastclose funcs, that
will free 0 objects.
The owner tracking now serves no purpose at all, hence rip it ou. We
can't kill the corresponding fields in struct drm_memblock_item yet
because we hijack these in the new driver private owner tracking. But
now that drm_sman.c doesn't touch ->owner_list anymore, we need to
kill the list_move hack and properly add the item to the file_priv
list.
Also leave the list_del(&obj->owner_list) in drm_sman_free for the
moment, it will move to the drivers when sman disappears completely.
v2: Remove the redundant INIT_LIST_HEAD as noted by Chris Wilson
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Skeggs [Mon, 21 Nov 2011 06:41:48 +0000 (16:41 +1000)]
drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues
- moves out of nouveau_bios.c and demagics the logical state definitions
- simplifies chipset-specific driver interface
- makes most of gpio irq handling common, will use for nv4x hpd later
- api extended to allow both direct gpio access, and access using the
logical function states
- api extended to allow for future use of gpio extender chips
- pre-nv50 was handled very badly, the main issue being that all GPIOs
were being treated as output-only.
- fixes nvd0 so gpio changes actually stick, magic reg needs bashing
More work needs to be done on supporting the different memory types.
v2 (Ben Skeggs):
- fixed up conflicts from not having pausing patch first
- restructured code somewhat to fit with how all the other code works
- fixed bug where incorrect mpll_ctrl could get set sometimes
- removed stuff that's cargo-culted from the binary driver
- merged nv92+ display disable into hwsq
- fixed incorrect opcode 0x5f magic at end of ucode
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 12 Oct 2011 06:36:42 +0000 (16:36 +1000)]
drm/nouveau/mxm: initial implementation of dcb sanitisation
The DCB table provided by the VBIOS on most MXM chips has a number of
entries which either need to be disabled, or modified according to the
MXM-SIS Output Device Descriptors.
The x86 vbios code usually takes care of this for us, however, with the
large number of laptops now with switchable graphics or optimus, a lot
of the time nouveau is responsible for POSTing the card instead - leaving
some fun situations like, plugging in a monitor and having nouveau decide
3 connectors actually just got plugged in..
Ben Skeggs [Fri, 18 Nov 2011 00:23:59 +0000 (10:23 +1000)]
drm/nouveau/disp: parse connector info directly in nouveau_connector.c
Another case where we parsed vbios data to some structs, then again use
that info once to construct another set of data. Skip the intermediate
step.
This is also slightly improved in that we can now use DCB 3.x connector
table info, which will allow NV4x to gain hotplug support, and to make
quirks for SPWG LVDS panels unnecessary.
Ben Skeggs [Wed, 21 Dec 2011 08:09:12 +0000 (18:09 +1000)]
drm/nouveau/i2c: handle bit-banging ourselves
i2c-algo-bit doesn't actually work very well on one card I have access to
(NVS 300), random single-bit errors occur most of the time - what we're
doing now is closer to what xf86i2c.c does.
The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
and fix it. However, while investigating I discovered i2c-algo-bit calls
cond_resched(), which makes it a bad idea for us to be using as we execute
VBIOS scripts from a tasklet, and there may very well be i2c transfers as
a result.
So, since I already wrote this code in userspace to track down the NVS 300
bug, and it's not really much code - lets use it.
Ben Skeggs [Thu, 17 Nov 2011 03:56:14 +0000 (13:56 +1000)]
drm/nouveau/i2c: tidy up bit-bang helpers, also fixing nv50 setsda bug
Was using nv_mask, which is bad. Reading the reg senses the current line
states, which aren't necessarily the states we're trying to drive the
lines to.
Fixed to store SCL driver state just as we already do for SDA.
Ben Skeggs [Fri, 11 Nov 2011 00:22:19 +0000 (10:22 +1000)]
drm/nouveau/i2c: do parsing of i2c-related vbios info in nouveau_i2c.c
Not much point parsing the vbios data into a struct which is only used once
to parse the data into another struct, go directly from vbios to
nouveau_i2c_chan.
Ben Skeggs [Thu, 10 Nov 2011 05:42:55 +0000 (15:42 +1000)]
drm/nouveau/bios: start refactoring dcb routines
This primary reason for this was mostly to avoid duplication of some of
this stuff by the MXM-SIS parser. However, some other cleanups will also
follow this as a result.
projects / mv-sheeva.git / log