date:20121214

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #8 from Maarten Lankhorst  ---
Could you please run a git bisection to see where that error has been
introduced, then?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/cab785b5/attachment.html>

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

2012-12-14 Thread Terje Bergström

On 14.12.2012 18:21, Stephen Warren wrote:
> On 12/13/2012 11:09 PM, Terje Bergstr?m wrote:
>> They want to get the global data by getting drvdata of their parent.
> 
> There's no reason that /has/ to be so; they can get any information from
> wherever it is, rather than trying to require it to be somewhere it isn't.

Exactly, this was also my solution.

>> The dummy device is not their parent - host1x is. There's no
>> connection between the dummy and the real client devices.
> 
> It's quite possible for the client devices to ask their actual parent
> (host1x) for the tegradrm struct device *, by calling a host1x API, and
> have host1x implement that API by returning the dummy/virtual device
> that it created. That should be just 1-2 lines of code to implement in
> host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED
> when appropriate.

My solution was to just have one global, and an getter for the global.
Instead of drvdata, the pointer is retrieved with the getter. No need
for dummy device, or passing points between host1x and tegradrm.

Terje

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #7 from Andy Furniss  ---
(In reply to comment #6)
> Created attachment 71507 [details] [review]
> fix
> 
> Should be fixed with this patch.

Probably :-)

It seems that current drm-next head + fix has a different issue which makes
etqw die quite quickly.

drm-next reset onto 

drm/ttm: remove no_wait_reserve, v3 + the fix 

is now stable with etqw.

The head issue is -

EE r600_texture.c:697 r600_texture_transfer_map - failed to create temporary
texture to hold untiled copy
Mesa: User error: GL_OUT_OF_MEMORY in glTexSubImage
radeon: The kernel rejected CS, see dmesg for more information.
double fault: 'Segmentation fault', bailing out

in dmesg - 

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (8192, 2,
4096, -12)
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
etqw.x86[2478]: segfault at 0 ip af5142ad sp bff8b310 error 4 in
gamex86.so[af23f000+948000]

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/1b47e266/attachment.html>

[RFC] drm/lcdc: add TI LCD Controller DRM driver

On Fri, Dec 14, 2012 at 1:04 AM, Rob Clark  wrote:
> +static int lcdc_crtc_page_flip(struct drm_crtc *crtc,
> +   struct drm_framebuffer *fb,
> +   struct drm_pending_vblank_event *event)
> +{
> +   struct lcdc_crtc *lcdc_crtc = to_lcdc_crtc(crtc);
> +   struct drm_device *dev = crtc->dev;
> +
> +   if (lcdc_crtc->event) {
> +   dev_err(dev->dev, "already pending page flip!\n");
> +   return -EBUSY;
> +   }
> +
> +   // TODO we should hold a ref to the fb somewhere..

Note that with the current fb refcounting nothing prevents you from
fixing this. The ugly problems I've had to solve for the locking
rework are all due to the drm core (i.e. setcrtc/pageflip/...) ioctl
functions assuming that an fb can't suddenly disappear while holding
the mode_config lock. Since I wanted to remove that requirement I've
had to changed the refcounting in the drm core functions.

But drivers can already extend the lifetime of an fb simply by
grabbing a reference (as long as they grab that reference while
holding the struct mutex all the time between fb lookup and grabbing
the reference). And it will continue to work the same with the new
locking scheme.
-Daniel

> +   crtc->fb = fb;
> +   lcdc_crtc->event = event;
> +   update_scanout(crtc);
> +
> +   return 0;
> +}
> +



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-14 Thread Christian König

On 14.12.2012 18:39, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
>
> After lockup we need to resume fence to last sync sequence and not
> last received sequence so that all thread waiting on command stream
> that lockedup resume. Otherwise GPU reset will be ineffective in most
> cases.
NAK. I changed this on purpose to get partial resets working, please 
don't change it back.

The IB test code should reset this to the last synced value anyway, if 
it doesn't work then there is something wrong there.

Christian.


>
> Signed-off-by: Jerome Glisse 
> ---
>   drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 22bd6c2..38233e7 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -787,7 +787,7 @@ int radeon_fence_driver_start_ring(struct radeon_device 
> *rdev, int ring)
>   }
>   rdev->fence_drv[ring].cpu_addr = >wb.wb[index/4];
>   rdev->fence_drv[ring].gpu_addr = rdev->wb.gpu_addr + index;
> - radeon_fence_write(rdev, 
> atomic64_read(>fence_drv[ring].last_seq), ring);
> + radeon_fence_write(rdev, rdev->fence_drv[ring].sync_seq[ring], ring);
>   rdev->fence_drv[ring].initialized = true;
>   dev_info(rdev->dev, "fence driver on ring %d use gpu addr 0x%016llx and 
> cpu addr 0x%p\n",
>ring, rdev->fence_drv[ring].gpu_addr, 
> rdev->fence_drv[ring].cpu_addr);

[PATCH] radeon: fix regression with eviction since evict caching changes

2012-12-14 Thread Dave Airlie

From: Dave Airlie 

Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
drm/radeon: use cached memory when evicting for vram on non agp

evicting from TTM would try and evict to TTM instead of system,
not so good.

This should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=58272

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 93d3445..883c95d 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -96,9 +96,9 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, 
u32 domain)
}
if (domain & RADEON_GEM_DOMAIN_CPU) {
if (rbo->rdev->flags & RADEON_IS_AGP) {
-   rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_TT;
+   rbo->placements[c++] = TTM_PL_FLAG_WC | 
TTM_PL_FLAG_SYSTEM;
} else {
-   rbo->placements[c++] = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_TT;
+   rbo->placements[c++] = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_SYSTEM;
}
}
if (!c)
-- 
1.8.0

[PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

Dude, you're seriously overshooting here. This patch isn't required
_at_ _all_ to do cross device sharing/reservations/whatever. We've
simply discussed TTM documentation in the context of Maartens work,
and I've suggested to include all the TTM kerneldoc into a nice
DocBook. That way the kerneldoc stuff gets at least check for correct
parameters and similar trivial stuff (core drm sucked royally in that
regard). So Maarten jabbed around, I and Dave joined in and since
besides vmwgfx nothing else uses it at all I've figured this can't
hurt.

If you think all the radeon/nouveau/i915/whatever drivers are screwed
up beyond repair and need to have the ttm_lock.c file where it is as a
stern reminder, I don't care one bit. Personally I think the right
solution is to abolish the drm master concept entirely and aim for
CONFIG_VT=n. Insulation is a userspace problem which e.g. policykit or
whatever the latest thing is can do, or which should be solved for
real with per-process address spaces. Everything else smells too fishy
for me. So yeah, I don't think the fact that vmwgfx is the only driver
with a ->set_master and ->drop_master callback is a good sign, but
alas, not my driver and the core impact is negligible.

Cheers, Daniel

On Fri, Dec 14, 2012 at 4:51 PM, Thomas Hellstr?m  
wrote:
> Nack,
>
> I'm not against moving the TTM lock away,
> when a replacement strategy for the main use case is presented.
>
> but using wording like "unholy", "scares" just because there is a lack of
> understanding or because it gets in the way of implementing cross-device
> reservation is a really really bad idea, and FWIW I think it's an even
> better idea to refrain from such wording unless you completely understand
> the problem and have a better solution in place.
>
> No other driver uses it, probably simply because the driver writers probably
> aren't aware of the use cases or don't implement parallel command
> submission.
>
> And if it weren't for the TTM lock, the cross device work wouldn't have to
> consider the case where a client
> needs to lock out other reservers, and the cross-device design would suffer.
>
> The main use cases are:
>
> 1) If we change master, clients of other masters need to be locked out from
> claiming memory resources (particularly VRAM).
> 2) If we're about to suspend and have cleaned VRAM, client's need to be
> stopped from validating VRAM buffer objects.
> 3) If a client needs access to the complete video memory space or need to
> defragment, it needs to lock out other reservers in a parallell command
> submission environment
>
> Now, present a better solution to those use cases, and I'll ack this patch
> and implement that solution, or
> leave the TTM lock in place as a reminder that these things need to be
> considered, and that we should have a common solution to them.
>
> /Thomas
>
>
>
>
>
> On 12/10/12 11:26 AM, Daniel Vetter wrote:
>>
>> ... it's the only user. Also move the header fil there.
>>
>>  but seriously, ttm_lock is best left undocumented since
>> nobody should use that unholy thing..
>>  agreed ;-)
>>  imo we should shovel that under drm/vmwgfx ...
>>  amen
>>  that thing scares me
>>  out of sight, out of mind ...
>>
>> Signed-off-by: Daniel Vetter 
>> ---
>>   drivers/gpu/drm/ttm/Makefile|2 +-
>>   drivers/gpu/drm/ttm/ttm_lock.c  |  310
>> ---
>>   drivers/gpu/drm/vmwgfx/Makefile |2 +-
>>   drivers/gpu/drm/vmwgfx/ttm_lock.c   |  310
>> +++
>>   drivers/gpu/drm/vmwgfx/ttm_lock.h   |  247 
>>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +-
>>   include/drm/ttm/ttm_lock.h  |  247 
>>   7 files changed, 560 insertions(+), 560 deletions(-)
>>   delete mode 100644 drivers/gpu/drm/ttm/ttm_lock.c
>>   create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c
>>   create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h
>>   delete mode 100644 include/drm/ttm/ttm_lock.h
>>
>> diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
>> index b2b33dd..607a0b6 100644
>> --- a/drivers/gpu/drm/ttm/Makefile
>> +++ b/drivers/gpu/drm/ttm/Makefile
>> @@ -4,7 +4,7 @@
>>   ccflags-y := -Iinclude/drm
>>   ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
>> ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
>> -   ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
>> +   ttm_object.o ttm_execbuf_util.o ttm_page_alloc.o \
>> ttm_bo_manager.o
>> ifeq ($(CONFIG_SWIOTLB),y)
>> diff --git a/drivers/gpu/drm/ttm/ttm_lock.c
>> b/drivers/gpu/drm/ttm/ttm_lock.c
>> deleted file mode 100644
>> index 3daa9a3..000
>> --- a/drivers/gpu/drm/ttm/ttm_lock.c
>> +++ /dev/null
>> @@ -1,310 +0,0 @@
>>
>> -/**
>> - *
>> - * Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
>> - * All Rights Reserved.
>> - *
>> - * Permission is hereby granted,

[pull] radeon drm-next-3.8

2012-12-14 Thread alexdeuc...@gmail.com

From: Alex Deucher 

Hi Dave,

  This adds CS ioctl support for the async DMA rings.
The rest is bug fixes.

Alex

The following changes since commit 9add1ac3dd256ad12e266f8403daf928be19953f:

  Merge branch 'drm-next-3.8' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2012-12-13 12:03:22 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.8

Alex Deucher (6):
  drm/radeon/kms: add 6xx/7xx CS parser for async DMA (v2)
  drm/radeon/kms: add evergreen/cayman CS parser for async DMA (v2)
  drm/radeon: add VM CS parser support for async DMA on cayman/TN/SI
  drm/radeon: enable the async DMA rings in the CS ioctl
  drm/radeon: bump version for CS ioctl support for async DMA
  drm/radeon: add more pedantic checks in the CP DMA checker

Daniel Vetter (3):
  drm/radeon: add W|RREG32_IDX for MM_INDEX|DATA based mmio accesss
  drm/radeon: make indirect register access concurrency-safe
  drm/radeon: fix fence locking in the pageflip callback

Dave Airlie (1):
  radeon: fix regression with eviction since evict caching changes

Jerome Glisse (1):
  drm/radeon: fix htile buffer size computation for command stream checker

 drivers/gpu/drm/radeon/evergreen_cs.c   |  603 ++-
 drivers/gpu/drm/radeon/r100.c   |   23 +-
 drivers/gpu/drm/radeon/r600_cs.c|  285 +++
 drivers/gpu/drm/radeon/radeon.h |   19 +-
 drivers/gpu/drm/radeon/radeon_asic.c|   26 +-
 drivers/gpu/drm/radeon/radeon_asic.h|3 +
 drivers/gpu/drm/radeon/radeon_combios.c |6 +-
 drivers/gpu/drm/radeon/radeon_cp.c  |   14 -
 drivers/gpu/drm/radeon/radeon_cs.c  |   13 +
 drivers/gpu/drm/radeon/radeon_cursor.c  |   17 +-
 drivers/gpu/drm/radeon/radeon_device.c  |1 +
 drivers/gpu/drm/radeon/radeon_display.c |4 +
 drivers/gpu/drm/radeon/radeon_drv.c |4 +-
 drivers/gpu/drm/radeon/radeon_drv.h |1 -
 drivers/gpu/drm/radeon/radeon_object.c  |4 +-
 include/uapi/drm/radeon_drm.h   |1 +
 16 files changed, 897 insertions(+), 127 deletions(-)

[PATCH 00/81] drm/i915: Atomic mode setting / page flip, yet again

On Wed, Dec 12, 2012 at 06:15:27PM +0200, ville.syrjala at linux.intel.com 
wrote:
...
> Ever since the code started to resemble something sane, I've tried
> to avoid squashing patches, just in case someone was actually trying
> to follow what's changed. But clearly some of the patches can
> be squashed, and that would probably allow some of the earlier ones
> to be dropped entirely.

FYI I now squashed this down to 56 patches, with 6 being pure
debug stuff, ~15 trivial unstatic/export stuff, and the rest
are of varying complexity. So we're down to ~35 patches with
substance.

Next week I can see about pulling some of the intel specific plane
stuff out and send that separately. Those would involve a few framework
type patches the core as well. By my quick calculation that could
bring the final count down by another 15 or so.

There are also some core drm patches that could be merged at any point,
but most of those wouldn't have any use until the atomic stuff starts
taking advantage or them (signed range props, resizeable blobs, etc.).

The current set is here:
https://gitorious.org/vsyrjala/linux/commits/drm_atomic_24

-- 
Ville Syrj?l?
Intel OTC

[RFC v5 5/5] drm/exynos: add gsc ipp driver

GSC is stand for General SCaler and supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and image effect functions, also supports writeback 
and display output operations.
M2M operation : supports crop/scale/rotation/csc so on.
Memory ---> GSC H/W  ---> Memory.
Writeback operation : supports cloned screen with FIMD.
FIMD ---> GSC H/W ---> Memory.
Output operation : supports direct display using local path.
Memory ---> GSC H/W  ---> FIMD, Mixer.

Changelog v5
- Changed return type
- Define hard coding value
- Changed to devm_ function

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/Kconfig  |5 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1870 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.h |   38 +
 drivers/gpu/drm/exynos/regs-gsc.h   |  284 +
 7 files changed, 2214 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
 create mode 100644 drivers/gpu/drm/exynos/regs-gsc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4860835..c93d776 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -64,3 +64,8 @@ config DRM_EXYNOS_ROTATOR
help
  Choose this option if you want to use Exynos Rotator for DRM.

+config DRM_EXYNOS_GSC
+   bool "Exynos DRM GSC"
+   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5
+   help
+ Choose this option if you want to use Exynos GSC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 3b70668..639b49e 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -19,5 +19,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09d884b..e0a8e80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -384,6 +384,12 @@ static int __init exynos_drm_init(void)
goto out_rotator;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_GSC
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_gsc;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -412,6 +418,11 @@ out_drm:
 out_ipp:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_GSC
+   platform_driver_unregister(_driver);
+out_gsc:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(_driver);
 out_rotator:
@@ -462,6 +473,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_GSC
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a74e37c..afe556c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -354,5 +354,6 @@ extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
 extern struct platform_driver rotator_driver;
+extern struct platform_driver gsc_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
new file mode 100644
index 000..5639353
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -0,0 +1,1870 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * Eunchul Kim 
+ * Jinyoung Jeon 
+ * Sangmin Lee 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "regs-gsc.h"
+#include "exynos_drm_ipp.h"
+#include "exynos_drm_gsc.h"
+
+/*
+ * GSC is stand for General SCaler and
+ * supports image scaler/rotator and input/output DMA operations.
+ * input DMA reads image data from the memory.
+ * output DMA writes image data to

[RFC v5 4/5] drm/exynos: add rotator ipp driver

Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal 
flip.
and has some limitations(source and destination format have to be same, no 
scaler)

Signed-off-by: Eunchul Kim 
Signed-off-by: Youngjun Cho 
---
 drivers/gpu/drm/exynos/Kconfig  |7 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  856 +++
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |   33 +
 drivers/gpu/drm/exynos/regs-rotator.h   |   73 +++
 7 files changed, 986 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h
 create mode 100644 drivers/gpu/drm/exynos/regs-rotator.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4915ab6..4860835 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -57,3 +57,10 @@ config DRM_EXYNOS_FIMC
depends on DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos FIMC for DRM.
+
+config DRM_EXYNOS_ROTATOR
+   bool "Exynos DRM Rotator"
+   depends on DRM_EXYNOS_IPP
+   help
+ Choose this option if you want to use Exynos Rotator for DRM.
+
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 9710024..3b70668 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -18,5 +18,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 73f02ac..09d884b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -378,6 +378,12 @@ static int __init exynos_drm_init(void)
goto out_fimc;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_rotator;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -406,6 +412,11 @@ out_drm:
 out_ipp:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(_driver);
+out_rotator:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(_driver);
 out_fimc:
@@ -451,6 +462,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 14f9490..a74e37c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -353,5 +353,6 @@ extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
+extern struct platform_driver rotator_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
new file mode 100644
index 000..0025314
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -0,0 +1,856 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * YoungJun Cho 
+ * Eunchul Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundationr
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "regs-rotator.h"
+#include "exynos_drm.h"
+#include "exynos_drm_ipp.h"
+
+/*
+ * Rotator supports image crop/rotator and input/output DMA operations.
+ * input DMA reads image data from the memory.
+ * output DMA writes image data to memory.
+ *
+ * M2M operation : supports crop/scale/rotation/csc so on.
+ * Memory > Rotator H/W > Memory.
+ */
+
+/*
+ * TODO
+ * 1. check suspend/resume api if needed.
+ * 2. need to check use case platform_device_id.
+ * 3. check src/dst size with, height.
+ * 4. need to add supported list in prop_list.
+ */
+
+#define get_rot_context(dev)   platform_get_drvdata(to_platform_device(dev))
+#define get_ctx_from_ippdrv(ippdrv)

[RFC v5 3/5] drm/exynos: add fimc ipp driver

FIMC is stand for Fully Interfactive Mobile Camera and
supports image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
FIMC supports image rotation and image effect functions.
also supports writeback and display output operations.

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/Kconfig   |6 +
 drivers/gpu/drm/exynos/Makefile  |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2002 ++
 drivers/gpu/drm/exynos/exynos_drm_fimc.h |   37 +
 drivers/gpu/drm/exynos/regs-fimc.h   |  669 ++
 include/drm/exynos_drm.h |   26 +
 8 files changed, 2757 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h
 create mode 100644 drivers/gpu/drm/exynos/regs-fimc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index bcf1c9d..4915ab6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -51,3 +51,9 @@ config DRM_EXYNOS_IPP
depends on DRM_EXYNOS
help
  Choose this option if you want to use IPP feature for DRM.
+
+config DRM_EXYNOS_FIMC
+   bool "Exynos DRM FIMC"
+   depends on DRM_EXYNOS_IPP
+   help
+ Choose this option if you want to use Exynos FIMC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 6c536ce..9710024 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,5 +17,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 0eb8a97..73f02ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -372,6 +372,12 @@ static int __init exynos_drm_init(void)
goto out_g2d;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_FIMC
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_fimc;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -400,6 +406,11 @@ out_drm:
 out_ipp:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_FIMC
+   platform_driver_unregister(_driver);
+out_fimc:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 out_g2d:
@@ -440,6 +451,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_FIMC
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a365788..14f9490 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -352,5 +352,6 @@ extern struct platform_driver mixer_driver;
 extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
+extern struct platform_driver fimc_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
new file mode 100644
index 000..31df4f5
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -0,0 +1,2002 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * Eunchul Kim 
+ * Jinyoung Jeon 
+ * Sangmin Lee 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "regs-fimc.h"
+#include "exynos_drm_ipp.h"
+#include "exynos_drm_fimc.h"
+
+/*
+ * FIMC is stand for Fully Interactive Mobile Camera and
+ * supports image scaler/rotator and input/output DMA operations.
+ * input DMA reads image data from the memory.
+ * output DMA writes image data to memory.
+ * FIMC supports image rotation and image effect functions.
+ *
+ * M2M operation : supports crop/scale/rotation/csc so on.
+ * Memory > FIMC H/W > Memory.
+ * Writeback operation : supports cloned screen with

[RFC v5 2/5] drm/exynos: add iommu support for ipp

This patch adds iommu support for ipp.
For this, it adds subdrv_probe/remove callback to enable or disable ipp iommu.
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr().

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index c640935..49eebe9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -24,6 +24,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_ipp.h"
+#include "exynos_drm_iommu.h"

 /*
  * IPP is stand for Image Post Processing and
@@ -1771,10 +1772,24 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
ippdrv->event_workq = ctx->event_workq;
ippdrv->sched_event = ipp_sched_event;
INIT_LIST_HEAD(>cmd_list);
+
+   if (is_drm_iommu_supported(drm_dev)) {
+   ret = drm_iommu_attach_device(drm_dev, ippdrv->dev);
+   if (ret) {
+   DRM_ERROR("failed to activate iommu\n");
+   goto err_iommu;
+   }
+   }
}

return 0;

+err_iommu:
+   /* get ipp driver entry */
+   list_for_each_entry_reverse(ippdrv, _drm_ippdrv_list, drv_list)
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv->dev);
+
 err_idr:
idr_remove_all(>ipp_idr);
idr_remove_all(>prop_idr);
@@ -1791,6 +1806,9 @@ static void ipp_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)

/* get ipp driver entry */
list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv->dev);
+
ippdrv->drm_dev = NULL;
exynos_drm_ippdrv_unregister(ippdrv);
}
-- 
1.7.0.4

[RFC v5 1/5] drm/exynos: add ipp subsystem

IPP stand for Image Post Processing and supports image scaler/rotator
/crop/flip/csc(color space conversion) and input/output DMA operations using 
ipp drivers.
also supports writeback and display output operations.
ipp driver include FIMC, Rotator, GSC, SC, so on.
and ipp is integration device driver for each hardware.

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   24 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |7 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2042 +++
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  266 
 include/uapi/drm/exynos_drm.h   |  190 +++
 7 files changed, 2536 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4ea8cdc..bcf1c9d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -45,3 +45,9 @@ config DRM_EXYNOS_G2D
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
+
+config DRM_EXYNOS_IPP
+   bool "Exynos DRM IPP"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use IPP feature for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 26813b8..6c536ce 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -16,5 +16,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
   exynos_drm_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4a1168d..0eb8a97 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -40,6 +40,7 @@
 #include "exynos_drm_vidi.h"
 #include "exynos_drm_dmabuf.h"
 #include "exynos_drm_g2d.h"
+#include "exynos_drm_ipp.h"
 #include "exynos_drm_iommu.h"

 #define DRIVER_NAME"exynos"
@@ -249,6 +250,14 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_g2d_set_cmdlist_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC,
exynos_g2d_exec_ioctl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY,
+   exynos_drm_ipp_get_property, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY,
+   exynos_drm_ipp_set_property, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF,
+   exynos_drm_ipp_queue_buf, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL,
+   exynos_drm_ipp_cmd_ctrl, DRM_UNLOCKED | DRM_AUTH),
 };

 static const struct file_operations exynos_drm_driver_fops = {
@@ -363,6 +372,12 @@ static int __init exynos_drm_init(void)
goto out_g2d;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_IPP
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_ipp;
+#endif
+
ret = platform_driver_register(_drm_platform_driver);
if (ret < 0)
goto out_drm;
@@ -380,6 +395,11 @@ out:
platform_driver_unregister(_drm_platform_driver);

 out_drm:
+#ifdef CONFIG_DRM_EXYNOS_IPP
+   platform_driver_unregister(_driver);
+out_ipp:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 out_g2d:
@@ -416,6 +436,10 @@ static void __exit exynos_drm_exit(void)

platform_driver_unregister(_drm_platform_driver);

+#ifdef CONFIG_DRM_EXYNOS_IPP
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a9db025..a365788 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -235,8 +235,14 @@ struct exynos_drm_g2d_private {
unsigned intgem_nr;
 };

+struct exynos_drm_ipp_private {
+   struct device   *dev;
+   struct list_headevent_list;
+};
+
 struct drm_exynos_file_private {
struct exynos_drm_g2d_private   *g2d_priv;
+   struct exynos_drm_ipp_private   *ipp_priv;
 };

 /*
@@ -346,4 +352,5 @@ extern struct platform_driver mixer_driver;
 extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver

[RFC v5 0/5] drm/exynos: add ipp subsystem and each ipp drivers

Hi All.

I am responsible for a display part from Samsung Electronics Telecommunication 
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinions of this patch,
please give some comments about my patch.

Changelog v5:
This RFC v5 changed TODO list for arrangement.
Supports devm_ fuction in resource handling.
Arranged comments and added description.
Changed return value for right detect error.
Added GSC definition.

Changelog v4:
This RFC v4 changed ipp subsystem for arrangement.
Remove EXPORT_SYMBOL_GPL in ipp subsystem.
Added error handling in ipp subsystem.
Change set_transf return from swap to ret and use pointer about swap.
Seperated function in Rotator.

Changelog v3:
This RFC v3 changed ipp subsystem for arrangement.
Fixed scaler problem in GSC.
Added/Removed comment from Inki.Dae.
Fixed Joonyoung.Shim comment.
Added rotator comments.

Changelog v2:
This RFC v2 supports iommu in ipp. and Added/Removed comment from Inki.Dae.
Fixed GSC part bugs and next time I will send our local git commit.
and We finished implementation of SC for post-processing.
SC driver not fully tested yet. so, I didn't add SC feature in this patch.

Changelog v1:

This patch is post-processing(IPP) support for exynos drm driver.

IPP is stands for Image Post Processing and supports image scaler/rotator
and input/output DMA operations using IPP drivers(FIMC, Rotator, GSC, SC, so 
on.)
IPP is integration device driver of same attibute hardware.

Exynos4 SoC support FIMC, Rotator for post-processing.
and Exynos5 SoC support GSC, Rotator, SC for post-processing.
SC driver not tested yet. so, I didn't add SC feature in this patch.
and IPP subsystem works on Exynos SoC version independently.

IPP drivers supports Memory to Memory operations with various converting.
and some drivers supports Writeback and Display output operations using local 
path.
User can make converted image using this driver.
and also supports streaming concept for multimedia data processing.

And supports various operations
1. Scale operation generates various sizes of image.
2. CSC(Color Space Conversion) operation supports format converting.
3. Crop operation supports cutting the image.
4. Rotate operation supports to 90, 180, 270 degree.
5. Flip operation supports to vertical, horizontal, and both.
6. Writeback operation genertates cloned image from display controller(FIMD).
7. Display output operation support various format display to display 
controller(FIMD).
8. Input DMA reads image data from the memory.
9. Output DMA writes image data to memory.
10. Supports image effect functions.

Descriptions)
User should make property informations and set this property to registers.
and IPP subsystem manages property id using command node and make queue list 
using memory node.
IPP subsystem supports register function of IPP drivers.
IPP driver manages input/output DMA with various operations. and some driver 
supports
optional operations(writeback, output).
IPP driver needs various informations, so User set property information to IPP 
driver.
and also IPP driver needs memory base address of image for various operations.
User doesn't know its address, so fills the gem handle of that memory than 
address of image base.
and than IPP driver start operation.

Ioctls)
We adds four ioctls and one event for IPP subsystem.

- ioctls
DRM_EXYNOS_IPP_GET_PROPERTY : get ipp driver capabilitis and id.
DRM_EXYNOS_IPP_SET_PROPERTY : set format, position, rotation, flip about 
source/destination.
DRM_EXYNOS_IPP_QUEUE_BUF : enqueue/dequeue buffer and make event list.
DRM_EXYNOS_IPP_CMD_CTRL : play/stop/pause/resume control.

- event
DRM_EXYNOS_IPP_EVENT : event to give notification completion of buffer DMA with 
buffer list

Basic control flow and Sample pseudo application)
1. Basic control flow is same as below
Open -> Get properties -> User choose IPP driver and set property information 
-> Set Property -> Create gem handle ->
Queue buffer(Enqueue) of source/destination -> Command control(Play) -> Event 
occured to User
-> User handle converted image -> (Queue buffer(Enqueue) of source/destination 
-> Event occured to User)*N ->
Queue buffer(Dequeue) of source/destination -> Command control(Stop) -> Free 
gem handle -> Close

2. Sample pseudo application
#include "exynos_drm.h"
static int exynos_drm_ipp_set_property(int fd ...)
{
struct drm_exynos_pos crop_pos = {0, 0, hsize, vsize};
struct drm_exynos_pos scale_pos = {0, 0, hsize, vsize};
struct drm_exynos_sz src_sz = {hsize, vsize};
struct drm_exynos_sz dst_sz = {hsize, vsize};
int ret = 0;

memset(property, 0x00, sizeof(struct drm_exynos_ipp_property));
property->cmd = cmd;

property->config[EXYNOS_DRM_OPS_SRC].ops_id = EXYNOS_DRM_OPS_SRC;
property->config[EXYNOS_DRM_OPS_SRC].flip = EXYNOS_DRM_FLIP_NONE;
property->config[EXYNOS_DRM_OPS_SRC].degree = EXYNOS_DRM_DEGREE_0;

[PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

2012-12-14 Thread Thomas Hellström

Nack,

I'm not against moving the TTM lock away,
when a replacement strategy for the main use case is presented.

but using wording like "unholy", "scares" just because there is a lack 
of understanding or because it gets in the way of implementing 
cross-device reservation is a really really bad idea, and FWIW I think 
it's an even better idea to refrain from such wording unless you 
completely understand the problem and have a better solution in place.

No other driver uses it, probably simply because the driver writers 
probably aren't aware of the use cases or don't implement parallel 
command submission.

And if it weren't for the TTM lock, the cross device work wouldn't have 
to consider the case where a client
needs to lock out other reservers, and the cross-device design would 
suffer.

The main use cases are:

1) If we change master, clients of other masters need to be locked out 
from claiming memory resources (particularly VRAM).
2) If we're about to suspend and have cleaned VRAM, client's need to be 
stopped from validating VRAM buffer objects.
3) If a client needs access to the complete video memory space or need 
to defragment, it needs to lock out other reservers in a parallell 
command submission environment

Now, present a better solution to those use cases, and I'll ack this 
patch and implement that solution, or
leave the TTM lock in place as a reminder that these things need to be 
considered, and that we should have a common solution to them.

/Thomas

On 12/10/12 11:26 AM, Daniel Vetter wrote:
> ... it's the only user. Also move the header fil there.
>
>  but seriously, ttm_lock is best left undocumented since
> nobody should use that unholy thing..
>  agreed ;-)
>  imo we should shovel that under drm/vmwgfx ...
>  amen
>  that thing scares me
>  out of sight, out of mind ...
>
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/ttm/Makefile|2 +-
>   drivers/gpu/drm/ttm/ttm_lock.c  |  310 
> ---
>   drivers/gpu/drm/vmwgfx/Makefile |2 +-
>   drivers/gpu/drm/vmwgfx/ttm_lock.c   |  310 
> +++
>   drivers/gpu/drm/vmwgfx/ttm_lock.h   |  247 
>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +-
>   include/drm/ttm/ttm_lock.h  |  247 
>   7 files changed, 560 insertions(+), 560 deletions(-)
>   delete mode 100644 drivers/gpu/drm/ttm/ttm_lock.c
>   create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c
>   create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h
>   delete mode 100644 include/drm/ttm/ttm_lock.h
>
> diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
> index b2b33dd..607a0b6 100644
> --- a/drivers/gpu/drm/ttm/Makefile
> +++ b/drivers/gpu/drm/ttm/Makefile
> @@ -4,7 +4,7 @@
>   ccflags-y := -Iinclude/drm
>   ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
>   ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
> - ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
> + ttm_object.o ttm_execbuf_util.o ttm_page_alloc.o \
>   ttm_bo_manager.o
>   
>   ifeq ($(CONFIG_SWIOTLB),y)
> diff --git a/drivers/gpu/drm/ttm/ttm_lock.c b/drivers/gpu/drm/ttm/ttm_lock.c
> deleted file mode 100644
> index 3daa9a3..000
> --- a/drivers/gpu/drm/ttm/ttm_lock.c
> +++ /dev/null
> @@ -1,310 +0,0 @@
> -/**
> - *
> - * Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
> - * All Rights Reserved.
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the
> - * "Software"), to deal in the Software without restriction, including
> - * without limitation the rights to use, copy, modify, merge, publish,
> - * distribute, sub license, and/or sell copies of the Software, and to
> - * permit persons to whom the Software is furnished to do so, subject to
> - * the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the
> - * next paragraph) shall be included in all copies or substantial portions
> - * of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> - * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY 
> CLAIM,
> - * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> - * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> - * USE OR OTHER DEALINGS IN THE SOFTWARE.
> - *
> - **/
> -/*
> - * Authors: Thomas Hellstrom 
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#define TTM_WRITE_LOCK_PENDING

[RFC 6/6] video: add makefile & kconfig

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/Kconfig  |1 +
 drivers/video/Makefile |1 +
 drivers/video/display/Kconfig  |   26 ++
 drivers/video/display/Makefile |5 +
 4 files changed, 33 insertions(+)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index c5b7bcf..e91f03e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2442,6 +2442,7 @@ source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"

 if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b936b00..0a4cfea 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= display/

 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..1d1a590
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,26 @@
+menuconfig DISPLAY_CORE
+   tristate "Display Core"
+   ---help---
+ Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_PANEL_DPI
+   tristate "DPI (Parallel) Display Panels"
+   ---help---
+ Support for simple digital (parallel) pixel interface panels. Those
+ panels receive pixel data through a parallel bus and have no control
+ bus.
+
+ If you are in doubt, say N.
+
+config DISPLAY_PANEL_DVI
+   tristate "DVI Monitor"
+
+config DISPLAY_PANEL_TAAL
+   tristate "Taal DSI command mode panel"
+
+config DISPLAY_CHIP_TFP410
+   tristate "DPI to DVI chip"
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..ac97dfd
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
+obj-$(CONFIG_DISPLAY_PANEL_DVI) += panel-dvi.o
+obj-$(CONFIG_DISPLAY_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_DISPLAY_CHIP_TFP410) += chip-tfp410.o
-- 
1.7.10.4

[RFC 5/6] video: add taal panel

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/display/panel-taal.c   |  383 ++
 include/video/omap-panel-nokia-dsi.h |4 +-
 2 files changed, 385 insertions(+), 2 deletions(-)
 create mode 100644 drivers/video/display/panel-taal.c

diff --git a/drivers/video/display/panel-taal.c 
b/drivers/video/display/panel-taal.c
new file mode 100644
index 000..f1c2196
--- /dev/null
+++ b/drivers/video/display/panel-taal.c
@@ -0,0 +1,383 @@
+/*
+ * Taal DSI command mode panel
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Tomi Valkeinen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#define DEBUG
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* DSI Virtual channel. Hardcoded for now. */
+#define TCH 0
+
+#define DCS_READ_NUM_ERRORS0x05
+#define DCS_BRIGHTNESS 0x51
+#define DCS_CTRL_DISPLAY   0x53
+#define DCS_WRITE_CABC 0x55
+#define DCS_READ_CABC  0x56
+#define DCS_GET_ID10xda
+#define DCS_GET_ID20xdb
+#define DCS_GET_ID30xdc
+
+struct taal_data {
+   struct platform_device *pdev;
+   struct video_source *src;
+   struct display_entity entity;
+
+   struct mutex lock;
+
+   unsigned long   hw_guard_end;   /* next value of jiffies when we can
+* issue the next sleep in/out command
+*/
+   unsigned long   hw_guard_wait;  /* max guard time in jiffies */
+
+   /* panel HW configuration from DT or platform data */
+   int reset_gpio;
+
+   /* runtime variables */
+   bool enabled;
+
+   bool te_enabled;
+
+   int channel;
+
+   bool cabc_broken;
+   unsigned cabc_mode;
+
+   bool intro_printed;
+};
+
+static void hw_guard_start(struct taal_data *td, int guard_msec)
+{
+   td->hw_guard_wait = msecs_to_jiffies(guard_msec);
+   td->hw_guard_end = jiffies + td->hw_guard_wait;
+}
+
+static void hw_guard_wait(struct taal_data *td)
+{
+   unsigned long wait = td->hw_guard_end - jiffies;
+
+   if ((long)wait > 0 && wait <= td->hw_guard_wait) {
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(wait);
+   }
+}
+
+static int taal_dcs_read_1(struct taal_data *td, u8 dcs_cmd, u8 *data)
+{
+   int r;
+   u8 buf[1];
+   struct video_source *src = td->src;
+
+   r = src->ops.dsi->dcs_read(src, td->channel, dcs_cmd, buf, 1);
+   if (r < 0)
+   return r;
+
+   *data = buf[0];
+
+   return 0;
+}
+
+static int taal_dcs_write_0(struct taal_data *td, u8 dcs_cmd)
+{
+   struct video_source *src = td->src;
+
+   return src->ops.dsi->dcs_write(src, td->channel, _cmd, 1);
+}
+
+static int taal_sleep_out(struct taal_data *td)
+{
+   int r;
+
+   hw_guard_wait(td);
+
+   r = taal_dcs_write_0(td, MIPI_DCS_EXIT_SLEEP_MODE);
+   if (r)
+   return r;
+
+   hw_guard_start(td, 120);
+
+   msleep(5);
+
+   return 0;
+}
+
+static int taal_get_id(struct taal_data *td, u8 *id1, u8 *id2, u8 *id3)
+{
+   int r;
+
+   r = taal_dcs_read_1(td, DCS_GET_ID1, id1);
+   if (r)
+   return r;
+   r = taal_dcs_read_1(td, DCS_GET_ID2, id2);
+   if (r)
+   return r;
+   r = taal_dcs_read_1(td, DCS_GET_ID3, id3);
+   if (r)
+   return r;
+
+   return 0;
+}
+
+static void taal_hw_reset(struct taal_data *td)
+{
+   if (!gpio_is_valid(td->reset_gpio))
+   return;
+
+   gpio_set_value(td->reset_gpio, 1);
+   udelay(10);
+   /* reset the panel */
+   gpio_set_value(td->reset_gpio, 0);
+   /* assert reset */
+   udelay(10);
+   gpio_set_value(td->reset_gpio, 1);
+   /* wait after releasing reset */
+   msleep(5);
+}
+
+#define to_panel(p) container_of(p, struct taal_data, entity)
+
+static int taal_set_state(struct display_entity *entity,
+  enum display_entity_state state)
+{
+   struct taal_data *td = to_panel(entity);
+   struct video_source *src = td->src;
+   int r;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   r = taal_dcs_write_0(td, MIPI_DCS_SET_DISPLAY_OFF);
+   if (r)
+

[RFC 4/6] video: add generic dvi monitor

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/display/panel-dvi.c |  164 +
 include/video/panel-dvi.h |   18 
 2 files changed, 182 insertions(+)
 create mode 100644 drivers/video/display/panel-dvi.c
 create mode 100644 include/video/panel-dvi.h

diff --git a/drivers/video/display/panel-dvi.c 
b/drivers/video/display/panel-dvi.c
new file mode 100644
index 000..01cea09
--- /dev/null
+++ b/drivers/video/display/panel-dvi.c
@@ -0,0 +1,164 @@
+/*
+ * Generic DVI monitor
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Contacts: Tomi Valkeinen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct panel_data {
+   struct display_entity entity;
+   struct video_source *in;
+};
+
+#define to_panel(p) container_of(p, struct panel_data, entity)
+
+static int panel_dvi_set_state(struct display_entity *entity,
+  enum display_entity_state state)
+{
+   struct panel_data *data = to_panel(entity);
+   struct video_source *in = data->in;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   in->common_ops->set_stream(in, DISPLAY_ENTITY_STREAM_STOPPED);
+   break;
+
+   case DISPLAY_ENTITY_STATE_ON:
+   in->common_ops->set_stream(in, 
DISPLAY_ENTITY_STREAM_CONTINUOUS);
+   break;
+   }
+
+   return 0;
+}
+
+static const struct videomode vga_mode = {
+   .pixelclock = 23500,
+
+   .hactive = 640,
+   .hfront_porch = 48,
+   .hback_porch = 80,
+   .hsync_len = 32,
+
+   .vactive = 480,
+   .vfront_porch = 3,
+   .vback_porch = 7,
+   .vsync_len = 4,
+
+   .hah = true,
+   .vah = true,
+   .de = true,
+};
+
+static int panel_dvi_get_modes(struct display_entity *entity,
+  const struct videomode **modes)
+{
+   //struct panel_data *data = to_panel(entity);
+
+   *modes = _mode;
+   return 1;
+}
+
+static int panel_dvi_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+   //struct panel_data *data = to_panel(entity);
+
+   *width = 10;
+   *height = 10;
+   return 0;
+}
+
+static const struct display_entity_control_ops panel_dvi_control_ops = {
+   .set_state = panel_dvi_set_state,
+   .get_modes = panel_dvi_get_modes,
+   .get_size = panel_dvi_get_size,
+};
+
+static void panel_dvi_release(struct display_entity *entity)
+{
+   printk("panel dvi release\n");
+}
+
+static int __devinit panel_dvi_probe(struct platform_device *pdev)
+{
+   const struct panel_dvi_platform_data *pdata = pdev->dev.platform_data;
+   struct panel_data *data;
+   int ret;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (data == NULL)
+   return -ENOMEM;
+
+   /* setup input */
+   data->in = video_source_find(pdata->video_source);
+   if (data->in == NULL) {
+   printk("failed to get video source\n");
+   return -EINVAL;
+   }
+
+   /* setup default mode */
+   data->in->ops.dvi->set_videomode(data->in, _mode);
+
+   /* setup panel entity */
+
+   data->entity.dev = >dev;
+   data->entity.release = panel_dvi_release;
+   data->entity.ops = _dvi_control_ops;
+
+   ret = display_entity_register(>entity);
+   if (ret < 0) {
+   video_source_put(data->in);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, data);
+
+   return 0;
+}
+
+static int panel_dvi_remove(struct platform_device *pdev)
+{
+   struct panel_data *data = platform_get_drvdata(pdev);
+
+   display_entity_unregister(>entity);
+
+   video_source_put(data->in);
+
+   return 0;
+}
+
+
+static const struct dev_pm_ops panel_dvi_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dvi_driver = {
+   .probe = panel_dvi_probe,
+   .remove = panel_dvi_remove,
+   .driver = {
+   .name = "panel_dvi",
+   .owner = THIS_MODULE,
+   .pm = _dvi_dev_pm_ops,
+   },
+};
+
+module_platform_driver(panel_dvi_driver);
+
+MODULE_AUTHOR("Tomi Valkeinen ");
+MODULE_DESCRIPTION("DVI Monitor");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-dvi.h b/include/video/panel-dvi.h
new file mode 100644
index 000..ab88380
--- /dev/null
+++ b/include/video/panel-dvi.h
@@ -0,0 +1,18 @@
+/*
+ * DVI Display Panel
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */

[RFC 3/6] video: add tfp410

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/display/chip-tfp410.c |  164 +++
 include/video/omap-panel-tfp410.h   |4 +
 2 files changed, 168 insertions(+)
 create mode 100644 drivers/video/display/chip-tfp410.c

diff --git a/drivers/video/display/chip-tfp410.c 
b/drivers/video/display/chip-tfp410.c
new file mode 100644
index 000..2f8bdb6
--- /dev/null
+++ b/drivers/video/display/chip-tfp410.c
@@ -0,0 +1,164 @@
+/*
+ * TFP410 DPI-to-DVI bridge
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Contacts: Tomi Valkeinen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct tfp410_data {
+   struct video_source *in;
+
+   struct video_source out;
+
+   int power_down_gpio;
+};
+
+#define to_tfp410(p) container_of(p, struct tfp410_data, out)
+
+static int tfp410_set_stream(struct video_source *src,
+enum video_source_stream_state state)
+{
+   struct tfp410_data *data = to_tfp410(src);
+   struct video_source *in = data->in;
+   int r;
+
+   r = in->common_ops->set_stream(in, state);
+   if (r)
+   return r;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STREAM_STOPPED:
+   printk("tfp410 set_stream: STOPPED\n");
+
+   gpio_set_value_cansleep(data->power_down_gpio, 0);
+
+   break;
+
+   case DISPLAY_ENTITY_STREAM_CONTINUOUS:
+   printk("tfp410 set_stream: CONTINUOUS\n");
+
+   gpio_set_value_cansleep(data->power_down_gpio, 1);
+
+   break;
+
+   default:
+   printk("tfp410 set_stream error\n");
+   break;
+   }
+
+   return 0;
+}
+
+static int tfp410_set_vm(struct video_source *src, const struct videomode *vm)
+{
+   struct tfp410_data *data = to_tfp410(src);
+   struct video_source *in = data->in;
+
+   printk("tfp410 set vm\n");
+
+   return in->ops.dpi->set_videomode(in, vm);
+}
+
+static const struct common_video_source_ops tfp410_common_ops = {
+   .set_stream = tfp410_set_stream,
+};
+
+static const struct dvi_video_source_ops tfp410_dvi_ops = {
+   .set_videomode = tfp410_set_vm,
+};
+
+static void tfp410_release(struct video_source *src)
+{
+   printk("tfp410 entity release\n");
+}
+
+static int __devinit tfp410_probe(struct platform_device *pdev)
+{
+   const struct tfp410_platform_data *pdata = pdev->dev.platform_data;
+   struct tfp410_data *data;
+   int r;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (data == NULL)
+   return -ENOMEM;
+
+   data->power_down_gpio = pdata->power_down_gpio;
+
+   r = devm_gpio_request_one(>dev, pdata->power_down_gpio,
+   GPIOF_OUT_INIT_LOW, "tfp410 pd");
+   if (r) {
+   printk("failed to request pd gpio\n");
+   return r;
+   }
+
+   /* setup input */
+
+   data->in = video_source_find(pdata->video_source);
+   if (data->in == NULL) {
+   printk("failed to get video source\n");
+   return -EINVAL;
+   }
+
+   data->in->ops.dpi->set_data_lines(data->in, 24);
+
+   /* setup output */
+
+   data->out.dev = >dev;
+   data->out.release = tfp410_release;
+   data->out.common_ops = _common_ops;
+   data->out.ops.dvi = _dvi_ops;
+   data->out.name = pdata->video_output;
+
+   r = video_source_register(>out);
+   if (r < 0) {
+   printk("tfp410 entity register failed\n");
+   video_source_put(data->in);
+   return r;
+   }
+
+   platform_set_drvdata(pdev, data);
+
+   return 0;
+}
+
+static int tfp410_remove(struct platform_device *pdev)
+{
+   struct tfp410_data *data = platform_get_drvdata(pdev);
+
+   video_source_unregister(>out);
+
+   video_source_put(data->in);
+
+   return 0;
+}
+
+static struct platform_driver tfp410_driver = {
+   .probe = tfp410_probe,
+   .remove = tfp410_remove,
+   .driver = {
+   .name = "tfp410",
+   .owner = THIS_MODULE,
+   },
+};
+
+module_platform_driver(tfp410_driver);
+
+MODULE_AUTHOR("Tomi Valkeinen ");
+MODULE_DESCRIPTION("TFP410 DPI-to-DVI Bridge");
+MODULE_LICENSE("GPL");
diff --git a/include/video/omap-panel-tfp410.h 
b/include/video/omap-panel-tfp410.h
index b5b05f4..18f2b46 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -30,6 +30,10 @@ struct omap_dss_device;
  */
 struct tfp410_platform_data {
const char *name;
+
+   const char *video_source;
+   const char *video_output;
+
u16 i2c_bus_num;
int power_down_gpio;

[RFC 2/6] video: add generic dpi panel

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/display/panel-dpi.c |  155 +
 include/video/panel-dpi.h |   25 ++
 2 files changed, 180 insertions(+)
 create mode 100644 drivers/video/display/panel-dpi.c
 create mode 100644 include/video/panel-dpi.h

diff --git a/drivers/video/display/panel-dpi.c 
b/drivers/video/display/panel-dpi.c
new file mode 100644
index 000..824cd88
--- /dev/null
+++ b/drivers/video/display/panel-dpi.c
@@ -0,0 +1,155 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct panel_dpi {
+   struct display_entity entity;
+   struct video_source *src;
+   const struct panel_dpi_platform_data *pdata;
+};
+
+#define to_panel_dpi(p)container_of(p, struct panel_dpi, 
entity)
+
+static int panel_dpi_set_state(struct display_entity *entity,
+  enum display_entity_state state)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+   struct video_source *src = panel->src;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   src->common_ops->set_stream(src,
+   DISPLAY_ENTITY_STREAM_STOPPED);
+   break;
+
+   case DISPLAY_ENTITY_STATE_ON:
+   src->common_ops->set_stream(src,
+   DISPLAY_ENTITY_STREAM_CONTINUOUS);
+   break;
+   }
+
+   return 0;
+}
+
+static int panel_dpi_get_modes(struct display_entity *entity,
+  const struct videomode **modes)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   *modes = panel->pdata->mode;
+   return 1;
+}
+
+static int panel_dpi_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   *width = panel->pdata->width;
+   *height = panel->pdata->height;
+   return 0;
+}
+
+static const struct display_entity_control_ops panel_dpi_control_ops = {
+   .set_state = panel_dpi_set_state,
+   .get_modes = panel_dpi_get_modes,
+   .get_size = panel_dpi_get_size,
+};
+
+static void panel_dpi_release(struct display_entity *entity)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   kfree(panel);
+}
+
+static int panel_dpi_remove(struct platform_device *pdev)
+{
+   struct panel_dpi *panel = platform_get_drvdata(pdev);
+
+   display_entity_unregister(>entity);
+
+   if (panel->src) {
+   video_source_put(panel->src);
+   panel->src = NULL;
+   }
+
+   platform_set_drvdata(pdev, NULL);
+
+   return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+   const struct panel_dpi_platform_data *pdata = pdev->dev.platform_data;
+   struct panel_dpi *panel;
+   int ret;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+   if (panel == NULL)
+   return -ENOMEM;
+
+   panel->pdata = pdata;
+
+   panel->src = video_source_find(pdata->video_source);
+   if (panel->src == NULL) {
+   printk("failed to get video source\n");
+   return -EINVAL;
+   }
+
+   panel->src->ops.dpi->set_data_lines(panel->src, 24);
+   panel->src->ops.dpi->set_videomode(panel->src, pdata->mode);
+
+   panel->entity.dev = >dev;
+   panel->entity.release = panel_dpi_release;
+   panel->entity.ops = _dpi_control_ops;
+
+   ret = display_entity_register(>entity);
+   if (ret < 0) {
+   kfree(panel);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, panel);
+
+   return 0;
+}
+
+static const struct dev_pm_ops panel_dpi_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dpi_driver = {
+   .probe = panel_dpi_probe,
+   .remove = panel_dpi_remove,
+   .driver = {
+   .name = "panel_dpi",
+   .owner = THIS_MODULE,
+   .pm = _dpi_dev_pm_ops,
+   },
+};
+
+module_platform_driver(panel_dpi_driver);
+
+MODULE_AUTHOR("Laurent Pinchart ");
+MODULE_DESCRIPTION("DPI Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-dpi.h b/include/video/panel-dpi.h
new file mode 100644
index 000..0c5856e
--- /dev/null
+++ b/include/video/panel-dpi.h
@@ -0,0 +1,25 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ *

[RFC 1/6] video: add display-core

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/display/display-core.c |  207 ++
 include/video/display.h  |  166 +++
 2 files changed, 373 insertions(+)
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 include/video/display.h

diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
new file mode 100644
index 000..5f8be30
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,207 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* 
-
+ * Display Entity
+ */
+
+static LIST_HEAD(display_entity_list);
+static DEFINE_MUTEX(display_entity_mutex);
+
+struct display_entity *display_entity_get_first(void)
+{
+   if (list_empty(_entity_list))
+   return NULL;
+
+   return list_first_entry(_entity_list, struct display_entity,
+   list);
+}
+EXPORT_SYMBOL(display_entity_get_first);
+
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   int ret;
+
+   if (entity->state == state)
+   return 0;
+
+   if (!entity->ops || !entity->ops->set_state)
+   return 0;
+
+   ret = entity->ops->set_state(entity, state);
+   if (ret < 0)
+   return ret;
+
+   entity->state = state;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+int display_entity_get_modes(struct display_entity *entity,
+const struct videomode **modes)
+{
+   if (!entity->ops || !entity->ops->get_modes)
+   return 0;
+
+   return entity->ops->get_modes(entity, modes);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_modes);
+
+int display_entity_get_size(struct display_entity *entity,
+   unsigned int *width, unsigned int *height)
+{
+   if (!entity->ops || !entity->ops->get_size)
+   return -EOPNOTSUPP;
+
+   return entity->ops->get_size(entity, width, height);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_size);
+
+static void display_entity_release(struct kref *ref)
+{
+   struct display_entity *entity =
+   container_of(ref, struct display_entity, ref);
+
+   if (entity->release)
+   entity->release(entity);
+}
+
+struct display_entity *display_entity_get(struct display_entity *entity)
+{
+   if (entity == NULL)
+   return NULL;
+
+   kref_get(>ref);
+   return entity;
+}
+EXPORT_SYMBOL_GPL(display_entity_get);
+
+void display_entity_put(struct display_entity *entity)
+{
+   kref_put(>ref, display_entity_release);
+}
+EXPORT_SYMBOL_GPL(display_entity_put);
+
+int __must_check __display_entity_register(struct display_entity *entity,
+  struct module *owner)
+{
+   kref_init(>ref);
+   entity->owner = owner;
+   entity->state = DISPLAY_ENTITY_STATE_OFF;
+
+   mutex_lock(_entity_mutex);
+   list_add(>list, _entity_list);
+
+   mutex_unlock(_entity_mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__display_entity_register);
+
+void display_entity_unregister(struct display_entity *entity)
+{
+   mutex_lock(_entity_mutex);
+
+   list_del(>list);
+   mutex_unlock(_entity_mutex);
+
+   display_entity_put(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_unregister);
+
+/* 
-
+ * Video Source
+ */
+
+static LIST_HEAD(video_source_list);
+static DEFINE_MUTEX(video_source_mutex);
+
+int __must_check __video_source_register(struct video_source *src,
+  struct module *owner)
+{
+   kref_init(>ref);
+   src->owner = owner;
+
+   mutex_lock(_source_mutex);
+   list_add(>list, _source_list);
+
+   mutex_unlock(_source_mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__video_source_register);
+
+void video_source_unregister(struct video_source *src)
+{
+   mutex_lock(_source_mutex);
+
+   list_del(>list);
+   mutex_unlock(_source_mutex);
+
+   video_source_put(src);
+}
+EXPORT_SYMBOL_GPL(video_source_unregister);
+
+
+static void video_source_release(struct kref *ref)
+{
+   struct video_source *src =
+   container_of(ref, struct video_source, ref);
+
+   if (src->release)
+   src->release(src);
+}
+
+struct video_source *video_source_get(struct video_source *src)
+{
+   if (src == NULL)
+   return NULL;
+
+

[RFC 0/6] Common Display Framework-T

Hi,

I have been testing Common Display Framework on OMAP, and making changes that
I've discussed in the posts I've sent in reply to the CDF series from Laurent.
While my CDF code is rather hacky and not at all ready, I wanted to post the
code for comments and also as a reference code to my posts.

So here is CDF-T (Tomi-edition =). 

Changes compared to Laurent's CDF
-

- DBI bus is removed. I don't have any DBI devices, and as I said in my posts,
  I didn't see need for a real bus for DBI (or DSI). I thus also removed the
  DBI panels.

- Split the display_entity into two parts: video_source, which is used to
  connect the display chips and panels, and display_entity, which represent
  either the panel or the whole pipeline (I'm not sure which is better).

- Added ops for DVI and DSI

- Added driver for TFP410, a DPI to DVI converter chip
- Added driver for generic DVI monitor
- Added driver for Taal, a DSI command mode panel

- Removed DISPLAY_ENTITY_STREAM_SINGLE_SHOT, and instead there's update() op.
  It's perhaps possible to use the single-shot method, but I went for a
  separate op to get a "update done"-callback implemented easily.

Notes about the code


As I said, the code is rather untidy, but I think it's more or less
understandable. I've skipped adding any helper funcs, for example to call the
ops, so it's easier for me to change the API.

I also (ab)used some of the omapdss panel headers to ease my hacking for
omapdss+cdf. These should be quite clear.

The code, including hacks to omapdss to make it use CDF, can be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-cdf

The DSI part is very unfinished. I am able to use it to start up the Taal
panel, and send frames to the panel, but it's really missing lots of stuff.

About display_entity & video_source
---

I've discussed this split in previous posts, but I'll describe it here again.

As I see it, the connections between the display blocks, and the use of the
panel (and thus the whole pipeline) are very different things, and I think they
should be separated. So in my version I have struct video_source, used to
connect the blocks, and display_entity, representing the panel or the whole
pipeline. display_entity is probably not a good name for it anymore, but I
didn't come up with a good one yet.

As an example, let's look at chip-tfp410.c and panel-dvi.c.

tfp410 uses two video_sources, one for input and one for output. The input
comes from some other display block, in my case from OMAP display subsystem.
OMAP DSS has registered a DPI video_source, and the tfp410 driver will get this
source using video_source_find().

tfp410 registers its output as a video source, using video_source_register.
panel-dvi will in turn use video_source_find() to get it.

Both drivers use video_source to configure the input bus, i.e. tfp410
configures the DPI bus between OMAP DSS and TFP410 using, for example,
set_data_lines op to configure the number of datalines on the DPI bus.

With the video_sources in place, the whole video pipeline can be used. However,
we still need to expose an API so that somebody can actually use the pipeline.
This is done with display_entity. display_entity contains higher level ops,
which are not bus specific. The display_entity is registered by the panel at
the end of the chain.

In my model the display_entity ops go to the panel driver, which then calls ops
in the input video source to do the work. Laurent has objected to this model,
and would rather have the display_entity ops go to the DSS side (if I
understood right), which would then propagate forward towards the panel. I have
still kept my model, as I don't see the downsides with my model, nor do I see
any use for propagating the ops from DSS to the panel. But I'm happy to hear
examples how it is beneficial and could be used.


About the bus model
---

Lauren't version uses a linux bus for DBI. The idea here is that DBI is the
control bus fro the panel/chip, and should thus be represented by a real bus.
While I agreed to this approach when we discussed about it, I now am slightly
against it.

My reason is that DBI (or DSI or any other similar bus) is not really control
bus, it is a video bus. It _can_ be used for control, but video is the main
purpose. This has the partical issues:

- There's never use for DBI only for control. DBI is always used for either
  video only, or control+video.

- If DBI is used only for video, there's no DBI bus. How to configure DBI in
  this case?

- If DBI is used for control and video, we have two separate APIs for the bus.
  In theory it's possible to handle this, but in practice it may be impossible,
  especially for more complex busses like DSI.

So in my version I added DSI as a plain video_source, without a real linux bus.
I think this model is a lot simpler, and works better.

 Tomi

Tomi Valkeinen (6):
  video: add

[PATCH] drm/radeon: restore modeset late in GPU reset path

2012-12-14 Thread j.gli...@gmail.com

From: Jerome Glisse 

Modeset path seems to conflict sometimes with the memory management
leading to kernel deadlock. This move modesetting reset after GPU
acceleration reset.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e2f5f88..ffd5534 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1337,7 +1337,6 @@ retry:
}

radeon_restore_bios_scratch_regs(rdev);
-   drm_helper_resume_force_mode(rdev->ddev);

if (!r) {
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
@@ -1362,6 +1361,8 @@ retry:
}
}

+   drm_helper_resume_force_mode(rdev->ddev);
+
ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
if (r) {
/* bad news, how to tell it to userspace ? */
-- 
1.7.11.7

new userspace API approaches atomic *

On Fri, Dec 14, 2012 at 07:13:33AM +1000, Dave Airlie wrote:
> So this is a how to get new features pronouncement,
> 
> >From what I can see people would like to have atomic interfaces for
> pageflip and modesetting merged,
> 
> Now how I think developing and merging these will work (i.e. do it
> this way or don't bother)
> 
> a) get an API you are happy with working, it doesn't need to be perfect
> 
> b) rework the internal drm core/driver APIs for all drivers to allow
> this new interface to be used. Remove
> the old internal apis and create an interface layer between the old
> userspace interface and the new API.

There are several problems with this:

- I can't test other drivers

- I don't have the knowledge or inclination to implement atomic semantics
  for everyone's favorite hardware, and without that there's little
  point in doing the work. Some of my initial code was layered on top of
  drm_crtc_helper though, so it might be possible to use that as a basis
  for an atomic helper, but there would actually be no benefit from
  using it apart from allowing those drivers to respond to the atomic
  ioctl. But we wouldn't use any of that w/ i915, so it would be better is
  someone else does that part.

- Replacing all the legacy codepaths with new code in one go increases the
  chance that we get a regression, and then we have no choice but to
  back out the whole thing. Also it seems that no-one apart from Rob has
  even looked at the code, so it seems likely that there would be heavy
  opposition to replacing the current code with something new.

- These are the reasons I would like to merge the thing without touching
  the legcay codepaths too much. Then each driver author could move their
  code over the new APIs. I'm willing to help of course, but the driver
  authors are in a much better position to make something that actually
  works for their hardware.

> c) throw away (a)
> 
> d) reimplement a userspace API on top of the new internal driver API
> fixing all the things you have learned,
> were crazy, insane, nuts etc.
> 
> e) have a lot of tests.

Sure more tests would be nice. I'll try to cook up something to stresses
the modeset side soon.

> f) get b merged standalone, transition phase is fine, but every driver
> needs to be ported before the API
> goes in.

Why? The current drivers are not using the same APIs internally anyway.
i915 doesn't use drm_crtc_helper for example. You didn't demand that
Daniel rewrite drm_crtc_helper to suit i915 and fix up all the other
drivers, did you?

> g) throw away d
> 
> h) write final API and get it merged.
> 
> Yes this is probably more work than you or your manager is willing to
> buy in, but then maybe the feature isn't that important.

Right, so either I rewrite the modeset and pageflip code for all drivers,
or I wait until all the driver authors decide to help me. The first one
will take approximately five years given that I don't know the hardware
and I have other tasks on my plate, and based on the past interest the
second one doesn't seem likely to happen anytime soon 

All this make me think I should just try to push it as an i915 private
feature. Damn the other drivers. That should make the management happy too
since everyone that needs atomic display updates on Linux will need to buy
Intel hardware.

Oh well, the world is supposedly ending in a few days anyway, so perhaps
I can just relax and stop caring :)

-- 
Ville Syrj?l?
Intel OTC

[PATCH 4/4] drm/exynos: support device tree for fimd

This adds the of_match_table to exynos-drm fimd driver to be probed from
the device tree.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1e4ea96..21a4f12 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include 
@@ -106,9 +107,26 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };

+#ifdef CONFIG_OF
+static const struct of_device_id fimd_driver_dt_match[] = {
+   { .compatible = "samsung,exynos4-fimd",
+ .data = _fimd_driver_data },
+   { .compatible = "samsung,exynos5-fimd",
+ .data = _fimd_driver_data },
+   {},
+};
+MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
+#endif
+
 static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
+   const struct of_device_id *of_id =
+   of_match_device(fimd_driver_dt_match, >dev);
+
+   if (of_id)
+   return (struct fimd_driver_data *)of_id->data;
+
return (struct fimd_driver_data *)
platform_get_device_id(pdev)->driver_data;
 }
@@ -1091,5 +1109,6 @@ struct platform_driver fimd_driver = {
.name   = "exynos4-fb",
.owner  = THIS_MODULE,
.pm = _pm_ops,
+   .of_match_table = of_match_ptr(fimd_driver_dt_match),
},
 };
-- 
1.7.9.5

[PATCH 3/4] drm/exynos: support extended screen coordinate of fimd

The fimd of exynos5 SoC supports extended screen coordinate.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index ae0153b..1e4ea96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -243,7 +243,9 @@ static void fimd_commit(struct device *dev)

/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing->yres - 1) |
-  VIDTCON2_HOZVAL(timing->xres - 1);
+  VIDTCON2_HOZVAL(timing->xres - 1) |
+  VIDTCON2_LINEVAL_E(timing->yres - 1) |
+  VIDTCON2_HOZVAL_E(timing->xres - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON2);

/* setup clock source, clock divider, enable dma. */
@@ -518,12 +520,16 @@ static void fimd_win_commit(struct device *dev, int zpos)

/* buffer size */
val = VIDW_BUF_SIZE_OFFSET(win_data->buf_offsize) |
-   VIDW_BUF_SIZE_PAGEWIDTH(win_data->line_size);
+   VIDW_BUF_SIZE_PAGEWIDTH(win_data->line_size) |
+   VIDW_BUF_SIZE_OFFSET_E(win_data->buf_offsize) |
+   VIDW_BUF_SIZE_PAGEWIDTH_E(win_data->line_size);
writel(val, ctx->regs + VIDWx_BUF_SIZE(win, 0));

/* OSD position */
val = VIDOSDxA_TOPLEFT_X(win_data->offset_x) |
-   VIDOSDxA_TOPLEFT_Y(win_data->offset_y);
+   VIDOSDxA_TOPLEFT_Y(win_data->offset_y) |
+   VIDOSDxA_TOPLEFT_X_E(win_data->offset_x) |
+   VIDOSDxA_TOPLEFT_Y_E(win_data->offset_y);
writel(val, ctx->regs + VIDOSD_A(win));

last_x = win_data->offset_x + win_data->ovl_width;
@@ -533,7 +539,9 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (last_y)
last_y--;

-   val = VIDOSDxB_BOTRIGHT_X(last_x) | VIDOSDxB_BOTRIGHT_Y(last_y);
+   val = VIDOSDxB_BOTRIGHT_X(last_x) | VIDOSDxB_BOTRIGHT_Y(last_y) |
+   VIDOSDxB_BOTRIGHT_X_E(last_x) | VIDOSDxB_BOTRIGHT_Y_E(last_y);
+
writel(val, ctx->regs + VIDOSD_B(win));

DRM_DEBUG_KMS("osd pos: tx = %d, ty = %d, bx = %d, by = %d\n",
-- 
1.7.9.5

[PATCH 2/4] drm/exynos: fix x, y coordinates for right bottom pixel

The x, y coordinates of right bottom pixel cannot be negative numbers.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 90ca4b2..ae0153b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -471,6 +471,8 @@ static void fimd_win_commit(struct device *dev, int zpos)
struct fimd_win_data *win_data;
int win = zpos;
unsigned long val, alpha, size;
+   unsigned int last_x;
+   unsigned int last_y;

DRM_DEBUG_KMS("%s\n", __FILE__);

@@ -524,16 +526,18 @@ static void fimd_win_commit(struct device *dev, int zpos)
VIDOSDxA_TOPLEFT_Y(win_data->offset_y);
writel(val, ctx->regs + VIDOSD_A(win));

-   val = VIDOSDxB_BOTRIGHT_X(win_data->offset_x +
-   win_data->ovl_width - 1) |
-   VIDOSDxB_BOTRIGHT_Y(win_data->offset_y +
-   win_data->ovl_height - 1);
+   last_x = win_data->offset_x + win_data->ovl_width;
+   if (last_x)
+   last_x--;
+   last_y = win_data->offset_y + win_data->ovl_height;
+   if (last_y)
+   last_y--;
+
+   val = VIDOSDxB_BOTRIGHT_X(last_x) | VIDOSDxB_BOTRIGHT_Y(last_y);
writel(val, ctx->regs + VIDOSD_B(win));

DRM_DEBUG_KMS("osd pos: tx = %d, ty = %d, bx = %d, by = %d\n",
-   win_data->offset_x, win_data->offset_y,
-   win_data->offset_x + win_data->ovl_width - 1,
-   win_data->offset_y + win_data->ovl_height - 1);
+   win_data->offset_x, win_data->offset_y, last_x, last_y);

/* hardware window 0 doesn't support alpha channel. */
if (win != 0) {
-- 
1.7.9.5

[PATCH 1/4] drm/exynos: fix fb offset calculation for plane

There is no any reason to change fb offset when CRTC is out of screen.
Also, this fixes a typing error.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 399b026..83efc66 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -40,7 +40,7 @@ static const uint32_t formats[] = {
  * CRTC 
  *  ^ start^ end
  *
- * There are six cases from a to b.
+ * There are six cases from a to f.
  *
  * <- SCREEN ->
  * 0 last
@@ -104,16 +104,12 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (crtc_x < 0) {
if (actual_w)
src_x -= crtc_x;
-   else
-   src_x += crtc_w;
crtc_x = 0;
}

if (crtc_y < 0) {
if (actual_h)
src_y -= crtc_y;
-   else
-   src_y += crtc_h;
crtc_y = 0;
}

-- 
1.7.9.5

[PATCH 0/4] drm/exynos: update plane and fimd

This patchset is to update plane and fimd of exynos-drm. it includes
modification about coordinates calculation of plane and fimd and device
tree support of fimd.

The patchset is based exynos-drm-next branch on of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Joonyoung Shim (4):
  drm/exynos: fix fb offset calculation for plane
  drm/exynos: fix x, y coordinates for right bottom pixel
  drm/exynos: support extended screen coordinate of fimd
  drm/exynos: support device tree for fimd

[PATCH v2] drm/exynos: fix allocation and cache mapping type

2012-12-14 Thread Inki Dae

This patch fixes memory alloction(contiguous or not) and
cache mapping types(cachable or not).
For this, it converts each type from user request into dma
attribute properly.

Changelog v2:
- just code cleanup.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c |   18 --
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 9732043..9601bad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -34,7 +34,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
int ret = 0;
-   enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
+   enum dma_attr attr;
unsigned int nr_pages;

DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -46,8 +46,22 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,

init_dma_attrs(>dma_attrs);

-   if (flags & EXYNOS_BO_NONCONTIG)
+   /*
+* if EXYNOS_BO_CONTIG, fully physically contiguous memory
+* region will be allocated else physically contiguous
+* as possible.
+*/
+   if (flags & EXYNOS_BO_CONTIG)
+   dma_set_attr(DMA_ATTR_FORCE_CONTIGUOUS, >dma_attrs);
+
+   /*
+* if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping
+* else cachable mapping.
+*/
+   if (flags & EXYNOS_BO_WC || !(flags & EXYNOS_BO_CACHABLE))
attr = DMA_ATTR_WRITE_COMBINE;
+   else
+   attr = DMA_ATTR_NON_CONSISTENT;

dma_set_attr(attr, >dma_attrs);
dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, >dma_attrs);
-- 
1.7.4.1

[Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Op 14-12-12 15:11, Rob Clark schreef:
> On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
>  wrote:
>> Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
>>> From: Sumit Semwal 
>>>
>>> Add debugfs support to make it easier to print debug information
>>> about the dma-buf buffers.
>>>
>> I like the idea, I don't know if it could be done in a free manner, but for 
>> bonus points
>> could we also have the dma-buf fd be obtainable that way from a debugfs 
>> entry?
>>
>> Doing so would allow me to 'steal' a dma-buf from an existing mapping 
>> easily, and test against that.
>>
>> Also I think the name of the device and process that exported the dma-buf 
>> would be useful
>> to have as well, even if in case of the device that would mean changing the 
>> api slightly to record it.
>>
>> I was thinking of having a directory structure like this:
>>
>> /sys/kernel/debug/dma_buf/stats
>>
>> and then for each dma-buf:
>>
>> /sys/kernel/debug/dma-buf/exporting_file.c/-fd
>> /sys/kernel/debug/dma-buf/exporting_file.c/-attachments
>> /sys/kernel/debug/dma-buf/exporting_file.c/-info
>>
>> Opening the fd file would give you back the original fd, or fail with -EIO 
>> if refcount was dropped to 0.
>>
>> Would something like this be doable? I don't know debugfs that well, but I 
>> don't see why it wouldn't be,
> yeah.. but sort of back-door's the security benefits of an anonymous fd..
>
> BR,
> -R
If you have access to debugfs you're root, so what stops you from stealing it 
through a ptrace?

~Maarten

[PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-14 Thread Jerome Glisse

On Fri, Dec 14, 2012 at 3:13 PM, Christian K?nig
 wrote:
> On 14.12.2012 18:39, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse 
>>
>> After lockup we need to resume fence to last sync sequence and not
>> last received sequence so that all thread waiting on command stream
>> that lockedup resume. Otherwise GPU reset will be ineffective in most
>> cases.
>
> NAK. I changed this on purpose to get partial resets working, please don't
> change it back.
>
> The IB test code should reset this to the last synced value anyway, if it
> doesn't work then there is something wrong there.
>
> Christian.

There is something wrong 

Jerome

[RESEND][PATCH] gpu: remove gma500 stub driver

2012-12-14 Thread Lee, Chun-Yi

In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.

Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-May/023426.html
http://lists.freedesktop.org/archives/dri-devel/2012-May/023467.html

Cc: randy.dunlap at oracle.com
Cc: trenn at suse.de
Cc: Valdis.Kletnieks at vt.edu
Cc: Dennis.Jansen at web.de
Cc: airlied at redhat.com
Cc: eric at anholt.net
Cc: alexdeucher at gmail.com
Cc: bskeggs at redhat.com
Cc: chris at chris-wilson.co.uk
Cc: Alan Cox 
Acked-by: Matthew Garrett 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Lee, Chun-Yi 
---
 drivers/gpu/Makefile   |2 +-
 drivers/gpu/stub/Kconfig   |   18 
 drivers/gpu/stub/Makefile  |1 -
 drivers/gpu/stub/poulsbo.c |   64 
 drivers/video/Kconfig  |2 -
 5 files changed, 1 insertions(+), 86 deletions(-)
 delete mode 100644 drivers/gpu/stub/Kconfig
 delete mode 100644 drivers/gpu/stub/Makefile
 delete mode 100644 drivers/gpu/stub/poulsbo.c

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index cc92778..30879df 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y  += drm/ vga/ stub/
+obj-y  += drm/ vga/
diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
deleted file mode 100644
index 4199179..000
--- a/drivers/gpu/stub/Kconfig
+++ /dev/null
@@ -1,18 +0,0 @@
-config STUB_POULSBO
-   tristate "Intel GMA500 Stub Driver"
-   depends on PCI
-   depends on NET # for THERMAL
-   # Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
-   # but for select to work, need to select ACPI_VIDEO's dependencies, ick
-   select BACKLIGHT_CLASS_DEVICE if ACPI
-   select VIDEO_OUTPUT_CONTROL if ACPI
-   select INPUT if ACPI
-   select ACPI_VIDEO if ACPI
-   select THERMAL if ACPI
-   help
- Choose this option if you have a system that has Intel GMA500
- (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
- intel opregion.
diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
deleted file mode 100644
index cd940cc..000
--- a/drivers/gpu/stub/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
deleted file mode 100644
index 7edfd27..000
--- a/drivers/gpu/stub/poulsbo.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Intel Poulsbo Stub driver
- *
- * Copyright (C) 2010 Novell 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#define DRIVER_NAME "poulsbo"
-
-enum {
-   CHIP_PSB_8108 = 0,
-   CHIP_PSB_8109 = 1,
-};
-
-static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
-   {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
-   {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
-   {0, 0, 0}
-};
-
-static int poulsbo_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-{
-   return acpi_video_register();
-}
-
-static void poulsbo_remove(struct pci_dev *pdev)
-{
-   acpi_video_unregister();
-}
-
-static struct pci_driver poulsbo_driver = {
-   .name = DRIVER_NAME,
-   .id_table = pciidlist,
-   .probe = poulsbo_probe,
-   .remove = poulsbo_remove,
-};
-
-static int __init poulsbo_init(void)
-{
-   return pci_register_driver(_driver);
-}
-
-static void __exit poulsbo_exit(void)
-{
-   pci_unregister_driver(_driver);
-}
-
-module_init(poulsbo_init);
-module_exit(poulsbo_exit);
-
-MODULE_AUTHOR("Lee, Chun-Yi ");
-MODULE_DESCRIPTION("Poulsbo Stub Driver");
-MODULE_LICENSE("GPL");
-
-MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..cc99f41 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,8 +21,6 @@ source "drivers/gpu/vga/Kconfig"

 source "drivers/gpu/drm/Kconfig"

-source "drivers/gpu/stub/Kconfig"
-
 config VGASTATE
tristate
default n
-- 
1.6.0.2

[PATCH] dma-buf: Add debugfs support

2012-12-14 Thread sumit.sem...@ti.com

From: Sumit Semwal 

Add debugfs support to make it easier to print debug information
about the dma-buf buffers.

Signed-off-by: Sumit Semwal 
---
 drivers/base/dma-buf.c  |  149 +++
 include/linux/dma-buf.h |6 +-
 2 files changed, 154 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..49fcf0f 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 static inline int is_dma_buf_file(struct file *);

+struct dma_buf_list {
+   struct list_head head;
+   struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -40,6 +49,11 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
dmabuf = file->private_data;

dmabuf->ops->release(dmabuf);
+
+   mutex_lock(_list.lock);
+   list_del(>list_node);
+   mutex_unlock(_list.lock);
+
kfree(dmabuf);
return 0;
 }
@@ -120,6 +134,10 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
mutex_init(>lock);
INIT_LIST_HEAD(>attachments);

+   mutex_lock(_list.lock);
+   list_add(>list_node, _list.head);
+   mutex_unlock(_list.lock);
+
return dmabuf;
 }
 EXPORT_SYMBOL_GPL(dma_buf_export);
@@ -505,3 +523,134 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
dmabuf->ops->vunmap(dmabuf, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+static int dma_buf_init_debugfs(void);
+static void dma_buf_uninit_debugfs(void);
+
+static void __init dma_buf_init(void)
+{
+   mutex_init(_list.lock);
+   INIT_LIST_HEAD(_list.head);
+   dma_buf_init_debugfs();
+}
+
+static void __exit dma_buf_deinit(void)
+{
+   dma_buf_uninit_debugfs();
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+   int ret;
+   struct dma_buf *buf_obj;
+   struct dma_buf_attachment *attach_obj;
+   int count = 0, attach_count;
+   size_t size = 0;
+
+   ret = mutex_lock_interruptible(_list.lock);
+
+   if (ret)
+   return ret;
+
+   seq_printf(s, "\nDma-buf Objects:\n");
+   seq_printf(s, "\tsize\tflags\tmode\tcount\n");
+
+   list_for_each_entry(buf_obj, _list.head, list_node) {
+   seq_printf(s, "\t");
+
+   seq_printf(s, "%08zu\t%08x\t%08x\t%08d\n",
+   buf_obj->size, buf_obj->file->f_flags,
+   buf_obj->file->f_mode,
+   buf_obj->file->f_count.counter);
+
+   seq_printf(s, "\t\tAttached Devices:\n");
+   attach_count = 0;
+
+   list_for_each_entry(attach_obj, _obj->attachments, node) {
+   seq_printf(s, "\t\t");
+
+   seq_printf(s, "%s\n", attach_obj->dev->init_name);
+   attach_count++;
+   }
+
+   seq_printf(s, "\n\t\tTotal %d devices attached\n",
+   attach_count);
+
+   count++;
+   size += buf_obj->size;
+   }
+
+   seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
+
+   mutex_unlock(_list.lock);
+   return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+   void (*func)(struct seq_file *) = s->private;
+   func(s);
+   return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, dma_buf_show, inode->i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+   .open   = dma_buf_debug_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+   int err = 0;
+   dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL);
+   if (IS_ERR(dma_buf_debugfs_dir)) {
+   err = PTR_ERR(dma_buf_debugfs_dir);
+   dma_buf_debugfs_dir = NULL;
+   return err;
+   }
+
+   err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe);
+
+   if (err)
+   pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
+
+   return err;
+}
+
+static void dma_buf_uninit_debugfs(void)
+{
+   if (dma_buf_debugfs_dir)
+   debugfs_remove_recursive(dma_buf_debugfs_dir);
+}
+
+int dma_buf_debugfs_create_file(const char *name,
+   int (*write)(struct seq_file *))
+{
+   struct dentry *d;
+
+   d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir,
+   write, _buf_debug_fops);
+
+   if (IS_ERR(d))
+   return PTR_ERR(d);
+
+

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #6 from Alex Deucher  ---
Created attachment 71507
  --> https://bugs.freedesktop.org/attachment.cgi?id=71507=edit
fix

Should be fixed with this patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/5164ee34/attachment.html>

[PATCH] drm/fb: avoid sleeping in unblank_screen() if oops in progress

2012-12-14 Thread Konstantin Khlebnikov

unblank_screen() can be called from interrupt context during oops.
thus all ->fb_blank handlers should avoid sleeping in this situation.

callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
mutex_lock(>mode_config.mutex)

Signed-off-by: Konstantin Khlebnikov 
Cc: Andrew Morton 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_fb_helper.c |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 954d175..2c9f49f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -326,7 +326,7 @@ static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = 
{
 static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
 #endif

-static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
+static int drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
 {
struct drm_fb_helper *fb_helper = info->par;
struct drm_device *dev = fb_helper->dev;
@@ -334,10 +334,15 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
struct drm_connector *connector;
int i, j;

+   if (oops_in_progress) {
+   if (!mutex_trylock(>mode_config.mutex))
+   return -EBUSY;
+   } else
+   mutex_lock(>mode_config.mutex);
+
/*
 * For each CRTC in this fb, turn the connectors on/off.
 */
-   mutex_lock(>mode_config.mutex);
for (i = 0; i < fb_helper->crtc_count; i++) {
crtc = fb_helper->crtc_info[i].mode_set.crtc;

@@ -353,6 +358,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
}
}
mutex_unlock(>mode_config.mutex);
+   return 0;
 }

 int drm_fb_helper_blank(int blank, struct fb_info *info)
@@ -360,24 +366,19 @@ int drm_fb_helper_blank(int blank, struct fb_info *info)
switch (blank) {
/* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
/* Display: Off; HSync: On, VSync: On */
case FB_BLANK_NORMAL:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
/* Display: Off; HSync: Off, VSync: On */
case FB_BLANK_HSYNC_SUSPEND:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
/* Display: Off; HSync: On, VSync: Off */
case FB_BLANK_VSYNC_SUSPEND:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
/* Display: Off; HSync: Off, VSync: Off */
case FB_BLANK_POWERDOWN:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
}
return 0;
 }

drm/exynos: fix allocation and cache mapping type

2012-12-14 Thread Inki Dae

This patch fixes memory alloction(contiguous or not) and
cache mapping types(cachable or not).
For this, it converts each type from user request into dma
attribute properly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c |   20 ++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 7dc1309..e05fcfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -61,7 +61,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
int ret = 0;
-   enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
+   enum dma_attr attr;
unsigned int nr_pages;

DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -73,8 +73,24 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,

init_dma_attrs(>dma_attrs);

-   if (flags & EXYNOS_BO_NONCONTIG)
+   /*
+* if EXYNOS_BO_CONTIG, fully physically contiguous memory
+* region will be allocated else physically contiguous
+* as possible.
+*/
+   if (flags & EXYNOS_BO_CONTIG) {
+   attr = DMA_ATTR_FORCE_CONTIGUOUS;
+   dma_set_attr(attr, >dma_attrs);
+   }
+
+   /*
+* if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping
+* else cachable mapping.
+*/
+   if (flags & EXYNOS_BO_WC || !(flags & EXYNOS_BO_CACHABLE))
attr = DMA_ATTR_WRITE_COMBINE;
+   else
+   attr = DMA_ATTR_NON_CONSISTENT;

dma_set_attr(attr, >dma_attrs);
dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, >dma_attrs);
-- 
1.7.4.1

[RFC v3 5/5] drm/exynos: add gsc ipp driver

Thank's for your comment.

please check my answer.

BR
Eunchul Kim

On 12/13/2012 11:29 AM, Joonyoung Shim wrote:
> Hi,
>
> I can't review about logic of driver because i don't know well but i
> feel there are too many checking codes and unused or big size defines.

- I think error handling need. and What is unused defines ?
   What is big size define ? you mean the coefficient value ?

> Please refer v4l2 exynos gsc driver in drivers/media/platform/exynos-gsc/.

- I will check exynos gsc.

>
> This v3 patch seems to add many codes than v2. Please write changelog in
> future.

- Thank's I don't have a lot of experience about posting.

> Even if line is short, many lines are split to two lines. Please check
> it overall.

- PATCH description ?

>
> Thanks.
>
> On 12/12/2012 04:34 PM, Eunchul Kim wrote:
>> GSC is stand for General SCaler and supports supports
>
> supports supports

- Thank's, done.

>
>> image scaler/rotator/crop/flip/csc and input/output DMA operations.
>> input DMA reads image data from the memory.
>> output DMA writes image data to memory.
>> GSC supports image rotation and imag effect functions.
>
> s/imag/image

- done.

>
>> also supports writeback and display output operations.
>
> There are to begin a new line unnecessarily. Could you rewrite
> detailedly how this driver operates?

- What kind of ? writeback ? output operation ?

>
>>
>> Signed-off-by: Eunchul Kim 
>> Signed-off-by: Jinyoung Jeon 
>> ---
>>   drivers/gpu/drm/exynos/Kconfig  |5 +
>>   drivers/gpu/drm/exynos/Makefile |1 +
>>   drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>>   drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1927
>> +++
>>   drivers/gpu/drm/exynos/exynos_drm_gsc.h |   34 +
>>   drivers/gpu/drm/exynos/regs-gsc.h   |  295 +
>>   7 files changed, 2278 insertions(+), 0 deletions(-)
>>   create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.c
>>   create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
>>   create mode 100644 drivers/gpu/drm/exynos/regs-gsc.h
>>
>> diff --git a/drivers/gpu/drm/exynos/Kconfig
>> b/drivers/gpu/drm/exynos/Kconfig
>> index 4860835..c93d776 100644
>> --- a/drivers/gpu/drm/exynos/Kconfig
>> +++ b/drivers/gpu/drm/exynos/Kconfig
>> @@ -64,3 +64,8 @@ config DRM_EXYNOS_ROTATOR
>>   help
>> Choose this option if you want to use Exynos Rotator for DRM.
>> +config DRM_EXYNOS_GSC
>> +bool "Exynos DRM GSC"
>> +depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5
>> +help
>> +  Choose this option if you want to use Exynos GSC for DRM.
>> diff --git a/drivers/gpu/drm/exynos/Makefile
>> b/drivers/gpu/drm/exynos/Makefile
>> index 3b70668..639b49e 100644
>> --- a/drivers/gpu/drm/exynos/Makefile
>> +++ b/drivers/gpu/drm/exynos/Makefile
>> @@ -19,5 +19,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+=
>> exynos_drm_g2d.o
>>   exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)+= exynos_drm_ipp.o
>>   exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
>>   exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
>> +exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
>>   obj-$(CONFIG_DRM_EXYNOS)+= exynosdrm.o
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 09d884b..e0a8e80 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -384,6 +384,12 @@ static int __init exynos_drm_init(void)
>>   goto out_rotator;
>>   #endif
>> +#ifdef CONFIG_DRM_EXYNOS_GSC
>> +ret = platform_driver_register(_driver);
>> +if (ret < 0)
>> +goto out_gsc;
>> +#endif
>> +
>>   #ifdef CONFIG_DRM_EXYNOS_IPP
>>   ret = platform_driver_register(_driver);
>>   if (ret < 0)
>> @@ -412,6 +418,11 @@ out_drm:
>>   out_ipp:
>>   #endif
>> +#ifdef CONFIG_DRM_EXYNOS_GSC
>> +platform_driver_unregister(_driver);
>> +out_gsc:
>> +#endif
>> +
>>   #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>>   platform_driver_unregister(_driver);
>>   out_rotator:
>> @@ -462,6 +473,10 @@ static void __exit exynos_drm_exit(void)
>>   platform_driver_unregister(_driver);
>>   #endif
>> +#ifdef CONFIG_DRM_EXYNOS_GSC
>> +platform_driver_unregister(_driver);
>> +#endif
>> +
>>   #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>>   platform_driver_unregister(_driver);
>>   #endif
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index a74e37c..afe556c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -354,5 +354,6 @@ extern struct platform_driver vidi_driver;
>>   extern struct platform_driver g2d_driver;
>>   extern struct platform_driver fimc_driver;
>>   extern struct platform_driver rotator_driver;
>> +extern struct platform_driver gsc_driver;
>>   extern struct platform_driver ipp_driver;
>>   #endif
>> diff --git

[PATCH 2/2] drm/exynos: reorder framebuffer init sequence

2012-12-14 Thread Inki Dae

2012/12/14 Daniel Vetter 

> On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae  wrote:
> > How about rebasing this patch to top of
> > git://people.freedesktop.org/~airlied/linux.git drm-next?
> > Exynos's many patches have already been merged to drm-next. Or if you are
> > ok, I'd like to rebase your patch to -next and test it. I don't care
> either
> > way. :)
>
> I've pushed out a rebased version, but somehow I can't compile-test
> exynos any more :( Probably missing some other stuff from linux-next.
> Anyway, I don't mind which patch you pick or whether you just roll
> your own, the important thing is that drm_framebuffer_init is called
> _after_ everything is set up and initialized. Everything else doesn't
> really matter.
>

I've rebase your patch to -next and tested it. But your patch had null
pointer issue to gem object so I fixed it.
For this, you can refer to the below link,

http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git;a=shortlog;h=refs/heads/exynos-drm-next

And I gonna request git pull to -next including that patch today. If there
is any problem, please let me know.

Thanks,
Inki Dae.



> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/d5740e68/attachment-0001.html>

[Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
> From: Sumit Semwal 
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
I like the idea, I don't know if it could be done in a free manner, but for 
bonus points
could we also have the dma-buf fd be obtainable that way from a debugfs entry?

Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, 
and test against that.

Also I think the name of the device and process that exported the dma-buf would 
be useful
to have as well, even if in case of the device that would mean changing the api 
slightly to record it.

I was thinking of having a directory structure like this:

/sys/kernel/debug/dma_buf/stats

and then for each dma-buf:

/sys/kernel/debug/dma-buf/exporting_file.c/-fd
/sys/kernel/debug/dma-buf/exporting_file.c/-attachments
/sys/kernel/debug/dma-buf/exporting_file.c/-info

Opening the fd file would give you back the original fd, or fail with -EIO if 
refcount was dropped to 0.

Would something like this be doable? I don't know debugfs that well, but I 
don't see why it wouldn't be,

~Maarten

[PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-14 Thread j.gli...@gmail.com

From: Jerome Glisse 

After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command stream
that lockedup resume. Otherwise GPU reset will be ineffective in most
cases.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 22bd6c2..38233e7 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -787,7 +787,7 @@ int radeon_fence_driver_start_ring(struct radeon_device 
*rdev, int ring)
}
rdev->fence_drv[ring].cpu_addr = >wb.wb[index/4];
rdev->fence_drv[ring].gpu_addr = rdev->wb.gpu_addr + index;
-   radeon_fence_write(rdev, 
atomic64_read(>fence_drv[ring].last_seq), ring);
+   radeon_fence_write(rdev, rdev->fence_drv[ring].sync_seq[ring], ring);
rdev->fence_drv[ring].initialized = true;
dev_info(rdev->dev, "fence driver on ring %d use gpu addr 0x%016llx and 
cpu addr 0x%p\n",
 ring, rdev->fence_drv[ring].gpu_addr, 
rdev->fence_drv[ring].cpu_addr);
-- 
1.7.11.7

[PATCH] drm/exynos: fix memory leak: free EDID block

2012-12-14 Thread Jani Nikula

On Tue, 20 Nov 2012, Sean Paul  wrote:
> On Tue, Nov 20, 2012 at 4:30 AM, Egbert Eich  wrote:
>> drm_get_edid() returns a pointer to an EDID block. The caller
>> is responsible to free this pointer itself.
>> Here the pointer gets assigned to the local variable raw_edid.
>> Therefore it should be freed before the variable goes out of
>> scope.
>>
>> Signed-off-by: Egbert Eich 
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 2c115f8..bc87bca 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -1293,6 +1293,7 @@ static int hdmi_get_edid(void *ctx, struct 
>> drm_connector *connector,
>> DRM_DEBUG_KMS("%s : width[%d] x height[%d]\n",
>> (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
>> raw_edid->width_cm, raw_edid->height_cm);
>> +   kfree(raw_edid);
>
> This will actually cause the memory to be freed twice.
>
> The reason this happens is drm_get_edid attaches this to
> connector->display_info.raw_edid, which is then freed in the
> exynos_drm_connector function that gets the edid.
>
> The whole thing is ugly, and needs to be revised. I've uploaded a
> patch to refactor this against the chromium tree, but haven't yet
> rebased against upstream. See
> https://gerrit.chromium.org/gerrit/#/c/38406/

The patch is good. connector->display_info.raw_edid is gone since

commit 451023dc32d4542c21b52ad1692e6e01cb75b099
Author: Jani Nikula 
Date:   Wed Aug 15 09:32:39 2012 +

drm: remove the raw_edid field from struct drm_display_info

BR,
Jani.


>
> For now, please drop this patch.
>
> Sean
>
>> } else {
>> return -ENODEV;
>> }
>> --
>> 1.7.7
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon: fix regression with eviction since evict caching changes

Op 14-12-12 12:04, Dave Airlie schreef:
> From: Dave Airlie 
>
> Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
> drm/radeon: use cached memory when evicting for vram on non agp
>
> evicting from TTM would try and evict to TTM instead of system,
> not so good.
>
> This should fix:
> https://bugs.freedesktop.org/show_bug.cgi?id=58272
>
> Signed-off-by: Dave Airlie 
Signed-off-by: Maarten Lankhorst

[PATCH] dma-buf: Add debugfs support

Missed one ...

On Fri, Dec 14, 2012 at 10:36 AM,   wrote:
> +   list_for_each_entry(attach_obj, _obj->attachments, node) {
> +   seq_printf(s, "\t\t");
> +
> +   seq_printf(s, "%s\n", attach_obj->dev->init_name);
> +   attach_count++;
> +   }

You need to hold dmabuf->lock while walking the attachment list.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] dma-buf: Add debugfs support

On Fri, Dec 14, 2012 at 10:36 AM,   wrote:
> From: Sumit Semwal 
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Signed-off-by: Sumit Semwal 

Looks line, only nitpick is that we have no idea who exported a given
buffer. So what about adding a new dma_buf_export_named which takes a
char * to identify the exporter, and then add a bit of cpp magic like
this:

#define dma_buf_export(args) dma_buf_export_named(args, stringify(__FILE))

At least for drm drivers using the prime helpers this should add the
file of the exporting driver, so would be good enough to identify the
exporter. Or we could add a dma_buf_export_dev which has a struct
device * as additional argument ... Otoh that wouldn't really work for
exporting dma_bufs from ION, so maybe a const char * is better.
-Daniel

> ---
>  drivers/base/dma-buf.c  |  149 
> +++
>  include/linux/dma-buf.h |6 +-
>  2 files changed, 154 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index a3f79c4..49fcf0f 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -27,9 +27,18 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  static inline int is_dma_buf_file(struct file *);
>
> +struct dma_buf_list {
> +   struct list_head head;
> +   struct mutex lock;
> +};
> +
> +static struct dma_buf_list db_list;
> +
>  static int dma_buf_release(struct inode *inode, struct file *file)
>  {
> struct dma_buf *dmabuf;
> @@ -40,6 +49,11 @@ static int dma_buf_release(struct inode *inode, struct 
> file *file)
> dmabuf = file->private_data;
>
> dmabuf->ops->release(dmabuf);
> +
> +   mutex_lock(_list.lock);
> +   list_del(>list_node);
> +   mutex_unlock(_list.lock);
> +
> kfree(dmabuf);
> return 0;
>  }
> @@ -120,6 +134,10 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
> dma_buf_ops *ops,
> mutex_init(>lock);
> INIT_LIST_HEAD(>attachments);
>
> +   mutex_lock(_list.lock);
> +   list_add(>list_node, _list.head);
> +   mutex_unlock(_list.lock);
> +
> return dmabuf;
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_export);
> @@ -505,3 +523,134 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> dmabuf->ops->vunmap(dmabuf, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
> +
> +static int dma_buf_init_debugfs(void);
> +static void dma_buf_uninit_debugfs(void);
> +
> +static void __init dma_buf_init(void)
> +{
> +   mutex_init(_list.lock);
> +   INIT_LIST_HEAD(_list.head);
> +   dma_buf_init_debugfs();
> +}
> +
> +static void __exit dma_buf_deinit(void)
> +{
> +   dma_buf_uninit_debugfs();
> +}
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int dma_buf_describe(struct seq_file *s)
> +{
> +   int ret;
> +   struct dma_buf *buf_obj;
> +   struct dma_buf_attachment *attach_obj;
> +   int count = 0, attach_count;
> +   size_t size = 0;
> +
> +   ret = mutex_lock_interruptible(_list.lock);
> +
> +   if (ret)
> +   return ret;
> +
> +   seq_printf(s, "\nDma-buf Objects:\n");
> +   seq_printf(s, "\tsize\tflags\tmode\tcount\n");
> +
> +   list_for_each_entry(buf_obj, _list.head, list_node) {
> +   seq_printf(s, "\t");
> +
> +   seq_printf(s, "%08zu\t%08x\t%08x\t%08d\n",
> +   buf_obj->size, buf_obj->file->f_flags,
> +   buf_obj->file->f_mode,
> +   buf_obj->file->f_count.counter);
> +
> +   seq_printf(s, "\t\tAttached Devices:\n");
> +   attach_count = 0;
> +
> +   list_for_each_entry(attach_obj, _obj->attachments, node) {
> +   seq_printf(s, "\t\t");
> +
> +   seq_printf(s, "%s\n", attach_obj->dev->init_name);
> +   attach_count++;
> +   }
> +
> +   seq_printf(s, "\n\t\tTotal %d devices attached\n",
> +   attach_count);
> +
> +   count++;
> +   size += buf_obj->size;
> +   }
> +
> +   seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
> +
> +   mutex_unlock(_list.lock);
> +   return 0;
> +}
> +
> +static int dma_buf_show(struct seq_file *s, void *unused)
> +{
> +   void (*func)(struct seq_file *) = s->private;
> +   func(s);
> +   return 0;
> +}
> +
> +static int dma_buf_debug_open(struct inode *inode, struct file *file)
> +{
> +   return single_open(file, dma_buf_show, inode->i_private);
> +}
> +
> +static const struct file_operations dma_buf_debug_fops = {
> +   .open   = dma_buf_debug_open,
> +   .read   = seq_read,
> +   .llseek = seq_lseek,
> +   .release= single_release,
> +};
> +
> +static struct dentry *dma_buf_debugfs_dir;
> +
> +static int

[RFC v2 0/5] Common Display Framework

2012-12-14 Thread Vikas Sajjan

y/panel-r61505.c
 create mode 100644 drivers/video/display/panel-r61517.c
 create mode 100644 include/video/display.h
 create mode 100644 include/video/mipi-dbi-bus.h
 create mode 100644 include/video/panel-dpi.h
 create mode 100644 include/video/panel-r61505.h
 create mode 100644 include/video/panel-r61517.h

Hi All,

I was thinking of porting samsung exynos 5250 display driver as per CDF,

but i had certain doubts and wanted to discuss with you guys,

 1. Samsung Exynos supports MIPI DSI based display panels, wondering
how to accommodate such thing in
CDF.  I mean how do I register my MIPI DSI driver with CDF.
because the s6e8ax0 AMOLED lcd driver registers itself with MIPI DSI
driver, and later the MIPI DSI driver probe calls the probe and init
sequence of the LCD driver.
Wanted know if anybody about any thoughts on this ?
2.One more thing is, when went through the patchset I coudn't get who
will register the mipi_dbi_bus_ops?

Regards
Vikas Sajjan

-- 
Regards,

Laurent Pinchart
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/b72ec3a6/attachment.html>

[PATCH 0/3] drm/exynos: add runtime pm support for hdmi and mixer.

2012-12-14 Thread Rahul Sharma

Hi All,

Kindly review the following patch set for Runtime PM  Changes for
Mixer and Hdmi.

regards,
Rahul Sharma

On Wed, Nov 28, 2012 at 11:30 AM, Rahul Sharma  
wrote:
> This patch set adds support for runtime power management for hdmi and
> mixer devices. Its also adds support for hdmiphy power control.
>
> It has been tested for hot plugin-plugout and dpms scenarios.
>
> Based on exynos-drm-next branch of
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
>
> Rahul Sharma (3):
>   drm/exynos: added runtime pm support for hdmi
>   drm/exynos: add runtime pm support for mixer
>   drm/exynos: add support for hdmiphy power control for exynos5
>
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |   81 +---
>  drivers/gpu/drm/exynos/exynos_mixer.c |   65 +++---
>  drivers/gpu/drm/exynos/regs-hdmi.h|5 ++
>  3 files changed, 136 insertions(+), 15 deletions(-)
>

[PATCH] radeon: fix regression with eviction since evict caching changes

2012-12-14 Thread Alex Deucher

Added to my tree.  Thanks.

On Fri, Dec 14, 2012 at 6:22 AM, Maarten Lankhorst
 wrote:
> Signed-off-by: Maarten Lankhorst

[PATCH 2/2] drm/exynos: reorder framebuffer init sequence

On Fri, Dec 14, 2012 at 5:57 AM, Inki Dae  wrote:
> 2012/12/14 Daniel Vetter 
>>
>> On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae  wrote:
>> > How about rebasing this patch to top of
>> > git://people.freedesktop.org/~airlied/linux.git drm-next?
>> > Exynos's many patches have already been merged to drm-next. Or if you
>> > are
>> > ok, I'd like to rebase your patch to -next and test it. I don't care
>> > either
>> > way. :)
>>
>> I've pushed out a rebased version, but somehow I can't compile-test
>> exynos any more :( Probably missing some other stuff from linux-next.
>> Anyway, I don't mind which patch you pick or whether you just roll
>> your own, the important thing is that drm_framebuffer_init is called
>> _after_ everything is set up and initialized. Everything else doesn't
>> really matter.
>
>
> I've rebase your patch to -next and tested it. But your patch had null
> pointer issue to gem object so I fixed it.
> For this, you can refer to the below link,
>
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git;a=shortlog;h=refs/heads/exynos-drm-next
>
> And I gonna request git pull to -next including that patch today. If there
> is any problem, please let me know.

Oops, sorry for missing the gem obj assignment, your updated version
looks good. Thanks for fixing it up.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

2012-12-14 Thread Stephen Warren

On 12/13/2012 11:09 PM, Terje Bergstr?m wrote:
> On 13.12.2012 19:58, Stephen Warren wrote:
>> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>>> After some more discussion with Stephen on IRC we came to the
>>> conclusion that the easiest might be to have tegra-drm call into
>>> host1x with something like:
>>>
>>> void host1x_set_drm_device(struct host1x *host1x, struct device
>>> *dev);
>>
>> If host1x is registering the dummy device that causes tegradrm to be
>> instantiated, then presumably there's no need for the API above, since
>> host1x will already have the struct device * for tegradrm, since it
>> created it?
> 
> I didn't add the dummy device in my latest patch set. I first set out to
> add it, and moved the drm global data to be drvdata of that device. Then
> I noticed that it doesn't actually help at all.
> 
> The critical accesses to the global data are from probes of DC, HDMI,
> etc.

OK

> They want to get the global data by getting drvdata of their parent.

There's no reason that /has/ to be so; they can get any information from
wherever it is, rather than trying to require it to be somewhere it isn't.

> The dummy device is not their parent - host1x is. There's no
> connection between the dummy and the real client devices.

It's quite possible for the client devices to ask their actual parent
(host1x) for the tegradrm struct device *, by calling a host1x API, and
have host1x implement that API by returning the dummy/virtual device
that it created. That should be just 1-2 lines of code to implement in
host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED
when appropriate.

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #5 from Maarten Lankhorst  ---
Do any of your local patches touch radeon_evict_flags or
radeon_ttm_placement_from_domain? I don't see why it would recurse so deeply
otherwise.

A full public git tree to reproduce the problem and seeing what patches are
applied would also be nice.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/8e7f6e86/attachment.html>

[Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

2012-12-14 Thread Rob Clark

On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
 wrote:
> Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
>> From: Sumit Semwal 
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
> I like the idea, I don't know if it could be done in a free manner, but for 
> bonus points
> could we also have the dma-buf fd be obtainable that way from a debugfs entry?
>
> Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, 
> and test against that.
>
> Also I think the name of the device and process that exported the dma-buf 
> would be useful
> to have as well, even if in case of the device that would mean changing the 
> api slightly to record it.
>
> I was thinking of having a directory structure like this:
>
> /sys/kernel/debug/dma_buf/stats
>
> and then for each dma-buf:
>
> /sys/kernel/debug/dma-buf/exporting_file.c/-fd
> /sys/kernel/debug/dma-buf/exporting_file.c/-attachments
> /sys/kernel/debug/dma-buf/exporting_file.c/-info
>
> Opening the fd file would give you back the original fd, or fail with -EIO if 
> refcount was dropped to 0.
>
> Would something like this be doable? I don't know debugfs that well, but I 
> don't see why it wouldn't be,

yeah.. but sort of back-door's the security benefits of an anonymous fd..

BR,
-R

> ~Maarten
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

2012-12-14 Thread Terje Bergström

On 13.12.2012 19:58, Stephen Warren wrote:
> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>> After some more discussion with Stephen on IRC we came to the
>> conclusion that the easiest might be to have tegra-drm call into
>> host1x with something like:
>>
>> void host1x_set_drm_device(struct host1x *host1x, struct device
>> *dev);
> 
> If host1x is registering the dummy device that causes tegradrm to be
> instantiated, then presumably there's no need for the API above, since
> host1x will already have the struct device * for tegradrm, since it
> created it?

I didn't add the dummy device in my latest patch set. I first set out to
add it, and moved the drm global data to be drvdata of that device. Then
I noticed that it doesn't actually help at all.

The critical accesses to the global data are from probes of DC, HDMI,
etc. They want to get the global data by getting drvdata of their
parent. The dummy device is not their parent - host1x is. There's no
connection between the dummy and the real client devices. So there's no
logical way for DC and HDMI to find the the dummy device, except perhaps
by searching for "tegradrm" device from platform bus. But then again,
that'd break encapsulation so it's as bad as a global variable - only
with a lot more code to do the same thing.

Accesses after probing can happen via drm->dev_private, so post-probe
we're fine.

Another problem arouse (already mentioned it) when I used the dummy
device to call to drm_platform_init(). It called back into tegradrm,
which calls the CMA FB helper to allocate memory. Unfortunately the
memory is allocated for the dummy device, and it's not initialized to do
do that. I ended up with failed frame buffer allocation. That needs
host1x allocator to fix.

host1x itself shouldn't need any DRM specific calls or callbacks. The
device model already allows traversing through list of host1x children.
The list of drm clients and devices is something that tegradrm needs to
be able to initialize DRM at appropriate time. I also took that into use
for storing the channel and class data. So we should try to keep the
list maintenance as local to tegradrm as we can.

In my latest patch set, I kept the list management inside tegradrm, and
put all DRM global data into struct tegradrm, which is accessed via a
global. I guess global in tegradrm is not as bad as global in host1x,
because one DRM driver can handle multiple devices, so there's no reason
to have multiple tegradrm's trampling on each others data. But if you
can come up with a better solution, I'm all ears.

Terje

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #4 from Maarten Lankhorst  ---
It looks nasty though, could you also dump mem_type for each time it calls
ttm_mem_evict_first?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/bafdf75e/attachment.html>

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #3 from Maarten Lankhorst  ---
It seems that ttm_mem_evict_first is called way more often in a nasted fashion
than is healthy there. Could you resolve the ttm_mem_evict_first address where
it ends up calling itself back to a specific line?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/22718628/attachment.html>

new userspace API approaches atomic *

2012-12-14 Thread Dave Airlie

So this is a how to get new features pronouncement,

>From what I can see people would like to have atomic interfaces for
pageflip and modesetting merged,

Now how I think developing and merging these will work (i.e. do it
this way or don't bother)

a) get an API you are happy with working, it doesn't need to be perfect

b) rework the internal drm core/driver APIs for all drivers to allow
this new interface to be used. Remove
the old internal apis and create an interface layer between the old
userspace interface and the new API.

c) throw away (a)

d) reimplement a userspace API on top of the new internal driver API
fixing all the things you have learned,
were crazy, insane, nuts etc.

e) have a lot of tests.

f) get b merged standalone, transition phase is fine, but every driver
needs to be ported before the API
goes in.

g) throw away d

h) write final API and get it merged.

Yes this is probably more work than you or your manager is willing to
buy in, but then maybe the feature isn't that important.

Dave.

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #2 from Andy Furniss  ---
Hmm I see using the word  a t t a c h m e n t does strange things  - 1 and 2
are not mine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/e28d8cc0/attachment.html>

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #1 from Andy Furniss  ---
Created attachment 71477
  --> https://bugs.freedesktop.org/attachment.cgi?id=71477=edit
errors in kern log before dma changes

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/1afc650c/attachment.html>

[Bug 58272] New: Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

  Priority: medium
Bug ID: 58272
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Rv670 AGP drm-next ttm errors
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: lists at andyfurniss.entadsl.com
  Hardware: x86 (IA32)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 71476
  --> https://bugs.freedesktop.org/attachment.cgi?id=71476=edit
errors in kern log with dma

I haven't had time to test latest drm-next but will post this now as may be AFK
tomorrow.

After finding a place on mesa where etqw seems OK with drm-fixes I am getting
errors with drm-next.

On yesterdays head + the wb patch I got attachment 1.

With the tree reset to before the dma changes which required the patch -

drm/ttm: remove no_wait_reserve, v3

I got attachment 2

the last lines repeating for 400k lines and the log also getting filled with
junk.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/820794f3/attachment.html>

[RESEND][PATCH] gpu: remove gma500 stub driver

2012-12-14 Thread Lee, Chun-Yi

In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.

Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-May/023426.html
http://lists.freedesktop.org/archives/dri-devel/2012-May/023467.html

Cc: randy.dun...@oracle.com
Cc: tr...@suse.de
Cc: valdis.kletni...@vt.edu
Cc: dennis.jan...@web.de
Cc: airl...@redhat.com
Cc: e...@anholt.net
Cc: alexdeuc...@gmail.com
Cc: bske...@redhat.com
Cc: ch...@chris-wilson.co.uk
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Acked-by: Matthew Garrett mj...@srcf.ucam.org
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
 drivers/gpu/Makefile   |2 +-
 drivers/gpu/stub/Kconfig   |   18 
 drivers/gpu/stub/Makefile  |1 -
 drivers/gpu/stub/poulsbo.c |   64 
 drivers/video/Kconfig  |2 -
 5 files changed, 1 insertions(+), 86 deletions(-)
 delete mode 100644 drivers/gpu/stub/Kconfig
 delete mode 100644 drivers/gpu/stub/Makefile
 delete mode 100644 drivers/gpu/stub/poulsbo.c

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index cc92778..30879df 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y  += drm/ vga/ stub/
+obj-y  += drm/ vga/
diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
deleted file mode 100644
index 4199179..000
--- a/drivers/gpu/stub/Kconfig
+++ /dev/null
@@ -1,18 +0,0 @@
-config STUB_POULSBO
-   tristate Intel GMA500 Stub Driver
-   depends on PCI
-   depends on NET # for THERMAL
-   # Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
-   # but for select to work, need to select ACPI_VIDEO's dependencies, ick
-   select BACKLIGHT_CLASS_DEVICE if ACPI
-   select VIDEO_OUTPUT_CONTROL if ACPI
-   select INPUT if ACPI
-   select ACPI_VIDEO if ACPI
-   select THERMAL if ACPI
-   help
- Choose this option if you have a system that has Intel GMA500
- (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
- intel opregion.
diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
deleted file mode 100644
index cd940cc..000
--- a/drivers/gpu/stub/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
deleted file mode 100644
index 7edfd27..000
--- a/drivers/gpu/stub/poulsbo.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Intel Poulsbo Stub driver
- *
- * Copyright (C) 2010 Novell j...@novell.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- */
-
-#include linux/module.h
-#include linux/pci.h
-#include linux/acpi.h
-#include acpi/video.h
-
-#define DRIVER_NAME poulsbo
-
-enum {
-   CHIP_PSB_8108 = 0,
-   CHIP_PSB_8109 = 1,
-};
-
-static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
-   {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
-   {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
-   {0, 0, 0}
-};
-
-static int poulsbo_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-{
-   return acpi_video_register();
-}
-
-static void poulsbo_remove(struct pci_dev *pdev)
-{
-   acpi_video_unregister();
-}
-
-static struct pci_driver poulsbo_driver = {
-   .name = DRIVER_NAME,
-   .id_table = pciidlist,
-   .probe = poulsbo_probe,
-   .remove = poulsbo_remove,
-};
-
-static int __init poulsbo_init(void)
-{
-   return pci_register_driver(poulsbo_driver);
-}
-
-static void __exit poulsbo_exit(void)
-{
-   pci_unregister_driver(poulsbo_driver);
-}
-
-module_init(poulsbo_init);
-module_exit(poulsbo_exit);
-
-MODULE_AUTHOR(Lee, Chun-Yi j...@novell.com);
-MODULE_DESCRIPTION(Poulsbo Stub Driver);
-MODULE_LICENSE(GPL);
-
-MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..cc99f41 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,8 +21,6 @@ source drivers/gpu/vga/Kconfig
 
 source drivers/gpu/drm/Kconfig
 
-source drivers/gpu/stub/Kconfig
-
 config VGASTATE
tristate
default n
-- 
1.6.0.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #4 from Maarten Lankhorst m.b.lankho...@gmail.com ---
It looks nasty though, could you also dump mem_type for each time it calls
ttm_mem_evict_first?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/exynos: reorder framebuffer init sequence

On Fri, Dec 14, 2012 at 5:57 AM, Inki Dae inki@samsung.com wrote:
2012/12/14 Daniel Vetter daniel.vet...@ffwll.ch

On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae inki@samsung.com wrote:
How about rebasing this patch to top of
git://people.freedesktop.org/~airlied/linux.git drm-next?
Exynos's many patches have already been merged to drm-next. Or if you
are
ok, I'd like to rebase your patch to -next and test it. I don't care
either
way. :)

I've pushed out a rebased version, but somehow I can't compile-test
exynos any more :( Probably missing some other stuff from linux-next.
Anyway, I don't mind which patch you pick or whether you just roll
your own, the important thing is that drm_framebuffer_init is called
_after_ everything is set up and initialized. Everything else doesn't
really matter.

I've rebase your patch to -next and tested it. But your patch had null
pointer issue to gem object so I fixed it.
For this, you can refer to the below link,

http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git;a=shortlog;h=refs/heads/exynos-drm-next

And I gonna request git pull to -next including that patch today. If there
is any problem, please let me know.

Oops, sorry for missing the gem obj assignment, your updated version
looks good. Thanks for fixing it up.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #5 from Maarten Lankhorst m.b.lankho...@gmail.com ---
Do any of your local patches touch radeon_evict_flags or
radeon_ttm_placement_from_domain? I don't see why it would recurse so deeply
otherwise.

A full public git tree to reproduce the problem and seeing what patches are
applied would also be nice.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v5 2/5] drm/exynos: add iommu support for ipp

This patch adds iommu support for ipp.
For this, it adds subdrv_probe/remove callback to enable or disable ipp iommu.
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr().

Signed-off-by: Eunchul Kim chulspro@samsung.com
Signed-off-by: Jinyoung Jeon jy0.j...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index c640935..49eebe9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -24,6 +24,7 @@
 #include exynos_drm_drv.h
 #include exynos_drm_gem.h
 #include exynos_drm_ipp.h
+#include exynos_drm_iommu.h
 
 /*
  * IPP is stand for Image Post Processing and
@@ -1771,10 +1772,24 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
ippdrv-event_workq = ctx-event_workq;
ippdrv-sched_event = ipp_sched_event;
INIT_LIST_HEAD(ippdrv-cmd_list);
+
+   if (is_drm_iommu_supported(drm_dev)) {
+   ret = drm_iommu_attach_device(drm_dev, ippdrv-dev);
+   if (ret) {
+   DRM_ERROR(failed to activate iommu\n);
+   goto err_iommu;
+   }
+   }
}
 
return 0;
 
+err_iommu:
+   /* get ipp driver entry */
+   list_for_each_entry_reverse(ippdrv, exynos_drm_ippdrv_list, drv_list)
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv-dev);
+
 err_idr:
idr_remove_all(ctx-ipp_idr);
idr_remove_all(ctx-prop_idr);
@@ -1791,6 +1806,9 @@ static void ipp_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)
 
/* get ipp driver entry */
list_for_each_entry(ippdrv, exynos_drm_ippdrv_list, drv_list) {
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv-dev);
+
ippdrv-drm_dev = NULL;
exynos_drm_ippdrv_unregister(ippdrv);
}
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v5 0/5] drm/exynos: add ipp subsystem and each ipp drivers

Hi All.

I am responsible for a display part from Samsung Electronics Telecommunication 
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinions of this patch,
please give some comments about my patch.

Changelog v5:
This RFC v5 changed TODO list for arrangement.
Supports devm_ fuction in resource handling.
Arranged comments and added description.
Changed return value for right detect error.
Added GSC definition.

Changelog v4:
This RFC v4 changed ipp subsystem for arrangement.
Remove EXPORT_SYMBOL_GPL in ipp subsystem.
Added error handling in ipp subsystem.
Change set_transf return from swap to ret and use pointer about swap.
Seperated function in Rotator.

Changelog v3:
This RFC v3 changed ipp subsystem for arrangement.
Fixed scaler problem in GSC.
Added/Removed comment from Inki.Dae.
Fixed Joonyoung.Shim comment.
Added rotator comments.

Changelog v2:
This RFC v2 supports iommu in ipp. and Added/Removed comment from Inki.Dae.
Fixed GSC part bugs and next time I will send our local git commit.
and We finished implementation of SC for post-processing.
SC driver not fully tested yet. so, I didn't add SC feature in this patch.

Changelog v1:

This patch is post-processing(IPP) support for exynos drm driver.

IPP is stands for Image Post Processing and supports image scaler/rotator
and input/output DMA operations using IPP drivers(FIMC, Rotator, GSC, SC, so 
on.)
IPP is integration device driver of same attibute hardware.

Exynos4 SoC support FIMC, Rotator for post-processing.
and Exynos5 SoC support GSC, Rotator, SC for post-processing.
SC driver not tested yet. so, I didn't add SC feature in this patch.
and IPP subsystem works on Exynos SoC version independently.

IPP drivers supports Memory to Memory operations with various converting.
and some drivers supports Writeback and Display output operations using local 
path.
User can make converted image using this driver.
and also supports streaming concept for multimedia data processing.

And supports various operations
1. Scale operation generates various sizes of image.
2. CSC(Color Space Conversion) operation supports format converting.
3. Crop operation supports cutting the image.
4. Rotate operation supports to 90, 180, 270 degree.
5. Flip operation supports to vertical, horizontal, and both.
6. Writeback operation genertates cloned image from display controller(FIMD).
7. Display output operation support various format display to display 
controller(FIMD).
8. Input DMA reads image data from the memory.
9. Output DMA writes image data to memory.
10. Supports image effect functions.

Descriptions)
User should make property informations and set this property to registers.
and IPP subsystem manages property id using command node and make queue list 
using memory node.
IPP subsystem supports register function of IPP drivers.
IPP driver manages input/output DMA with various operations. and some driver 
supports
optional operations(writeback, output).
IPP driver needs various informations, so User set property information to IPP 
driver.
and also IPP driver needs memory base address of image for various operations.
User doesn't know its address, so fills the gem handle of that memory than 
address of image base.
and than IPP driver start operation.

Ioctls)
We adds four ioctls and one event for IPP subsystem.

- ioctls
DRM_EXYNOS_IPP_GET_PROPERTY : get ipp driver capabilitis and id.
DRM_EXYNOS_IPP_SET_PROPERTY : set format, position, rotation, flip about 
source/destination.
DRM_EXYNOS_IPP_QUEUE_BUF : enqueue/dequeue buffer and make event list.
DRM_EXYNOS_IPP_CMD_CTRL : play/stop/pause/resume control.

- event
DRM_EXYNOS_IPP_EVENT : event to give notification completion of buffer DMA with 
buffer list

Basic control flow and Sample pseudo application)
1. Basic control flow is same as below
Open - Get properties - User choose IPP driver and set property information 
- Set Property - Create gem handle -
Queue buffer(Enqueue) of source/destination - Command control(Play) - Event 
occured to User
- User handle converted image - (Queue buffer(Enqueue) of source/destination 
- Event occured to User)*N -
Queue buffer(Dequeue) of source/destination - Command control(Stop) - Free 
gem handle - Close

2. Sample pseudo application
#include exynos_drm.h
static int exynos_drm_ipp_set_property(int fd ...)
{
struct drm_exynos_pos crop_pos = {0, 0, hsize, vsize};
struct drm_exynos_pos scale_pos = {0, 0, hsize, vsize};
struct drm_exynos_sz src_sz = {hsize, vsize};
struct drm_exynos_sz dst_sz = {hsize, vsize};
int ret = 0;

memset(property, 0x00, sizeof(struct drm_exynos_ipp_property));
property-cmd = cmd;

property-config[EXYNOS_DRM_OPS_SRC].ops_id = EXYNOS_DRM_OPS_SRC;
property-config[EXYNOS_DRM_OPS_SRC].flip = EXYNOS_DRM_FLIP_NONE;
property-config[EXYNOS_DRM_OPS_SRC].degree = EXYNOS_DRM_DEGREE_0;
property-config[EXYNOS_DRM_OPS_SRC].fmt =

[RFC v5 4/5] drm/exynos: add rotator ipp driver

Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal 
flip.
and has some limitations(source and destination format have to be same, no 
scaler)

Signed-off-by: Eunchul Kim chulspro@samsung.com
Signed-off-by: Youngjun Cho yj44@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig  |7 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  856 +++
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |   33 +
 drivers/gpu/drm/exynos/regs-rotator.h   |   73 +++
 7 files changed, 986 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h
 create mode 100644 drivers/gpu/drm/exynos/regs-rotator.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4915ab6..4860835 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -57,3 +57,10 @@ config DRM_EXYNOS_FIMC
depends on DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos FIMC for DRM.
+
+config DRM_EXYNOS_ROTATOR
+   bool Exynos DRM Rotator
+   depends on DRM_EXYNOS_IPP
+   help
+ Choose this option if you want to use Exynos Rotator for DRM.
+
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 9710024..3b70668 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -18,5 +18,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 73f02ac..09d884b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -378,6 +378,12 @@ static int __init exynos_drm_init(void)
goto out_fimc;
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   ret = platform_driver_register(rotator_driver);
+   if (ret  0)
+   goto out_rotator;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(ipp_driver);
if (ret  0)
@@ -406,6 +412,11 @@ out_drm:
 out_ipp:
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(rotator_driver);
+out_rotator:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(fimc_driver);
 out_fimc:
@@ -451,6 +462,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(ipp_driver);
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(rotator_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(fimc_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 14f9490..a74e37c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -353,5 +353,6 @@ extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
+extern struct platform_driver rotator_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
new file mode 100644
index 000..0025314
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -0,0 +1,856 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * YoungJun Cho yj44@samsung.com
+ * Eunchul Kim chulspro@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundationr
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/pm_runtime.h
+
+#include drm/drmP.h
+#include drm/exynos_drm.h
+#include regs-rotator.h
+#include exynos_drm.h
+#include exynos_drm_ipp.h
+
+/*
+ * Rotator supports image crop/rotator and input/output DMA operations.
+ * input DMA reads image data from the memory.
+ * output DMA writes image data to memory.
+ *
+ * M2M operation : supports crop/scale/rotation/csc so on.
+ * Memory  Rotator H/W  Memory.
+ */
+
+/*
+ * TODO
+ * 1. check suspend/resume api if needed.
+ * 2.

[PATCH] dma-buf: Add debugfs support

2012-12-14 Thread sumit.semwal

From: Sumit Semwal sumit.sem...@linaro.org

Add debugfs support to make it easier to print debug information
about the dma-buf buffers.

Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
 drivers/base/dma-buf.c  |  149 +++
 include/linux/dma-buf.h |6 +-
 2 files changed, 154 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..49fcf0f 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@
 #include linux/dma-buf.h
 #include linux/anon_inodes.h
 #include linux/export.h
+#include linux/debugfs.h
+#include linux/seq_file.h
 
 static inline int is_dma_buf_file(struct file *);
 
+struct dma_buf_list {
+   struct list_head head;
+   struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -40,6 +49,11 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
dmabuf = file-private_data;
 
dmabuf-ops-release(dmabuf);
+
+   mutex_lock(db_list.lock);
+   list_del(dmabuf-list_node);
+   mutex_unlock(db_list.lock);
+
kfree(dmabuf);
return 0;
 }
@@ -120,6 +134,10 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
mutex_init(dmabuf-lock);
INIT_LIST_HEAD(dmabuf-attachments);
 
+   mutex_lock(db_list.lock);
+   list_add(dmabuf-list_node, db_list.head);
+   mutex_unlock(db_list.lock);
+
return dmabuf;
 }
 EXPORT_SYMBOL_GPL(dma_buf_export);
@@ -505,3 +523,134 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
dmabuf-ops-vunmap(dmabuf, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+static int dma_buf_init_debugfs(void);
+static void dma_buf_uninit_debugfs(void);
+
+static void __init dma_buf_init(void)
+{
+   mutex_init(db_list.lock);
+   INIT_LIST_HEAD(db_list.head);
+   dma_buf_init_debugfs();
+}
+
+static void __exit dma_buf_deinit(void)
+{
+   dma_buf_uninit_debugfs();
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+   int ret;
+   struct dma_buf *buf_obj;
+   struct dma_buf_attachment *attach_obj;
+   int count = 0, attach_count;
+   size_t size = 0;
+
+   ret = mutex_lock_interruptible(db_list.lock);
+
+   if (ret)
+   return ret;
+
+   seq_printf(s, \nDma-buf Objects:\n);
+   seq_printf(s, \tsize\tflags\tmode\tcount\n);
+
+   list_for_each_entry(buf_obj, db_list.head, list_node) {
+   seq_printf(s, \t);
+
+   seq_printf(s, %08zu\t%08x\t%08x\t%08d\n,
+   buf_obj-size, buf_obj-file-f_flags,
+   buf_obj-file-f_mode,
+   buf_obj-file-f_count.counter);
+
+   seq_printf(s, \t\tAttached Devices:\n);
+   attach_count = 0;
+
+   list_for_each_entry(attach_obj, buf_obj-attachments, node) {
+   seq_printf(s, \t\t);
+
+   seq_printf(s, %s\n, attach_obj-dev-init_name);
+   attach_count++;
+   }
+
+   seq_printf(s, \n\t\tTotal %d devices attached\n,
+   attach_count);
+
+   count++;
+   size += buf_obj-size;
+   }
+
+   seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
+
+   mutex_unlock(db_list.lock);
+   return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+   void (*func)(struct seq_file *) = s-private;
+   func(s);
+   return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, dma_buf_show, inode-i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+   .open   = dma_buf_debug_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+   int err = 0;
+   dma_buf_debugfs_dir = debugfs_create_dir(dma_buf, NULL);
+   if (IS_ERR(dma_buf_debugfs_dir)) {
+   err = PTR_ERR(dma_buf_debugfs_dir);
+   dma_buf_debugfs_dir = NULL;
+   return err;
+   }
+
+   err = dma_buf_debugfs_create_file(bufinfo, dma_buf_describe);
+
+   if (err)
+   pr_debug(dma_buf: debugfs: failed to create node bufinfo\n);
+
+   return err;
+}
+
+static void dma_buf_uninit_debugfs(void)
+{
+   if (dma_buf_debugfs_dir)
+   debugfs_remove_recursive(dma_buf_debugfs_dir);
+}
+
+int dma_buf_debugfs_create_file(const char *name,
+   int (*write)(struct seq_file *))
+{
+   struct dentry *d;
+
+   d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir,
+

Re: [PATCH] drm/exynos: fix memory leak: free EDID block

2012-12-14 Thread Jani Nikula

On Tue, 20 Nov 2012, Sean Paul seanp...@chromium.org wrote:
 On Tue, Nov 20, 2012 at 4:30 AM, Egbert Eich e...@suse.de wrote:
 drm_get_edid() returns a pointer to an EDID block. The caller
 is responsible to free this pointer itself.
 Here the pointer gets assigned to the local variable raw_edid.
 Therefore it should be freed before the variable goes out of
 scope.

 Signed-off-by: Egbert Eich e...@suse.de
 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 2c115f8..bc87bca 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -1293,6 +1293,7 @@ static int hdmi_get_edid(void *ctx, struct 
 drm_connector *connector,
 DRM_DEBUG_KMS(%s : width[%d] x height[%d]\n,
 (hdata-dvi_mode ? dvi monitor : hdmi monitor),
 raw_edid-width_cm, raw_edid-height_cm);
 +   kfree(raw_edid);

 This will actually cause the memory to be freed twice.

 The reason this happens is drm_get_edid attaches this to
 connector-display_info.raw_edid, which is then freed in the
 exynos_drm_connector function that gets the edid.

 The whole thing is ugly, and needs to be revised. I've uploaded a
 patch to refactor this against the chromium tree, but haven't yet
 rebased against upstream. See
 https://gerrit.chromium.org/gerrit/#/c/38406/

The patch is good. connector-display_info.raw_edid is gone since

commit 451023dc32d4542c21b52ad1692e6e01cb75b099
Author: Jani Nikula jani.nik...@intel.com
Date:   Wed Aug 15 09:32:39 2012 +

drm: remove the raw_edid field from struct drm_display_info

BR,
Jani.



 For now, please drop this patch.

 Sean

 } else {
 return -ENODEV;
 }
 --
 1.7.7

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: Add debugfs support

On Fri, Dec 14, 2012 at 10:36 AM,  sumit.sem...@ti.com wrote:
 From: Sumit Semwal sumit.sem...@linaro.org

 Add debugfs support to make it easier to print debug information
 about the dma-buf buffers.

 Signed-off-by: Sumit Semwal sumit.sem...@ti.com

Looks line, only nitpick is that we have no idea who exported a given
buffer. So what about adding a new dma_buf_export_named which takes a
char * to identify the exporter, and then add a bit of cpp magic like
this:

#define dma_buf_export(args) dma_buf_export_named(args, stringify(__FILE))

At least for drm drivers using the prime helpers this should add the
file of the exporting driver, so would be good enough to identify the
exporter. Or we could add a dma_buf_export_dev which has a struct
device * as additional argument ... Otoh that wouldn't really work for
exporting dma_bufs from ION, so maybe a const char * is better.
-Daniel

 ---
  drivers/base/dma-buf.c  |  149 
 +++
  include/linux/dma-buf.h |6 +-
  2 files changed, 154 insertions(+), 1 deletion(-)

 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index a3f79c4..49fcf0f 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -27,9 +27,18 @@
  #include linux/dma-buf.h
  #include linux/anon_inodes.h
  #include linux/export.h
 +#include linux/debugfs.h
 +#include linux/seq_file.h

  static inline int is_dma_buf_file(struct file *);

 +struct dma_buf_list {
 +   struct list_head head;
 +   struct mutex lock;
 +};
 +
 +static struct dma_buf_list db_list;
 +
  static int dma_buf_release(struct inode *inode, struct file *file)
  {
 struct dma_buf *dmabuf;
 @@ -40,6 +49,11 @@ static int dma_buf_release(struct inode *inode, struct 
 file *file)
 dmabuf = file-private_data;

 dmabuf-ops-release(dmabuf);
 +
 +   mutex_lock(db_list.lock);
 +   list_del(dmabuf-list_node);
 +   mutex_unlock(db_list.lock);
 +
 kfree(dmabuf);
 return 0;
  }
 @@ -120,6 +134,10 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
 dma_buf_ops *ops,
 mutex_init(dmabuf-lock);
 INIT_LIST_HEAD(dmabuf-attachments);

 +   mutex_lock(db_list.lock);
 +   list_add(dmabuf-list_node, db_list.head);
 +   mutex_unlock(db_list.lock);
 +
 return dmabuf;
  }
  EXPORT_SYMBOL_GPL(dma_buf_export);
 @@ -505,3 +523,134 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 dmabuf-ops-vunmap(dmabuf, vaddr);
  }
  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
 +
 +static int dma_buf_init_debugfs(void);
 +static void dma_buf_uninit_debugfs(void);
 +
 +static void __init dma_buf_init(void)
 +{
 +   mutex_init(db_list.lock);
 +   INIT_LIST_HEAD(db_list.head);
 +   dma_buf_init_debugfs();
 +}
 +
 +static void __exit dma_buf_deinit(void)
 +{
 +   dma_buf_uninit_debugfs();
 +}
 +
 +#ifdef CONFIG_DEBUG_FS
 +static int dma_buf_describe(struct seq_file *s)
 +{
 +   int ret;
 +   struct dma_buf *buf_obj;
 +   struct dma_buf_attachment *attach_obj;
 +   int count = 0, attach_count;
 +   size_t size = 0;
 +
 +   ret = mutex_lock_interruptible(db_list.lock);
 +
 +   if (ret)
 +   return ret;
 +
 +   seq_printf(s, \nDma-buf Objects:\n);
 +   seq_printf(s, \tsize\tflags\tmode\tcount\n);
 +
 +   list_for_each_entry(buf_obj, db_list.head, list_node) {
 +   seq_printf(s, \t);
 +
 +   seq_printf(s, %08zu\t%08x\t%08x\t%08d\n,
 +   buf_obj-size, buf_obj-file-f_flags,
 +   buf_obj-file-f_mode,
 +   buf_obj-file-f_count.counter);
 +
 +   seq_printf(s, \t\tAttached Devices:\n);
 +   attach_count = 0;
 +
 +   list_for_each_entry(attach_obj, buf_obj-attachments, node) {
 +   seq_printf(s, \t\t);
 +
 +   seq_printf(s, %s\n, attach_obj-dev-init_name);
 +   attach_count++;
 +   }
 +
 +   seq_printf(s, \n\t\tTotal %d devices attached\n,
 +   attach_count);
 +
 +   count++;
 +   size += buf_obj-size;
 +   }
 +
 +   seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
 +
 +   mutex_unlock(db_list.lock);
 +   return 0;
 +}
 +
 +static int dma_buf_show(struct seq_file *s, void *unused)
 +{
 +   void (*func)(struct seq_file *) = s-private;
 +   func(s);
 +   return 0;
 +}
 +
 +static int dma_buf_debug_open(struct inode *inode, struct file *file)
 +{
 +   return single_open(file, dma_buf_show, inode-i_private);
 +}
 +
 +static const struct file_operations dma_buf_debug_fops = {
 +   .open   = dma_buf_debug_open,
 +   .read   = seq_read,
 +   .llseek = seq_lseek,
 +   .release= single_release,
 +};
 +
 +static struct dentry *dma_buf_debugfs_dir;
 +
 +static int

Re: [PATCH] dma-buf: Add debugfs support

Missed one ...

On Fri, Dec 14, 2012 at 10:36 AM,  sumit.sem...@ti.com wrote:
 +   list_for_each_entry(attach_obj, buf_obj-attachments, node) {
 +   seq_printf(s, \t\t);
 +
 +   seq_printf(s, %s\n, attach_obj-dev-init_name);
 +   attach_count++;
 +   }

You need to hold dmabuf-lock while walking the attachment list.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/fb: avoid sleeping in unblank_screen() if oops in progress

2012-12-14 Thread Konstantin Khlebnikov

unblank_screen() can be called from interrupt context during oops.
thus all -fb_blank handlers should avoid sleeping in this situation.

callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc-vc_sw-con_blank()
fbcon_blank()
fb_blank()
info-fbops-fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
mutex_lock(dev-mode_config.mutex)

Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_fb_helper.c |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 954d175..2c9f49f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -326,7 +326,7 @@ static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = 
{
 static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
 #endif
 
-static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
+static int drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
 {
struct drm_fb_helper *fb_helper = info-par;
struct drm_device *dev = fb_helper-dev;
@@ -334,10 +334,15 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
struct drm_connector *connector;
int i, j;
 
+   if (oops_in_progress) {
+   if (!mutex_trylock(dev-mode_config.mutex))
+   return -EBUSY;
+   } else
+   mutex_lock(dev-mode_config.mutex);
+
/*
 * For each CRTC in this fb, turn the connectors on/off.
 */
-   mutex_lock(dev-mode_config.mutex);
for (i = 0; i  fb_helper-crtc_count; i++) {
crtc = fb_helper-crtc_info[i].mode_set.crtc;
 
@@ -353,6 +358,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
}
}
mutex_unlock(dev-mode_config.mutex);
+   return 0;
 }
 
 int drm_fb_helper_blank(int blank, struct fb_info *info)
@@ -360,24 +366,19 @@ int drm_fb_helper_blank(int blank, struct fb_info *info)
switch (blank) {
/* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
/* Display: Off; HSync: On, VSync: On */
case FB_BLANK_NORMAL:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
/* Display: Off; HSync: Off, VSync: On */
case FB_BLANK_HSYNC_SUSPEND:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
/* Display: Off; HSync: On, VSync: Off */
case FB_BLANK_VSYNC_SUSPEND:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
/* Display: Off; HSync: Off, VSync: Off */
case FB_BLANK_POWERDOWN:
-   drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
-   break;
+   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
}
return 0;
 }

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon: fix regression with eviction since evict caching changes

2012-12-14 Thread Dave Airlie

From: Dave Airlie airl...@redhat.com

Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
drm/radeon: use cached memory when evicting for vram on non agp

evicting from TTM would try and evict to TTM instead of system,
not so good.

This should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=58272

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 93d3445..883c95d 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -96,9 +96,9 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, 
u32 domain)
}
if (domain  RADEON_GEM_DOMAIN_CPU) {
if (rbo-rdev-flags  RADEON_IS_AGP) {
-   rbo-placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_TT;
+   rbo-placements[c++] = TTM_PL_FLAG_WC | 
TTM_PL_FLAG_SYSTEM;
} else {
-   rbo-placements[c++] = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_TT;
+   rbo-placements[c++] = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_SYSTEM;
}
}
if (!c)
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] radeon: fix regression with eviction since evict caching changes

Op 14-12-12 12:04, Dave Airlie schreef:
 From: Dave Airlie airl...@redhat.com

 Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
 drm/radeon: use cached memory when evicting for vram on non agp

 evicting from TTM would try and evict to TTM instead of system,
 not so good.

 This should fix:
 https://bugs.freedesktop.org/show_bug.cgi?id=58272

 Signed-off-by: Dave Airlie airl...@redhat.com
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
 From: Sumit Semwal sumit.sem...@linaro.org

 Add debugfs support to make it easier to print debug information
 about the dma-buf buffers.

I like the idea, I don't know if it could be done in a free manner, but for 
bonus points
could we also have the dma-buf fd be obtainable that way from a debugfs entry?

Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, 
and test against that.

Also I think the name of the device and process that exported the dma-buf would 
be useful
to have as well, even if in case of the device that would mean changing the api 
slightly to record it.

I was thinking of having a directory structure like this:

/sys/kernel/debug/dma_buf/stats

and then for each dma-buf:

/sys/kernel/debug/dma-buf/exporting_file.c/number-fd
/sys/kernel/debug/dma-buf/exporting_file.c/number-attachments
/sys/kernel/debug/dma-buf/exporting_file.c/number-info

Opening the fd file would give you back the original fd, or fail with -EIO if 
refcount was dropped to 0.

Would something like this be doable? I don't know debugfs that well, but I 
don't see why it wouldn't be,

~Maarten

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: new userspace API approaches atomic *

On Fri, Dec 14, 2012 at 07:13:33AM +1000, Dave Airlie wrote:
 So this is a how to get new features pronouncement,
 
 From what I can see people would like to have atomic interfaces for
 pageflip and modesetting merged,
 
 Now how I think developing and merging these will work (i.e. do it
 this way or don't bother)
 
 a) get an API you are happy with working, it doesn't need to be perfect
 
 b) rework the internal drm core/driver APIs for all drivers to allow
 this new interface to be used. Remove
 the old internal apis and create an interface layer between the old
 userspace interface and the new API.

There are several problems with this:

- I can't test other drivers

- I don't have the knowledge or inclination to implement atomic semantics
  for everyone's favorite hardware, and without that there's little
  point in doing the work. Some of my initial code was layered on top of
  drm_crtc_helper though, so it might be possible to use that as a basis
  for an atomic helper, but there would actually be no benefit from
  using it apart from allowing those drivers to respond to the atomic
  ioctl. But we wouldn't use any of that w/ i915, so it would be better is
  someone else does that part.

- Replacing all the legacy codepaths with new code in one go increases the
  chance that we get a regression, and then we have no choice but to
  back out the whole thing. Also it seems that no-one apart from Rob has
  even looked at the code, so it seems likely that there would be heavy
  opposition to replacing the current code with something new.

- These are the reasons I would like to merge the thing without touching
  the legcay codepaths too much. Then each driver author could move their
  code over the new APIs. I'm willing to help of course, but the driver
  authors are in a much better position to make something that actually
  works for their hardware.

 c) throw away (a)
 
 d) reimplement a userspace API on top of the new internal driver API
 fixing all the things you have learned,
 were crazy, insane, nuts etc.
 
 e) have a lot of tests.

Sure more tests would be nice. I'll try to cook up something to stresses
the modeset side soon.

 f) get b merged standalone, transition phase is fine, but every driver
 needs to be ported before the API
 goes in.

Why? The current drivers are not using the same APIs internally anyway.
i915 doesn't use drm_crtc_helper for example. You didn't demand that
Daniel rewrite drm_crtc_helper to suit i915 and fix up all the other
drivers, did you?

 g) throw away d
 
 h) write final API and get it merged.
 
 Yes this is probably more work than you or your manager is willing to
 buy in, but then maybe the feature isn't that important.

Right, so either I rewrite the modeset and pageflip code for all drivers,
or I wait until all the driver authors decide to help me. The first one
will take approximately five years given that I don't know the hardware
and I have other tasks on my plate, and based on the past interest the
second one doesn't seem likely to happen anytime soon 

All this make me think I should just try to push it as an i915 private
feature. Damn the other drivers. That should make the management happy too
since everyone that needs atomic display updates on Linux will need to buy
Intel hardware.

Oh well, the world is supposedly ending in a few days anyway, so perhaps
I can just relax and stop caring :)

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

2012-12-14 Thread Rob Clark

On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
 Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
 From: Sumit Semwal sumit.sem...@linaro.org

 Add debugfs support to make it easier to print debug information
 about the dma-buf buffers.

 I like the idea, I don't know if it could be done in a free manner, but for 
 bonus points
 could we also have the dma-buf fd be obtainable that way from a debugfs entry?

 Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, 
 and test against that.

 Also I think the name of the device and process that exported the dma-buf 
 would be useful
 to have as well, even if in case of the device that would mean changing the 
 api slightly to record it.

 I was thinking of having a directory structure like this:

 /sys/kernel/debug/dma_buf/stats

 and then for each dma-buf:

 /sys/kernel/debug/dma-buf/exporting_file.c/number-fd
 /sys/kernel/debug/dma-buf/exporting_file.c/number-attachments
 /sys/kernel/debug/dma-buf/exporting_file.c/number-info

 Opening the fd file would give you back the original fd, or fail with -EIO if 
 refcount was dropped to 0.

 Would something like this be doable? I don't know debugfs that well, but I 
 don't see why it wouldn't be,

yeah.. but sort of back-door's the security benefits of an anonymous fd..

BR,
-R

 ~Maarten

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Op 14-12-12 15:11, Rob Clark schreef:
 On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
 m.b.lankho...@gmail.com wrote:
 Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
 From: Sumit Semwal sumit.sem...@linaro.org

 Add debugfs support to make it easier to print debug information
 about the dma-buf buffers.

 I like the idea, I don't know if it could be done in a free manner, but for 
 bonus points
 could we also have the dma-buf fd be obtainable that way from a debugfs 
 entry?

 Doing so would allow me to 'steal' a dma-buf from an existing mapping 
 easily, and test against that.

 Also I think the name of the device and process that exported the dma-buf 
 would be useful
 to have as well, even if in case of the device that would mean changing the 
 api slightly to record it.

 I was thinking of having a directory structure like this:

 /sys/kernel/debug/dma_buf/stats

 and then for each dma-buf:

 /sys/kernel/debug/dma-buf/exporting_file.c/number-fd
 /sys/kernel/debug/dma-buf/exporting_file.c/number-attachments
 /sys/kernel/debug/dma-buf/exporting_file.c/number-info

 Opening the fd file would give you back the original fd, or fail with -EIO 
 if refcount was dropped to 0.

 Would something like this be doable? I don't know debugfs that well, but I 
 don't see why it wouldn't be,
 yeah.. but sort of back-door's the security benefits of an anonymous fd..

 BR,
 -R
If you have access to debugfs you're root, so what stops you from stealing it 
through a ptrace?

~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] radeon: fix regression with eviction since evict caching changes

2012-12-14 Thread Alex Deucher

Added to my tree.  Thanks.

On Fri, Dec 14, 2012 at 6:22 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #6 from Alex Deucher ag...@yahoo.com ---
Created attachment 71507
  -- https://bugs.freedesktop.org/attachment.cgi?id=71507action=edit
fix

Should be fixed with this patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

2012-12-14 Thread Thomas Hellström


Nack,

I'm not against moving the TTM lock away,
when a replacement strategy for the main use case is presented.

but using wording like unholy, scares just because there is a lack 
of understanding or because it gets in the way of implementing 
cross-device reservation is a really really bad idea, and FWIW I think 
it's an even better idea to refrain from such wording unless you 
completely understand the problem and have a better solution in place.


No other driver uses it, probably simply because the driver writers 
probably aren't aware of the use cases or don't implement parallel 
command submission.


And if it weren't for the TTM lock, the cross device work wouldn't have 
to consider the case where a client
needs to lock out other reservers, and the cross-device design would 
suffer.


The main use cases are:

1) If we change master, clients of other masters need to be locked out 
from claiming memory resources (particularly VRAM).
2) If we're about to suspend and have cleaned VRAM, client's need to be 
stopped from validating VRAM buffer objects.
3) If a client needs access to the complete video memory space or need 
to defragment, it needs to lock out other reservers in a parallell 
command submission environment


Now, present a better solution to those use cases, and I'll ack this 
patch and implement that solution, or
leave the TTM lock in place as a reminder that these things need to be 
considered, and that we should have a common solution to them.


/Thomas




On 12/10/12 11:26 AM, Daniel Vetter wrote:

... it's the only user. Also move the header fil there.

mlankhorst but seriously, ttm_lock is best left undocumented since
nobody should use that unholy thing..
danvet agreed ;-)
danvet imo we should shovel that under drm/vmwgfx ...
airlied amen
airlied that thing scares me
danvet out of sight, out of mind ...

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/ttm/Makefile|2 +-
  drivers/gpu/drm/ttm/ttm_lock.c  |  310 ---
  drivers/gpu/drm/vmwgfx/Makefile |2 +-
  drivers/gpu/drm/vmwgfx/ttm_lock.c   |  310 +++
  drivers/gpu/drm/vmwgfx/ttm_lock.h   |  247 
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +-
  include/drm/ttm/ttm_lock.h  |  247 
  7 files changed, 560 insertions(+), 560 deletions(-)
  delete mode 100644 drivers/gpu/drm/ttm/ttm_lock.c
  create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c
  create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h
  delete mode 100644 include/drm/ttm/ttm_lock.h

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index b2b33dd..607a0b6 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
  ccflags-y := -Iinclude/drm
  ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
-   ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
+   ttm_object.o ttm_execbuf_util.o ttm_page_alloc.o \
ttm_bo_manager.o
  
  ifeq ($(CONFIG_SWIOTLB),y)

diff --git a/drivers/gpu/drm/ttm/ttm_lock.c b/drivers/gpu/drm/ttm/ttm_lock.c
deleted file mode 100644
index 3daa9a3..000
--- a/drivers/gpu/drm/ttm/ttm_lock.c
+++ /dev/null
@@ -1,310 +0,0 @@
-/**
- *
- * Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * Software), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- **/
-/*
- * Authors: Thomas Hellstrom thellstrom-at-vmware-dot-com
- */
-
-#include drm/ttm/ttm_lock.h
-#include drm/ttm/ttm_module.h
-#include linux/atomic.h
-#include linux/errno.h
-#include linux/wait.h
-#include linux/sched.h
-#include linux/module.h
-

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

2012-12-14 Thread Stephen Warren

On 12/13/2012 11:09 PM, Terje Bergström wrote:
 On 13.12.2012 19:58, Stephen Warren wrote:
 On 12/13/2012 01:57 AM, Thierry Reding wrote:
 After some more discussion with Stephen on IRC we came to the
 conclusion that the easiest might be to have tegra-drm call into
 host1x with something like:

 void host1x_set_drm_device(struct host1x *host1x, struct device
 *dev);

 If host1x is registering the dummy device that causes tegradrm to be
 instantiated, then presumably there's no need for the API above, since
 host1x will already have the struct device * for tegradrm, since it
 created it?
 
 I didn't add the dummy device in my latest patch set. I first set out to
 add it, and moved the drm global data to be drvdata of that device. Then
 I noticed that it doesn't actually help at all.
 
 The critical accesses to the global data are from probes of DC, HDMI,
 etc.

OK

 They want to get the global data by getting drvdata of their parent.

There's no reason that /has/ to be so; they can get any information from
wherever it is, rather than trying to require it to be somewhere it isn't.

 The dummy device is not their parent - host1x is. There's no
 connection between the dummy and the real client devices.

It's quite possible for the client devices to ask their actual parent
(host1x) for the tegradrm struct device *, by calling a host1x API, and
have host1x implement that API by returning the dummy/virtual device
that it created. That should be just 1-2 lines of code to implement in
host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED
when appropriate.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/81] drm/i915: Atomic mode setting / page flip, yet again

On Wed, Dec 12, 2012 at 06:15:27PM +0200, ville.syrj...@linux.intel.com wrote:
...
 Ever since the code started to resemble something sane, I've tried
 to avoid squashing patches, just in case someone was actually trying
 to follow what's changed. But clearly some of the patches can
 be squashed, and that would probably allow some of the earlier ones
 to be dropped entirely.

FYI I now squashed this down to 56 patches, with 6 being pure
debug stuff, ~15 trivial unstatic/export stuff, and the rest
are of varying complexity. So we're down to ~35 patches with
substance.

Next week I can see about pulling some of the intel specific plane
stuff out and send that separately. Those would involve a few framework
type patches the core as well. By my quick calculation that could
bring the final count down by another 15 or so.

There are also some core drm patches that could be merged at any point,
but most of those wouldn't have any use until the atomic stuff starts
taking advantage or them (signed range props, resizeable blobs, etc.).

The current set is here:
https://gitorious.org/vsyrjala/linux/commits/drm_atomic_24

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/6] Common Display Framework-T

Hi,

I have been testing Common Display Framework on OMAP, and making changes that
I've discussed in the posts I've sent in reply to the CDF series from Laurent.
While my CDF code is rather hacky and not at all ready, I wanted to post the
code for comments and also as a reference code to my posts.

So here is CDF-T (Tomi-edition =). 

Changes compared to Laurent's CDF
-

- DBI bus is removed. I don't have any DBI devices, and as I said in my posts,
  I didn't see need for a real bus for DBI (or DSI). I thus also removed the
  DBI panels.

- Split the display_entity into two parts: video_source, which is used to
  connect the display chips and panels, and display_entity, which represent
  either the panel or the whole pipeline (I'm not sure which is better).

- Added ops for DVI and DSI

- Added driver for TFP410, a DPI to DVI converter chip
- Added driver for generic DVI monitor
- Added driver for Taal, a DSI command mode panel

- Removed DISPLAY_ENTITY_STREAM_SINGLE_SHOT, and instead there's update() op.
  It's perhaps possible to use the single-shot method, but I went for a
  separate op to get a update done-callback implemented easily.

Notes about the code


As I said, the code is rather untidy, but I think it's more or less
understandable. I've skipped adding any helper funcs, for example to call the
ops, so it's easier for me to change the API.

I also (ab)used some of the omapdss panel headers to ease my hacking for
omapdss+cdf. These should be quite clear.

The code, including hacks to omapdss to make it use CDF, can be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-cdf

The DSI part is very unfinished. I am able to use it to start up the Taal
panel, and send frames to the panel, but it's really missing lots of stuff.

About display_entity  video_source
---

I've discussed this split in previous posts, but I'll describe it here again.

As I see it, the connections between the display blocks, and the use of the
panel (and thus the whole pipeline) are very different things, and I think they
should be separated. So in my version I have struct video_source, used to
connect the blocks, and display_entity, representing the panel or the whole
pipeline. display_entity is probably not a good name for it anymore, but I
didn't come up with a good one yet.

As an example, let's look at chip-tfp410.c and panel-dvi.c.

tfp410 uses two video_sources, one for input and one for output. The input
comes from some other display block, in my case from OMAP display subsystem.
OMAP DSS has registered a DPI video_source, and the tfp410 driver will get this
source using video_source_find().

tfp410 registers its output as a video source, using video_source_register.
panel-dvi will in turn use video_source_find() to get it.

Both drivers use video_source to configure the input bus, i.e. tfp410
configures the DPI bus between OMAP DSS and TFP410 using, for example,
set_data_lines op to configure the number of datalines on the DPI bus.

With the video_sources in place, the whole video pipeline can be used. However,
we still need to expose an API so that somebody can actually use the pipeline.
This is done with display_entity. display_entity contains higher level ops,
which are not bus specific. The display_entity is registered by the panel at
the end of the chain.

In my model the display_entity ops go to the panel driver, which then calls ops
in the input video source to do the work. Laurent has objected to this model,
and would rather have the display_entity ops go to the DSS side (if I
understood right), which would then propagate forward towards the panel. I have
still kept my model, as I don't see the downsides with my model, nor do I see
any use for propagating the ops from DSS to the panel. But I'm happy to hear
examples how it is beneficial and could be used.


About the bus model
---

Lauren't version uses a linux bus for DBI. The idea here is that DBI is the
control bus fro the panel/chip, and should thus be represented by a real bus.
While I agreed to this approach when we discussed about it, I now am slightly
against it.

My reason is that DBI (or DSI or any other similar bus) is not really control
bus, it is a video bus. It _can_ be used for control, but video is the main
purpose. This has the partical issues:

- There's never use for DBI only for control. DBI is always used for either
  video only, or control+video.

- If DBI is used only for video, there's no DBI bus. How to configure DBI in
  this case?

- If DBI is used for control and video, we have two separate APIs for the bus.
  In theory it's possible to handle this, but in practice it may be impossible,
  especially for more complex busses like DSI.

So in my version I added DSI as a plain video_source, without a real linux bus.
I think this model is a lot simpler, and works better.

 Tomi

Tomi Valkeinen (6):
  video: add

[RFC 1/6] video: add display-core

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/display/display-core.c |  207 ++
 include/video/display.h  |  166 +++
 2 files changed, 373 insertions(+)
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 include/video/display.h

diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
new file mode 100644
index 000..5f8be30
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,207 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/videomode.h
+
+#include video/display.h
+
+/* 
-
+ * Display Entity
+ */
+
+static LIST_HEAD(display_entity_list);
+static DEFINE_MUTEX(display_entity_mutex);
+
+struct display_entity *display_entity_get_first(void)
+{
+   if (list_empty(display_entity_list))
+   return NULL;
+
+   return list_first_entry(display_entity_list, struct display_entity,
+   list);
+}
+EXPORT_SYMBOL(display_entity_get_first);
+
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   int ret;
+
+   if (entity-state == state)
+   return 0;
+
+   if (!entity-ops || !entity-ops-set_state)
+   return 0;
+
+   ret = entity-ops-set_state(entity, state);
+   if (ret  0)
+   return ret;
+
+   entity-state = state;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+int display_entity_get_modes(struct display_entity *entity,
+const struct videomode **modes)
+{
+   if (!entity-ops || !entity-ops-get_modes)
+   return 0;
+
+   return entity-ops-get_modes(entity, modes);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_modes);
+
+int display_entity_get_size(struct display_entity *entity,
+   unsigned int *width, unsigned int *height)
+{
+   if (!entity-ops || !entity-ops-get_size)
+   return -EOPNOTSUPP;
+
+   return entity-ops-get_size(entity, width, height);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_size);
+
+static void display_entity_release(struct kref *ref)
+{
+   struct display_entity *entity =
+   container_of(ref, struct display_entity, ref);
+
+   if (entity-release)
+   entity-release(entity);
+}
+
+struct display_entity *display_entity_get(struct display_entity *entity)
+{
+   if (entity == NULL)
+   return NULL;
+
+   kref_get(entity-ref);
+   return entity;
+}
+EXPORT_SYMBOL_GPL(display_entity_get);
+
+void display_entity_put(struct display_entity *entity)
+{
+   kref_put(entity-ref, display_entity_release);
+}
+EXPORT_SYMBOL_GPL(display_entity_put);
+
+int __must_check __display_entity_register(struct display_entity *entity,
+  struct module *owner)
+{
+   kref_init(entity-ref);
+   entity-owner = owner;
+   entity-state = DISPLAY_ENTITY_STATE_OFF;
+
+   mutex_lock(display_entity_mutex);
+   list_add(entity-list, display_entity_list);
+
+   mutex_unlock(display_entity_mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__display_entity_register);
+
+void display_entity_unregister(struct display_entity *entity)
+{
+   mutex_lock(display_entity_mutex);
+
+   list_del(entity-list);
+   mutex_unlock(display_entity_mutex);
+
+   display_entity_put(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_unregister);
+
+/* 
-
+ * Video Source
+ */
+
+static LIST_HEAD(video_source_list);
+static DEFINE_MUTEX(video_source_mutex);
+
+int __must_check __video_source_register(struct video_source *src,
+  struct module *owner)
+{
+   kref_init(src-ref);
+   src-owner = owner;
+
+   mutex_lock(video_source_mutex);
+   list_add(src-list, video_source_list);
+
+   mutex_unlock(video_source_mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__video_source_register);
+
+void video_source_unregister(struct video_source *src)
+{
+   mutex_lock(video_source_mutex);
+
+   list_del(src-list);
+   mutex_unlock(video_source_mutex);
+
+   video_source_put(src);
+}
+EXPORT_SYMBOL_GPL(video_source_unregister);
+
+
+static void video_source_release(struct kref *ref)
+{
+   struct video_source *src =
+

[RFC 2/6] video: add generic dpi panel

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/display/panel-dpi.c |  155 +
 include/video/panel-dpi.h |   25 ++
 2 files changed, 180 insertions(+)
 create mode 100644 drivers/video/display/panel-dpi.c
 create mode 100644 include/video/panel-dpi.h

diff --git a/drivers/video/display/panel-dpi.c 
b/drivers/video/display/panel-dpi.c
new file mode 100644
index 000..824cd88
--- /dev/null
+++ b/drivers/video/display/panel-dpi.c
@@ -0,0 +1,155 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include video/display.h
+#include video/panel-dpi.h
+
+struct panel_dpi {
+   struct display_entity entity;
+   struct video_source *src;
+   const struct panel_dpi_platform_data *pdata;
+};
+
+#define to_panel_dpi(p)container_of(p, struct panel_dpi, 
entity)
+
+static int panel_dpi_set_state(struct display_entity *entity,
+  enum display_entity_state state)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+   struct video_source *src = panel-src;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   src-common_ops-set_stream(src,
+   DISPLAY_ENTITY_STREAM_STOPPED);
+   break;
+
+   case DISPLAY_ENTITY_STATE_ON:
+   src-common_ops-set_stream(src,
+   DISPLAY_ENTITY_STREAM_CONTINUOUS);
+   break;
+   }
+
+   return 0;
+}
+
+static int panel_dpi_get_modes(struct display_entity *entity,
+  const struct videomode **modes)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   *modes = panel-pdata-mode;
+   return 1;
+}
+
+static int panel_dpi_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   *width = panel-pdata-width;
+   *height = panel-pdata-height;
+   return 0;
+}
+
+static const struct display_entity_control_ops panel_dpi_control_ops = {
+   .set_state = panel_dpi_set_state,
+   .get_modes = panel_dpi_get_modes,
+   .get_size = panel_dpi_get_size,
+};
+
+static void panel_dpi_release(struct display_entity *entity)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   kfree(panel);
+}
+
+static int panel_dpi_remove(struct platform_device *pdev)
+{
+   struct panel_dpi *panel = platform_get_drvdata(pdev);
+
+   display_entity_unregister(panel-entity);
+
+   if (panel-src) {
+   video_source_put(panel-src);
+   panel-src = NULL;
+   }
+
+   platform_set_drvdata(pdev, NULL);
+
+   return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+   const struct panel_dpi_platform_data *pdata = pdev-dev.platform_data;
+   struct panel_dpi *panel;
+   int ret;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+   if (panel == NULL)
+   return -ENOMEM;
+
+   panel-pdata = pdata;
+
+   panel-src = video_source_find(pdata-video_source);
+   if (panel-src == NULL) {
+   printk(failed to get video source\n);
+   return -EINVAL;
+   }
+
+   panel-src-ops.dpi-set_data_lines(panel-src, 24);
+   panel-src-ops.dpi-set_videomode(panel-src, pdata-mode);
+
+   panel-entity.dev = pdev-dev;
+   panel-entity.release = panel_dpi_release;
+   panel-entity.ops = panel_dpi_control_ops;
+
+   ret = display_entity_register(panel-entity);
+   if (ret  0) {
+   kfree(panel);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, panel);
+
+   return 0;
+}
+
+static const struct dev_pm_ops panel_dpi_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dpi_driver = {
+   .probe = panel_dpi_probe,
+   .remove = panel_dpi_remove,
+   .driver = {
+   .name = panel_dpi,
+   .owner = THIS_MODULE,
+   .pm = panel_dpi_dev_pm_ops,
+   },
+};
+
+module_platform_driver(panel_dpi_driver);
+
+MODULE_AUTHOR(Laurent Pinchart laurent.pinch...@ideasonboard.com);
+MODULE_DESCRIPTION(DPI Display Panel);
+MODULE_LICENSE(GPL);
diff --git a/include/video/panel-dpi.h b/include/video/panel-dpi.h
new file mode 100644
index 000..0c5856e
--- /dev/null
+++ b/include/video/panel-dpi.h
@@ -0,0 +1,25 @@
+/*
+ * DPI Display Panel
+ *

[RFC 3/6] video: add tfp410

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/display/chip-tfp410.c |  164 +++
 include/video/omap-panel-tfp410.h   |4 +
 2 files changed, 168 insertions(+)
 create mode 100644 drivers/video/display/chip-tfp410.c

diff --git a/drivers/video/display/chip-tfp410.c 
b/drivers/video/display/chip-tfp410.c
new file mode 100644
index 000..2f8bdb6
--- /dev/null
+++ b/drivers/video/display/chip-tfp410.c
@@ -0,0 +1,164 @@
+/*
+ * TFP410 DPI-to-DVI bridge
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Contacts: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/gpio.h
+#include linux/platform_device.h
+
+#include video/display.h
+#include video/omap-panel-tfp410.h
+
+struct tfp410_data {
+   struct video_source *in;
+
+   struct video_source out;
+
+   int power_down_gpio;
+};
+
+#define to_tfp410(p) container_of(p, struct tfp410_data, out)
+
+static int tfp410_set_stream(struct video_source *src,
+enum video_source_stream_state state)
+{
+   struct tfp410_data *data = to_tfp410(src);
+   struct video_source *in = data-in;
+   int r;
+
+   r = in-common_ops-set_stream(in, state);
+   if (r)
+   return r;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STREAM_STOPPED:
+   printk(tfp410 set_stream: STOPPED\n);
+
+   gpio_set_value_cansleep(data-power_down_gpio, 0);
+
+   break;
+
+   case DISPLAY_ENTITY_STREAM_CONTINUOUS:
+   printk(tfp410 set_stream: CONTINUOUS\n);
+
+   gpio_set_value_cansleep(data-power_down_gpio, 1);
+
+   break;
+
+   default:
+   printk(tfp410 set_stream error\n);
+   break;
+   }
+
+   return 0;
+}
+
+static int tfp410_set_vm(struct video_source *src, const struct videomode *vm)
+{
+   struct tfp410_data *data = to_tfp410(src);
+   struct video_source *in = data-in;
+
+   printk(tfp410 set vm\n);
+
+   return in-ops.dpi-set_videomode(in, vm);
+}
+
+static const struct common_video_source_ops tfp410_common_ops = {
+   .set_stream = tfp410_set_stream,
+};
+
+static const struct dvi_video_source_ops tfp410_dvi_ops = {
+   .set_videomode = tfp410_set_vm,
+};
+
+static void tfp410_release(struct video_source *src)
+{
+   printk(tfp410 entity release\n);
+}
+
+static int __devinit tfp410_probe(struct platform_device *pdev)
+{
+   const struct tfp410_platform_data *pdata = pdev-dev.platform_data;
+   struct tfp410_data *data;
+   int r;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+   if (data == NULL)
+   return -ENOMEM;
+
+   data-power_down_gpio = pdata-power_down_gpio;
+
+   r = devm_gpio_request_one(pdev-dev, pdata-power_down_gpio,
+   GPIOF_OUT_INIT_LOW, tfp410 pd);
+   if (r) {
+   printk(failed to request pd gpio\n);
+   return r;
+   }
+
+   /* setup input */
+
+   data-in = video_source_find(pdata-video_source);
+   if (data-in == NULL) {
+   printk(failed to get video source\n);
+   return -EINVAL;
+   }
+
+   data-in-ops.dpi-set_data_lines(data-in, 24);
+
+   /* setup output */
+
+   data-out.dev = pdev-dev;
+   data-out.release = tfp410_release;
+   data-out.common_ops = tfp410_common_ops;
+   data-out.ops.dvi = tfp410_dvi_ops;
+   data-out.name = pdata-video_output;
+
+   r = video_source_register(data-out);
+   if (r  0) {
+   printk(tfp410 entity register failed\n);
+   video_source_put(data-in);
+   return r;
+   }
+
+   platform_set_drvdata(pdev, data);
+
+   return 0;
+}
+
+static int tfp410_remove(struct platform_device *pdev)
+{
+   struct tfp410_data *data = platform_get_drvdata(pdev);
+
+   video_source_unregister(data-out);
+
+   video_source_put(data-in);
+
+   return 0;
+}
+
+static struct platform_driver tfp410_driver = {
+   .probe = tfp410_probe,
+   .remove = tfp410_remove,
+   .driver = {
+   .name = tfp410,
+   .owner = THIS_MODULE,
+   },
+};
+
+module_platform_driver(tfp410_driver);
+
+MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
+MODULE_DESCRIPTION(TFP410 DPI-to-DVI Bridge);
+MODULE_LICENSE(GPL);
diff --git a/include/video/omap-panel-tfp410.h 
b/include/video/omap-panel-tfp410.h
index b5b05f4..18f2b46 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -30,6 +30,10 @@ struct omap_dss_device;
  */
 struct tfp410_platform_data {

[RFC 4/6] video: add generic dvi monitor

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/display/panel-dvi.c |  164 +
 include/video/panel-dvi.h |   18 
 2 files changed, 182 insertions(+)
 create mode 100644 drivers/video/display/panel-dvi.c
 create mode 100644 include/video/panel-dvi.h

diff --git a/drivers/video/display/panel-dvi.c 
b/drivers/video/display/panel-dvi.c
new file mode 100644
index 000..01cea09
--- /dev/null
+++ b/drivers/video/display/panel-dvi.c
@@ -0,0 +1,164 @@
+/*
+ * Generic DVI monitor
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Contacts: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include video/display.h
+#include video/panel-dvi.h
+
+struct panel_data {
+   struct display_entity entity;
+   struct video_source *in;
+};
+
+#define to_panel(p) container_of(p, struct panel_data, entity)
+
+static int panel_dvi_set_state(struct display_entity *entity,
+  enum display_entity_state state)
+{
+   struct panel_data *data = to_panel(entity);
+   struct video_source *in = data-in;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   in-common_ops-set_stream(in, DISPLAY_ENTITY_STREAM_STOPPED);
+   break;
+
+   case DISPLAY_ENTITY_STATE_ON:
+   in-common_ops-set_stream(in, 
DISPLAY_ENTITY_STREAM_CONTINUOUS);
+   break;
+   }
+
+   return 0;
+}
+
+static const struct videomode vga_mode = {
+   .pixelclock = 23500,
+
+   .hactive = 640,
+   .hfront_porch = 48,
+   .hback_porch = 80,
+   .hsync_len = 32,
+
+   .vactive = 480,
+   .vfront_porch = 3,
+   .vback_porch = 7,
+   .vsync_len = 4,
+
+   .hah = true,
+   .vah = true,
+   .de = true,
+};
+
+static int panel_dvi_get_modes(struct display_entity *entity,
+  const struct videomode **modes)
+{
+   //struct panel_data *data = to_panel(entity);
+
+   *modes = vga_mode;
+   return 1;
+}
+
+static int panel_dvi_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+   //struct panel_data *data = to_panel(entity);
+
+   *width = 10;
+   *height = 10;
+   return 0;
+}
+
+static const struct display_entity_control_ops panel_dvi_control_ops = {
+   .set_state = panel_dvi_set_state,
+   .get_modes = panel_dvi_get_modes,
+   .get_size = panel_dvi_get_size,
+};
+
+static void panel_dvi_release(struct display_entity *entity)
+{
+   printk(panel dvi release\n);
+}
+
+static int __devinit panel_dvi_probe(struct platform_device *pdev)
+{
+   const struct panel_dvi_platform_data *pdata = pdev-dev.platform_data;
+   struct panel_data *data;
+   int ret;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+   if (data == NULL)
+   return -ENOMEM;
+
+   /* setup input */
+   data-in = video_source_find(pdata-video_source);
+   if (data-in == NULL) {
+   printk(failed to get video source\n);
+   return -EINVAL;
+   }
+
+   /* setup default mode */
+   data-in-ops.dvi-set_videomode(data-in, vga_mode);
+
+   /* setup panel entity */
+
+   data-entity.dev = pdev-dev;
+   data-entity.release = panel_dvi_release;
+   data-entity.ops = panel_dvi_control_ops;
+
+   ret = display_entity_register(data-entity);
+   if (ret  0) {
+   video_source_put(data-in);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, data);
+
+   return 0;
+}
+
+static int panel_dvi_remove(struct platform_device *pdev)
+{
+   struct panel_data *data = platform_get_drvdata(pdev);
+
+   display_entity_unregister(data-entity);
+
+   video_source_put(data-in);
+
+   return 0;
+}
+
+
+static const struct dev_pm_ops panel_dvi_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dvi_driver = {
+   .probe = panel_dvi_probe,
+   .remove = panel_dvi_remove,
+   .driver = {
+   .name = panel_dvi,
+   .owner = THIS_MODULE,
+   .pm = panel_dvi_dev_pm_ops,
+   },
+};
+
+module_platform_driver(panel_dvi_driver);
+
+MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
+MODULE_DESCRIPTION(DVI Monitor);
+MODULE_LICENSE(GPL);
diff --git a/include/video/panel-dvi.h b/include/video/panel-dvi.h
new file mode 100644
index 000..ab88380
--- /dev/null
+++ b/include/video/panel-dvi.h
@@ -0,0 +1,18 @@
+/*
+ * DVI Display Panel
+ *
+ * This program is free software; you can

[RFC 5/6] video: add taal panel

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/display/panel-taal.c   |  383 ++
 include/video/omap-panel-nokia-dsi.h |4 +-
 2 files changed, 385 insertions(+), 2 deletions(-)
 create mode 100644 drivers/video/display/panel-taal.c

diff --git a/drivers/video/display/panel-taal.c 
b/drivers/video/display/panel-taal.c
new file mode 100644
index 000..f1c2196
--- /dev/null
+++ b/drivers/video/display/panel-taal.c
@@ -0,0 +1,383 @@
+/*
+ * Taal DSI command mode panel
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DEBUG
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/jiffies.h
+#include linux/sched.h
+#include linux/gpio.h
+#include linux/mutex.h
+#include linux/platform_device.h
+#include linux/videomode.h
+
+#include video/omapdss.h
+#include video/display.h
+#include video/omap-panel-nokia-dsi.h
+#include video/mipi_display.h
+
+/* DSI Virtual channel. Hardcoded for now. */
+#define TCH 0
+
+#define DCS_READ_NUM_ERRORS0x05
+#define DCS_BRIGHTNESS 0x51
+#define DCS_CTRL_DISPLAY   0x53
+#define DCS_WRITE_CABC 0x55
+#define DCS_READ_CABC  0x56
+#define DCS_GET_ID10xda
+#define DCS_GET_ID20xdb
+#define DCS_GET_ID30xdc
+
+struct taal_data {
+   struct platform_device *pdev;
+   struct video_source *src;
+   struct display_entity entity;
+
+   struct mutex lock;
+
+   unsigned long   hw_guard_end;   /* next value of jiffies when we can
+* issue the next sleep in/out command
+*/
+   unsigned long   hw_guard_wait;  /* max guard time in jiffies */
+
+   /* panel HW configuration from DT or platform data */
+   int reset_gpio;
+
+   /* runtime variables */
+   bool enabled;
+
+   bool te_enabled;
+
+   int channel;
+
+   bool cabc_broken;
+   unsigned cabc_mode;
+
+   bool intro_printed;
+};
+
+static void hw_guard_start(struct taal_data *td, int guard_msec)
+{
+   td-hw_guard_wait = msecs_to_jiffies(guard_msec);
+   td-hw_guard_end = jiffies + td-hw_guard_wait;
+}
+
+static void hw_guard_wait(struct taal_data *td)
+{
+   unsigned long wait = td-hw_guard_end - jiffies;
+
+   if ((long)wait  0  wait = td-hw_guard_wait) {
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(wait);
+   }
+}
+
+static int taal_dcs_read_1(struct taal_data *td, u8 dcs_cmd, u8 *data)
+{
+   int r;
+   u8 buf[1];
+   struct video_source *src = td-src;
+
+   r = src-ops.dsi-dcs_read(src, td-channel, dcs_cmd, buf, 1);
+   if (r  0)
+   return r;
+
+   *data = buf[0];
+
+   return 0;
+}
+
+static int taal_dcs_write_0(struct taal_data *td, u8 dcs_cmd)
+{
+   struct video_source *src = td-src;
+
+   return src-ops.dsi-dcs_write(src, td-channel, dcs_cmd, 1);
+}
+
+static int taal_sleep_out(struct taal_data *td)
+{
+   int r;
+
+   hw_guard_wait(td);
+
+   r = taal_dcs_write_0(td, MIPI_DCS_EXIT_SLEEP_MODE);
+   if (r)
+   return r;
+
+   hw_guard_start(td, 120);
+
+   msleep(5);
+
+   return 0;
+}
+
+static int taal_get_id(struct taal_data *td, u8 *id1, u8 *id2, u8 *id3)
+{
+   int r;
+
+   r = taal_dcs_read_1(td, DCS_GET_ID1, id1);
+   if (r)
+   return r;
+   r = taal_dcs_read_1(td, DCS_GET_ID2, id2);
+   if (r)
+   return r;
+   r = taal_dcs_read_1(td, DCS_GET_ID3, id3);
+   if (r)
+   return r;
+
+   return 0;
+}
+
+static void taal_hw_reset(struct taal_data *td)
+{
+   if (!gpio_is_valid(td-reset_gpio))
+   return;
+
+   gpio_set_value(td-reset_gpio, 1);
+   udelay(10);
+   /* reset the panel */
+   gpio_set_value(td-reset_gpio, 0);
+   /* assert reset */
+   udelay(10);
+   gpio_set_value(td-reset_gpio, 1);
+   /* wait after releasing reset */
+   msleep(5);
+}
+
+#define to_panel(p) container_of(p, struct taal_data, entity)
+
+static int taal_set_state(struct display_entity *entity,
+  enum display_entity_state state)
+{
+   struct taal_data *td = to_panel(entity);
+   struct video_source *src = td-src;
+   int r;

[RFC 6/6] video: add makefile kconfig

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/Kconfig  |1 +
 drivers/video/Makefile |1 +
 drivers/video/display/Kconfig  |   26 ++
 drivers/video/display/Makefile |5 +
 4 files changed, 33 insertions(+)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index c5b7bcf..e91f03e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2442,6 +2442,7 @@ source drivers/video/omap/Kconfig
 source drivers/video/omap2/Kconfig
 source drivers/video/exynos/Kconfig
 source drivers/video/backlight/Kconfig
+source drivers/video/display/Kconfig
 
 if VT
source drivers/video/console/Kconfig
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b936b00..0a4cfea 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= display/
 
 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
 
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..1d1a590
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,26 @@
+menuconfig DISPLAY_CORE
+   tristate Display Core
+   ---help---
+ Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_PANEL_DPI
+   tristate DPI (Parallel) Display Panels
+   ---help---
+ Support for simple digital (parallel) pixel interface panels. Those
+ panels receive pixel data through a parallel bus and have no control
+ bus.
+
+ If you are in doubt, say N.
+
+config DISPLAY_PANEL_DVI
+   tristate DVI Monitor
+
+config DISPLAY_PANEL_TAAL
+   tristate Taal DSI command mode panel
+
+config DISPLAY_CHIP_TFP410
+   tristate DPI to DVI chip
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..ac97dfd
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
+obj-$(CONFIG_DISPLAY_PANEL_DVI) += panel-dvi.o
+obj-$(CONFIG_DISPLAY_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_DISPLAY_CHIP_TFP410) += chip-tfp410.o
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-14 Thread j . glisse

From: Jerome Glisse jgli...@redhat.com

After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command stream
that lockedup resume. Otherwise GPU reset will be ineffective in most
cases.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 22bd6c2..38233e7 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -787,7 +787,7 @@ int radeon_fence_driver_start_ring(struct radeon_device 
*rdev, int ring)
}
rdev-fence_drv[ring].cpu_addr = rdev-wb.wb[index/4];
rdev-fence_drv[ring].gpu_addr = rdev-wb.gpu_addr + index;
-   radeon_fence_write(rdev, 
atomic64_read(rdev-fence_drv[ring].last_seq), ring);
+   radeon_fence_write(rdev, rdev-fence_drv[ring].sync_seq[ring], ring);
rdev-fence_drv[ring].initialized = true;
dev_info(rdev-dev, fence driver on ring %d use gpu addr 0x%016llx and 
cpu addr 0x%p\n,
 ring, rdev-fence_drv[ring].gpu_addr, 
rdev-fence_drv[ring].cpu_addr);
-- 
1.7.11.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull v3] exynos-drm-next

2012-12-14 Thread inki . dae

Hi Dave,

This is final git pull request for -next and includes some new features,
fixups and cleanups.

And a summary to this is as the following:
- add dmabuf attach/detach feature
  . This patch would resolve performance deterioration issue
when v4l2-based driver is using the buffer imported from gem.
- drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute
  . With gem allocation, kernel space mapping isn't allocated and
also physical pages aren't mapped with the kernel space.
The physical pages are mapped with kernel space though vmap
function only for console framebuffer.
- add the below two patches I missed.
  drm: exynos: moved exynos drm device registration to drm driver
  drm: exynos: moved exynos drm hdmi device registration to drm driver
- add IPP subsystem framework and its-based device drivers.
  . This patch set includes fimc, rotator and gsc drivers to perform
image scaling, rotation and color space conversion.
- add runtime pm support to hdmi driver.
- And fixups and cleanups. 

If there is any problem, please let me know.

Thanks,
Inki Dae

The following changes since commit 9add1ac3dd256ad12e266f8403daf928be19953f:

  Merge branch 'drm-next-3.8' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2012-12-13 12:03:22 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to f2646380655b32481b5e76c666e1793dfef184bd:

  drm/exynos: add gsc ipp driver (2012-12-15 02:40:00 +0900)


Daniel Vetter (1):
  drm/exynos: reorder framebuffer init sequence

Eunchul Kim (5):
  drm/exynos: add ipp subsystem
  drm/exynos: add iommu support for ipp
  drm/exynos: add fimc ipp driver
  drm/exynos: add rotator ipp driver
  drm/exynos: add gsc ipp driver

Inki Dae (4):
  drm/exynos: add dmabuf attach/detach callbacks.
  drm/exynos: add exception codes to exynos_drm_fbdev_create()
  drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute
  drm/exynos: fix allocation and cache mapping type

Joonyoung Shim (4):
  drm/exynos: fix fb offset calculation for plane
  drm/exynos: fix x, y coordinates for right bottom pixel
  drm/exynos: support extended screen coordinate of fimd
  drm/exynos: support device tree for fimd

Prathyush K (7):
  drm/exynos: make wait_for_vblank a manager op
  drm/exynos: move hdmi's wait_for_vblank to manager_ops
  drm/exynos: move fimd wait_for_vblank to manager_ops
  drm/exynos: modify wait_for_vblank of mixer
  drm/exynos: modify wait_for_vblank of fimd
  drm/exynos: clear windows in mixer dpms off
  drm/exynos: clear windows in fimd dpms off

Rahul Sharma (5):
  drm: exynos: moved exynos drm device registration to drm driver
  drm: exynos: moved exynos drm hdmi device registration to drm driver
  drm/exynos: added runtime pm support for hdmi
  drm/exynos: add runtime pm support for mixer
  drm/exynos: add support for hdmiphy power control for exynos5

Sachin Kamat (2):
  drm/exynos: hdmi: Add CONFIG_OF and use of_match_ptr() macro
  drm/exynos: hdmi: Fix potential NULL pointer dereference error

Wei Yongjun (1):
  drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

YoungJun Cho (1):
  drm/exynos: remove unused vaddr member

 drivers/gpu/drm/exynos/Kconfig  |   24 +
 drivers/gpu/drm/exynos/Makefile |4 +
 drivers/gpu/drm/exynos/exynos_ddc.c |4 +-
 drivers/gpu/drm/exynos/exynos_drm_buf.c |   49 +-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c  |  104 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   94 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   29 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   25 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |   40 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |   42 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c| 2001 ++
 drivers/gpu/drm/exynos/exynos_drm_fimc.h|   37 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  140 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.h |2 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1870 
 drivers/gpu/drm/exynos/exynos_drm_gsc.h |   38 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|   44 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
 drivers/gpu/drm/exynos/exynos_drm_iommu.c   |4 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2060 +++
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  266 
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  855 +++
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |   33 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|6 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|   87

Re: [PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

Dude, you're seriously overshooting here. This patch isn't required
_at_ _all_ to do cross device sharing/reservations/whatever. We've
simply discussed TTM documentation in the context of Maartens work,
and I've suggested to include all the TTM kerneldoc into a nice
DocBook. That way the kerneldoc stuff gets at least check for correct
parameters and similar trivial stuff (core drm sucked royally in that
regard). So Maarten jabbed around, I and Dave joined in and since
besides vmwgfx nothing else uses it at all I've figured this can't
hurt.

If you think all the radeon/nouveau/i915/whatever drivers are screwed
up beyond repair and need to have the ttm_lock.c file where it is as a
stern reminder, I don't care one bit. Personally I think the right
solution is to abolish the drm master concept entirely and aim for
CONFIG_VT=n. Insulation is a userspace problem which e.g. policykit or
whatever the latest thing is can do, or which should be solved for
real with per-process address spaces. Everything else smells too fishy
for me. So yeah, I don't think the fact that vmwgfx is the only driver
with a -set_master and -drop_master callback is a good sign, but
alas, not my driver and the core impact is negligible.

Cheers, Daniel

On Fri, Dec 14, 2012 at 4:51 PM, Thomas Hellström tho...@shipmail.org wrote:
 Nack,

 I'm not against moving the TTM lock away,
 when a replacement strategy for the main use case is presented.

 but using wording like unholy, scares just because there is a lack of
 understanding or because it gets in the way of implementing cross-device
 reservation is a really really bad idea, and FWIW I think it's an even
 better idea to refrain from such wording unless you completely understand
 the problem and have a better solution in place.

 No other driver uses it, probably simply because the driver writers probably
 aren't aware of the use cases or don't implement parallel command
 submission.

 And if it weren't for the TTM lock, the cross device work wouldn't have to
 consider the case where a client
 needs to lock out other reservers, and the cross-device design would suffer.

 The main use cases are:

 1) If we change master, clients of other masters need to be locked out from
 claiming memory resources (particularly VRAM).
 2) If we're about to suspend and have cleaned VRAM, client's need to be
 stopped from validating VRAM buffer objects.
 3) If a client needs access to the complete video memory space or need to
 defragment, it needs to lock out other reservers in a parallell command
 submission environment

 Now, present a better solution to those use cases, and I'll ack this patch
 and implement that solution, or
 leave the TTM lock in place as a reminder that these things need to be
 considered, and that we should have a common solution to them.

 /Thomas





 On 12/10/12 11:26 AM, Daniel Vetter wrote:

 ... it's the only user. Also move the header fil there.

 mlankhorst but seriously, ttm_lock is best left undocumented since
 nobody should use that unholy thing..
 danvet agreed ;-)
 danvet imo we should shovel that under drm/vmwgfx ...
 airlied amen
 airlied that thing scares me
 danvet out of sight, out of mind ...

 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
   drivers/gpu/drm/ttm/Makefile|2 +-
   drivers/gpu/drm/ttm/ttm_lock.c  |  310
 ---
   drivers/gpu/drm/vmwgfx/Makefile |2 +-
   drivers/gpu/drm/vmwgfx/ttm_lock.c   |  310
 +++
   drivers/gpu/drm/vmwgfx/ttm_lock.h   |  247 
   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +-
   include/drm/ttm/ttm_lock.h  |  247 
   7 files changed, 560 insertions(+), 560 deletions(-)
   delete mode 100644 drivers/gpu/drm/ttm/ttm_lock.c
   create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c
   create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h
   delete mode 100644 include/drm/ttm/ttm_lock.h

 diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
 index b2b33dd..607a0b6 100644
 --- a/drivers/gpu/drm/ttm/Makefile
 +++ b/drivers/gpu/drm/ttm/Makefile
 @@ -4,7 +4,7 @@
   ccflags-y := -Iinclude/drm
   ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
 ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
 -   ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
 +   ttm_object.o ttm_execbuf_util.o ttm_page_alloc.o \
 ttm_bo_manager.o
 ifeq ($(CONFIG_SWIOTLB),y)
 diff --git a/drivers/gpu/drm/ttm/ttm_lock.c
 b/drivers/gpu/drm/ttm/ttm_lock.c
 deleted file mode 100644
 index 3daa9a3..000
 --- a/drivers/gpu/drm/ttm/ttm_lock.c
 +++ /dev/null
 @@ -1,310 +0,0 @@

 -/**
 - *
 - * Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
 - * All Rights Reserved.
 - *
 - * Permission is hereby granted, free of charge, to any person obtaining
 a
 - * copy of this software

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

2012-12-14 Thread Terje Bergström

On 14.12.2012 18:21, Stephen Warren wrote:
 On 12/13/2012 11:09 PM, Terje Bergström wrote:
 They want to get the global data by getting drvdata of their parent.
 
 There's no reason that /has/ to be so; they can get any information from
 wherever it is, rather than trying to require it to be somewhere it isn't.

Exactly, this was also my solution.

 The dummy device is not their parent - host1x is. There's no
 connection between the dummy and the real client devices.
 
 It's quite possible for the client devices to ask their actual parent
 (host1x) for the tegradrm struct device *, by calling a host1x API, and
 have host1x implement that API by returning the dummy/virtual device
 that it created. That should be just 1-2 lines of code to implement in
 host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED
 when appropriate.

My solution was to just have one global, and an getter for the global.
Instead of drvdata, the pointer is retrieved with the getter. No need
for dummy device, or passing points between host1x and tegradrm.

Terje

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-14 Thread Christian König


On 14.12.2012 18:39, j.gli...@gmail.com wrote:

From: Jerome Glisse jgli...@redhat.com

After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command stream
that lockedup resume. Otherwise GPU reset will be ineffective in most
cases.
NAK. I changed this on purpose to get partial resets working, please 
don't change it back.


The IB test code should reset this to the last synced value anyway, if 
it doesn't work then there is something wrong there.


Christian.




Signed-off-by: Jerome Glisse jgli...@redhat.com
---
  drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 22bd6c2..38233e7 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -787,7 +787,7 @@ int radeon_fence_driver_start_ring(struct radeon_device 
*rdev, int ring)
}
rdev-fence_drv[ring].cpu_addr = rdev-wb.wb[index/4];
rdev-fence_drv[ring].gpu_addr = rdev-wb.gpu_addr + index;
-   radeon_fence_write(rdev, 
atomic64_read(rdev-fence_drv[ring].last_seq), ring);
+   radeon_fence_write(rdev, rdev-fence_drv[ring].sync_seq[ring], ring);
rdev-fence_drv[ring].initialized = true;
dev_info(rdev-dev, fence driver on ring %d use gpu addr 0x%016llx and cpu 
addr 0x%p\n,
 ring, rdev-fence_drv[ring].gpu_addr, 
rdev-fence_drv[ring].cpu_addr);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-14 Thread Jerome Glisse

On Fri, Dec 14, 2012 at 3:13 PM, Christian König
deathsim...@vodafone.de wrote:
 On 14.12.2012 18:39, j.gli...@gmail.com wrote:

 From: Jerome Glisse jgli...@redhat.com

 After lockup we need to resume fence to last sync sequence and not
 last received sequence so that all thread waiting on command stream
 that lockedup resume. Otherwise GPU reset will be ineffective in most
 cases.

 NAK. I changed this on purpose to get partial resets working, please don't
 change it back.

 The IB test code should reset this to the last synced value anyway, if it
 doesn't work then there is something wrong there.

 Christian.

There is something wrong 

Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

On Fri, Dec 14, 2012 at 1:04 AM, Rob Clark robdcl...@gmail.com wrote:
 +static int lcdc_crtc_page_flip(struct drm_crtc *crtc,
 +   struct drm_framebuffer *fb,
 +   struct drm_pending_vblank_event *event)
 +{
 +   struct lcdc_crtc *lcdc_crtc = to_lcdc_crtc(crtc);
 +   struct drm_device *dev = crtc-dev;
 +
 +   if (lcdc_crtc-event) {
 +   dev_err(dev-dev, already pending page flip!\n);
 +   return -EBUSY;
 +   }
 +
 +   // TODO we should hold a ref to the fb somewhere..

Note that with the current fb refcounting nothing prevents you from
fixing this. The ugly problems I've had to solve for the locking
rework are all due to the drm core (i.e. setcrtc/pageflip/...) ioctl
functions assuming that an fb can't suddenly disappear while holding
the mode_config lock. Since I wanted to remove that requirement I've
had to changed the refcounting in the drm core functions.

But drivers can already extend the lifetime of an fb simply by
grabbing a reference (as long as they grab that reference while
holding the struct mutex all the time between fb lookup and grabbing
the reference). And it will continue to work the same with the new
locking scheme.
-Daniel

 +   crtc-fb = fb;
 +   lcdc_crtc-event = event;
 +   update_scanout(crtc);
 +
 +   return 0;
 +}
 +



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: restore modeset late in GPU reset path

2012-12-14 Thread j . glisse

From: Jerome Glisse jgli...@redhat.com

Modeset path seems to conflict sometimes with the memory management
leading to kernel deadlock. This move modesetting reset after GPU
acceleration reset.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e2f5f88..ffd5534 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1337,7 +1337,6 @@ retry:
}
 
radeon_restore_bios_scratch_regs(rdev);
-   drm_helper_resume_force_mode(rdev-ddev);
 
if (!r) {
for (i = 0; i  RADEON_NUM_RINGS; ++i) {
@@ -1362,6 +1361,8 @@ retry:
}
}
 
+   drm_helper_resume_force_mode(rdev-ddev);
+
ttm_bo_unlock_delayed_workqueue(rdev-mman.bdev, resched);
if (r) {
/* bad news, how to tell it to userspace ? */
-- 
1.7.11.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272

--- Comment #7 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #6)
 Created attachment 71507 [details] [review]
 fix
 
 Should be fixed with this patch.

Probably :-)

It seems that current drm-next head + fix has a different issue which makes
etqw die quite quickly.

drm-next reset onto 

drm/ttm: remove no_wait_reserve, v3 + the fix 

is now stable with etqw.

The head issue is -

EE r600_texture.c:697 r600_texture_transfer_map - failed to create temporary
texture to hold untiled copy
Mesa: User error: GL_OUT_OF_MEMORY in glTexSubImage
radeon: The kernel rejected CS, see dmesg for more information.
double fault: 'Segmentation fault', bailing out

in dmesg - 

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (8192, 2,
4096, -12)
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
etqw.x86[2478]: segfault at 0 ip af5142ad sp bff8b310 error 4 in
gamex86.so[af23f000+948000]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58272] Rv670 AGP drm-next ttm errors