[PATCHv4 3/8] gpu: host1x: Add channel support

2012-12-21 Thread Steven Rostedt
On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote:

> diff --git a/include/trace/events/host1x.h b/include/trace/events/host1x.h
> index d98d74c..e087910 100644
> --- a/include/trace/events/host1x.h
> +++ b/include/trace/events/host1x.h
> @@ -37,6 +37,214 @@ DECLARE_EVENT_CLASS(host1x,
>   TP_printk("name=%s", __entry->name)
>  );
>  
> +DEFINE_EVENT(host1x, host1x_channel_open,
> + TP_PROTO(const char *name),
> + TP_ARGS(name)
> +);
> +
> +DEFINE_EVENT(host1x, host1x_channel_release,
> + TP_PROTO(const char *name),
> + TP_ARGS(name)
> +);
> +
> +TRACE_EVENT(host1x_cdma_begin,
> + TP_PROTO(const char *name),
> +
> + TP_ARGS(name),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + ),
> +
> + TP_printk("name=%s",
> + __entry->name)
> +);
> +
> +TRACE_EVENT(host1x_cdma_end,
> + TP_PROTO(const char *name),
> +
> + TP_ARGS(name),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + ),
> +
> + TP_printk("name=%s",
> + __entry->name)
> +);

The above two should be combined into a DECLARE_EVENT_CLASS() and
DEFINE_EVENT()s. Saves text and data space that way.

> +
> +TRACE_EVENT(host1x_cdma_flush,
> + TP_PROTO(const char *name, int timeout),
> +
> + TP_ARGS(name, timeout),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(int, timeout)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + __entry->timeout = timeout;
> + ),
> +
> + TP_printk("name=%s, timeout=%d",
> + __entry->name, __entry->timeout)
> +);
> +
> +TRACE_EVENT(host1x_cdma_push,
> + TP_PROTO(const char *name, u32 op1, u32 op2),
> +
> + TP_ARGS(name, op1, op2),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, op1)
> + __field(u32, op2)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + __entry->op1 = op1;
> + __entry->op2 = op2;
> + ),
> +
> + TP_printk("name=%s, op1=%08x, op2=%08x",
> + __entry->name, __entry->op1, __entry->op2)
> +);
> +
> +TRACE_EVENT(host1x_cdma_push_gather,
> + TP_PROTO(const char *name, u32 mem_id,
> + u32 words, u32 offset, void *cmdbuf),
> +
> + TP_ARGS(name, mem_id, words, offset, cmdbuf),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, mem_id)
> + __field(u32, words)
> + __field(u32, offset)
> + __field(bool, cmdbuf)
> + __dynamic_array(u32, cmdbuf, words)
> + ),
> +
> + TP_fast_assign(
> + if (cmdbuf) {
> + memcpy(__get_dynamic_array(cmdbuf), cmdbuf+offset,
> + words * sizeof(u32));
> + }
> + __entry->cmdbuf = cmdbuf;
> + __entry->name = name;
> + __entry->mem_id = mem_id;
> + __entry->words = words;
> + __entry->offset = offset;
> + ),
> +
> + TP_printk("name=%s, mem_id=%08x, words=%u, offset=%d, contents=[%s]",
> +   __entry->name, __entry->mem_id,
> +   __entry->words, __entry->offset,
> +   __print_hex(__get_dynamic_array(cmdbuf),
> +   __entry->cmdbuf ? __entry->words * 4 : 0))
> +);
> +
> +TRACE_EVENT(host1x_channel_submit,
> + TP_PROTO(const char *name, u32 cmdbufs, u32 relocs, u32 waitchks,
> + u32 syncpt_id, u32 syncpt_incrs),
> +
> + TP_ARGS(name, cmdbufs, relocs, waitchks, syncpt_id, syncpt_incrs),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, cmdbufs)
> + __field(u32, relocs)
> + __field(u32, waitchks)
> + __field(u32, syncpt_id)
> + __field(u32, syncpt_incrs)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + __entry->cmdbufs = cmdbufs;
> + __entry->relocs = relocs;
> + __entry->waitchks = waitchks;
> + __entry->syncpt_id = syncpt_id;
> + __entry->syncpt_incrs = syncpt_incrs;
> + ),
> +
> + TP_printk("name=%s, cmdbufs=%u, relocs=%u, waitchks=%d,"
> + "syncpt_id=%u, syncpt_incrs=%u",
> +   __entry->name, __entry->cmdbufs, __entry->relocs, __entry->waitchks,
> +   __entry->syncpt_id, __entry->syncpt_incrs)
> +);
> +
> +TRACE_EVENT(host1x_channel_submitted,
> + TP_PROTO(const char *name, u32 syncpt_base, u32 syncpt_max),
> +
> + TP_ARGS(name, syncpt_base, syncpt_max),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, syncpt_base)
> + __field(u32, 

Hangcheck timer elapsed..

2012-12-21 Thread Daniel Vetter
On Fri, Dec 21, 2012 at 4:56 AM, Linus Torvalds
 wrote:
> This thing isn't repeatable, and it can go days without happening, but
> it has happened several times now over the last several weeks, to the
> point where it is very annoying.
>
> I get:
>
>   [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
>   [drm] capturing error event; look for more information in
> /debug/dri/0/i915_error_state
>   [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
>   [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
>   [drm:i915_reset] *ERROR* Failed to reset chip.
>
> and then I need to reboot, because restarting X just causes it to be
> slow and unaccelerated.
>
> I'm attaching the i915_error_state thing, although I suspect it's
> useless, since I got it after an X restart. But maybe it shows why
> even the X restart doesn't do anything.
>
> This is a Westmere setup: it's a
>
>   Intel(R) Core(TM) i5 CPU 670  @ 3.47GHz
>
> and dmesg doesn't have anything interesting in it at all. Running
> up-to-date Fedora 17.

Yeah, looks like the ilk death which somehow became much easier to hit
in 3.7. Bug to track the various reporters is at

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

> Any ideas about anything in particular I can do to trigger it and help
> debug it? There's usually nothing special going on when this happens.
> This last one was during a kernel build, but the screen was actually
> locked (and I don't even have a fancy screensaver, it's just a blank
> black screen for me).

As far as we know it requires light gpu load (desktop, 3d compositor
seems to help to hit it) with some form of memory/io load. Kernel
compiles, massive svn checkouts or just filling the pagecache with
crap and cleaning it up again seems to be good at triggering it.
Progress in debugging has been extremely slow, especially after we've
disabled rc6 on ilk (attempted an enable in the 3.7 by default of
that) - without rc6 none of the local machines we devs have here can
reproduce the bug any more, and the rc6 hangs have a slightly
different hang signature, so decent chance it's a different bug.

We're suspecting it's an old one, just made somehow much easier to hit
with the changes in 3.7. Chris has some good evidence already that the
hw has stricter alignment requirements than what we implement, but
patches are only just now gathering testing feedback. And after a few
weeks of searching for the loose piece of ducttape so that we can
reattach it I've finally found a slight change in our shrinker
behaviour which might mitigate things. Patch is in testing since a few
days and hasn't blown up yet - which is a record thus far. So I'm
still hopeful that I can forge this quick hack into a real patch to
reapply the lost ducttape.

> Other times, it's just normal desktop. Quite often it is during a
> kernel compile, with loads in the 30+ range, so maybe it's triggered
> by high loads resulting in some program not being hugely responsive
> (maybe losing the drm state?) but quite frankly, I do a *lot* of
> kernel compiles especially during the merge window, so the "it
> happened during a kernel compile" is not necessarily indicative of any
> deeper causation - it's just that compiling kernels is what I do ;)
>
> I've gotten hangcheck timers over the years, but it really seems to
> have been getting worse. Please help. If the reset worked and it would
> clear up after I just logged out and back in again, that would already
> be a big thing.

gpu reset state transitions should be much less racy in 3.8 than 3.7,
but that doesn't help if the gpu hangs to quickly. You can try to
resurrect it in that case with

# echo 0 > /sys/kernel/debug/dri/0/i915_wedged

We can't really disable that "hanging too fast" check, since it helps
tremendously in preventing gpu hangs from spiralling into certain
death of the entire system, and so is important for debugging.

Other workarounds to mitigate things are:
- Don't use a 3d compositor, the ddx should transparently fall over to
sw rendering when the gpu is permanently declared dead.
- Using SNA accelaration instead of UXA in the ddx seems to migitate
the hangs a lot (Option "AccelMethod" "SNA" in an xorg.conf snippet) -
we suspect it's due to the different layout of the indirect state
objects. UXA has an entire tree of those, SNA packs them into one
single gem object, which seems to tremendously reduce changes that the
gpu/kernel barfs on them and so hangs the gpu.

Oh, and in case you get the urge to flame your drm/i915 maintainer to
crips over this disaster (it's one imo), I'll be offline the next 2
weeks, snowboarding in the swiss alps ;-)

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


i-g-t test for gem flink race

2012-12-21 Thread Daniel Vetter
On Fri, Dec 21, 2012 at 3:46 AM, Dave Airlie  wrote:
> On Fri, Dec 21, 2012 at 11:49 AM, Dave Airlie  wrote:
>> As we talked on irc, I decided to write a test case and it actually
>> seems to trigger the race.
>>
>> Really its insane userspace behaviour and I'm not really sure we
>> should care to fix, I can't see it causing an oops, more userspace
>> does something insane, it gets a bad result, but I'll contemplate it a
>> bit more.
>
> Yeah after considering this a bit more, I really think its just a
> userspace problem, don''t go closing gem object handles that other
> threads could be using. Lets state any result after doing something
> like that is undefined, and the current behaviour is within spec.

Yeah, I've looked at the code again and I think we can't oops or leak
stuff with the current code. But userspace could end up with a gem
handle and a removed flink name, but I agree now that we don't need to
care about this for flink. Important is just that a non-zero flink
can't be observed without a corresponding reference, for otherwise
we'd need to resurrect zombies. I've looked a the code again and I
think we're safe.

Looking at dma-buf I think the same applies, if userspace races
imports against gem_close it's kinda not our problem. I've thought for
a while that for cross-process situations we need better guarantees
since the dma-buf can exists on its own and doesn't need an open
userspace gem handle to survive like an flink name. But then I think
we just have to be careful with locking at import time to so that we
don't end up with two gem objects for the same dma-buf somehow. Much
simpler than worrying about close vs. import races.

For the racing igt test itself I think that one could still be useful
- just make it never fail and we can use it to hunt for leaks and
other issues in that code.

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


[PATCHv16 0/7] of: add display helper

2012-12-21 Thread Leela Krishna Amudala
Hello All,
Any comments for this patch set..?

Best Wishes,
Leela Krishna Amudala.

On Tue, Dec 18, 2012 at 10:34 PM, Steffen Trumtrar
 wrote:
>
> Hi!
>
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
>
> Changes since v15:
> - move include/linux/{videomode,display_timing}.h to include/video
> - move include/linux/of_{videomode,display_timing}.h to
> include/video
> - reimplement flags: add VESA flags and data flags
> - let pixelclock in struct videomode be unsigned long
> - rename of_display_timings_exists to of_display_timings_exist
> - revise logging/error messages: replace __func__ with
> np->full_name
> - rename pixelclk-inverted to pixelclk-active
> - revise comments in code
>
> Changes since v14:
> - fix "const struct *" warning
> (reported by: Leela Krishna Amudala
> )
> - return -EINVAL when htotal or vtotal are zero
> - remove unreachable code in of_get_display_timings
> - include headers in .c files and not implicit in .h
> - sort includes alphabetically
> - fix lower/uppercase in binding documentation
> - rebase onto v3.7-rc7
>
> Changes since v13:
> - fix "const struct *" warning
> (reported by: Laurent Pinchart
> )
> - prevent division by zero in fb_videomode_from_videomode
>
> Changes since v12:
> - rename struct display_timing to via_display_timing in via
> subsystem
> - fix refreshrate calculation
> - fix "const struct *" warnings
> (reported by: Manjunathappa, Prakash )
> - some CodingStyle fixes
> - rewrite parts of commit messages and display-timings.txt
> - let display_timing_get_value get all values instead of just
> typical
>
> Changes since v11:
> - make pointers const where applicable
> - add reviewed-by Laurent Pinchart
>
> Changes since v10:
> - fix function name (drm_)display_mode_from_videomode
> - add acked-by, reviewed-by, tested-by
>
> Changes since v9:
> - don't leak memory when previous timings were correct
> - CodingStyle fixes
> - move blank lines around
>
> Changes since v8:
> - fix memory leaks
> - change API to be more consistent (foo_from_bar(struct bar,
> struct foo))
> - include headers were necessary
> - misc minor bugfixes
>
> Changes since v7:
> - move of_xxx to drivers/video
> - remove non-binding documentation from display-timings.txt
> - squash display_timings and videomode in one patch
> - misc minor fixes
>
> Changes since v6:
> - get rid of some empty lines etc.
> - move functions to their subsystems
> - split of_ from non-of_ functions
> - add at least some kerneldoc to some functions
>
> Changes since v5:
> - removed all display stuff and just describe timings
>
> Changes since v4:
> - refactored functions
>
> Changes since v3:
> - print error messages
> - free alloced memory
> - general cleanup
>
> Changes since v2:
> - use hardware-near property-names
> - provide a videomode structure
> - allow ranges for all properties ()
> - functions to get display_mode or fb_videomode
>
> Regards,
> Steffen
>
>
>
> Steffen Trumtrar (7):
>   viafb: rename display_timing to via_display_timing
>   video: add display_timing and videomode
>   video: add of helper for display timings/videomode
>   fbmon: add videomode helpers
>   fbmon: add of_videomode helpers
>   drm_modes: add videomode helpers
>   drm_modes: add of_videomode helpers
>
>  .../devicetree/bindings/video/display-timing.txt   |  109 +
>  drivers/gpu/drm/drm_modes.c|   70 ++
>  drivers/video/Kconfig  |   21 ++
>  drivers/video/Makefile |4 +
>  drivers/video/display_timing.c |   24 ++
>  drivers/video/fbmon.c  |   94 
>  drivers/video/of_display_timing.c  |  239
> 
>  drivers/video/of_videomode.c   |   54 +
>  drivers/video/via/hw.c |6 +-
>  drivers/video/via/hw.h |2 +-
>  drivers/video/via/lcd.c|2 +-
>  drivers/video/via/share.h  |2 +-
>  drivers/video/via/via_modesetting.c|8 +-
>  drivers/video/via/via_modesetting.h|6 +-
>  drivers/video/videomode.c  |   39 
>  include/drm/drmP.h |9 +
>  include/linux/fb.h |8 +
>  include/video/display_timing.h |  124 ++
>  include/video/of_display_timing.h

Bisected regression on RV610

2012-12-21 Thread Alex Deucher
On Fri, Dec 21, 2012 at 10:33 AM, Pavel Roskin  wrote:
> Hello!
>
> The system running the current mainline Linux shows black screen for me
> reliably if I run the unshield program on xterm.  Linux 3.7 is OK.
>
> The bisection found the first bad commit:
>
> deab48f140d28d788cb2b5705761a92b02e3440d
> Alex Deucher 
>
> drm/radeon: add dma engine support for vm pt updates on si (v2)
>
> Async DMA has a special packet for contiguous pt updates
> which saves overhead.
>
> v2: rebase

That patch only affects SI chips which yours is not, so it's probably
not what's causing problems for you.

>
> It can be reverted on top on the mainline Linux, but I still get the black
> screen.  I guess it's the first commit that is bad for my video card, but
> not the only one.
>
> While bisecting, I noticed another manifestation of the problem - unshield
> would hang for a few seconds and continue.  Following appears in the kernel
> log:
>
> [   31.476089] radeon :01:00.0: GPU lockup CP stall for more than
> 1msec
> [   31.476094] radeon :01:00.0: GPU lockup (waiting for
> 0x0006 last fence id 0x0005)
>
> # lspci -vnn -s 01:00.0
> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV610 video
> device [Radeon HD 2400 PRO] [1002:94c3] (prog-if 00 [VGA controller])
> Subsystem: ASUSTeK Computer Inc. Device [1043:01c2]
> Flags: bus master, fast devsel, latency 0, IRQ 46
> Memory at e000 (64-bit, prefetchable) [size=256M]
> Memory at f500 (64-bit, non-prefetchable) [size=64K]
> I/O ports at b000 [size=256]
> [virtual] Expansion ROM at f400 [disabled] [size=128K]
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Express Legacy Endpoint, MSI 00
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1
> Len=010 
> Kernel driver in use: radeon
>

This looks like a duplicate of this issue:
http://lists.freedesktop.org/archives/dri-devel/2012-December/032139.html
http://lists.freedesktop.org/archives/dri-devel/2012-December/032291.html

Some of the ttm changes in 3.8 seem problematic.

Alex


[RFC] drm/exynos: added hdcp driver for contents protection.

2012-12-21 Thread Eunchul Kim
HDCP stands for High-bandwidth Digital Content Protection.
This is a newer form of Digital Rights Management(secure DRM)
that was designed to control digital video and audio content.
Contains an integrated HDCP encryption engine for video/audio content 
protection.
supports version HDCP v1.1.
Exynos AP supports embedded HDCP key system.
The HDCP key value is fused during fabrication, based on customer's request.

Exynos HDCP scenario.
- start encryption.
- receive Bcaps, Bksv from peer device.
- check repeater caps from Bcaps.
- send An, Aksv to peer device.
- receive Rj from peer device.
- compare Ri,Rj. If same and not repeater, then start encryption.
- If not same, retry. If repeater, then start second authentication.
- stop encryption.

Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_hdcp.c| 1164 +++
 drivers/gpu/drm/exynos/exynos_hdcp.h|   47 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c|   11 +
 drivers/gpu/drm/exynos/exynos_hdmi.h|7 +
 drivers/gpu/drm/exynos/regs-hdmi.h  |  177 +
 9 files changed, 1426 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..93c2f00 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -34,6 +34,12 @@ config DRM_EXYNOS_HDMI
help
  Choose this option if you want to use Exynos HDMI for DRM.

+config DRM_EXYNOS_HDCP
+   bool "Exynos DRM HDCP"
+   depends on DRM_EXYNOS_HDMI
+   help
+ Choose this option if you want to use Exynos HDCP in HDMI for DRM.
+
 config DRM_EXYNOS_VIDI
bool "Exynos DRM Virtual Display"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 639b49e..58d8fb7 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -14,6 +14,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_HDCP) += exynos_hdcp.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
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e0a8e80..0d2ada1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -345,6 +345,11 @@ static int __init exynos_drm_init(void)
 #endif

 #ifdef CONFIG_DRM_EXYNOS_HDMI
+#ifdef CONFIG_DRM_EXYNOS_HDCP
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_hdcp;
+#endif
ret = platform_driver_register(_driver);
if (ret < 0)
goto out_hdmi;
@@ -452,6 +457,10 @@ out_common_hdmi:
 out_mixer:
platform_driver_unregister(_driver);
 out_hdmi:
+#ifdef CONFIG_DRM_EXYNOS_HDCP
+   platform_driver_unregister(_driver);
+out_hdcp:
+#endif
 #endif

 #ifdef CONFIG_DRM_EXYNOS_FIMD
@@ -494,6 +503,9 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_drm_common_hdmi_driver);
platform_driver_unregister(_driver);
platform_driver_unregister(_driver);
+#ifdef CONFIG_DRM_EXYNOS_HDCP
+   platform_driver_unregister(_driver);
+#endif
 #endif

 #ifdef CONFIG_DRM_EXYNOS_VIDI
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index f5a9774..c591ffc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -344,6 +344,7 @@ extern int exynos_platform_device_hdmi_register(void);
 void exynos_platform_device_hdmi_unregister(void);

 extern struct platform_driver fimd_driver;
+extern struct platform_driver hdcp_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
 extern struct platform_driver exynos_drm_common_hdmi_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.c 
b/drivers/gpu/drm/exynos/exynos_hdcp.c
new file mode 100644
index 000..58a345c
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_hdcp.c
@@ -0,0 +1,1164 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * Eunchul Kim 
+ *
+ * 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 

[RFC] added hdcp driver in hdmi

2012-12-21 Thread Eunchul Kim
Hi All.

This patch supports HDCP feature in Exynos DRM HDMI.
We enhaced feature of HDCP for content protection.
please check my commit and If you have any opinion of this patch.
please give comment to me.

HDCP stands for High-bandwidth Digital Content Protection.
contains an integrated HDCP encryption engine
for video/audio content protection.
supports version HDCP v1.1.
Exynos supports embedded HDCP key system.
The HDCP key value is fused during fabrication, based on customer's request.

First part authentication protocol.
The HDCP transmitter(Device A) can initiate authentication at any time.
Authentication is initiated by the HDCP transmitter by sending an An, Aksv.
An(64-bit psedo-random value), Aksv(Transmitter Key Selection Vector).
The HDCP Receiver(Device B) generates Rj.
The HDCP Receiver responds by sending a response message Bksv.
Bksv(Receiver Key Selection Vector).
If authentication was successfull, then Ri will be equal to Rj.

Second part authentication protocol.
The second part of the authentication protocol is required
if the HDCP receiver is an HDCP repeater.
The HDCP transmitter executes the second part of the protocol only
when the REPEATER bit is set,
indicating that the attached HDCP receiver is an HDCP repeater.
This part of the protocol assembles a list of all downstream
KSVs attached to the HDCP repeater through a permitted connection tree,
enabling revocation support upstream.

Third part authentication protocol.
The third part of the authentication protocol occurs during
the vertical blanking interval preceding the frame for which it applies.
Each of the two HDCP devices calculates new cipher initialization values,
Ki and Mi, and a third value Ri. and asynchronous polling every 2 seconds.

Exynos scenario.
1. start encryption.
2. receive Bcaps, Bksv from peer device.
3. check repeater caps from Bcaps.
4. send An, Aksv to peer device.
5. receive Rj from peer device.
6. compare Ri, Rj. If same and not repeater, then start encryption.
7. If not same, retry. If repeater, then start second authentication.
8. stop encryption.

Thank's
BR
Eunchul Kim

Eunchul Kim (1):
  drm/exynos: added hdcp driver for contents protection.

 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_hdcp.c| 1164 +++
 drivers/gpu/drm/exynos/exynos_hdcp.h|   47 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c|   11 +
 drivers/gpu/drm/exynos/exynos_hdmi.h|7 +
 drivers/gpu/drm/exynos/regs-hdmi.h  |  177 +
 9 files changed, 1426 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.h



[Bug 52360] [32bit/r600-llvm] Counter Strike 1.6 segfaults on start

2012-12-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=52360

--- Comment #2 from okias  ---
Created attachment 71943
  --> https://bugs.freedesktop.org/attachment.cgi?id=71943=edit
R600_DUMP_SHADERS.log

R600_DUMP_SHADERS=1

new kernel 3.7.1, mesa-git, llvm-git and still same problem

-- 
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/20121221/60d6c95c/attachment.html>


[PATCH v2] drm/exynos: consider no iommu support to console framebuffer

2012-12-21 Thread Inki Dae
This patch considers no iommu support to kernel space mapping
of console framebuffer.

Without iommu, we get physical address instead of device address
after dma_alloc_attrs function is called. So we should consider
the case without iommu when it maps console framebuffer with
kernel space.

Changelog v2:
- calll vunmap function only with iommu support.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index f433eb7..eae064a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -34,6 +34,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
+#include "exynos_drm_iommu.h"

 #define MAX_CONNECTOR  4
 #define PREFERRED_BPP  32
@@ -111,9 +112,18 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,

/* map pages with kernel virtual space. */
if (!buffer->kvaddr) {
-   unsigned int nr_pages = buffer->size >> PAGE_SHIFT;
-   buffer->kvaddr = vmap(buffer->pages, nr_pages, VM_MAP,
+   if (is_drm_iommu_supported(dev)) {
+   unsigned int nr_pages = buffer->size >> PAGE_SHIFT;
+
+   buffer->kvaddr = vmap(buffer->pages, nr_pages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
+   } else {
+   phys_addr_t dma_addr = buffer->dma_addr;
+   if (dma_addr)
+   buffer->kvaddr = phys_to_virt(dma_addr);
+   else
+   buffer->kvaddr = (void __iomem *)NULL;
+   }
if (!buffer->kvaddr) {
DRM_ERROR("failed to map pages to kernel space.\n");
return -EIO;
@@ -128,8 +138,12 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,

dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
fbi->screen_base = buffer->kvaddr + offset;
-   fbi->fix.smem_start = (unsigned long)
+   if (is_drm_iommu_supported(dev))
+   fbi->fix.smem_start = (unsigned long)
(page_to_phys(sg_page(buffer->sgt->sgl)) + offset);
+   else
+   fbi->fix.smem_start = (unsigned long)buffer->dma_addr;
+
fbi->screen_size = size;
fbi->fix.smem_len = size;

@@ -320,7 +334,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd->exynos_gem_obj;
struct drm_framebuffer *fb;

-   if (exynos_gem_obj->buffer->kvaddr)
+   if (is_drm_iommu_supported(dev) && exynos_gem_obj->buffer->kvaddr)
vunmap(exynos_gem_obj->buffer->kvaddr);

/* release drm framebuffer and real buffer */
-- 
1.7.4.1



[PATCH] drm/exynos: fix erroneous register read

2012-12-21 Thread Inki Dae
This patch fixes erroneous register read.

readl function needs register base address + offset but
exynos_drm_gsc module used only offset to read a register.

So this patch uses gsc_read function instead of readl.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5639353..bd42542 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1604,7 +1604,7 @@ static int gsc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
exynos_drm_ippnb_send_event(IPP_SET_WRITEBACK, (void *)_wb);

/* src local path */
-   cfg = readl(GSC_IN_CON);
+   cfg = gsc_read(GSC_IN_CON);
cfg &= ~(GSC_IN_PATH_MASK | GSC_IN_LOCAL_SEL_MASK);
cfg |= (GSC_IN_PATH_LOCAL | GSC_IN_LOCAL_FIMD_WB);
gsc_write(cfg, GSC_IN_CON);
-- 
1.7.4.1



[PATCH] drm/exynos: consider no iommu support to console framebuffer

2012-12-21 Thread Inki Dae
This patch considers no iommu support to kernel space mapping
of console framebuffer.

Without iommu, we get physical address instead of device address
after dma_alloc_attrs function is called. So we should consider
the case without iommu when it maps console framebuffer with
kernel space.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index f433eb7..ae0607f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -34,6 +34,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
+#include "exynos_drm_iommu.h"

 #define MAX_CONNECTOR  4
 #define PREFERRED_BPP  32
@@ -111,9 +112,18 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,

/* map pages with kernel virtual space. */
if (!buffer->kvaddr) {
-   unsigned int nr_pages = buffer->size >> PAGE_SHIFT;
-   buffer->kvaddr = vmap(buffer->pages, nr_pages, VM_MAP,
+   if (is_drm_iommu_supported(dev)) {
+   unsigned int nr_pages = buffer->size >> PAGE_SHIFT;
+
+   buffer->kvaddr = vmap(buffer->pages, nr_pages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
+   } else {
+   phys_addr_t dma_addr = buffer->dma_addr;
+   if (dma_addr)
+   buffer->kvaddr = phys_to_virt(dma_addr);
+   else
+   buffer->kvaddr = (void __iomem *)NULL;
+   }
if (!buffer->kvaddr) {
DRM_ERROR("failed to map pages to kernel space.\n");
return -EIO;
@@ -128,8 +138,12 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,

dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
fbi->screen_base = buffer->kvaddr + offset;
-   fbi->fix.smem_start = (unsigned long)
+   if (is_drm_iommu_supported(dev))
+   fbi->fix.smem_start = (unsigned long)
(page_to_phys(sg_page(buffer->sgt->sgl)) + offset);
+   else
+   fbi->fix.smem_start = (unsigned long)buffer->dma_addr;
+
fbi->screen_size = size;
fbi->fix.smem_len = size;

-- 
1.7.4.1



System freezes with radeon DRM driver since kernel 3.6

2012-12-21 Thread Stephan Seitz
On Fri, Dec 21, 2012 at 10:23:41AM -0500, Alex Deucher wrote:
>On Fri, Dec 21, 2012 at 10:14 AM, Stephan Seitz
>> Not without some help,. I?m no programmer. You probably mean I should 
>> test different git commits?
>Git provides a a bisect option that allows you to track down when a
>problem was introduced.  You'll need a copy of the kernel git tree.
>You can follow a tutorial like this one:
>http://www.landley.net/writing/git-bisect-howto.html
>git will bisect the tree picking commits for you to try.  You

Thanks for the link. I will try it the next weeks and report back to you.

Merry christmas!

Stephan

-- 
| Stephan Seitz  E-Mail: stse at fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121221/93b8e779/attachment-0001.bin>


System freezes with radeon DRM driver since kernel 3.6

2012-12-21 Thread Stephan Seitz
On Fri, Dec 21, 2012 at 09:30:39AM -0500, Alex Deucher wrote:
>On Thu, Dec 20, 2012 at 5:09 AM, Stephan Seitz
><stse+dri at fsing.rootsland.net> wrote:
>> filename: 
>> /lib/modules/3.7.0-Dom0/kernel/drivers/gpu/drm/radeon/radeon.ko
>>
>> hardware:
>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
>> RV730XT [Radeon HD 4670] (prog-if 00 [VGA controller])
>> Subsystem: Hightech Information System Ltd. Device 2003
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- > Latency: 0, Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 11
>> Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
>> Region 2: Memory at e500 (64-bit, non-prefetchable) [size=64K]
>> Region 4: I/O ports at b000 [size=256]
>> [virtual] Expansion ROM at e400 [disabled] [size=128K]
>> Capabilities: 
>>
>> 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI
>> Audio [Radeon HD 4000 series]
>> Subsystem: Hightech Information System Ltd. Device aa38
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- > Latency: 0, Cache Line Size: 32 bytes
>> Interrupt: pin B routed to IRQ 63
>> Region 0: Memory at e501 (64-bit, non-prefetchable) [size=16K]
>> Capabilities: 
>> Kernel driver in use: snd_hda_intel
>>
>> My system is debian testing with self-made kernels. The system is working as
>> Dom0 under Xen 4.1.
>>
>> Since kernel 3.6 the drm radeon driver freezes the system after some time.
>> This time can be 10 minutes or some hours. Since the system is completely
>> frozen I don?t know if there are error messages displayed, but the log
>> contains nothing. Simply pressing the reset switch won?t reset the graphic
>> card (no output), I have to switch off the system to get the card working
>> again.
>
>Did you also change the userspace drivers (mesa, xf86-video-ati)?  If

This system is a console system, X is only used sometimes. So while there 
may be updates of other components (it is Debian testing after all) the 
problem occurs in console mode without running X or mesa.
And rebooting the old 3.5 kernel solves the problem.

>you only changed the kernel version, can you bisect?  If you updated

Not without some help,. I?m no programmer. You probably mean I should 
test different git commits?

Stephan

-- 
| Stephan Seitz  E-Mail: stse at fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121221/f733e938/attachment-0001.bin>


[PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Terje Bergström
On 21.12.2012 15:50, Lucas Stach wrote:
> This has to be resolved before merging. Personally I'm in favour of
> keeping reg access patterns close to what is done in other parts of the
> kernel.

I haven't so far received comments from too many people, so that's why I
left it as is.

>>  * Uses still CMA helpers. IOMMU support will replace CMA with host1x
>>specific allocator.
> 
> I really want the allocator issue resolved before talking about merging
> those patches. Proper IOMMU support will require a bit of rework of the
> current upstream IOMMU API, so it will still be a bit out.
> 
> But if you don't mind I'll try to implement the host1x allocator over
> the holidays and provide an incremental patch.

Do you mean host1x CMA allocator using dma mapping API? That'd be great
if you could help out. I've just tried to concentrate on getting ok for
base essentials before doing any extra work.

Terje



[PATCHv4 5/8] drm: tegra: Remove redundant host1x

2012-12-21 Thread Thierry Reding
 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/>.
> + */
> +
> +#ifndef _TEGRA_DRM_H_
> +#define _TEGRA_DRM_H_
> +
> +#endif

This can be removed as well.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121221/b24631d4/attachment.pgp>


[Bug 58568] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

2012-12-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=58568

Paul Menzel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG
 CC||paulepanter at users.sourcefor
   ||ge.net

--- Comment #2 from Paul Menzel  ---
(In reply to comment #1)
> Make sure pci quirks are enabled in your kernel config.  Can you bisect?

That was it. I had those disabled! Sorry for the noise.

-- 
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/20121221/3f0a9606/attachment.html>


[PATCHv4 8/8] gpu: host1x: Register DRM dummy device

2012-12-21 Thread Thierry Reding
On Fri, Dec 21, 2012 at 02:53:51PM +0100, Lucas Stach wrote:
> Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
[...]
> > +void host1x_unregister_drm_device(struct host1x *host1x)
> > +{
> > +   if (host1x->drm_device)
> > +   platform_device_unregister(host1x->drm_device);
> > +}
> > +EXPORT_SYMBOL(host1x_unregister_drm_device);
> > +
> > +struct platform_device *host1x_drm_device(struct platform_device *pdev)
> > +{
> > +   struct host1x *host = platform_get_drvdata(pdev);
> > +   return host->drm_device;
> > +}
> > +EXPORT_SYMBOL(host1x_drm_device);
> This should be called host1x_get_drm_device

Or maybe even host1x_drm_get_device() to make it more obvious that it
doesn't return a struct drm_device. Also I think it would be better to
make it take a struct device * and return a struct device * instead.
Users of the API will probably call this like so:

struct device *dummy = host1x_drm_get_device(pdev->dev.parent);
struct drm_device *drm = dev_get_drvdata(dummy);

So we save ourselves some needless up-casting.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121221/068a256e/attachment.pgp>


[PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Lucas Stach
Am Freitag, den 21.12.2012, 15:57 +0200 schrieb Terje Bergstr?m:
> On 21.12.2012 15:50, Lucas Stach wrote:
> > This has to be resolved before merging. Personally I'm in favour of
> > keeping reg access patterns close to what is done in other parts of the
> > kernel.
> 
> I haven't so far received comments from too many people, so that's why I
> left it as is.
> 
> >>  * Uses still CMA helpers. IOMMU support will replace CMA with host1x
> >>specific allocator.
> > 
> > I really want the allocator issue resolved before talking about merging
> > those patches. Proper IOMMU support will require a bit of rework of the
> > current upstream IOMMU API, so it will still be a bit out.
> > 
> > But if you don't mind I'll try to implement the host1x allocator over
> > the holidays and provide an incremental patch.
> 
> Do you mean host1x CMA allocator using dma mapping API? That'd be great
> if you could help out. I've just tried to concentrate on getting ok for
> base essentials before doing any extra work.
> 
Yes, exactly that.

I'll provide comments to the other patches when I find time to do so.
Digging in the code might help with this.

Regards,
Lucas



[PATCHv4 8/8] gpu: host1x: Register DRM dummy device

2012-12-21 Thread Lucas Stach
Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
> Register a dummy device for tegradrm, and provide a getter to
> access the device.
> 
> Signed-off-by: Terje Bergstrom 
> ---
[...]
> diff --git a/drivers/gpu/host1x/drm.c b/drivers/gpu/host1x/drm.c
> new file mode 100644
> index 000..eaaaeed
> --- /dev/null
> +++ b/drivers/gpu/host1x/drm.c
> @@ -0,0 +1,51 @@
> +/*
> + * Tegra host1x driver DRM dummy device
> + *
> + * Copyright (c) 2012, NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "drm.h"
> +#include "dev.h"
> +
> +int host1x_register_drm_device(struct host1x *host1x)
> +{
> + struct platform_device *drm_device;
> +
> + drm_device = platform_device_register_simple("tegradrm", -1, NULL, 0);
> + if (!drm_device)
> + return -ENOMEM;
> + dma_set_coherent_mask(_device->dev, DMA_BIT_MASK(32));
> +
This might not be necessary once we move the allocator to host1x.

> + host1x->drm_device = drm_device;
> + return 0;
> +}
> +EXPORT_SYMBOL(host1x_register_drm_device);
> +
> +void host1x_unregister_drm_device(struct host1x *host1x)
> +{
> + if (host1x->drm_device)
> + platform_device_unregister(host1x->drm_device);
> +}
> +EXPORT_SYMBOL(host1x_unregister_drm_device);
> +
> +struct platform_device *host1x_drm_device(struct platform_device *pdev)
> +{
> + struct host1x *host = platform_get_drvdata(pdev);
> + return host->drm_device;
> +}
> +EXPORT_SYMBOL(host1x_drm_device);
This should be called host1x_get_drm_device






[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

2012-12-21 Thread Florian Mickler
On Tue, 18 Dec 2012 23:33:20 +0100
Paul Menzel  wrote:

> Dear Florian,
> 
> 
> Am Dienstag, den 18.12.2012, 21:03 +0100 schrieb Florian Mickler:
> 
> > On Wed, 15 Aug 2012 17:40:40 +0200 Paul Menzel wrote:
> > 
> > > Date: Wed, 8 Aug 2012 23:12:19 +0200
> > > 
> > > Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
> > > vertical stripes in the top half.
> > 
> > This patch, which was merged in v3.6-rc4, makes the image on my ASUS
> > VW222U ca. 1 inch too wide left/right and top/bottom.  The effect is as
> > if the image was zoomed (bigger, more pixely).
> > 
> > Reverting it fixes the problem.
> 
> I am sorry for the trouble caused by this. As a work around, you could
> also specify the QUIRKS on the Linux command line.
> 
> > The Monitor is connected via VGA, but also has a DVI interface.
> > 
> > Maybe the quirk-apply criteria is too unspecific?
> 
> Hmm, I guess everything is identical but the DVI connector they added to
> the VW222U. Though I should have noticed the effect on the VW222S and
> did not. :(

Hm.. why should you have noticed the effect on the VW222S? Does it
happen there too?

> 
> Could you please send the `edid-decode` output on your system and
> `/var/log/Xorg.0.log`.
> 

I attached the xrandr --verbose output and the 
# get-edid  | parse-edid
output from http://www.polypux.org/projects/read-edid/ which I already
had installed. Hope this works for you too.



> Also I wonder how this quirk could create such a behavior.


Yes. I'm not shure how this could happen. It probably is either a bug
somewhere, or it is the 'natural' effect of misconfiguring the vga
pipeline.  Maybe someone more knowledgeable than me could make a more
educated guess about this.


> 
> [1] http://cgit.freedesktop.org/xorg/app/edid-decode/
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: xrandr_verbose.txt
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121221/1c602af7/attachment.txt>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: parse-edid.txt
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121221/1c602af7/attachment-0001.txt>


[PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Lucas Stach
Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
> This set of patches adds support for Tegra20 and Tegra30 host1x and
> 2D. It is based on linux-next-20121220.
> 
> The fourth version has only few changes compared to previous version:
>  * Fixed some sparse warnings
>  * Fixed host1x Makefile to allow building as module
>  * Fixed host1x module unload
>  * Fixed tegradrm unload sequence
>  * host1x creates DRM dummy device and tegradrm uses it for storing
>DRM related data.
> 
> Some of the issues left open:
>  * Register definitions still use static inline. There has been a
>debate about code style versus ability to use compiler type
>checking and code coverage analysis. There was no conclusion, so
>I left it as was.
This has to be resolved before merging. Personally I'm in favour of
keeping reg access patterns close to what is done in other parts of the
kernel.

>  * Uses still CMA helpers. IOMMU support will replace CMA with host1x
>specific allocator.

I really want the allocator issue resolved before talking about merging
those patches. Proper IOMMU support will require a bit of rework of the
current upstream IOMMU API, so it will still be a bit out.

But if you don't mind I'll try to implement the host1x allocator over
the holidays and provide an incremental patch.

Regards,
Lucas



[PATCH] uxa: Align tiled surface size to an number of tiled rows

2012-12-21 Thread Chris Wilson
Align surface sizes to an even number of tile rows to cater for sampler
prefetch, as shown by enabling GPU invalid PTE detection (i.e. clearing
the valid bit of the PTE).
---

We are investigating bug
https://bugs.freedesktop.org/show_bug.cgi?id=55984 where the only lead
so far is the ordering of eviction under memory pressure. This patch
seems promising because the GPU is detecting that we are accessing invalid
pages beyond the end of our allocations (and so the eviction may lead us
to randomly read the scratch PTE and randomly hang the GPU), however the
only bug that I have seen with such a tell-tale error state is
https://bugzilla.redhat.com/show_bug.cgi?id=877461
-Chris

---
 src/intel_uxa.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index f5ac0a6..2f14173 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -209,7 +209,7 @@ intel_uxa_pixmap_compute_size(PixmapPtr pixmap,
tile_height = 8;
else
tile_height = 32;
-   aligned_h = ALIGN(h, tile_height);
+   aligned_h = ALIGN(h, 2*tile_height);

*stride = intel_get_fence_pitch(intel,
ALIGN(pitch, 512),
-- 
1.7.10.4



[RFC] drm/exynos: added hdcp driver for contents protection.

2012-12-21 Thread Sean Paul
On Fri, Dec 21, 2012 at 4:47 AM, Eunchul Kim  
wrote:
> HDCP stands for High-bandwidth Digital Content Protection.
> This is a newer form of Digital Rights Management(secure DRM)
> that was designed to control digital video and audio content.
> Contains an integrated HDCP encryption engine for video/audio content 
> protection.
> supports version HDCP v1.1.
> Exynos AP supports embedded HDCP key system.
> The HDCP key value is fused during fabrication, based on customer's request.
>
> Exynos HDCP scenario.
> - start encryption.
> - receive Bcaps, Bksv from peer device.
> - check repeater caps from Bcaps.
> - send An, Aksv to peer device.
> - receive Rj from peer device.
> - compare Ri,Rj. If same and not repeater, then start encryption.
> - If not same, retry. If repeater, then start second authentication.
> - stop encryption.
>
> Signed-off-by: Eunchul Kim 
> ---

Hey Eunchul,
Through some unfortunate duplication of work, I've also been working
on HDCP for exynos drm.

I uploaded my patch a couple of days ago
https://gerrit.chromium.org/gerrit/#/c/39960.

A few high level comments on your patch:

- Why implement a new driver? You're using the irq and registers from
the hdmi IP block, seems to make more sense to do it right in the hdmi
driver. There's a fair bit of code gymnastics that you're doing to
make hdcp visible to hdmi that just wouldn't be necessary if it was
all included.
- I'm not sure what your interface to userspace is. I think it makes
most sense to implement this as a connector property. Here's a patch I
uploaded a couple weeks ago
https://gerrit.chromium.org/gerrit/#/c/38845/

A couple more comments inline.

>  drivers/gpu/drm/exynos/Kconfig  |6 +
>  drivers/gpu/drm/exynos/Makefile |1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>  drivers/gpu/drm/exynos/exynos_hdcp.c| 1164 
> +++
>  drivers/gpu/drm/exynos/exynos_hdcp.h|   47 ++
>  drivers/gpu/drm/exynos/exynos_hdmi.c|   11 +
>  drivers/gpu/drm/exynos/exynos_hdmi.h|7 +
>  drivers/gpu/drm/exynos/regs-hdmi.h  |  177 +
>  9 files changed, 1426 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.c
>  create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.h
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 1d1f1e5..93c2f00 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -34,6 +34,12 @@ config DRM_EXYNOS_HDMI
> help
>   Choose this option if you want to use Exynos HDMI for DRM.
>
> +config DRM_EXYNOS_HDCP
> +   bool "Exynos DRM HDCP"
> +   depends on DRM_EXYNOS_HDMI
> +   help
> + Choose this option if you want to use Exynos HDCP in HDMI for DRM.
> +
>  config DRM_EXYNOS_VIDI
> bool "Exynos DRM Virtual Display"
> depends on DRM_EXYNOS
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 639b49e..58d8fb7 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -14,6 +14,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
>exynos_ddc.o exynos_hdmiphy.o \
>exynos_drm_hdmi.o
> +exynosdrm-$(CONFIG_DRM_EXYNOS_HDCP) += exynos_hdcp.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
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index e0a8e80..0d2ada1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -345,6 +345,11 @@ static int __init exynos_drm_init(void)
>  #endif
>
>  #ifdef CONFIG_DRM_EXYNOS_HDMI
> +#ifdef CONFIG_DRM_EXYNOS_HDCP
> +   ret = platform_driver_register(_driver);
> +   if (ret < 0)
> +   goto out_hdcp;
> +#endif
> ret = platform_driver_register(_driver);
> if (ret < 0)
> goto out_hdmi;
> @@ -452,6 +457,10 @@ out_common_hdmi:
>  out_mixer:
> platform_driver_unregister(_driver);
>  out_hdmi:
> +#ifdef CONFIG_DRM_EXYNOS_HDCP
> +   platform_driver_unregister(_driver);
> +out_hdcp:
> +#endif
>  #endif
>
>  #ifdef CONFIG_DRM_EXYNOS_FIMD
> @@ -494,6 +503,9 @@ static void __exit exynos_drm_exit(void)
> platform_driver_unregister(_drm_common_hdmi_driver);
> platform_driver_unregister(_driver);
> platform_driver_unregister(_driver);
> +#ifdef CONFIG_DRM_EXYNOS_HDCP
> +   platform_driver_unregister(_driver);
> +#endif
>  #endif
>
>  #ifdef CONFIG_DRM_EXYNOS_VIDI
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 

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

2012-12-21 Thread Stephen Warren
On 12/21/2012 01:57 AM, Arto Merilainen wrote:
> On 12/20/2012 07:14 PM, Stephen Warren wrote:
>>
>> What's wrong with just having each device ask the host1x (its parent)
>> for a pointer to the (dummy) tegradrm device. That seems extremely
>>
> 
> We are talking about creating a dummy device because:
> - we need to give something for drm_platform_init(),
> - drm related data should be stored somewhere,

Yes to those too, I believe.

> - some data must be passed to all driver probe() functions. This is not
> hw-related data, but just some lists that are used to ensure that all
> drivers have been initialised before calling drm_platform_init().

I haven't really thought through /when/ host1x would create the dummy
device. I guess if tegradrm really must initialize after all the devices
that it uses (rather than using something like deferred probe) then the
above may be true.

> All these issues are purely tegra-drm related and solving them elsewhere
> (in host1x) would be just wrong! host1x would not even use the dummy
> device for anything so creating it there seems bizarre.

I see the situation more like:

* There's host1x hardware.

* There's a low-level driver just for host1x itself; the host1x driver.

* There's a high-level driver for the entire host1x complex of devices.
That is tegradrm. There may be more high-level drivers in the future
(e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x
sub-devices liek tegradrm does).

* The presence of the host1x DT node logically implies that both the two
drivers in the previous two points should be instantiated.

* Linux instantiates a single device per DT node.

* So, it's host1x's responsibility to instantiate the other device(s). I
think it's reasonable for the host1x driver to know exactly what
features the host1x HW complex supports; raw host1x access being one,
and the higher level concept of a tegradrm being another. So, it's
reasonable for host1x to trigger the instantiation of tegradrm.

* If DRM core didn't stomp on the device object's drvdata (or whichever
field it is), I would recommend not creating a dummy device at all, but
rather having the host1x driver directly implement multiple driver
interfaces. There are many examples like this already in the kernel,
e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc.


Fan control in nouveau driver with geforce 9600gt

2012-12-21 Thread Ozan Çağlayan
> Of course it is, but why would you disable automatic fan management?
>
> You are supposed to activate it and let it activated at all time.

It's not me but someone inexperienced playing with sysfs tunables for example :)



-- 
Ozan ?a?layan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com


[PATCHv4 8/8] gpu: host1x: Register DRM dummy device

2012-12-21 Thread Terje Bergstrom
Register a dummy device for tegradrm, and provide a getter to
access the device.

Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/drm/tegra/dc.c   |5 -
 drivers/gpu/drm/tegra/drm.c  |   11 +
 drivers/gpu/drm/tegra/gr2d.c |4 +++-
 drivers/gpu/drm/tegra/hdmi.c |5 -
 drivers/gpu/host1x/Makefile  |3 ++-
 drivers/gpu/host1x/dev.c |9 
 drivers/gpu/host1x/dev.h |2 ++
 drivers/gpu/host1x/drm.c |   51 ++
 drivers/gpu/host1x/drm.h |   25 +
 include/linux/host1x.h   |2 ++
 10 files changed, 103 insertions(+), 14 deletions(-)
 create mode 100644 drivers/gpu/host1x/drm.c
 create mode 100644 drivers/gpu/host1x/drm.h

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 24bcd06..d01be50 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -740,7 +741,9 @@ static int tegra_dc_probe(struct platform_device *pdev)
struct resource *regs;
struct tegra_dc *dc;
int err;
-   struct tegradrm *tegradrm = platform_get_drvdata(pdev);
+   struct platform_device *drm_device =
+   host1x_drm_device(to_platform_device(pdev->dev.parent));
+   struct tegradrm *tegradrm = platform_get_drvdata(drm_device);

dc = devm_kzalloc(>dev, sizeof(*dc), GFP_KERNEL);
if (!dc)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 637b621..d64935d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -56,7 +56,6 @@ static int tegra_drm_add_client(struct device *dev, void 
*data)
client->np = of_node_get(dev->of_node);

list_add_tail(>list, >drm_clients);
-   dev_set_drvdata(dev, tegradrm);
}
}

@@ -258,16 +257,10 @@ static struct platform_driver tegra_drm_platform_driver = 
{
 static int __init tegra_drm_init(void)
 {
int err;
-   struct platform_device *drm_device;
-
-   drm_device = platform_device_register_simple("tegradrm", -1, NULL, 0);
-   if (!drm_device)
-   return -ENOMEM;
-   dma_set_coherent_mask(_device->dev, DMA_BIT_MASK(32));

err = platform_driver_register(_drm_platform_driver);
if (err < 0)
-   goto unregister_tegra_dev;
+   return err;

err = platform_driver_register(_dc_driver);
if (err < 0)
@@ -288,8 +281,6 @@ unregister_dc:
platform_driver_unregister(_dc_driver);
 unregister_tegra_drv:
platform_driver_unregister(_drm_platform_driver);
-unregister_tegra_dev:
-   platform_device_unregister(drm_device);
return err;
 }
 module_init(tegra_drm_init);
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 8865099..a936902 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -247,7 +247,9 @@ static int __devinit gr2d_probe(struct platform_device *dev)
 {
int err;
struct gr2d *gr2d = NULL;
-   struct tegradrm *tegradrm = platform_get_drvdata(dev);
+   struct platform_device *drm_device =
+   host1x_drm_device(to_platform_device(dev->dev.parent));
+   struct tegradrm *tegradrm = platform_get_drvdata(drm_device);

gr2d = devm_kzalloc(>dev, sizeof(*gr2d), GFP_KERNEL);
if (!gr2d)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index fce3e66..a90a76f 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -1214,7 +1215,9 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
struct tegra_hdmi *hdmi;
struct resource *regs;
int err;
-   struct tegradrm *tegradrm = platform_get_drvdata(pdev);
+   struct platform_device *drm_device =
+   host1x_drm_device(to_platform_device(pdev->dev.parent));
+   struct tegradrm *tegradrm = platform_get_drvdata(drm_device);

hdmi = devm_kzalloc(>dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 049c07a..f8749fb 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -10,7 +10,8 @@ host1x-y = \
job.o \
debug.o \
memmgr.o \
-   hw/host1x01.o
+   hw/host1x01.o \
+   drm.o

 host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 8d710ef..07e8813 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include "dev.h"
+#include "drm.h"
 #include "intr.h"
 #include "channel.h"
 #include "debug.h"
@@ -145,6 +146,12 @@ static int host1x_probe(struct platform_device *dev)

/* set 

[PATCHv4 7/8] drm: tegra: Add gr2d device

2012-12-21 Thread Terje Bergstrom
Add client driver for 2D device.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/drm/tegra/Makefile |2 +-
 drivers/gpu/drm/tegra/drm.c|  211 ++-
 drivers/gpu/drm/tegra/drm.h|   29 
 drivers/gpu/drm/tegra/gr2d.c   |  307 
 include/drm/tegra_drm.h|  111 +++
 5 files changed, 658 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/tegra/gr2d.c

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index f4c05bb..2661f41 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -1,7 +1,7 @@
 ccflags-y := -Iinclude/drm
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG

-tegra-drm-y := drm.o fb.o dc.o
+tegra-drm-y := drm.o fb.o dc.o gr2d.o
 tegra-drm-y += output.o rgb.o hdmi.o

 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 3de6c8e..637b621 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -36,8 +36,10 @@ static int tegra_drm_add_client(struct device *dev, void 
*data)
static const char * const compat[] = {
"nvidia,tegra20-dc",
"nvidia,tegra20-hdmi",
+   "nvidia,tegra20-gr2d",
"nvidia,tegra30-dc",
"nvidia,tegra30-hdmi",
+   "nvidia,tegra30-gr2d"
};
struct tegradrm *tegradrm = data;
struct tegra_drm_client_entry *client;
@@ -183,12 +185,29 @@ static int tegra_drm_unload(struct drm_device *drm)

 static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
 {
-   return 0;
+   struct tegra_drm_fpriv *fpriv;
+   int err = 0;
+
+   fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
+   if (!fpriv)
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(>contexts);
+   filp->driver_priv = fpriv;
+
+   return err;
 }

 static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
 {
+   struct tegra_drm_fpriv *fpriv = tegra_drm_fpriv(filp);
+   struct tegra_drm_context *context, *tmp;

+   list_for_each_entry_safe(context, tmp, >contexts, list) {
+   context->client->ops->close_channel(context);
+   kfree(context);
+   }
+   kfree(fpriv);
 }

 static void tegra_drm_lastclose(struct drm_device *drm)
@@ -257,8 +276,14 @@ static int __init tegra_drm_init(void)
err = platform_driver_register(_hdmi_driver);
if (err < 0)
goto unregister_dc;
+
+   err = platform_driver_register(_gr2d_driver);
+   if (err < 0)
+   goto unregister_hdmi;
return 0;

+unregister_hdmi:
+   platform_driver_unregister(_hdmi_driver);
 unregister_dc:
platform_driver_unregister(_dc_driver);
 unregister_tegra_drv:
@@ -271,13 +296,197 @@ module_init(tegra_drm_init);

 static void __exit tegra_drm_exit(void)
 {
+   platform_driver_unregister(_gr2d_driver);
platform_driver_unregister(_hdmi_driver);
platform_driver_unregister(_dc_driver);
platform_driver_unregister(_drm_platform_driver);
 }
 module_exit(tegra_drm_exit);

+static int
+tegra_drm_ioctl_syncpt_read(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_syncpt_read_args *args = data;
+
+   args->value = host1x_syncpt_read_byid(args->id);
+   return 0;
+}
+
+static int
+tegra_drm_ioctl_syncpt_incr(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_syncpt_incr_args *args = data;
+   host1x_syncpt_incr_byid(args->id);
+   return 0;
+}
+
+static int
+tegra_drm_ioctl_syncpt_wait(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_syncpt_wait_args *args = data;
+   int err;
+
+   err = host1x_syncpt_wait_byid(args->id, args->thresh,
+   args->timeout, >value);
+
+   return err;
+}
+
+static int
+tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_open_channel_args *args = data;
+   struct tegra_drm_client *client;
+   struct tegra_drm_context *context;
+   struct tegra_drm_fpriv *fpriv = tegra_drm_fpriv(file_priv);
+   struct tegradrm *tegradrm = drm->dev_private;
+   int err = 0;
+
+   context = kzalloc(sizeof(*context), GFP_KERNEL);
+   if (!context)
+   return -ENOMEM;
+
+   list_for_each_entry(client, >clients, list) {
+   if (client->class == args->class) {
+   dev_dbg(drm->dev, "opening client %x\n", args->class);
+   context->client = client;
+   err = client->ops->open_channel(client, context);
+   if (err)
+   

[PATCHv4 6/8] ARM: tegra: Add board data and 2D clocks

2012-12-21 Thread Terje Bergstrom
Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
of 2D clock to that driver alias.

Signed-off-by: Terje Bergstrom 
---
 arch/arm/mach-tegra/board-dt-tegra20.c|1 +
 arch/arm/mach-tegra/board-dt-tegra30.c|1 +
 arch/arm/mach-tegra/tegra20_clocks_data.c |2 +-
 arch/arm/mach-tegra/tegra30_clocks_data.c |1 +
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c 
b/arch/arm/mach-tegra/board-dt-tegra20.c
index 734d9cc..2b7a3c2 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -95,6 +95,7 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D800, "spi_tegra.2", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000DA00, "spi_tegra.3", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-host1x", 0x5000, "host1x", NULL),
+   OF_DEV_AUXDATA("nvidia,tegra20-gr2d", 0x5414, "gr2d", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-dc", 0x5420, "tegradc.0", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-dc", 0x5424, "tegradc.1", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-hdmi", 0x5428, "hdmi", NULL),
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c 
b/arch/arm/mach-tegra/board-dt-tegra30.c
index 6497d12..6a9e6cb 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@ -58,6 +58,7 @@ struct of_dev_auxdata tegra30_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("nvidia,tegra30-slink", 0x7000DC00, "spi_tegra.4", NULL),
OF_DEV_AUXDATA("nvidia,tegra30-slink", 0x7000DE00, "spi_tegra.5", NULL),
OF_DEV_AUXDATA("nvidia,tegra30-host1x", 0x5000, "host1x", NULL),
+   OF_DEV_AUXDATA("nvidia,tegra30-gr2d", 0x5414, "gr2d", NULL),
OF_DEV_AUXDATA("nvidia,tegra30-dc", 0x5420, "tegradc.0", NULL),
OF_DEV_AUXDATA("nvidia,tegra30-dc", 0x5424, "tegradc.1", NULL),
OF_DEV_AUXDATA("nvidia,tegra30-hdmi", 0x5428, "hdmi", NULL),
diff --git a/arch/arm/mach-tegra/tegra20_clocks_data.c 
b/arch/arm/mach-tegra/tegra20_clocks_data.c
index a23a073..15d440a 100644
--- a/arch/arm/mach-tegra/tegra20_clocks_data.c
+++ b/arch/arm/mach-tegra/tegra20_clocks_data.c
@@ -1041,7 +1041,7 @@ static struct clk_duplicate tegra_clk_duplicates[] = {
CLK_DUPLICATE("usbd",   "utmip-pad",NULL),
CLK_DUPLICATE("usbd",   "tegra-ehci.0", NULL),
CLK_DUPLICATE("usbd",   "tegra-otg",NULL),
-   CLK_DUPLICATE("2d", "tegra_grhost", "gr2d"),
+   CLK_DUPLICATE("2d", "gr2d", "gr2d"),
CLK_DUPLICATE("3d", "tegra_grhost", "gr3d"),
CLK_DUPLICATE("epp","tegra_grhost", "epp"),
CLK_DUPLICATE("mpe","tegra_grhost", "mpe"),
diff --git a/arch/arm/mach-tegra/tegra30_clocks_data.c 
b/arch/arm/mach-tegra/tegra30_clocks_data.c
index 6942c7a..5787865 100644
--- a/arch/arm/mach-tegra/tegra30_clocks_data.c
+++ b/arch/arm/mach-tegra/tegra30_clocks_data.c
@@ -1338,6 +1338,7 @@ struct clk_duplicate tegra_clk_duplicates[] = {
CLK_DUPLICATE("pll_p", "tegradc.0", "parent"),
CLK_DUPLICATE("pll_p", "tegradc.1", "parent"),
CLK_DUPLICATE("pll_d2_out0", "hdmi", "parent"),
+   CLK_DUPLICATE("2d", "gr2d", "gr2d"),
 };

 struct clk *tegra_ptr_clks[] = {
-- 
1.7.9.5



[PATCHv4 5/8] drm: tegra: Remove redundant host1x

2012-12-21 Thread Terje Bergstrom
From: Arto Merilainen 

This patch removes the redundant host1x driver from tegradrm and
makes necessary bindings to the separate host driver.

The infrastructure for drm client lists is merged to drm.c.

The patch simplifies driver initialization; The original driver had
two lists for registered devices (clients and drm_active). The
clients list included references to all registered devices whereas
the drm_active list included only the devices that the tegradrm
driver itself supported. host1x is separated into a driver of its own
and hence there should be no need to support registration of external
drivers.  Therefore, only the drm_active list is reserved. Removal of
the list also simplifies the driver unregistration.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/drm/tegra/Kconfig  |2 +-
 drivers/gpu/drm/tegra/Makefile |2 +-
 drivers/gpu/drm/tegra/dc.c |   23 +--
 drivers/gpu/drm/tegra/drm.c|  231 ++--
 drivers/gpu/drm/tegra/drm.h|   43 +++---
 drivers/gpu/drm/tegra/fb.c |   17 ++-
 drivers/gpu/drm/tegra/hdmi.c   |   27 ++--
 drivers/gpu/drm/tegra/host1x.c |  325 
 include/drm/tegra_drm.h|   20 +++
 9 files changed, 298 insertions(+), 392 deletions(-)
 delete mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 include/drm/tegra_drm.h

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index be1daf7..4a0290e 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -1,6 +1,6 @@
 config DRM_TEGRA
tristate "NVIDIA Tegra DRM"
-   depends on DRM && OF && ARCH_TEGRA
+   depends on DRM && OF && ARCH_TEGRA && TEGRA_HOST1X
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 80f73d1..f4c05bb 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -1,7 +1,7 @@
 ccflags-y := -Iinclude/drm
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG

-tegra-drm-y := drm.o fb.o dc.o host1x.o
+tegra-drm-y := drm.o fb.o dc.o
 tegra-drm-y += output.o rgb.o hdmi.o

 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0744103..24bcd06 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -673,10 +673,10 @@ static int tegra_dc_debugfs_exit(struct tegra_dc *dc)
return 0;
 }

-static int tegra_dc_drm_init(struct host1x_client *client,
+static int tegra_dc_drm_init(struct tegra_drm_client *client,
 struct drm_device *drm)
 {
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_dc *dc = tegra_drm_client_to_dc(client);
int err;

dc->pipe = drm->mode_config.num_crtc;
@@ -708,9 +708,9 @@ static int tegra_dc_drm_init(struct host1x_client *client,
return 0;
 }

-static int tegra_dc_drm_exit(struct host1x_client *client)
+static int tegra_dc_drm_exit(struct tegra_drm_client *client)
 {
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_dc *dc = tegra_drm_client_to_dc(client);
int err;

devm_free_irq(dc->dev, dc->irq, dc);
@@ -730,17 +730,17 @@ static int tegra_dc_drm_exit(struct host1x_client *client)
return 0;
 }

-static const struct host1x_client_ops dc_client_ops = {
+static const struct tegra_drm_client_ops dc_client_ops = {
.drm_init = tegra_dc_drm_init,
.drm_exit = tegra_dc_drm_exit,
 };

 static int tegra_dc_probe(struct platform_device *pdev)
 {
-   struct host1x *host1x = dev_get_drvdata(pdev->dev.parent);
struct resource *regs;
struct tegra_dc *dc;
int err;
+   struct tegradrm *tegradrm = platform_get_drvdata(pdev);

dc = devm_kzalloc(>dev, sizeof(*dc), GFP_KERNEL);
if (!dc)
@@ -780,6 +780,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
INIT_LIST_HEAD(>client.list);
dc->client.ops = _client_ops;
dc->client.dev = >dev;
+   dc->client.tegradrm = tegradrm;

err = tegra_dc_rgb_probe(dc);
if (err < 0 && err != -ENODEV) {
@@ -787,9 +788,9 @@ static int tegra_dc_probe(struct platform_device *pdev)
return err;
}

-   err = host1x_register_client(host1x, >client);
+   err = tegra_drm_register_client(tegradrm, >client);
if (err < 0) {
-   dev_err(>dev, "failed to register host1x client: %d\n",
+   dev_err(>dev, "failed to register tegra drm client: %d\n",
err);
return err;
}
@@ -801,13 +802,13 @@ static int tegra_dc_probe(struct platform_device *pdev)

 static int tegra_dc_remove(struct platform_device *pdev)
 {
-   struct host1x *host1x = dev_get_drvdata(pdev->dev.parent);
struct tegra_dc *dc = 

[PATCHv4 4/8] gpu: host1x: Add debug support

2012-12-21 Thread Terje Bergstrom
Add support for host1x debugging. Adds debugfs entries, and dumps
channel state to UART in case of stuck job.

Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Makefile |1 +
 drivers/gpu/host1x/cdma.c   |   37 +++
 drivers/gpu/host1x/debug.c  |  207 ++
 drivers/gpu/host1x/debug.h  |   49 
 drivers/gpu/host1x/dev.c|3 +
 drivers/gpu/host1x/dev.h|   17 ++
 drivers/gpu/host1x/hw/cdma_hw.c |3 +
 drivers/gpu/host1x/hw/debug_hw.c|  399 +++
 drivers/gpu/host1x/hw/host1x01.c|2 +
 drivers/gpu/host1x/hw/hw_host1x01_channel.h |   12 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h|   77 ++
 drivers/gpu/host1x/hw/syncpt_hw.c   |1 +
 drivers/gpu/host1x/syncpt.c |3 +
 13 files changed, 811 insertions(+)
 create mode 100644 drivers/gpu/host1x/debug.c
 create mode 100644 drivers/gpu/host1x/debug.h
 create mode 100644 drivers/gpu/host1x/hw/debug_hw.c

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 59ecd82..049c07a 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -8,6 +8,7 @@ host1x-y = \
intr.o \
channel.o \
job.o \
+   debug.o \
memmgr.o \
hw/host1x01.o

diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 1193fea..b924f23 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -19,6 +19,7 @@
 #include "cdma.h"
 #include "channel.h"
 #include "dev.h"
+#include "debug.h"
 #include "memmgr.h"
 #include 

@@ -369,12 +370,45 @@ int host1x_cdma_begin(struct host1x_cdma *cdma, struct 
host1x_job *job)
return 0;
 }

+static void trace_write_gather(struct host1x_cdma *cdma,
+   struct mem_handle *ref,
+   u32 offset, u32 words)
+{
+   void *mem = NULL;
+
+   if (host1x_debug_trace_cmdbuf) {
+   mem = host1x_memmgr_mmap(ref);
+   if (IS_ERR_OR_NULL(mem))
+   mem = NULL;
+   };
+
+   if (mem) {
+   u32 i;
+   /*
+* Write in batches of 128 as there seems to be a limit
+* of how much you can output to ftrace at once.
+*/
+   for (i = 0; i < words; i += TRACE_MAX_LENGTH) {
+   trace_host1x_cdma_push_gather(
+   cdma_to_channel(cdma)->dev->name,
+   (u32)ref,
+   min(words - i, TRACE_MAX_LENGTH),
+   offset + i * sizeof(u32),
+   mem);
+   }
+   host1x_memmgr_munmap(ref, mem);
+   }
+}
+
 /*
  * Push two words into a push buffer slot
  * Blocks as necessary if the push buffer is full.
  */
 void host1x_cdma_push(struct host1x_cdma *cdma, u32 op1, u32 op2)
 {
+   if (host1x_debug_trace_cmdbuf)
+   trace_host1x_cdma_push(cdma_to_channel(cdma)->dev->name,
+   op1, op2);
host1x_cdma_push_gather(cdma, NULL, 0, op1, op2);
 }

@@ -390,6 +424,9 @@ void host1x_cdma_push_gather(struct host1x_cdma *cdma,
u32 slots_free = cdma->slots_free;
struct push_buffer *pb = >push_buffer;

+   if (handle)
+   trace_write_gather(cdma, handle, offset, op1 & 0x);
+
if (slots_free == 0) {
host1x->cdma_op.kick(cdma);
slots_free = host1x_cdma_wait_locked(cdma,
diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
new file mode 100644
index 000..86d5c70
--- /dev/null
+++ b/drivers/gpu/host1x/debug.c
@@ -0,0 +1,207 @@
+/*
+ * Copyright (C) 2010 Google, Inc.
+ * Author: Erik Gilling 
+ *
+ * Copyright (C) 2011-2012 NVIDIA Corporation
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "dev.h"
+#include "debug.h"
+#include "channel.h"
+
+static pid_t host1x_debug_null_kickoff_pid;
+unsigned int host1x_debug_trace_cmdbuf;
+
+static pid_t host1x_debug_force_timeout_pid;
+static u32 host1x_debug_force_timeout_val;
+static u32 host1x_debug_force_timeout_channel;
+
+void host1x_debug_output(struct output *o, const char *fmt, ...)
+{
+   va_list args;
+   int len;
+
+   va_start(args, fmt);
+   len = vsnprintf(o->buf, sizeof(o->buf), fmt, args);
+   va_end(args);
+   o->fn(o->ctx, o->buf, len);
+}
+

[PATCHv4 3/8] gpu: host1x: Add channel support

2012-12-21 Thread Terje Bergstrom
Add support for host1x client modules, and host1x channels to submit
work to the clients. The work is submitted in GEM CMA buffers, so
this patch adds support for them.

Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Kconfig  |   24 +-
 drivers/gpu/host1x/Makefile |5 +
 drivers/gpu/host1x/cdma.c   |  438 +++
 drivers/gpu/host1x/cdma.h   |  107 +
 drivers/gpu/host1x/channel.c|  137 ++
 drivers/gpu/host1x/channel.h|   64 +++
 drivers/gpu/host1x/cma.c|  117 +
 drivers/gpu/host1x/cma.h|   43 ++
 drivers/gpu/host1x/dev.c|   13 +
 drivers/gpu/host1x/dev.h|   54 +++
 drivers/gpu/host1x/hw/cdma_hw.c |  477 +
 drivers/gpu/host1x/hw/cdma_hw.h |   37 ++
 drivers/gpu/host1x/hw/channel_hw.c  |  147 +++
 drivers/gpu/host1x/hw/host1x01.c|6 +
 drivers/gpu/host1x/hw/host1x01_hardware.h   |  124 ++
 drivers/gpu/host1x/hw/hw_host1x01_channel.h |   86 
 drivers/gpu/host1x/hw/hw_host1x01_sync.h|8 +
 drivers/gpu/host1x/hw/hw_host1x01_uclass.h  |  130 ++
 drivers/gpu/host1x/hw/syncpt_hw.c   |   10 +
 drivers/gpu/host1x/intr.c   |   29 +-
 drivers/gpu/host1x/intr.h   |6 +
 drivers/gpu/host1x/job.c|  618 +++
 drivers/gpu/host1x/memmgr.c |  174 
 drivers/gpu/host1x/memmgr.h |   53 +++
 drivers/gpu/host1x/syncpt.c |6 +
 drivers/gpu/host1x/syncpt.h |2 +
 include/linux/host1x.h  |  173 
 include/trace/events/host1x.h   |  235 ++
 28 files changed, 3321 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/host1x/cdma.c
 create mode 100644 drivers/gpu/host1x/cdma.h
 create mode 100644 drivers/gpu/host1x/channel.c
 create mode 100644 drivers/gpu/host1x/channel.h
 create mode 100644 drivers/gpu/host1x/cma.c
 create mode 100644 drivers/gpu/host1x/cma.h
 create mode 100644 drivers/gpu/host1x/hw/cdma_hw.c
 create mode 100644 drivers/gpu/host1x/hw/cdma_hw.h
 create mode 100644 drivers/gpu/host1x/hw/channel_hw.c
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_channel.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_uclass.h
 create mode 100644 drivers/gpu/host1x/job.c
 create mode 100644 drivers/gpu/host1x/memmgr.c
 create mode 100644 drivers/gpu/host1x/memmgr.h

diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index e89fb2b..61e7ba3 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -3,4 +3,26 @@ config TEGRA_HOST1X
help
  Driver for the Tegra host1x hardware.

- Required for enabling tegradrm.
+ Required for enabling tegradrm and 2D acceleration.
+
+if TEGRA_HOST1X
+
+config TEGRA_HOST1X_CMA
+   bool "Support DRM CMA buffers"
+   depends on DRM
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Say yes if you wish to use DRM CMA buffers.
+
+ If unsure, choose Y.
+
+config TEGRA_HOST1X_FIREWALL
+   bool "Enable HOST1X security firewall"
+   default y
+   help
+ Say yes if kernel should protect command streams from tampering.
+
+ If unsure, choose Y.
+
+endif
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index d3eb3b4..59ecd82 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -4,6 +4,11 @@ host1x-y = \
syncpt.o \
dev.o \
intr.o \
+   cdma.o \
+   intr.o \
+   channel.o \
+   job.o \
+   memmgr.o \
hw/host1x01.o

 host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
new file mode 100644
index 000..1193fea
--- /dev/null
+++ b/drivers/gpu/host1x/cdma.c
@@ -0,0 +1,438 @@
+/*
+ * Tegra host1x Command DMA
+ *
+ * Copyright (c) 2010-2012, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+#include "cdma.h"
+#include "channel.h"
+#include "dev.h"
+#include "memmgr.h"
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define TRACE_MAX_LENGTH 128U
+
+/*
+ * Add an entry to the sync queue.
+ */
+static void 

[PATCHv4 2/8] gpu: host1x: Add syncpoint wait and interrupts

2012-12-21 Thread Terje Bergstrom
Add support for sync point interrupts, and sync point wait. Sync
point wait used interrupts for unblocking wait.

Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Makefile  |2 +
 drivers/gpu/host1x/dev.c |   37 +++-
 drivers/gpu/host1x/dev.h |   15 ++
 drivers/gpu/host1x/hw/host1x01.c |2 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h |   30 ++-
 drivers/gpu/host1x/hw/intr_hw.c  |  178 +++
 drivers/gpu/host1x/intr.c|  350 ++
 drivers/gpu/host1x/intr.h|  100 +
 drivers/gpu/host1x/syncpt.c  |  164 +-
 drivers/gpu/host1x/syncpt.h  |4 +
 include/linux/host1x.h   |1 +
 11 files changed, 880 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/host1x/hw/intr_hw.c
 create mode 100644 drivers/gpu/host1x/intr.c
 create mode 100644 drivers/gpu/host1x/intr.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 363e6ab..d3eb3b4 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -3,6 +3,8 @@ ccflags-y = -Idrivers/gpu/host1x
 host1x-y = \
syncpt.o \
dev.o \
+   intr.o \
hw/host1x01.o

+host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index b0d630d..f441b6c 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include "dev.h"
+#include "intr.h"
 #include "hw/host1x01.h"

 #define CREATE_TRACE_POINTS
@@ -48,6 +49,13 @@ u32 host1x_syncpt_read_byid(u32 id)
 }
 EXPORT_SYMBOL(host1x_syncpt_read_byid);

+int host1x_syncpt_wait_byid(u32 id, u32 thresh, long timeout, u32 *value)
+{
+   struct host1x_syncpt *sp = host1x->syncpt + id;
+   return host1x_syncpt_wait(sp, thresh, timeout, value);
+}
+EXPORT_SYMBOL(host1x_syncpt_wait_byid);
+
 void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
 {
void __iomem *sync_regs = host1x->regs + host1x->info.sync_offset;
@@ -62,6 +70,21 @@ u32 host1x_sync_readl(struct host1x *host1x, u32 r)
return readl(sync_regs + r);
 }

+static int host1x_alloc_resources(struct host1x *host)
+{
+   host->intr.syncpt = devm_kzalloc(>dev->dev,
+   sizeof(struct host1x_intr_syncpt) *
+   host->info.nb_pts,
+   GFP_KERNEL);
+
+   if (!host->intr.syncpt) {
+   /* frees happen in the support removal phase */
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
 static struct host1x_device_info host1x_info = {
.nb_channels= 8,
.nb_pts = 32,
@@ -110,7 +133,6 @@ static int host1x_probe(struct platform_device *dev)

/* set common host1x device data */
platform_set_drvdata(dev, host);
-
host->regs = devm_request_and_ioremap(>dev, regs);
if (!host->regs) {
dev_err(>dev, "failed to remap host registers\n");
@@ -118,6 +140,12 @@ static int host1x_probe(struct platform_device *dev)
goto fail;
}

+   err = host1x_alloc_resources(host);
+   if (err) {
+   dev_err(>dev, "failed to init chip support\n");
+   goto fail;
+   }
+
if (host->info.init) {
err = host->info.init(host);
if (err)
@@ -132,6 +160,10 @@ static int host1x_probe(struct platform_device *dev)
if (!host->nop_sp)
goto fail;

+   err = host1x_intr_init(>intr, syncpt_irq);
+   if (err)
+   goto fail;
+
host->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(host->clk)) {
dev_err(>dev, "failed to get clock\n");
@@ -145,6 +177,8 @@ static int host1x_probe(struct platform_device *dev)

host1x_syncpt_reset(host);

+   host1x_intr_start(>intr, clk_get_rate(host->clk));
+
host1x = host;

dev_info(>dev, "initialized\n");
@@ -160,6 +194,7 @@ fail:
 static int __exit host1x_remove(struct platform_device *dev)
 {
struct host1x *host = platform_get_drvdata(dev);
+   host1x_intr_deinit(>intr);
host1x_syncpt_deinit(host);
clk_disable_unprepare(host->clk);
return 0;
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 8245e24..a1622bb 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -20,6 +20,7 @@
 #include 

 #include "syncpt.h"
+#include "intr.h"

 struct host1x;
 struct host1x_syncpt;
@@ -36,6 +37,18 @@ struct host1x_syncpt_ops {
const char * (*name)(struct host1x_syncpt *);
 };

+struct host1x_intr_ops {
+   void (*init_host_sync)(struct host1x_intr *);
+   void (*set_host_clocks_per_usec)(
+   struct host1x_intr *, u32 clocks);
+   void (*set_syncpt_threshold)(
+   struct host1x_intr *, u32 id, u32 thresh);
+ 

[PATCHv4 1/8] gpu: host1x: Add host1x driver

2012-12-21 Thread Terje Bergstrom
Add host1x, the driver for host1x and its client unit 2D.

Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/Makefile  |1 +
 drivers/gpu/host1x/Kconfig|6 +
 drivers/gpu/host1x/Makefile   |8 +
 drivers/gpu/host1x/dev.c  |  182 +++
 drivers/gpu/host1x/dev.h  |   79 ++
 drivers/gpu/host1x/hw/Makefile|6 +
 drivers/gpu/host1x/hw/host1x01.c  |   36 +
 drivers/gpu/host1x/hw/host1x01.h  |   25 
 drivers/gpu/host1x/hw/host1x01_hardware.h |   26 
 drivers/gpu/host1x/hw/hw_host1x01_sync.h  |   66 +
 drivers/gpu/host1x/hw/syncpt_hw.c |  146 +++
 drivers/gpu/host1x/syncpt.c   |  227 +
 drivers/gpu/host1x/syncpt.h   |  128 
 drivers/video/Kconfig |2 +
 include/linux/host1x.h|   41 ++
 include/trace/events/host1x.h |   61 
 16 files changed, 1040 insertions(+)
 create mode 100644 drivers/gpu/host1x/Kconfig
 create mode 100644 drivers/gpu/host1x/Makefile
 create mode 100644 drivers/gpu/host1x/dev.c
 create mode 100644 drivers/gpu/host1x/dev.h
 create mode 100644 drivers/gpu/host1x/hw/Makefile
 create mode 100644 drivers/gpu/host1x/hw/host1x01.c
 create mode 100644 drivers/gpu/host1x/hw/host1x01.h
 create mode 100644 drivers/gpu/host1x/hw/host1x01_hardware.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_sync.h
 create mode 100644 drivers/gpu/host1x/hw/syncpt_hw.c
 create mode 100644 drivers/gpu/host1x/syncpt.c
 create mode 100644 drivers/gpu/host1x/syncpt.h
 create mode 100644 include/linux/host1x.h
 create mode 100644 include/trace/events/host1x.h

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index cc92778..7fa2f68 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_TEGRA_HOST1X) += host1x/
 obj-y  += drm/ vga/ stub/
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
new file mode 100644
index 000..e89fb2b
--- /dev/null
+++ b/drivers/gpu/host1x/Kconfig
@@ -0,0 +1,6 @@
+config TEGRA_HOST1X
+   tristate "Tegra host1x driver"
+   help
+ Driver for the Tegra host1x hardware.
+
+ Required for enabling tegradrm.
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
new file mode 100644
index 000..363e6ab
--- /dev/null
+++ b/drivers/gpu/host1x/Makefile
@@ -0,0 +1,8 @@
+ccflags-y = -Idrivers/gpu/host1x
+
+host1x-y = \
+   syncpt.o \
+   dev.o \
+   hw/host1x01.o
+
+obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
new file mode 100644
index 000..b0d630d
--- /dev/null
+++ b/drivers/gpu/host1x/dev.c
@@ -0,0 +1,182 @@
+/*
+ * Tegra host1x driver
+ *
+ * Copyright (c) 2010-2012, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dev.h"
+#include "hw/host1x01.h"
+
+#define CREATE_TRACE_POINTS
+#include 
+
+#define DRIVER_NAME"tegra-host1x"
+
+struct host1x *host1x;
+
+void host1x_syncpt_incr_byid(u32 id)
+{
+   struct host1x_syncpt *sp = host1x->syncpt + id;
+   return host1x_syncpt_incr(sp);
+}
+EXPORT_SYMBOL(host1x_syncpt_incr_byid);
+
+u32 host1x_syncpt_read_byid(u32 id)
+{
+   struct host1x_syncpt *sp = host1x->syncpt + id;
+   return host1x_syncpt_read(sp);
+}
+EXPORT_SYMBOL(host1x_syncpt_read_byid);
+
+void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
+{
+   void __iomem *sync_regs = host1x->regs + host1x->info.sync_offset;
+
+   writel(v, sync_regs + r);
+}
+
+u32 host1x_sync_readl(struct host1x *host1x, u32 r)
+{
+   void __iomem *sync_regs = host1x->regs + host1x->info.sync_offset;
+
+   return readl(sync_regs + r);
+}
+
+static struct host1x_device_info host1x_info = {
+   .nb_channels= 8,
+   .nb_pts = 32,
+   .nb_mlocks  = 16,
+   .nb_bases   = 8,
+   .init   = host1x01_init,
+   .sync_offset= 0x3000,
+};
+
+static struct of_device_id host1x_match[] = {
+   { .compatible = "nvidia,tegra30-host1x", .data = _info, },
+   { .compatible = "nvidia,tegra20-host1x", .data = _info, },
+   { },
+};
+

[PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Terje Bergstrom
This set of patches adds support for Tegra20 and Tegra30 host1x and
2D. It is based on linux-next-20121220.

The fourth version has only few changes compared to previous version:
 * Fixed some sparse warnings
 * Fixed host1x Makefile to allow building as module
 * Fixed host1x module unload
 * Fixed tegradrm unload sequence
 * host1x creates DRM dummy device and tegradrm uses it for storing
   DRM related data.

Some of the issues left open:
 * Register definitions still use static inline. There has been a
   debate about code style versus ability to use compiler type
   checking and code coverage analysis. There was no conclusion, so
   I left it as was.
 * Uses still CMA helpers. IOMMU support will replace CMA with host1x
   specific allocator.

host1x is the driver that controls host1x hardware. It supports
host1x command channels, synchronization, and memory management. It
is sectioned into logical driver under drivers/gpu/host1x and
physical driver under drivers/host1x/hw. The physical driver is
compiled with the hardware headers of the particular host1x version.

The hardware units are described (briefly) in the Tegra2 TRM. Wiki
page https://gitorious.org/linux-tegra-drm/pages/Host1xIntroduction
also contains a short description of the functionality.

The patch set removes responsibility of host1x from tegradrm. At the
same time, it moves all drm related infrastructure in
drivers/gpu/drm/tegra/host1x.c to drm.c. To replace the host1x
central device, host1x creates a dummy device for tegradrm to hang
global data to. This is a break in responsibility split of tegradrm
taking care of DRM and host1x driver taking care of host1x and
clients, but this structure was insisted. I've kept creation of dummy
device as a separate patch to illustrate the alternatives. It can be
later squashed into other patches.

The patch set adds 2D driver to tegradrm, which uses host1x for
communicating with host1x to access sync points and channels. We
expect to use the same infrastructure for other host1x clients, so
we have kept host1x and tegradrm separate.

The patch set also adds user space API to tegradrm for accessing
host1x and 2D.

Arto Merilainen (1):
  drm: tegra: Remove redundant host1x

Terje Bergstrom (7):
  gpu: host1x: Add host1x driver
  gpu: host1x: Add syncpoint wait and interrupts
  gpu: host1x: Add channel support
  gpu: host1x: Add debug support
  ARM: tegra: Add board data and 2D clocks
  drm: tegra: Add gr2d device
  gpu: host1x: Register DRM dummy device

 arch/arm/mach-tegra/board-dt-tegra20.c  |1 +
 arch/arm/mach-tegra/board-dt-tegra30.c  |1 +
 arch/arm/mach-tegra/tegra20_clocks_data.c   |2 +-
 arch/arm/mach-tegra/tegra30_clocks_data.c   |1 +
 drivers/gpu/Makefile|1 +
 drivers/gpu/drm/tegra/Kconfig   |2 +-
 drivers/gpu/drm/tegra/Makefile  |2 +-
 drivers/gpu/drm/tegra/dc.c  |   26 +-
 drivers/gpu/drm/tegra/drm.c |  433 ++-
 drivers/gpu/drm/tegra/drm.h |   72 ++--
 drivers/gpu/drm/tegra/fb.c  |   17 +-
 drivers/gpu/drm/tegra/gr2d.c|  309 ++
 drivers/gpu/drm/tegra/hdmi.c|   30 +-
 drivers/gpu/drm/tegra/host1x.c  |  325 --
 drivers/gpu/host1x/Kconfig  |   28 ++
 drivers/gpu/host1x/Makefile |   17 +
 drivers/gpu/host1x/cdma.c   |  475 
 drivers/gpu/host1x/cdma.h   |  107 +
 drivers/gpu/host1x/channel.c|  137 ++
 drivers/gpu/host1x/channel.h|   64 +++
 drivers/gpu/host1x/cma.c|  117 +
 drivers/gpu/host1x/cma.h|   43 ++
 drivers/gpu/host1x/debug.c  |  207 +
 drivers/gpu/host1x/debug.h  |   49 +++
 drivers/gpu/host1x/dev.c|  242 +++
 drivers/gpu/host1x/dev.h|  167 
 drivers/gpu/host1x/drm.c|   51 +++
 drivers/gpu/host1x/drm.h|   25 ++
 drivers/gpu/host1x/hw/Makefile  |6 +
 drivers/gpu/host1x/hw/cdma_hw.c |  480 +
 drivers/gpu/host1x/hw/cdma_hw.h |   37 ++
 drivers/gpu/host1x/hw/channel_hw.c  |  147 +++
 drivers/gpu/host1x/hw/debug_hw.c|  399 +
 drivers/gpu/host1x/hw/host1x01.c|   46 ++
 drivers/gpu/host1x/hw/host1x01.h|   25 ++
 drivers/gpu/host1x/hw/host1x01_hardware.h   |  150 +++
 drivers/gpu/host1x/hw/hw_host1x01_channel.h |   98 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h|  179 
 drivers/gpu/host1x/hw/hw_host1x01_uclass.h  |  130 ++
 drivers/gpu/host1x/hw/intr_hw.c |  178 
 drivers/gpu/host1x/hw/syncpt_hw.c   |  157 +++
 drivers/gpu/host1x/intr.c   |  377 
 

[PATCH v2 8/8] drm/exynos: cleanup needless parenthesis.

2012-12-21 Thread Eunchul Kim
This patch cleanup needless parenthesis. we got the comment from  GSC.
but we missed fimc side. so, we cleanup the code.

Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 9f52b7f..2c03ffa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1212,7 +1212,7 @@ static int fimc_dst_set_buf_seq(struct fimc_context *ctx, 
u32 buf_id,
}

/* sequence id */
-   cfg &= (~mask);
+   cfg &= ~mask;
cfg |= (enable << buf_id);
fimc_write(cfg, EXYNOS_CIFCNTSEQ);

-- 
1.7.0.4



[PATCH v2 7/8] drm/exynos: fixed unnormal interrupt in m2m operation.

2012-12-21 Thread Eunchul Kim
From: Jinyoung Jeon 

This patch fixed unnormal interrupt at m2m operation sometimes.
m2m operation called s/w reset during every frame.
but m2m occured interrupt after s/w reset sometimes.
so, we cleared dma operation and capture operation.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index a99ceef..9f52b7f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -169,10 +169,23 @@ static void fimc_sw_reset(struct fimc_context *ctx)

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

+   /* stop dma operation */
+   cfg = fimc_read(EXYNOS_CISTATUS);
+   if (EXYNOS_CISTATUS_GET_ENVID_STATUS(cfg)) {
+   cfg = fimc_read(EXYNOS_MSCTRL);
+   cfg &= ~EXYNOS_MSCTRL_ENVID;
+   fimc_write(cfg, EXYNOS_MSCTRL);
+   }
+
cfg = fimc_read(EXYNOS_CISRCFMT);
cfg |= EXYNOS_CISRCFMT_ITU601_8BIT;
fimc_write(cfg, EXYNOS_CISRCFMT);

+   /* disable image capture */
+   cfg = fimc_read(EXYNOS_CIIMGCPT);
+   cfg &= ~(EXYNOS_CIIMGCPT_IMGCPTEN_SC | EXYNOS_CIIMGCPT_IMGCPTEN);
+   fimc_write(cfg, EXYNOS_CIIMGCPT);
+
/* s/w reset */
cfg = fimc_read(EXYNOS_CIGCTRL);
cfg |= (EXYNOS_CIGCTRL_SWRST);
-- 
1.7.0.4



[PATCH v2 6/8] drm/exynos: removed color bar pattern display.

2012-12-21 Thread Eunchul Kim
From: JoongMock Shin 

This patch removed color bar pattern register. we not use color bar
any more. and don't support color bar at writeback operation.

Signed-off-by: JoongMock Shin 
Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 8cfc5a9..a99ceef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -163,17 +163,14 @@ struct fimc_context {
boolsuspended;
 };

-static void fimc_sw_reset(struct fimc_context *ctx, bool pattern)
+static void fimc_sw_reset(struct fimc_context *ctx)
 {
u32 cfg;

-   DRM_DEBUG_KMS("%s:pattern[%d]\n", __func__, pattern);
+   DRM_DEBUG_KMS("%s\n", __func__);

cfg = fimc_read(EXYNOS_CISRCFMT);
cfg |= EXYNOS_CISRCFMT_ITU601_8BIT;
-   if (pattern)
-   cfg |= EXYNOS_CIGCTRL_TESTPATTERN_COLOR_BAR;
-
fimc_write(cfg, EXYNOS_CISRCFMT);

/* s/w reset */
@@ -1536,7 +1533,7 @@ static int fimc_ippdrv_reset(struct device *dev)
DRM_DEBUG_KMS("%s\n", __func__);

/* reset h/w block */
-   fimc_sw_reset(ctx, false);
+   fimc_sw_reset(ctx);

/* reset scaler capability */
memset(>sc, 0x0, sizeof(ctx->sc));
-- 
1.7.0.4



[PATCH v2 5/8] drm/exynos: cleanup comment of abbreviation.

2012-12-21 Thread Eunchul Kim
This patch cleanup comment of abbreviation.

Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c  |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index abfff9e..8cfc5a9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -25,7 +25,7 @@
 #include "exynos_drm_fimc.h"

 /*
- * FIMC is stand for Fully Interactive Mobile Camera and
+ * FIMC stands 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.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 410175a..509f2f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -25,7 +25,7 @@
 #include "exynos_drm_gsc.h"

 /*
- * GSC is stand for General SCaler and
+ * GSC stands 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 memory.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index cac94fe..63bcf92 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -27,7 +27,7 @@
 #include "exynos_drm_iommu.h"

 /*
- * IPP is stand for Image Post Processing and
+ * IPP stands for Image Post Processing and
  * supports image scaler/rotator and input/output DMA operations.
  * using FIMC, GSC, Rotator, so on.
  * IPP is integration device driver of same attribute h/w
-- 
1.7.0.4



[PATCH v2 4/8] drm/exynos: fixed warnning in GSC build.

2012-12-21 Thread Eunchul Kim
This patch fixed warnning in GSC build.

Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 3e5b456..410175a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1592,7 +1592,7 @@ static int gsc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
exynos_drm_ippnb_send_event(IPP_SET_WRITEBACK, (void *)_wb);

/* src local path */
-   cfg = readl(GSC_IN_CON);
+   cfg = gsc_read(GSC_IN_CON);
cfg &= ~(GSC_IN_PATH_MASK | GSC_IN_LOCAL_SEL_MASK);
cfg |= (GSC_IN_PATH_LOCAL | GSC_IN_LOCAL_FIMD_WB);
gsc_write(cfg, GSC_IN_CON);
-- 
1.7.0.4



[PATCH v2 3/8] drm/exynos: fixed vflip, hflip case at the same time.

2012-12-21 Thread Eunchul Kim
Changelog v2:
This patch added EXYNOS_DRM_FLIP_BOTH enum value for warnning.

Changelog v1:
This patch fixed vflip, hflip at the same time. If we want to change 180 degree 
about buffer,
then we can use h,vflip or 180 degree. we supports 180 degree using h,vflip.
but we make error handling in this case. so, fixed it.

Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |1 +
 include/uapi/drm/exynos_drm.h   |2 ++
 4 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 5dc0251..abfff9e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1387,6 +1387,7 @@ static inline bool fimc_check_drm_flip(enum 
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
+   case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index ba5fefd..3e5b456 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1391,7 +1391,7 @@ static inline bool gsc_check_drm_flip(enum 
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
-   case EXYNOS_DRM_FLIP_VERTICAL | EXYNOS_DRM_FLIP_HORIZONTAL:
+   case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 17e4474..8bf9c50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -513,6 +513,7 @@ static inline bool rotator_check_drm_flip(enum 
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
+   case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index e7f52c3..7ed11b2 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -185,6 +185,8 @@ enum drm_exynos_flip {
EXYNOS_DRM_FLIP_NONE = (0 << 0),
EXYNOS_DRM_FLIP_VERTICAL = (1 << 0),
EXYNOS_DRM_FLIP_HORIZONTAL = (1 << 1),
+   EXYNOS_DRM_FLIP_BOTH = EXYNOS_DRM_FLIP_VERTICAL |
+   EXYNOS_DRM_FLIP_HORIZONTAL,
 };

 enum drm_exynos_degree {
-- 
1.7.0.4



[PATCH v2 2/8] drm/exynos: removed needless error handling about property.

2012-12-21 Thread Eunchul Kim
This patch removed property error handling. property couldn't be NULL.
so, I removed it.

Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |   12 
 drivers/gpu/drm/exynos/exynos_drm_gsc.c  |   12 
 drivers/gpu/drm/exynos/exynos_drm_ipp.c  |5 -
 3 files changed, 0 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 7a3e460..5dc0251 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -705,10 +705,6 @@ static int fimc_src_set_addr(struct device *dev,
}

property = _node->property;
-   if (!property) {
-   DRM_ERROR("failed to get property.\n");
-   return -EINVAL;
-   }

DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1241,10 +1237,6 @@ static int fimc_dst_set_addr(struct device *dev,
}

property = _node->property;
-   if (!property) {
-   DRM_ERROR("failed to get property.\n");
-   return -EINVAL;
-   }

DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1573,10 +1565,6 @@ static int fimc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
}

property = _node->property;
-   if (!property) {
-   DRM_ERROR("failed to get property.\n");
-   return -EINVAL;
-   }

fimc_handle_irq(ctx, true, false, true);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index c443c3b..ba5fefd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -720,10 +720,6 @@ static int gsc_src_set_addr(struct device *dev,
}

property = _node->property;
-   if (!property) {
-   DRM_ERROR("failed to get property.\n");
-   return -EFAULT;
-   }

DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1180,10 +1176,6 @@ static int gsc_dst_set_addr(struct device *dev,
}

property = _node->property;
-   if (!property) {
-   DRM_ERROR("failed to get property.\n");
-   return -EFAULT;
-   }

DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1565,10 +1557,6 @@ static int gsc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
}

property = _node->property;
-   if (!property) {
-   DRM_ERROR("failed to get property.\n");
-   return -EINVAL;
-   }

gsc_handle_irq(ctx, true, false, true);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index ba45f9a..cac94fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1487,11 +1487,6 @@ void ipp_sched_cmd(struct work_struct *work)
mutex_lock(_node->cmd_lock);

property = _node->property;
-   if (!property) {
-   DRM_ERROR("failed to get property:prop_id[%d]\n",
-   c_node->property.prop_id);
-   goto err_unlock;
-   }

switch (cmd_work->ctrl) {
case IPP_CTRL_PLAY:
-- 
1.7.0.4



[PATCH v2 1/8] drm/exynos: cleanup current command name.

2012-12-21 Thread Eunchul Kim
This patch changed current command name from cmd to c_node.
because we already use cmd for command control ioctl in another structure.
so, this name make some confusion.

Signed-off-by: Eunchul Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|8 
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |8 
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |4 ++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +-
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 61ea242..7a3e460 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -695,7 +695,7 @@ static int fimc_src_set_addr(struct device *dev,
 {
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;

@@ -1231,7 +1231,7 @@ static int fimc_dst_set_addr(struct device *dev,
 {
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;

@@ -1317,7 +1317,7 @@ static irqreturn_t fimc_irq_handler(int irq, void *dev_id)
 {
struct fimc_context *ctx = dev_id;
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_event_work *event_work =
c_node->event_work;
int buf_id;
@@ -1557,7 +1557,7 @@ static int fimc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
 {
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
struct drm_exynos_pos   img_pos[EXYNOS_DRM_OPS_MAX];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5639353..c443c3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -711,7 +711,7 @@ static int gsc_src_set_addr(struct device *dev,
 {
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;

if (!c_node) {
@@ -1171,7 +1171,7 @@ static int gsc_dst_set_addr(struct device *dev,
 {
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;

if (!c_node) {
@@ -1312,7 +1312,7 @@ static irqreturn_t gsc_irq_handler(int irq, void *dev_id)
 {
struct gsc_context *ctx = dev_id;
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_event_work *event_work =
c_node->event_work;
u32 status;
@@ -1549,7 +1549,7 @@ static int gsc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
 {
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
struct drm_exynos_pos   img_pos[EXYNOS_DRM_OPS_MAX];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 49eebe9..ba45f9a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1292,7 +1292,7 @@ static int ipp_start_property(struct exynos_drm_ippdrv 
*ippdrv,
DRM_DEBUG_KMS("%s:prop_id[%d]\n", __func__, property->prop_id);

/* store command info in ippdrv */
-   ippdrv->cmd = c_node;
+   ippdrv->c_node = c_node;

if (!ipp_check_mem_list(c_node)) {
DRM_DEBUG_KMS("%s:empty memory.\n", __func__);
@@ -1303,7 

[PATCH v2 0/8] drm/exynos: fixed and cleanup ipp subsystem drivers

2012-12-21 Thread Eunchul Kim
Hi All.

This patch set fixed some issue and cleanup code.
please check my commit and let me know about your comment.

Changelog v2:
- This patch set fixes the following:
 * fixed vflip, hflip case at the same time: we use vflip, hflip set at the 
same time for 180 degree supporting.
so, we added FLIP_BOTH for fixing warnning.

Changelog v1:
- This patch set fixes the following:
 * fixed vflip, hflip case at the same time: we use vflip, hflip set at the 
same time for 180 degree supporting.
so, we added this case.
 * fixed warnning in GSC build: we don't use directly readl, but this code 
remained. so, we changed it.
 * fixed unnormal interrupt in m2m operation : m2m operation called reset 
function at every time. but we don't disable dma start.
so, we added dma stop and capture stop operation.

- And code clean like bellow:
 * cleanup current command name : we use 'cmd' in property structure and so on.
so, this naming make some confusion. we changed 'cmd' to 'c_node' for avoid 
confusion.
 * removed error handling about property : property could't be NULL. so, we 
removed error handling about NULL.
 * cleanup comment of abbreviation : we changed comments for right grammar.
 * cleanup needless parenthesis : we missed changing of fimc side. so, I added 
it.
 * removed color bar pattern display : we don't use color display at writeback. 
so, removed it.

Thank's
BR
Eunchul Kim

Eunchul Kim (6):
  drm/exynos: cleanup current command name.
  drm/exynos: removed needless error handling about property.
  drm/exynos: fixed vflip, hflip case at the same time.
  drm/exynos: fixed warnning in GSC build.
  drm/exynos: cleanup comment of abbreviation.
  drm/exynos: cleanup needless parenthesis.

Jinyoung Jeon (1):
  drm/exynos: fixed unnormal interrupt in m2m operation.

JoongMock Shin (1):
  drm/exynos: removed color bar pattern display.

 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   47 +--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   26 ---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   13 ++-
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |4 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |3 +-
 include/uapi/drm/exynos_drm.h   |2 +
 6 files changed, 40 insertions(+), 55 deletions(-)



i-g-t test for gem flink race

2012-12-21 Thread Dave Airlie
On Fri, Dec 21, 2012 at 11:49 AM, Dave Airlie  wrote:
> As we talked on irc, I decided to write a test case and it actually
> seems to trigger the race.
>
> Really its insane userspace behaviour and I'm not really sure we
> should care to fix, I can't see it causing an oops, more userspace
> does something insane, it gets a bad result, but I'll contemplate it a
> bit more.

Yeah after considering this a bit more, I really think its just a
userspace problem, don''t go closing gem object handles that other
threads could be using. Lets state any result after doing something
like that is undefined, and the current behaviour is within spec.

Dave.


[RFC] drm/exynos: added hdcp driver for contents protection.

2012-12-21 Thread Alan Cox
On Fri, 21 Dec 2012 18:47:57 +0900
Eunchul Kim  wrote:

> HDCP stands for High-bandwidth Digital Content Protection.
> This is a newer form of Digital Rights Management(secure DRM)

was.. the master key was leaked long ago 8)

> that was designed to control digital video and audio content.
> Contains an integrated HDCP encryption engine for video/audio content 
> protection.
> supports version HDCP v1.1.
> Exynos AP supports embedded HDCP key system.
> The HDCP key value is fused during fabrication, based on customer's request.

For this code to go into the kernel it must do so in GPL form. Can you
confirm Samsung has the necessary IPR and permissions to grant use of
this to all third parties as the GPL requires not just to specific
customers ? (whether they can use it usefully is a different question as
obviously they need the key.

I ask this because there are currently a lot of lawyers busy trying to
sue makers of some HDCP aware devices.

> +
> + dev_info(dev, "drm hdcp registered successfully.\n");

This sort of stuff ought to be dev_dbg, minor item


> diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h 
> b/drivers/gpu/drm/exynos/exynos_hdcp.h
> new file mode 100644
> index 000..86d0c79
> --- /dev/null
> +++ b/drivers/gpu/drm/exynos/exynos_hdcp.h
> @@ -0,0 +1,47 @@
> +/*
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + *
> + * Authors:
> + *   Eunchul Kim 
> + *
> + * 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, sublicense,
> + * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
> + * VA LINUX SYSTEMS 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.
> + */


Two things strike me here - firstly kernel code is GPLv2 or later (or
dual licensed) as per the Signed-off-by: certification. I don't see any
problem in the above but to be sure you realise.

Secondly - VA Linux systems ??? has this been copied from some random
file and not updated correctly or does the old VA Linux Systems really
own bits of this code.

Other questions I'll look at later - in particular
- I don't see how the work queue is locked against the main thread of
  execution within the driver
- There is a general DRI question here about HDCP and interfaces -
  several out of tree drivers do HDCP and perhaps a common API would be
  sensible ?

Alan


i-g-t test for gem flink race

2012-12-21 Thread Dave Airlie
As we talked on irc, I decided to write a test case and it actually
seems to trigger the race.

Really its insane userspace behaviour and I'm not really sure we
should care to fix, I can't see it causing an oops, more userspace
does something insane, it gets a bad result, but I'll contemplate it a
bit more.

http://cgit.freedesktop.org/~airlied/intel-gpu-tools/commit/?h=prime=2e7433f87b337116ab848c12b05a1a05891640df

is the current test, it fails for me here usually once in
100,000->200,000 cycles.

Dave.


[pull] radeon drm-fixes-3.8

2012-12-21 Thread Alex Deucher
One more patch I just pushed:


commit 668bbc81baf0f34df832d8aca5c7d5e19a493c68
Author: Alex Deucher 
Date:   Thu Dec 20 21:19:32 2012 -0500

drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

It's used in a recent mesa commit:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
and there may be some other cases in the future where it's required.

Signed-off-by: Alex Deucher 
Reviewed-by: Jerome Glisse 
Cc: stable at vger.kernel.org


On Thu, Dec 20, 2012 at 6:39 PM,   wrote:
> From: Alex Deucher 
>
> Hi Dave,
>
>   Just a few fixes from the last week or so.
>
> Alex
>
> The following changes since commit 0953e76e91f4b6206cef50bd680696dc6bf1ef99:
>
>   drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling 
> (2012-12-20 07:46:20 +1000)
>
> are available in the git repository at:
>   git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8
>
> Jerome Glisse (4):
>   drm/radeon: don't leave fence blocked process on failed GPU reset
>   drm/radeon: avoid deadlock in pm path when waiting for fence
>   drm/radeon: restore modeset late in GPU reset path
>   drm/radeon: add support for MEM_WRITE packet
>
>  drivers/gpu/drm/radeon/evergreen_cs.c  |   29 +++
>  drivers/gpu/drm/radeon/r600_cs.c   |   29 +++
>  drivers/gpu/drm/radeon/radeon.h|3 +-
>  drivers/gpu/drm/radeon/radeon_device.c |   17 +--
>  drivers/gpu/drm/radeon/radeon_drv.c|3 +-
>  drivers/gpu/drm/radeon/radeon_fence.c  |   49 +--
>  drivers/gpu/drm/radeon/radeon_pm.c |   15 --
>  7 files changed, 121 insertions(+), 24 deletions(-)


[RFC v2 0/5] Common Display Framework

2012-12-21 Thread Tomasz Figa
Hi Vikas,

On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
>  Hi Laurent,
> 
> Thanks for the reply.
> 
> On 17 December 2012 20:55, Laurent Pinchart <
> 
> laurent.pinchart at ideasonboard.com> wrote:
> > Hi Vikas,
> > 
> > Sorry for the late reply. I now have more time to work on CDF, so
> > delays should be much shorter.
> > 
> > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > > Hi Laurent,
> > > 
> > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what
> > > I
> > 
> > found
> > 
> > > is that, the exynos display controller is MIPI DSI based controller.
> > > 
> > > But if I look at CDF patches, it has only support for MIPI DBI based
> > 
> > Display
> > 
> > > controller.
> > > 
> > > So my question is, do we have any generic framework for MIPI DSI
> > > based
> > > display controller? basically I wanted to know, how to go about
> > > porting
> > 
> > CDF
> > 
> > > for such kind of display controller.
> > 
> > MIPI DSI support is not available yet. The only reason for that is
> > that I don't have any MIPI DSI hardware to write and test the code
> > with :-)
> > 
> > The common display framework should definitely support MIPI DSI. I
> > think the
> > existing MIPI DBI code could be used as a base, so the implementation
> > shouldn't be too high.
> > 
> > Yeah, i was also thinking in similar lines, below is my though for
> > MIPI
> 
> DSI support in CDF.
> 
> o   MIPI DSI support as part of CDF framework will expose
> 
> ?  mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c
> file )
> 
> ?  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from
> platform specific init driver call )
> 
> ?bus ops will be
> 
> o   read data
> 
> o   write data
> 
> o   write command
> 
> ?  MIPI DSI will be registered as bus_register()
> 
> When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
> initialize the MIPI DSI HW IP.
> 
>  This probe will also parse the DT file for MIPI DSI based panel, add
> the panel device (device_add() ) to kernel and register the display
> entity with its control and  video ops with CDF.
> 
> I can give this a try.

I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 
LCD driver to use the v2 RFC of Common Display Framework. I have most of 
the work done, I have just to solve several remaining problems.

Best regards,
-- 
Tomasz Figa
Samsung Poland R Center
SW Solution Development, Linux Platform



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

2012-12-21 Thread Arto Merilainen
On 12/20/2012 07:14 PM, Stephen Warren wrote:
>
> What's wrong with just having each device ask the host1x (its parent)
> for a pointer to the (dummy) tegradrm device. That seems extremely
>

We are talking about creating a dummy device because:
- we need to give something for drm_platform_init(),
- drm related data should be stored somewhere,
- some data must be passed to all driver probe() functions. This is not 
hw-related data, but just some lists that are used to ensure that all 
drivers have been initialised before calling drm_platform_init().

All these issues are purely tegra-drm related and solving them elsewhere 
(in host1x) would be just wrong! host1x would not even use the dummy 
device for anything so creating it there seems bizarre.

- Arto


[PATCH] drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

2012-12-21 Thread Jerome Glisse
On Thu, Dec 20, 2012 at 9:34 PM,   wrote:
> From: Alex Deucher 
>
> It's used in a recent mesa commit:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
> and there may be some other cases in the future where it's required.
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

Reviewed-by: Jerome Glisse 

> ---
>  drivers/gpu/drm/radeon/evergreen_cs.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 5cea852..7a44566 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -3316,6 +3316,7 @@ static bool evergreen_vm_reg_valid(u32 reg)
>
> /* check config regs */
> switch (reg) {
> +   case WAIT_UNTIL:
> case GRBM_GFX_INDEX:
> case CP_STRMOUT_CNTL:
> case CP_COHER_CNTL:
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


Bisected regression on RV610

2012-12-21 Thread Pavel Roskin
Hello!

The system running the current mainline Linux shows black screen for  
me reliably if I run the unshield program on xterm.  Linux 3.7 is OK.

The bisection found the first bad commit:

deab48f140d28d788cb2b5705761a92b02e3440d
Alex Deucher 

 drm/radeon: add dma engine support for vm pt updates on si (v2)

 Async DMA has a special packet for contiguous pt updates
 which saves overhead.

 v2: rebase

It can be reverted on top on the mainline Linux, but I still get the  
black screen.  I guess it's the first commit that is bad for my video  
card, but not the only one.

While bisecting, I noticed another manifestation of the problem -  
unshield would hang for a few seconds and continue.  Following appears  
in the kernel log:

[   31.476089] radeon :01:00.0: GPU lockup CP stall for more than  
1msec
[   31.476094] radeon :01:00.0: GPU lockup (waiting for  
0x0006 last fence id 0x0005)

# lspci -vnn -s 01:00.0
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV610  
video device [Radeon HD 2400 PRO] [1002:94c3] (prog-if 00 [VGA  
controller])
 Subsystem: ASUSTeK Computer Inc. Device [1043:01c2]
 Flags: bus master, fast devsel, latency 0, IRQ 46
 Memory at e000 (64-bit, prefetchable) [size=256M]
 Memory at f500 (64-bit, non-prefetchable) [size=64K]
 I/O ports at b000 [size=256]
 [virtual] Expansion ROM at f400 [disabled] [size=128K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001  
Rev=1 Len=010 
 Kernel driver in use: radeon

The kernel .config file is attached.

-- 
Regards,
Pavel Roskin

-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.7.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set

System freezes with radeon DRM driver since kernel 3.6

2012-12-21 Thread Alex Deucher
On Fri, Dec 21, 2012 at 10:14 AM, Stephan Seitz
 wrote:
> On Fri, Dec 21, 2012 at 09:30:39AM -0500, Alex Deucher wrote:
>>
>> On Thu, Dec 20, 2012 at 5:09 AM, Stephan Seitz
>>  wrote:
>>>
>>> filename: /lib/modules/3.7.0-Dom0/kernel/drivers/gpu/drm/radeon/radeon.ko
>>>
>>> hardware:
>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
>>> RV730XT [Radeon HD 4670] (prog-if 00 [VGA controller])
>>> Subsystem: Hightech Information System Ltd. Device 2003
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr-
>>> Stepping- SERR- FastB2B- DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> SERR- >> Latency: 0, Cache Line Size: 32 bytes
>>> Interrupt: pin A routed to IRQ 11
>>> Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
>>> Region 2: Memory at e500 (64-bit, non-prefetchable)
>>> [size=64K]
>>> Region 4: I/O ports at b000 [size=256]
>>> [virtual] Expansion ROM at e400 [disabled] [size=128K]
>>> Capabilities: 
>>>
>>> 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI
>>> Audio [Radeon HD 4000 series]
>>> Subsystem: Hightech Information System Ltd. Device aa38
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr-
>>> Stepping- SERR- FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> SERR- >> Latency: 0, Cache Line Size: 32 bytes
>>> Interrupt: pin B routed to IRQ 63
>>> Region 0: Memory at e501 (64-bit, non-prefetchable)
>>> [size=16K]
>>> Capabilities: 
>>> Kernel driver in use: snd_hda_intel
>>>
>>> My system is debian testing with self-made kernels. The system is working
>>> as
>>> Dom0 under Xen 4.1.
>>>
>>> Since kernel 3.6 the drm radeon driver freezes the system after some
>>> time.
>>> This time can be 10 minutes or some hours. Since the system is completely
>>> frozen I don?t know if there are error messages displayed, but the log
>>> contains nothing. Simply pressing the reset switch won?t reset the
>>> graphic
>>> card (no output), I have to switch off the system to get the card working
>>> again.
>>
>>
>> Did you also change the userspace drivers (mesa, xf86-video-ati)?  If
>
>
> This system is a console system, X is only used sometimes. So while there
> may be updates of other components (it is Debian testing after all) the
> problem occurs in console mode without running X or mesa.
> And rebooting the old 3.5 kernel solves the problem.
>
>> you only changed the kernel version, can you bisect?  If you updated
>
>
> Not without some help,. I?m no programmer. You probably mean I should test
> different git commits?

Git provides a a bisect option that allows you to track down when a
problem was introduced.  You'll need a copy of the kernel git tree.
You can follow a tutorial like this one:
http://www.landley.net/writing/git-bisect-howto.html
git will bisect the tree picking commits for you to try.  You
basically build, install, and test the commit git bisect picks for
you.  If it works, you report it to get by saying 'git bisect good',
if it's bad, you tell git by saying 'git bisect bad' after you report,
git will pick another commit and you continue until the problematic
commit has been identified.

Alex


[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset

2012-12-21 Thread Paul Bolle
On Thu, 2012-12-20 at 13:37 -0500, Alex Deucher wrote:
> On Tue, Dec 18, 2012 at 12:28 PM, Paul Bolle  wrote:
> > On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote:
> >> On Tue, Dec 18, 2012 at 5:36 AM, Christian K?nig
> >>  wrote:
> >> > You should definitely try Alex latest drm-fixes-3.8 branch
> >> > (git://people.freedesktop.org/~agd5f/linux) since the possibility is 
> >> > quite
> >> > high that we already have fixed that bug. If that doesn't helps then 
> >> > please
> >> > open a bug report and leave me a note so that I can investigate further.
> >>
> >> I don't have a 3.8 fixes branch up just yet, but will soon.
> >
> > I see. I'll watch that repository, but I would appreciate it if you
> > notify me if that branch pops up.
> 
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.8

Thanks.

I tried drm-fixes-3.8, at commit
4613ca14b9739428abb53bef9cd0f8b3fee23a95 ("drm/radeon: add support for
MEM_WRITE packet"), on top of v3.7. It hangs in the exact same way.

Christian, were should I open a bug, and under which component, etc.?


Paul Bolle



System freezes with radeon DRM driver since kernel 3.6

2012-12-21 Thread Alex Deucher
On Thu, Dec 20, 2012 at 5:09 AM, Stephan Seitz
 wrote:
> Hi!
>
> filename: /lib/modules/3.7.0-Dom0/kernel/drivers/gpu/drm/radeon/radeon.ko
>
> hardware:
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
> RV730XT [Radeon HD 4670] (prog-if 00 [VGA controller])
> Subsystem: Hightech Information System Ltd. Device 2003
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
> Region 2: Memory at e500 (64-bit, non-prefetchable) [size=64K]
> Region 4: I/O ports at b000 [size=256]
> [virtual] Expansion ROM at e400 [disabled] [size=128K]
> Capabilities: 
>
> 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI
> Audio [Radeon HD 4000 series]
> Subsystem: Hightech Information System Ltd. Device aa38
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin B routed to IRQ 63
> Region 0: Memory at e501 (64-bit, non-prefetchable) [size=16K]
> Capabilities: 
> Kernel driver in use: snd_hda_intel
>
> My system is debian testing with self-made kernels. The system is working as
> Dom0 under Xen 4.1.
>
> Since kernel 3.6 the drm radeon driver freezes the system after some time.
> This time can be 10 minutes or some hours. Since the system is completely
> frozen I don?t know if there are error messages displayed, but the log
> contains nothing. Simply pressing the reset switch won?t reset the graphic
> card (no output), I have to switch off the system to get the card working
> again.

Did you also change the userspace drivers (mesa, xf86-video-ati)?  If
you only changed the kernel version, can you bisect?  If you updated
multiple components, can you sort out which one caused the issue?

Alex


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

2012-12-21 Thread Terje Bergström
On 21.12.2012 00:28, Stephen Warren wrote:
> On 12/20/2012 02:34 PM, Terje Bergstr?m wrote:
>> On 20.12.2012 22:30, Thierry Reding wrote:
>>> The problem with your proposed solution is that, even any of Stephen's
>>> valid objections aside, it won't work. Once the tegra-drm module is
>>> unloaded, the driver's data will be left in the current state and the
>>> link to the dummy device will be lost.
>>
>> The dummy device is created by tegradrm's module init, because it's used
> 
> No, the tegradrm driver object might be registered by tegradrm's module
> init, but the dummy tegradrm platform device would need to be
> created/registered by host1x's probe. Otherwise, the device would get
> created even if there was no host1x/... in the system (disabled for some
> reason, multi-SoC kernel, ...)

Oh. I was all the time thinking that dummy device needs to be created by
tegradrm, because it's only used by tegradrm.  But as we're mixing the
responsibilities, we might then just as well go all the way.

Terje


drivers/gpu/drm/i915/intel_display.c:1536:3: error: 'value' undeclared

2012-12-21 Thread kbuild test robot
tree:   git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
head:   e03a89ed11fc77b78135ae473725fbfa876c1d95
commit: b3d6da16e97f181bca681e486adfcc6632bae2de Merge remote-tracking branch 
'origin/drm-intel-fixes' into drm-intel-nightly
date:   16 minutes ago
config: make ARCH=i386 allyesconfig

All error/warnings:

drivers/gpu/drm/i915/intel_display.c: In function 'intel_sbi_read':
drivers/gpu/drm/i915/intel_display.c:1536:3: error: 'value' undeclared (first 
use in this function)
drivers/gpu/drm/i915/intel_display.c:1536:3: note: each undeclared identifier 
is reported only once for each function it appears in

vim +/value +1536 drivers/gpu/drm/i915/intel_display.c

09153000 Daniel Vetter  2012-12-12  1530return 0;
a416edef Eugeni Dodonov 2012-05-09  1531}
a416edef Eugeni Dodonov 2012-05-09  1532  
988d6ee8 Paulo Zanoni   2012-12-01  1533I915_WRITE(SBI_ADDR, (reg << 
16));
988d6ee8 Paulo Zanoni   2012-12-01  1534  
988d6ee8 Paulo Zanoni   2012-12-01  1535if (destination == SBI_ICLK)
988d6ee8 Paulo Zanoni   2012-12-01 @1536value = 
SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRRD;
988d6ee8 Paulo Zanoni   2012-12-01  1537else
988d6ee8 Paulo Zanoni   2012-12-01  1538value = 
SBI_CTL_DEST_MPHY | SBI_CTL_OP_IORD;
988d6ee8 Paulo Zanoni   2012-12-01  1539I915_WRITE(SBI_CTL_STAT, value 
| SBI_BUSY);

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation


[pull] drm-intel-fixes

2012-12-21 Thread Daniel Vetter
Hi Dave

Some fixes for 3.8:
- Watermark fixups from Chris Wilson (4 pieces).
- 2 snb workarounds, seem to be recently added to our internal DB.
- workaround for the infamous i830/i845 hang, seems now finally solid!
  Based on Chris' fix for SNA, now also for UXA/mesa SNA.
- Some more fixlets for shrinker-pulls-the-rug issues (Chris).
- Fix dma-buf flags when exporting (you).
- Disable the VGA plane if it's enabled on lid open - similar fix in
  spirit to the one I've sent you last weeek, BIOS' really like to mess
  with the display when closing the lid (awesome debug work from Krzysztof
  Mazur).

There's some fallout in the sprite code that Chris discovered which is
still pending, but the big issue there seems to be our utter lack in
automated yuv plane testing :(

Cheers, Daniel

PS: Also had some new ideas about the ilk disaster, test patch is attached
to the bug ...

The following changes since commit 20652097dadd9a7fb4d652f25466299974bc78f9:

  drm/i915: Fix missed needs_dmar setting (2012-12-13 21:40:24 +0100)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to da494d7ca5e0a1afca3480826b5060e15c951e80:

  drm/i915: disable shrinker lock stealing for create_mmap_offset (2012-12-20 
14:57:35 +0100)


Chris Wilson (6):
  drm/i915: Fixup cursor latency used for IVB lp3 watermarks
  drm/i915: Double the cursor self-refresh latency on Valleyview
  drm/i915: Clear self-refresh watermarks when disabled
  drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM 
computations
  drm: Export routines for inserting preallocated nodes into the mm manager
  drm/i915: Preallocate the drm_mm_node prior to manipulating the GTT 
drm_mm manager

Daniel Vetter (6):
  drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
  drm/i915: Implement WaSetupGtModeTdRowDispatch
  drm/i915: Implement workaround for broken CS tlb on i830/845
  drm/i915: don't disable disconnected outputs
  drm/i915: optionally disable shrinker lock stealing
  drm/i915: disable shrinker lock stealing for create_mmap_offset

Dave Airlie (1):
  drm/i915: fix flags in dma buf exporting

Krzysztof Mazur (1):
  i915: ensure that VGA plane is disabled

 drivers/gpu/drm/drm_mm.c   |   41 ---
 drivers/gpu/drm/i915/i915_dma.c|3 +
 drivers/gpu/drm/i915/i915_drv.h|8 ++
 drivers/gpu/drm/i915/i915_gem.c|   77 +++--
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +
 drivers/gpu/drm/i915/i915_irq.c|   12 +++
 drivers/gpu/drm/i915/i915_reg.h|4 +-
 drivers/gpu/drm/i915/intel_display.c   |   23 +++-
 drivers/gpu/drm/i915/intel_pm.c|  160 
 drivers/gpu/drm/i915/intel_ringbuffer.c|   76 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h|1 +
 include/drm/drm_mm.h   |   25 -
 include/uapi/drm/i915_drm.h|   10 ++
 14 files changed, 356 insertions(+), 88 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

2012-12-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=58372

--- Comment #8 from Alex Deucher  ---
(In reply to comment #7)
> Created attachment 71883 [details]
> dmesg with drm-fixes-3.8
> 
> The dmesg message changed after merging in drm-fixes-3.8:
> 
> [drm:evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS

That's a different bug.  Please file a new one for that.  what you are seeing
is due to a change in mesa:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a

-- 
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/20121221/0158bc70/attachment.html>


[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

2012-12-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=58372

--- Comment #7 from Serkan Hosca  ---
Created attachment 71883
  --> https://bugs.freedesktop.org/attachment.cgi?id=71883=edit
dmesg with drm-fixes-3.8

The dmesg message changed after merging in drm-fixes-3.8:

[drm:evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS

-- 
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/20121221/65d27697/attachment.html>


[PATCH] drm/exynos: fix erroneous register read

2012-12-21 Thread Inki Dae
This patch fixes erroneous register read.

readl function needs register base address + offset but
exynos_drm_gsc module used only offset to read a register.

So this patch uses gsc_read function instead of readl.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5639353..bd42542 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1604,7 +1604,7 @@ static int gsc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
exynos_drm_ippnb_send_event(IPP_SET_WRITEBACK, (void *)set_wb);
 
/* src local path */
-   cfg = readl(GSC_IN_CON);
+   cfg = gsc_read(GSC_IN_CON);
cfg = ~(GSC_IN_PATH_MASK | GSC_IN_LOCAL_SEL_MASK);
cfg |= (GSC_IN_PATH_LOCAL | GSC_IN_LOCAL_FIMD_WB);
gsc_write(cfg, GSC_IN_CON);
-- 
1.7.4.1

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


[PATCH] drm/exynos: consider no iommu support to console framebuffer

2012-12-21 Thread Inki Dae
This patch considers no iommu support to kernel space mapping
of console framebuffer.

Without iommu, we get physical address instead of device address
after dma_alloc_attrs function is called. So we should consider
the case without iommu when it maps console framebuffer with
kernel space.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index f433eb7..ae0607f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -34,6 +34,7 @@
 #include exynos_drm_drv.h
 #include exynos_drm_fb.h
 #include exynos_drm_gem.h
+#include exynos_drm_iommu.h
 
 #define MAX_CONNECTOR  4
 #define PREFERRED_BPP  32
@@ -111,9 +112,18 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
 
/* map pages with kernel virtual space. */
if (!buffer-kvaddr) {
-   unsigned int nr_pages = buffer-size  PAGE_SHIFT;
-   buffer-kvaddr = vmap(buffer-pages, nr_pages, VM_MAP,
+   if (is_drm_iommu_supported(dev)) {
+   unsigned int nr_pages = buffer-size  PAGE_SHIFT;
+
+   buffer-kvaddr = vmap(buffer-pages, nr_pages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
+   } else {
+   phys_addr_t dma_addr = buffer-dma_addr;
+   if (dma_addr)
+   buffer-kvaddr = phys_to_virt(dma_addr);
+   else
+   buffer-kvaddr = (void __iomem *)NULL;
+   }
if (!buffer-kvaddr) {
DRM_ERROR(failed to map pages to kernel space.\n);
return -EIO;
@@ -128,8 +138,12 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
 
dev-mode_config.fb_base = (resource_size_t)buffer-dma_addr;
fbi-screen_base = buffer-kvaddr + offset;
-   fbi-fix.smem_start = (unsigned long)
+   if (is_drm_iommu_supported(dev))
+   fbi-fix.smem_start = (unsigned long)
(page_to_phys(sg_page(buffer-sgt-sgl)) + offset);
+   else
+   fbi-fix.smem_start = (unsigned long)buffer-dma_addr;
+
fbi-screen_size = size;
fbi-fix.smem_len = size;
 
-- 
1.7.4.1

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


Re: [PATCH] [RFC] drm/radeon: return 0 on successful gpu reset

2012-12-21 Thread Paul Bolle
On Thu, 2012-12-20 at 13:37 -0500, Alex Deucher wrote:
 On Tue, Dec 18, 2012 at 12:28 PM, Paul Bolle pebo...@tiscali.nl wrote:
  On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote:
  On Tue, Dec 18, 2012 at 5:36 AM, Christian König
  deathsim...@vodafone.de wrote:
   You should definitely try Alex latest drm-fixes-3.8 branch
   (git://people.freedesktop.org/~agd5f/linux) since the possibility is 
   quite
   high that we already have fixed that bug. If that doesn't helps then 
   please
   open a bug report and leave me a note so that I can investigate further.
 
  I don't have a 3.8 fixes branch up just yet, but will soon.
 
  I see. I'll watch that repository, but I would appreciate it if you
  notify me if that branch pops up.
 
 http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.8

Thanks.

I tried drm-fixes-3.8, at commit
4613ca14b9739428abb53bef9cd0f8b3fee23a95 (drm/radeon: add support for
MEM_WRITE packet), on top of v3.7. It hangs in the exact same way.

Christian, were should I open a bug, and under which component, etc.?


Paul Bolle

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


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

2012-12-21 Thread Arto Merilainen

On 12/20/2012 07:14 PM, Stephen Warren wrote:


What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm device. That seems extremely



We are talking about creating a dummy device because:
- we need to give something for drm_platform_init(),
- drm related data should be stored somewhere,
- some data must be passed to all driver probe() functions. This is not 
hw-related data, but just some lists that are used to ensure that all 
drivers have been initialised before calling drm_platform_init().


All these issues are purely tegra-drm related and solving them elsewhere 
(in host1x) would be just wrong! host1x would not even use the dummy 
device for anything so creating it there seems bizarre.


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


[PATCH v2] drm/exynos: consider no iommu support to console framebuffer

2012-12-21 Thread Inki Dae
This patch considers no iommu support to kernel space mapping
of console framebuffer.

Without iommu, we get physical address instead of device address
after dma_alloc_attrs function is called. So we should consider
the case without iommu when it maps console framebuffer with
kernel space.

Changelog v2:
- calll vunmap function only with iommu support.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   22 ++
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index f433eb7..eae064a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -34,6 +34,7 @@
 #include exynos_drm_drv.h
 #include exynos_drm_fb.h
 #include exynos_drm_gem.h
+#include exynos_drm_iommu.h
 
 #define MAX_CONNECTOR  4
 #define PREFERRED_BPP  32
@@ -111,9 +112,18 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
 
/* map pages with kernel virtual space. */
if (!buffer-kvaddr) {
-   unsigned int nr_pages = buffer-size  PAGE_SHIFT;
-   buffer-kvaddr = vmap(buffer-pages, nr_pages, VM_MAP,
+   if (is_drm_iommu_supported(dev)) {
+   unsigned int nr_pages = buffer-size  PAGE_SHIFT;
+
+   buffer-kvaddr = vmap(buffer-pages, nr_pages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
+   } else {
+   phys_addr_t dma_addr = buffer-dma_addr;
+   if (dma_addr)
+   buffer-kvaddr = phys_to_virt(dma_addr);
+   else
+   buffer-kvaddr = (void __iomem *)NULL;
+   }
if (!buffer-kvaddr) {
DRM_ERROR(failed to map pages to kernel space.\n);
return -EIO;
@@ -128,8 +138,12 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
 
dev-mode_config.fb_base = (resource_size_t)buffer-dma_addr;
fbi-screen_base = buffer-kvaddr + offset;
-   fbi-fix.smem_start = (unsigned long)
+   if (is_drm_iommu_supported(dev))
+   fbi-fix.smem_start = (unsigned long)
(page_to_phys(sg_page(buffer-sgt-sgl)) + offset);
+   else
+   fbi-fix.smem_start = (unsigned long)buffer-dma_addr;
+
fbi-screen_size = size;
fbi-fix.smem_len = size;
 
@@ -320,7 +334,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd-exynos_gem_obj;
struct drm_framebuffer *fb;
 
-   if (exynos_gem_obj-buffer-kvaddr)
+   if (is_drm_iommu_supported(dev)  exynos_gem_obj-buffer-kvaddr)
vunmap(exynos_gem_obj-buffer-kvaddr);
 
/* release drm framebuffer and real buffer */
-- 
1.7.4.1

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


[RFC] added hdcp driver in hdmi

2012-12-21 Thread Eunchul Kim
Hi All.

This patch supports HDCP feature in Exynos DRM HDMI.
We enhaced feature of HDCP for content protection.
please check my commit and If you have any opinion of this patch.
please give comment to me.

HDCP stands for High-bandwidth Digital Content Protection.
contains an integrated HDCP encryption engine
for video/audio content protection.
supports version HDCP v1.1.
Exynos supports embedded HDCP key system.
The HDCP key value is fused during fabrication, based on customer's request.

First part authentication protocol.
The HDCP transmitter(Device A) can initiate authentication at any time.
Authentication is initiated by the HDCP transmitter by sending an An, Aksv.
An(64-bit psedo-random value), Aksv(Transmitter Key Selection Vector).
The HDCP Receiver(Device B) generates Rj.
The HDCP Receiver responds by sending a response message Bksv.
Bksv(Receiver Key Selection Vector).
If authentication was successfull, then Ri will be equal to Rj.

Second part authentication protocol.
The second part of the authentication protocol is required
if the HDCP receiver is an HDCP repeater.
The HDCP transmitter executes the second part of the protocol only
when the REPEATER bit is set,
indicating that the attached HDCP receiver is an HDCP repeater.
This part of the protocol assembles a list of all downstream
KSVs attached to the HDCP repeater through a permitted connection tree,
enabling revocation support upstream.

Third part authentication protocol.
The third part of the authentication protocol occurs during
the vertical blanking interval preceding the frame for which it applies.
Each of the two HDCP devices calculates new cipher initialization values,
Ki and Mi, and a third value Ri. and asynchronous polling every 2 seconds.

Exynos scenario.
1. start encryption.
2. receive Bcaps, Bksv from peer device.
3. check repeater caps from Bcaps.
4. send An, Aksv to peer device.
5. receive Rj from peer device.
6. compare Ri, Rj. If same and not repeater, then start encryption.
7. If not same, retry. If repeater, then start second authentication.
8. stop encryption.

Thank's
BR
Eunchul Kim

Eunchul Kim (1):
  drm/exynos: added hdcp driver for contents protection.

 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_hdcp.c| 1164 +++
 drivers/gpu/drm/exynos/exynos_hdcp.h|   47 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c|   11 +
 drivers/gpu/drm/exynos/exynos_hdmi.h|7 +
 drivers/gpu/drm/exynos/regs-hdmi.h  |  177 +
 9 files changed, 1426 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.h

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


[RFC] drm/exynos: added hdcp driver for contents protection.

2012-12-21 Thread Eunchul Kim
HDCP stands for High-bandwidth Digital Content Protection.
This is a newer form of Digital Rights Management(secure DRM)
that was designed to control digital video and audio content.
Contains an integrated HDCP encryption engine for video/audio content 
protection.
supports version HDCP v1.1.
Exynos AP supports embedded HDCP key system.
The HDCP key value is fused during fabrication, based on customer's request.

Exynos HDCP scenario.
- start encryption.
- receive Bcaps, Bksv from peer device.
- check repeater caps from Bcaps.
- send An, Aksv to peer device.
- receive Rj from peer device.
- compare Ri,Rj. If same and not repeater, then start encryption.
- If not same, retry. If repeater, then start second authentication.
- stop encryption.

Signed-off-by: Eunchul Kim chulspro@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_hdcp.c| 1164 +++
 drivers/gpu/drm/exynos/exynos_hdcp.h|   47 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c|   11 +
 drivers/gpu/drm/exynos/exynos_hdmi.h|7 +
 drivers/gpu/drm/exynos/regs-hdmi.h  |  177 +
 9 files changed, 1426 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..93c2f00 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -34,6 +34,12 @@ config DRM_EXYNOS_HDMI
help
  Choose this option if you want to use Exynos HDMI for DRM.
 
+config DRM_EXYNOS_HDCP
+   bool Exynos DRM HDCP
+   depends on DRM_EXYNOS_HDMI
+   help
+ Choose this option if you want to use Exynos HDCP in HDMI for DRM.
+
 config DRM_EXYNOS_VIDI
bool Exynos DRM Virtual Display
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 639b49e..58d8fb7 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -14,6 +14,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_HDCP) += exynos_hdcp.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
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e0a8e80..0d2ada1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -345,6 +345,11 @@ static int __init exynos_drm_init(void)
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_HDMI
+#ifdef CONFIG_DRM_EXYNOS_HDCP
+   ret = platform_driver_register(hdcp_driver);
+   if (ret  0)
+   goto out_hdcp;
+#endif
ret = platform_driver_register(hdmi_driver);
if (ret  0)
goto out_hdmi;
@@ -452,6 +457,10 @@ out_common_hdmi:
 out_mixer:
platform_driver_unregister(hdmi_driver);
 out_hdmi:
+#ifdef CONFIG_DRM_EXYNOS_HDCP
+   platform_driver_unregister(hdcp_driver);
+out_hdcp:
+#endif
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_FIMD
@@ -494,6 +503,9 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(exynos_drm_common_hdmi_driver);
platform_driver_unregister(mixer_driver);
platform_driver_unregister(hdmi_driver);
+#ifdef CONFIG_DRM_EXYNOS_HDCP
+   platform_driver_unregister(hdcp_driver);
+#endif
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_VIDI
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index f5a9774..c591ffc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -344,6 +344,7 @@ extern int exynos_platform_device_hdmi_register(void);
 void exynos_platform_device_hdmi_unregister(void);
 
 extern struct platform_driver fimd_driver;
+extern struct platform_driver hdcp_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
 extern struct platform_driver exynos_drm_common_hdmi_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.c 
b/drivers/gpu/drm/exynos/exynos_hdcp.c
new file mode 100644
index 000..58a345c
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_hdcp.c
@@ -0,0 +1,1164 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * 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 as published by the
+ * Free 

Re: [RFC v2 0/5] Common Display Framework

2012-12-21 Thread Tomasz Figa
Hi Vikas,

On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
  Hi Laurent,
 
 Thanks for the reply.
 
 On 17 December 2012 20:55, Laurent Pinchart 
 
 laurent.pinch...@ideasonboard.com wrote:
  Hi Vikas,
  
  Sorry for the late reply. I now have more time to work on CDF, so
  delays should be much shorter.
  
  On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
   Hi Laurent,
   
   I was thinking of porting CDF to samsung EXYNOS 5250 platform, what
   I
  
  found
  
   is that, the exynos display controller is MIPI DSI based controller.
   
   But if I look at CDF patches, it has only support for MIPI DBI based
  
  Display
  
   controller.
   
   So my question is, do we have any generic framework for MIPI DSI
   based
   display controller? basically I wanted to know, how to go about
   porting
  
  CDF
  
   for such kind of display controller.
  
  MIPI DSI support is not available yet. The only reason for that is
  that I don't have any MIPI DSI hardware to write and test the code
  with :-)
  
  The common display framework should definitely support MIPI DSI. I
  think the
  existing MIPI DBI code could be used as a base, so the implementation
  shouldn't be too high.
  
  Yeah, i was also thinking in similar lines, below is my though for
  MIPI
 
 DSI support in CDF.
 
 o   MIPI DSI support as part of CDF framework will expose
 
 §  mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c
 file )
 
 §  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from
 platform specific init driver call )
 
 ·bus ops will be
 
 o   read data
 
 o   write data
 
 o   write command
 
 §  MIPI DSI will be registered as bus_register()
 
 When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
 initialize the MIPI DSI HW IP.
 
  This probe will also parse the DT file for MIPI DSI based panel, add
 the panel device (device_add() ) to kernel and register the display
 entity with its control and  video ops with CDF.
 
 I can give this a try.

I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 
LCD driver to use the v2 RFC of Common Display Framework. I have most of 
the work done, I have just to solve several remaining problems.

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform

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


[PATCHv4 6/8] ARM: tegra: Add board data and 2D clocks

2012-12-21 Thread Terje Bergstrom
Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
of 2D clock to that driver alias.

Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
 arch/arm/mach-tegra/board-dt-tegra20.c|1 +
 arch/arm/mach-tegra/board-dt-tegra30.c|1 +
 arch/arm/mach-tegra/tegra20_clocks_data.c |2 +-
 arch/arm/mach-tegra/tegra30_clocks_data.c |1 +
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c 
b/arch/arm/mach-tegra/board-dt-tegra20.c
index 734d9cc..2b7a3c2 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -95,6 +95,7 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(nvidia,tegra20-slink, 0x7000D800, spi_tegra.2, NULL),
OF_DEV_AUXDATA(nvidia,tegra20-slink, 0x7000DA00, spi_tegra.3, NULL),
OF_DEV_AUXDATA(nvidia,tegra20-host1x, 0x5000, host1x, NULL),
+   OF_DEV_AUXDATA(nvidia,tegra20-gr2d, 0x5414, gr2d, NULL),
OF_DEV_AUXDATA(nvidia,tegra20-dc, 0x5420, tegradc.0, NULL),
OF_DEV_AUXDATA(nvidia,tegra20-dc, 0x5424, tegradc.1, NULL),
OF_DEV_AUXDATA(nvidia,tegra20-hdmi, 0x5428, hdmi, NULL),
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c 
b/arch/arm/mach-tegra/board-dt-tegra30.c
index 6497d12..6a9e6cb 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@ -58,6 +58,7 @@ struct of_dev_auxdata tegra30_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(nvidia,tegra30-slink, 0x7000DC00, spi_tegra.4, NULL),
OF_DEV_AUXDATA(nvidia,tegra30-slink, 0x7000DE00, spi_tegra.5, NULL),
OF_DEV_AUXDATA(nvidia,tegra30-host1x, 0x5000, host1x, NULL),
+   OF_DEV_AUXDATA(nvidia,tegra30-gr2d, 0x5414, gr2d, NULL),
OF_DEV_AUXDATA(nvidia,tegra30-dc, 0x5420, tegradc.0, NULL),
OF_DEV_AUXDATA(nvidia,tegra30-dc, 0x5424, tegradc.1, NULL),
OF_DEV_AUXDATA(nvidia,tegra30-hdmi, 0x5428, hdmi, NULL),
diff --git a/arch/arm/mach-tegra/tegra20_clocks_data.c 
b/arch/arm/mach-tegra/tegra20_clocks_data.c
index a23a073..15d440a 100644
--- a/arch/arm/mach-tegra/tegra20_clocks_data.c
+++ b/arch/arm/mach-tegra/tegra20_clocks_data.c
@@ -1041,7 +1041,7 @@ static struct clk_duplicate tegra_clk_duplicates[] = {
CLK_DUPLICATE(usbd,   utmip-pad,NULL),
CLK_DUPLICATE(usbd,   tegra-ehci.0, NULL),
CLK_DUPLICATE(usbd,   tegra-otg,NULL),
-   CLK_DUPLICATE(2d, tegra_grhost, gr2d),
+   CLK_DUPLICATE(2d, gr2d, gr2d),
CLK_DUPLICATE(3d, tegra_grhost, gr3d),
CLK_DUPLICATE(epp,tegra_grhost, epp),
CLK_DUPLICATE(mpe,tegra_grhost, mpe),
diff --git a/arch/arm/mach-tegra/tegra30_clocks_data.c 
b/arch/arm/mach-tegra/tegra30_clocks_data.c
index 6942c7a..5787865 100644
--- a/arch/arm/mach-tegra/tegra30_clocks_data.c
+++ b/arch/arm/mach-tegra/tegra30_clocks_data.c
@@ -1338,6 +1338,7 @@ struct clk_duplicate tegra_clk_duplicates[] = {
CLK_DUPLICATE(pll_p, tegradc.0, parent),
CLK_DUPLICATE(pll_p, tegradc.1, parent),
CLK_DUPLICATE(pll_d2_out0, hdmi, parent),
+   CLK_DUPLICATE(2d, gr2d, gr2d),
 };
 
 struct clk *tegra_ptr_clks[] = {
-- 
1.7.9.5

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


[PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Terje Bergstrom
This set of patches adds support for Tegra20 and Tegra30 host1x and
2D. It is based on linux-next-20121220.

The fourth version has only few changes compared to previous version:
 * Fixed some sparse warnings
 * Fixed host1x Makefile to allow building as module
 * Fixed host1x module unload
 * Fixed tegradrm unload sequence
 * host1x creates DRM dummy device and tegradrm uses it for storing
   DRM related data.

Some of the issues left open:
 * Register definitions still use static inline. There has been a
   debate about code style versus ability to use compiler type
   checking and code coverage analysis. There was no conclusion, so
   I left it as was.
 * Uses still CMA helpers. IOMMU support will replace CMA with host1x
   specific allocator.

host1x is the driver that controls host1x hardware. It supports
host1x command channels, synchronization, and memory management. It
is sectioned into logical driver under drivers/gpu/host1x and
physical driver under drivers/host1x/hw. The physical driver is
compiled with the hardware headers of the particular host1x version.

The hardware units are described (briefly) in the Tegra2 TRM. Wiki
page https://gitorious.org/linux-tegra-drm/pages/Host1xIntroduction
also contains a short description of the functionality.

The patch set removes responsibility of host1x from tegradrm. At the
same time, it moves all drm related infrastructure in
drivers/gpu/drm/tegra/host1x.c to drm.c. To replace the host1x
central device, host1x creates a dummy device for tegradrm to hang
global data to. This is a break in responsibility split of tegradrm
taking care of DRM and host1x driver taking care of host1x and
clients, but this structure was insisted. I've kept creation of dummy
device as a separate patch to illustrate the alternatives. It can be
later squashed into other patches.

The patch set adds 2D driver to tegradrm, which uses host1x for
communicating with host1x to access sync points and channels. We
expect to use the same infrastructure for other host1x clients, so
we have kept host1x and tegradrm separate.

The patch set also adds user space API to tegradrm for accessing
host1x and 2D.

Arto Merilainen (1):
  drm: tegra: Remove redundant host1x

Terje Bergstrom (7):
  gpu: host1x: Add host1x driver
  gpu: host1x: Add syncpoint wait and interrupts
  gpu: host1x: Add channel support
  gpu: host1x: Add debug support
  ARM: tegra: Add board data and 2D clocks
  drm: tegra: Add gr2d device
  gpu: host1x: Register DRM dummy device

 arch/arm/mach-tegra/board-dt-tegra20.c  |1 +
 arch/arm/mach-tegra/board-dt-tegra30.c  |1 +
 arch/arm/mach-tegra/tegra20_clocks_data.c   |2 +-
 arch/arm/mach-tegra/tegra30_clocks_data.c   |1 +
 drivers/gpu/Makefile|1 +
 drivers/gpu/drm/tegra/Kconfig   |2 +-
 drivers/gpu/drm/tegra/Makefile  |2 +-
 drivers/gpu/drm/tegra/dc.c  |   26 +-
 drivers/gpu/drm/tegra/drm.c |  433 ++-
 drivers/gpu/drm/tegra/drm.h |   72 ++--
 drivers/gpu/drm/tegra/fb.c  |   17 +-
 drivers/gpu/drm/tegra/gr2d.c|  309 ++
 drivers/gpu/drm/tegra/hdmi.c|   30 +-
 drivers/gpu/drm/tegra/host1x.c  |  325 --
 drivers/gpu/host1x/Kconfig  |   28 ++
 drivers/gpu/host1x/Makefile |   17 +
 drivers/gpu/host1x/cdma.c   |  475 
 drivers/gpu/host1x/cdma.h   |  107 +
 drivers/gpu/host1x/channel.c|  137 ++
 drivers/gpu/host1x/channel.h|   64 +++
 drivers/gpu/host1x/cma.c|  117 +
 drivers/gpu/host1x/cma.h|   43 ++
 drivers/gpu/host1x/debug.c  |  207 +
 drivers/gpu/host1x/debug.h  |   49 +++
 drivers/gpu/host1x/dev.c|  242 +++
 drivers/gpu/host1x/dev.h|  167 
 drivers/gpu/host1x/drm.c|   51 +++
 drivers/gpu/host1x/drm.h|   25 ++
 drivers/gpu/host1x/hw/Makefile  |6 +
 drivers/gpu/host1x/hw/cdma_hw.c |  480 +
 drivers/gpu/host1x/hw/cdma_hw.h |   37 ++
 drivers/gpu/host1x/hw/channel_hw.c  |  147 +++
 drivers/gpu/host1x/hw/debug_hw.c|  399 +
 drivers/gpu/host1x/hw/host1x01.c|   46 ++
 drivers/gpu/host1x/hw/host1x01.h|   25 ++
 drivers/gpu/host1x/hw/host1x01_hardware.h   |  150 +++
 drivers/gpu/host1x/hw/hw_host1x01_channel.h |   98 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h|  179 
 drivers/gpu/host1x/hw/hw_host1x01_uclass.h  |  130 ++
 drivers/gpu/host1x/hw/intr_hw.c |  178 
 drivers/gpu/host1x/hw/syncpt_hw.c   |  157 +++
 drivers/gpu/host1x/intr.c   |  377 
 

[PATCHv4 1/8] gpu: host1x: Add host1x driver

2012-12-21 Thread Terje Bergstrom
Add host1x, the driver for host1x and its client unit 2D.

Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
 drivers/gpu/Makefile  |1 +
 drivers/gpu/host1x/Kconfig|6 +
 drivers/gpu/host1x/Makefile   |8 +
 drivers/gpu/host1x/dev.c  |  182 +++
 drivers/gpu/host1x/dev.h  |   79 ++
 drivers/gpu/host1x/hw/Makefile|6 +
 drivers/gpu/host1x/hw/host1x01.c  |   36 +
 drivers/gpu/host1x/hw/host1x01.h  |   25 
 drivers/gpu/host1x/hw/host1x01_hardware.h |   26 
 drivers/gpu/host1x/hw/hw_host1x01_sync.h  |   66 +
 drivers/gpu/host1x/hw/syncpt_hw.c |  146 +++
 drivers/gpu/host1x/syncpt.c   |  227 +
 drivers/gpu/host1x/syncpt.h   |  128 
 drivers/video/Kconfig |2 +
 include/linux/host1x.h|   41 ++
 include/trace/events/host1x.h |   61 
 16 files changed, 1040 insertions(+)
 create mode 100644 drivers/gpu/host1x/Kconfig
 create mode 100644 drivers/gpu/host1x/Makefile
 create mode 100644 drivers/gpu/host1x/dev.c
 create mode 100644 drivers/gpu/host1x/dev.h
 create mode 100644 drivers/gpu/host1x/hw/Makefile
 create mode 100644 drivers/gpu/host1x/hw/host1x01.c
 create mode 100644 drivers/gpu/host1x/hw/host1x01.h
 create mode 100644 drivers/gpu/host1x/hw/host1x01_hardware.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_sync.h
 create mode 100644 drivers/gpu/host1x/hw/syncpt_hw.c
 create mode 100644 drivers/gpu/host1x/syncpt.c
 create mode 100644 drivers/gpu/host1x/syncpt.h
 create mode 100644 include/linux/host1x.h
 create mode 100644 include/trace/events/host1x.h

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index cc92778..7fa2f68 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_TEGRA_HOST1X) += host1x/
 obj-y  += drm/ vga/ stub/
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
new file mode 100644
index 000..e89fb2b
--- /dev/null
+++ b/drivers/gpu/host1x/Kconfig
@@ -0,0 +1,6 @@
+config TEGRA_HOST1X
+   tristate Tegra host1x driver
+   help
+ Driver for the Tegra host1x hardware.
+
+ Required for enabling tegradrm.
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
new file mode 100644
index 000..363e6ab
--- /dev/null
+++ b/drivers/gpu/host1x/Makefile
@@ -0,0 +1,8 @@
+ccflags-y = -Idrivers/gpu/host1x
+
+host1x-y = \
+   syncpt.o \
+   dev.o \
+   hw/host1x01.o
+
+obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
new file mode 100644
index 000..b0d630d
--- /dev/null
+++ b/drivers/gpu/host1x/dev.c
@@ -0,0 +1,182 @@
+/*
+ * Tegra host1x driver
+ *
+ * Copyright (c) 2010-2012, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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/.
+ */
+
+#include linux/module.h
+#include linux/host1x.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/clk.h
+#include linux/io.h
+#include dev.h
+#include hw/host1x01.h
+
+#define CREATE_TRACE_POINTS
+#include trace/events/host1x.h
+
+#define DRIVER_NAMEtegra-host1x
+
+struct host1x *host1x;
+
+void host1x_syncpt_incr_byid(u32 id)
+{
+   struct host1x_syncpt *sp = host1x-syncpt + id;
+   return host1x_syncpt_incr(sp);
+}
+EXPORT_SYMBOL(host1x_syncpt_incr_byid);
+
+u32 host1x_syncpt_read_byid(u32 id)
+{
+   struct host1x_syncpt *sp = host1x-syncpt + id;
+   return host1x_syncpt_read(sp);
+}
+EXPORT_SYMBOL(host1x_syncpt_read_byid);
+
+void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
+{
+   void __iomem *sync_regs = host1x-regs + host1x-info.sync_offset;
+
+   writel(v, sync_regs + r);
+}
+
+u32 host1x_sync_readl(struct host1x *host1x, u32 r)
+{
+   void __iomem *sync_regs = host1x-regs + host1x-info.sync_offset;
+
+   return readl(sync_regs + r);
+}
+
+static struct host1x_device_info host1x_info = {
+   .nb_channels= 8,
+   .nb_pts = 32,
+   .nb_mlocks  = 16,
+   .nb_bases   = 8,
+   .init   = host1x01_init,
+   .sync_offset= 0x3000,
+};
+
+static struct of_device_id host1x_match[] = {
+   { .compatible = 

[PATCHv4 2/8] gpu: host1x: Add syncpoint wait and interrupts

2012-12-21 Thread Terje Bergstrom
Add support for sync point interrupts, and sync point wait. Sync
point wait used interrupts for unblocking wait.

Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
 drivers/gpu/host1x/Makefile  |2 +
 drivers/gpu/host1x/dev.c |   37 +++-
 drivers/gpu/host1x/dev.h |   15 ++
 drivers/gpu/host1x/hw/host1x01.c |2 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h |   30 ++-
 drivers/gpu/host1x/hw/intr_hw.c  |  178 +++
 drivers/gpu/host1x/intr.c|  350 ++
 drivers/gpu/host1x/intr.h|  100 +
 drivers/gpu/host1x/syncpt.c  |  164 +-
 drivers/gpu/host1x/syncpt.h  |4 +
 include/linux/host1x.h   |1 +
 11 files changed, 880 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/host1x/hw/intr_hw.c
 create mode 100644 drivers/gpu/host1x/intr.c
 create mode 100644 drivers/gpu/host1x/intr.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 363e6ab..d3eb3b4 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -3,6 +3,8 @@ ccflags-y = -Idrivers/gpu/host1x
 host1x-y = \
syncpt.o \
dev.o \
+   intr.o \
hw/host1x01.o
 
+host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index b0d630d..f441b6c 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -25,6 +25,7 @@
 #include linux/clk.h
 #include linux/io.h
 #include dev.h
+#include intr.h
 #include hw/host1x01.h
 
 #define CREATE_TRACE_POINTS
@@ -48,6 +49,13 @@ u32 host1x_syncpt_read_byid(u32 id)
 }
 EXPORT_SYMBOL(host1x_syncpt_read_byid);
 
+int host1x_syncpt_wait_byid(u32 id, u32 thresh, long timeout, u32 *value)
+{
+   struct host1x_syncpt *sp = host1x-syncpt + id;
+   return host1x_syncpt_wait(sp, thresh, timeout, value);
+}
+EXPORT_SYMBOL(host1x_syncpt_wait_byid);
+
 void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
 {
void __iomem *sync_regs = host1x-regs + host1x-info.sync_offset;
@@ -62,6 +70,21 @@ u32 host1x_sync_readl(struct host1x *host1x, u32 r)
return readl(sync_regs + r);
 }
 
+static int host1x_alloc_resources(struct host1x *host)
+{
+   host-intr.syncpt = devm_kzalloc(host-dev-dev,
+   sizeof(struct host1x_intr_syncpt) *
+   host-info.nb_pts,
+   GFP_KERNEL);
+
+   if (!host-intr.syncpt) {
+   /* frees happen in the support removal phase */
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
 static struct host1x_device_info host1x_info = {
.nb_channels= 8,
.nb_pts = 32,
@@ -110,7 +133,6 @@ static int host1x_probe(struct platform_device *dev)
 
/* set common host1x device data */
platform_set_drvdata(dev, host);
-
host-regs = devm_request_and_ioremap(dev-dev, regs);
if (!host-regs) {
dev_err(dev-dev, failed to remap host registers\n);
@@ -118,6 +140,12 @@ static int host1x_probe(struct platform_device *dev)
goto fail;
}
 
+   err = host1x_alloc_resources(host);
+   if (err) {
+   dev_err(dev-dev, failed to init chip support\n);
+   goto fail;
+   }
+
if (host-info.init) {
err = host-info.init(host);
if (err)
@@ -132,6 +160,10 @@ static int host1x_probe(struct platform_device *dev)
if (!host-nop_sp)
goto fail;
 
+   err = host1x_intr_init(host-intr, syncpt_irq);
+   if (err)
+   goto fail;
+
host-clk = devm_clk_get(dev-dev, NULL);
if (IS_ERR(host-clk)) {
dev_err(dev-dev, failed to get clock\n);
@@ -145,6 +177,8 @@ static int host1x_probe(struct platform_device *dev)
 
host1x_syncpt_reset(host);
 
+   host1x_intr_start(host-intr, clk_get_rate(host-clk));
+
host1x = host;
 
dev_info(dev-dev, initialized\n);
@@ -160,6 +194,7 @@ fail:
 static int __exit host1x_remove(struct platform_device *dev)
 {
struct host1x *host = platform_get_drvdata(dev);
+   host1x_intr_deinit(host-intr);
host1x_syncpt_deinit(host);
clk_disable_unprepare(host-clk);
return 0;
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 8245e24..a1622bb 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -20,6 +20,7 @@
 #include linux/host1x.h
 
 #include syncpt.h
+#include intr.h
 
 struct host1x;
 struct host1x_syncpt;
@@ -36,6 +37,18 @@ struct host1x_syncpt_ops {
const char * (*name)(struct host1x_syncpt *);
 };
 
+struct host1x_intr_ops {
+   void (*init_host_sync)(struct host1x_intr *);
+   void (*set_host_clocks_per_usec)(
+   struct host1x_intr *, u32 clocks);
+   void 

[PATCHv4 7/8] drm: tegra: Add gr2d device

2012-12-21 Thread Terje Bergstrom
Add client driver for 2D device.

Signed-off-by: Arto Merilainen amerilai...@nvidia.com
Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
 drivers/gpu/drm/tegra/Makefile |2 +-
 drivers/gpu/drm/tegra/drm.c|  211 ++-
 drivers/gpu/drm/tegra/drm.h|   29 
 drivers/gpu/drm/tegra/gr2d.c   |  307 
 include/drm/tegra_drm.h|  111 +++
 5 files changed, 658 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/tegra/gr2d.c

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index f4c05bb..2661f41 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -1,7 +1,7 @@
 ccflags-y := -Iinclude/drm
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
 
-tegra-drm-y := drm.o fb.o dc.o
+tegra-drm-y := drm.o fb.o dc.o gr2d.o
 tegra-drm-y += output.o rgb.o hdmi.o
 
 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 3de6c8e..637b621 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -36,8 +36,10 @@ static int tegra_drm_add_client(struct device *dev, void 
*data)
static const char * const compat[] = {
nvidia,tegra20-dc,
nvidia,tegra20-hdmi,
+   nvidia,tegra20-gr2d,
nvidia,tegra30-dc,
nvidia,tegra30-hdmi,
+   nvidia,tegra30-gr2d
};
struct tegradrm *tegradrm = data;
struct tegra_drm_client_entry *client;
@@ -183,12 +185,29 @@ static int tegra_drm_unload(struct drm_device *drm)
 
 static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
 {
-   return 0;
+   struct tegra_drm_fpriv *fpriv;
+   int err = 0;
+
+   fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
+   if (!fpriv)
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(fpriv-contexts);
+   filp-driver_priv = fpriv;
+
+   return err;
 }
 
 static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
 {
+   struct tegra_drm_fpriv *fpriv = tegra_drm_fpriv(filp);
+   struct tegra_drm_context *context, *tmp;
 
+   list_for_each_entry_safe(context, tmp, fpriv-contexts, list) {
+   context-client-ops-close_channel(context);
+   kfree(context);
+   }
+   kfree(fpriv);
 }
 
 static void tegra_drm_lastclose(struct drm_device *drm)
@@ -257,8 +276,14 @@ static int __init tegra_drm_init(void)
err = platform_driver_register(tegra_hdmi_driver);
if (err  0)
goto unregister_dc;
+
+   err = platform_driver_register(tegra_gr2d_driver);
+   if (err  0)
+   goto unregister_hdmi;
return 0;
 
+unregister_hdmi:
+   platform_driver_unregister(tegra_hdmi_driver);
 unregister_dc:
platform_driver_unregister(tegra_dc_driver);
 unregister_tegra_drv:
@@ -271,13 +296,197 @@ module_init(tegra_drm_init);
 
 static void __exit tegra_drm_exit(void)
 {
+   platform_driver_unregister(tegra_gr2d_driver);
platform_driver_unregister(tegra_hdmi_driver);
platform_driver_unregister(tegra_dc_driver);
platform_driver_unregister(tegra_drm_platform_driver);
 }
 module_exit(tegra_drm_exit);
 
+static int
+tegra_drm_ioctl_syncpt_read(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_syncpt_read_args *args = data;
+
+   args-value = host1x_syncpt_read_byid(args-id);
+   return 0;
+}
+
+static int
+tegra_drm_ioctl_syncpt_incr(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_syncpt_incr_args *args = data;
+   host1x_syncpt_incr_byid(args-id);
+   return 0;
+}
+
+static int
+tegra_drm_ioctl_syncpt_wait(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_syncpt_wait_args *args = data;
+   int err;
+
+   err = host1x_syncpt_wait_byid(args-id, args-thresh,
+   args-timeout, args-value);
+
+   return err;
+}
+
+static int
+tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
+struct drm_file *file_priv)
+{
+   struct tegra_drm_open_channel_args *args = data;
+   struct tegra_drm_client *client;
+   struct tegra_drm_context *context;
+   struct tegra_drm_fpriv *fpriv = tegra_drm_fpriv(file_priv);
+   struct tegradrm *tegradrm = drm-dev_private;
+   int err = 0;
+
+   context = kzalloc(sizeof(*context), GFP_KERNEL);
+   if (!context)
+   return -ENOMEM;
+
+   list_for_each_entry(client, tegradrm-clients, list) {
+   if (client-class == args-class) {
+   dev_dbg(drm-dev, opening client %x\n, args-class);
+   context-client = client;
+   err = 

[PATCHv4 8/8] gpu: host1x: Register DRM dummy device

2012-12-21 Thread Terje Bergstrom
Register a dummy device for tegradrm, and provide a getter to
access the device.

Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
 drivers/gpu/drm/tegra/dc.c   |5 -
 drivers/gpu/drm/tegra/drm.c  |   11 +
 drivers/gpu/drm/tegra/gr2d.c |4 +++-
 drivers/gpu/drm/tegra/hdmi.c |5 -
 drivers/gpu/host1x/Makefile  |3 ++-
 drivers/gpu/host1x/dev.c |9 
 drivers/gpu/host1x/dev.h |2 ++
 drivers/gpu/host1x/drm.c |   51 ++
 drivers/gpu/host1x/drm.h |   25 +
 include/linux/host1x.h   |2 ++
 10 files changed, 103 insertions(+), 14 deletions(-)
 create mode 100644 drivers/gpu/host1x/drm.c
 create mode 100644 drivers/gpu/host1x/drm.h

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 24bcd06..d01be50 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -12,6 +12,7 @@
 #include linux/module.h
 #include linux/of.h
 #include linux/platform_device.h
+#include linux/host1x.h
 
 #include mach/clk.h
 
@@ -740,7 +741,9 @@ static int tegra_dc_probe(struct platform_device *pdev)
struct resource *regs;
struct tegra_dc *dc;
int err;
-   struct tegradrm *tegradrm = platform_get_drvdata(pdev);
+   struct platform_device *drm_device =
+   host1x_drm_device(to_platform_device(pdev-dev.parent));
+   struct tegradrm *tegradrm = platform_get_drvdata(drm_device);
 
dc = devm_kzalloc(pdev-dev, sizeof(*dc), GFP_KERNEL);
if (!dc)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 637b621..d64935d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -56,7 +56,6 @@ static int tegra_drm_add_client(struct device *dev, void 
*data)
client-np = of_node_get(dev-of_node);
 
list_add_tail(client-list, tegradrm-drm_clients);
-   dev_set_drvdata(dev, tegradrm);
}
}
 
@@ -258,16 +257,10 @@ static struct platform_driver tegra_drm_platform_driver = 
{
 static int __init tegra_drm_init(void)
 {
int err;
-   struct platform_device *drm_device;
-
-   drm_device = platform_device_register_simple(tegradrm, -1, NULL, 0);
-   if (!drm_device)
-   return -ENOMEM;
-   dma_set_coherent_mask(drm_device-dev, DMA_BIT_MASK(32));
 
err = platform_driver_register(tegra_drm_platform_driver);
if (err  0)
-   goto unregister_tegra_dev;
+   return err;
 
err = platform_driver_register(tegra_dc_driver);
if (err  0)
@@ -288,8 +281,6 @@ unregister_dc:
platform_driver_unregister(tegra_dc_driver);
 unregister_tegra_drv:
platform_driver_unregister(tegra_drm_platform_driver);
-unregister_tegra_dev:
-   platform_device_unregister(drm_device);
return err;
 }
 module_init(tegra_drm_init);
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 8865099..a936902 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -247,7 +247,9 @@ static int __devinit gr2d_probe(struct platform_device *dev)
 {
int err;
struct gr2d *gr2d = NULL;
-   struct tegradrm *tegradrm = platform_get_drvdata(dev);
+   struct platform_device *drm_device =
+   host1x_drm_device(to_platform_device(dev-dev.parent));
+   struct tegradrm *tegradrm = platform_get_drvdata(drm_device);
 
gr2d = devm_kzalloc(dev-dev, sizeof(*gr2d), GFP_KERNEL);
if (!gr2d)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index fce3e66..a90a76f 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -14,6 +14,7 @@
 #include linux/of.h
 #include linux/platform_device.h
 #include linux/regulator/consumer.h
+#include linux/host1x.h
 
 #include mach/clk.h
 
@@ -1214,7 +1215,9 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
struct tegra_hdmi *hdmi;
struct resource *regs;
int err;
-   struct tegradrm *tegradrm = platform_get_drvdata(pdev);
+   struct platform_device *drm_device =
+   host1x_drm_device(to_platform_device(pdev-dev.parent));
+   struct tegradrm *tegradrm = platform_get_drvdata(drm_device);
 
hdmi = devm_kzalloc(pdev-dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 049c07a..f8749fb 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -10,7 +10,8 @@ host1x-y = \
job.o \
debug.o \
memmgr.o \
-   hw/host1x01.o
+   hw/host1x01.o \
+   drm.o
 
 host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 8d710ef..07e8813 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ 

[PATCHv4 5/8] drm: tegra: Remove redundant host1x

2012-12-21 Thread Terje Bergstrom
From: Arto Merilainen amerilai...@nvidia.com

This patch removes the redundant host1x driver from tegradrm and
makes necessary bindings to the separate host driver.

The infrastructure for drm client lists is merged to drm.c.

The patch simplifies driver initialization; The original driver had
two lists for registered devices (clients and drm_active). The
clients list included references to all registered devices whereas
the drm_active list included only the devices that the tegradrm
driver itself supported. host1x is separated into a driver of its own
and hence there should be no need to support registration of external
drivers.  Therefore, only the drm_active list is reserved. Removal of
the list also simplifies the driver unregistration.

Signed-off-by: Arto Merilainen amerilai...@nvidia.com
Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
 drivers/gpu/drm/tegra/Kconfig  |2 +-
 drivers/gpu/drm/tegra/Makefile |2 +-
 drivers/gpu/drm/tegra/dc.c |   23 +--
 drivers/gpu/drm/tegra/drm.c|  231 ++--
 drivers/gpu/drm/tegra/drm.h|   43 +++---
 drivers/gpu/drm/tegra/fb.c |   17 ++-
 drivers/gpu/drm/tegra/hdmi.c   |   27 ++--
 drivers/gpu/drm/tegra/host1x.c |  325 
 include/drm/tegra_drm.h|   20 +++
 9 files changed, 298 insertions(+), 392 deletions(-)
 delete mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 include/drm/tegra_drm.h

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index be1daf7..4a0290e 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -1,6 +1,6 @@
 config DRM_TEGRA
tristate NVIDIA Tegra DRM
-   depends on DRM  OF  ARCH_TEGRA
+   depends on DRM  OF  ARCH_TEGRA  TEGRA_HOST1X
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 80f73d1..f4c05bb 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -1,7 +1,7 @@
 ccflags-y := -Iinclude/drm
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
 
-tegra-drm-y := drm.o fb.o dc.o host1x.o
+tegra-drm-y := drm.o fb.o dc.o
 tegra-drm-y += output.o rgb.o hdmi.o
 
 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0744103..24bcd06 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -673,10 +673,10 @@ static int tegra_dc_debugfs_exit(struct tegra_dc *dc)
return 0;
 }
 
-static int tegra_dc_drm_init(struct host1x_client *client,
+static int tegra_dc_drm_init(struct tegra_drm_client *client,
 struct drm_device *drm)
 {
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_dc *dc = tegra_drm_client_to_dc(client);
int err;
 
dc-pipe = drm-mode_config.num_crtc;
@@ -708,9 +708,9 @@ static int tegra_dc_drm_init(struct host1x_client *client,
return 0;
 }
 
-static int tegra_dc_drm_exit(struct host1x_client *client)
+static int tegra_dc_drm_exit(struct tegra_drm_client *client)
 {
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_dc *dc = tegra_drm_client_to_dc(client);
int err;
 
devm_free_irq(dc-dev, dc-irq, dc);
@@ -730,17 +730,17 @@ static int tegra_dc_drm_exit(struct host1x_client *client)
return 0;
 }
 
-static const struct host1x_client_ops dc_client_ops = {
+static const struct tegra_drm_client_ops dc_client_ops = {
.drm_init = tegra_dc_drm_init,
.drm_exit = tegra_dc_drm_exit,
 };
 
 static int tegra_dc_probe(struct platform_device *pdev)
 {
-   struct host1x *host1x = dev_get_drvdata(pdev-dev.parent);
struct resource *regs;
struct tegra_dc *dc;
int err;
+   struct tegradrm *tegradrm = platform_get_drvdata(pdev);
 
dc = devm_kzalloc(pdev-dev, sizeof(*dc), GFP_KERNEL);
if (!dc)
@@ -780,6 +780,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
INIT_LIST_HEAD(dc-client.list);
dc-client.ops = dc_client_ops;
dc-client.dev = pdev-dev;
+   dc-client.tegradrm = tegradrm;
 
err = tegra_dc_rgb_probe(dc);
if (err  0  err != -ENODEV) {
@@ -787,9 +788,9 @@ static int tegra_dc_probe(struct platform_device *pdev)
return err;
}
 
-   err = host1x_register_client(host1x, dc-client);
+   err = tegra_drm_register_client(tegradrm, dc-client);
if (err  0) {
-   dev_err(pdev-dev, failed to register host1x client: %d\n,
+   dev_err(pdev-dev, failed to register tegra drm client: %d\n,
err);
return err;
}
@@ -801,13 +802,13 @@ static int tegra_dc_probe(struct platform_device *pdev)
 
 static int tegra_dc_remove(struct platform_device *pdev)
 {
-   struct host1x *host1x = 

[PATCHv4 4/8] gpu: host1x: Add debug support

2012-12-21 Thread Terje Bergstrom
Add support for host1x debugging. Adds debugfs entries, and dumps
channel state to UART in case of stuck job.

Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
 drivers/gpu/host1x/Makefile |1 +
 drivers/gpu/host1x/cdma.c   |   37 +++
 drivers/gpu/host1x/debug.c  |  207 ++
 drivers/gpu/host1x/debug.h  |   49 
 drivers/gpu/host1x/dev.c|3 +
 drivers/gpu/host1x/dev.h|   17 ++
 drivers/gpu/host1x/hw/cdma_hw.c |3 +
 drivers/gpu/host1x/hw/debug_hw.c|  399 +++
 drivers/gpu/host1x/hw/host1x01.c|2 +
 drivers/gpu/host1x/hw/hw_host1x01_channel.h |   12 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h|   77 ++
 drivers/gpu/host1x/hw/syncpt_hw.c   |1 +
 drivers/gpu/host1x/syncpt.c |3 +
 13 files changed, 811 insertions(+)
 create mode 100644 drivers/gpu/host1x/debug.c
 create mode 100644 drivers/gpu/host1x/debug.h
 create mode 100644 drivers/gpu/host1x/hw/debug_hw.c

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 59ecd82..049c07a 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -8,6 +8,7 @@ host1x-y = \
intr.o \
channel.o \
job.o \
+   debug.o \
memmgr.o \
hw/host1x01.o
 
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 1193fea..b924f23 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -19,6 +19,7 @@
 #include cdma.h
 #include channel.h
 #include dev.h
+#include debug.h
 #include memmgr.h
 #include asm/cacheflush.h
 
@@ -369,12 +370,45 @@ int host1x_cdma_begin(struct host1x_cdma *cdma, struct 
host1x_job *job)
return 0;
 }
 
+static void trace_write_gather(struct host1x_cdma *cdma,
+   struct mem_handle *ref,
+   u32 offset, u32 words)
+{
+   void *mem = NULL;
+
+   if (host1x_debug_trace_cmdbuf) {
+   mem = host1x_memmgr_mmap(ref);
+   if (IS_ERR_OR_NULL(mem))
+   mem = NULL;
+   };
+
+   if (mem) {
+   u32 i;
+   /*
+* Write in batches of 128 as there seems to be a limit
+* of how much you can output to ftrace at once.
+*/
+   for (i = 0; i  words; i += TRACE_MAX_LENGTH) {
+   trace_host1x_cdma_push_gather(
+   cdma_to_channel(cdma)-dev-name,
+   (u32)ref,
+   min(words - i, TRACE_MAX_LENGTH),
+   offset + i * sizeof(u32),
+   mem);
+   }
+   host1x_memmgr_munmap(ref, mem);
+   }
+}
+
 /*
  * Push two words into a push buffer slot
  * Blocks as necessary if the push buffer is full.
  */
 void host1x_cdma_push(struct host1x_cdma *cdma, u32 op1, u32 op2)
 {
+   if (host1x_debug_trace_cmdbuf)
+   trace_host1x_cdma_push(cdma_to_channel(cdma)-dev-name,
+   op1, op2);
host1x_cdma_push_gather(cdma, NULL, 0, op1, op2);
 }
 
@@ -390,6 +424,9 @@ void host1x_cdma_push_gather(struct host1x_cdma *cdma,
u32 slots_free = cdma-slots_free;
struct push_buffer *pb = cdma-push_buffer;
 
+   if (handle)
+   trace_write_gather(cdma, handle, offset, op1  0x);
+
if (slots_free == 0) {
host1x-cdma_op.kick(cdma);
slots_free = host1x_cdma_wait_locked(cdma,
diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
new file mode 100644
index 000..86d5c70
--- /dev/null
+++ b/drivers/gpu/host1x/debug.c
@@ -0,0 +1,207 @@
+/*
+ * Copyright (C) 2010 Google, Inc.
+ * Author: Erik Gilling konk...@android.com
+ *
+ * Copyright (C) 2011-2012 NVIDIA Corporation
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include linux/debugfs.h
+#include linux/seq_file.h
+#include linux/uaccess.h
+
+#include linux/io.h
+
+#include dev.h
+#include debug.h
+#include channel.h
+
+static pid_t host1x_debug_null_kickoff_pid;
+unsigned int host1x_debug_trace_cmdbuf;
+
+static pid_t host1x_debug_force_timeout_pid;
+static u32 host1x_debug_force_timeout_val;
+static u32 host1x_debug_force_timeout_channel;
+
+void host1x_debug_output(struct output *o, const char *fmt, ...)
+{
+   va_list args;
+   int len;
+
+   va_start(args, fmt);
+   len = 

Re: [RFC] drm/exynos: added hdcp driver for contents protection.

2012-12-21 Thread Alan Cox
On Fri, 21 Dec 2012 18:47:57 +0900
Eunchul Kim chulspro@samsung.com wrote:

 HDCP stands for High-bandwidth Digital Content Protection.
 This is a newer form of Digital Rights Management(secure DRM)

was.. the master key was leaked long ago 8)

 that was designed to control digital video and audio content.
 Contains an integrated HDCP encryption engine for video/audio content 
 protection.
 supports version HDCP v1.1.
 Exynos AP supports embedded HDCP key system.
 The HDCP key value is fused during fabrication, based on customer's request.

For this code to go into the kernel it must do so in GPL form. Can you
confirm Samsung has the necessary IPR and permissions to grant use of
this to all third parties as the GPL requires not just to specific
customers ? (whether they can use it usefully is a different question as
obviously they need the key.

I ask this because there are currently a lot of lawyers busy trying to
sue makers of some HDCP aware devices.

 +
 + dev_info(dev, drm hdcp registered successfully.\n);

This sort of stuff ought to be dev_dbg, minor item


 diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h 
 b/drivers/gpu/drm/exynos/exynos_hdcp.h
 new file mode 100644
 index 000..86d0c79
 --- /dev/null
 +++ b/drivers/gpu/drm/exynos/exynos_hdcp.h
 @@ -0,0 +1,47 @@
 +/*
 + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
 + *
 + * Authors:
 + *   Eunchul Kim chulspro@samsung.com
 + *
 + * 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, sublicense,
 + * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
 + * VA LINUX SYSTEMS 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.
 + */


Two things strike me here - firstly kernel code is GPLv2 or later (or
dual licensed) as per the Signed-off-by: certification. I don't see any
problem in the above but to be sure you realise.

Secondly - VA Linux systems ??? has this been copied from some random
file and not updated correctly or does the old VA Linux Systems really
own bits of this code.

Other questions I'll look at later - in particular
- I don't see how the work queue is locked against the main thread of
  execution within the driver
- There is a general DRI question here about HDCP and interfaces -
  several out of tree drivers do HDCP and perhaps a common API would be
  sensible ?

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


Re: Fan control in nouveau driver with geforce 9600gt

2012-12-21 Thread Ozan Çağlayan
 Of course it is, but why would you disable automatic fan management?

 You are supposed to activate it and let it activated at all time.

It's not me but someone inexperienced playing with sysfs tunables for example :)



-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Lucas Stach
Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
 This set of patches adds support for Tegra20 and Tegra30 host1x and
 2D. It is based on linux-next-20121220.
 
 The fourth version has only few changes compared to previous version:
  * Fixed some sparse warnings
  * Fixed host1x Makefile to allow building as module
  * Fixed host1x module unload
  * Fixed tegradrm unload sequence
  * host1x creates DRM dummy device and tegradrm uses it for storing
DRM related data.
 
 Some of the issues left open:
  * Register definitions still use static inline. There has been a
debate about code style versus ability to use compiler type
checking and code coverage analysis. There was no conclusion, so
I left it as was.
This has to be resolved before merging. Personally I'm in favour of
keeping reg access patterns close to what is done in other parts of the
kernel.

  * Uses still CMA helpers. IOMMU support will replace CMA with host1x
specific allocator.

I really want the allocator issue resolved before talking about merging
those patches. Proper IOMMU support will require a bit of rework of the
current upstream IOMMU API, so it will still be a bit out.

But if you don't mind I'll try to implement the host1x allocator over
the holidays and provide an incremental patch.

Regards,
Lucas

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


Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

2012-12-21 Thread Florian Mickler
On Tue, 18 Dec 2012 23:33:20 +0100
Paul Menzel paulepan...@users.sourceforge.net wrote:

 Dear Florian,
 
 
 Am Dienstag, den 18.12.2012, 21:03 +0100 schrieb Florian Mickler:
 
  On Wed, 15 Aug 2012 17:40:40 +0200 Paul Menzel wrote:
  
   Date: Wed, 8 Aug 2012 23:12:19 +0200
   
   Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
   vertical stripes in the top half.
  
  This patch, which was merged in v3.6-rc4, makes the image on my ASUS
  VW222U ca. 1 inch too wide left/right and top/bottom.  The effect is as
  if the image was zoomed (bigger, more pixely).
  
  Reverting it fixes the problem.
 
 I am sorry for the trouble caused by this. As a work around, you could
 also specify the QUIRKS on the Linux command line.
 
  The Monitor is connected via VGA, but also has a DVI interface.
  
  Maybe the quirk-apply criteria is too unspecific?
 
 Hmm, I guess everything is identical but the DVI connector they added to
 the VW222U. Though I should have noticed the effect on the VW222S and
 did not. :(

Hm.. why should you have noticed the effect on the VW222S? Does it
happen there too?

 
 Could you please send the `edid-decode` output on your system and
 `/var/log/Xorg.0.log`.
 

I attached the xrandr --verbose output and the 
# get-edid  | parse-edid
output from http://www.polypux.org/projects/read-edid/ which I already
had installed. Hope this works for you too.



 Also I wonder how this quirk could create such a behavior.


Yes. I'm not shure how this could happen. It probably is either a bug
somewhere, or it is the 'natural' effect of misconfiguring the vga
pipeline.  Maybe someone more knowledgeable than me could make a more
educated guess about this.


 
 [1] http://cgit.freedesktop.org/xorg/app/edid-decode/
Screen 0: minimum 320 x 200, current 3080 x 1050, maximum 8192 x 8192
LVDS1 connected 1400x1050+1680+0 (0x44) normal (normal left inverted right x 
axis y axis) 304mm x 228mm
Identifier: 0x41
Timestamp:  20362
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   1
CRTCs:  1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000030ae4240
000f0103801e1778ea3c809757518a27
22505421080081800101010101010101
010101010101302a7820511a10403070
130030e4101825237820511a1040
3070130030e41018000f0090
4332904328140100320c532100fe
004c503135304530372d544c303300ca
BACKLIGHT: 15 (0x000f)  range:  (0,15)
Backlight: 15 (0x000f)  range:  (0,15)
scaling mode:   Full aspect
supported: None Full Center   Full aspect 
  1400x1050 (0x44)  108.0MHz -HSync -VSync *current +preferred
h: width  1400 start 1448 end 1560 total 1688 skew0 clock   64.0KHz
v: height 1050 start 1051 end 1054 total 1066   clock   60.0Hz
  1400x1050 (0x45)  122.0MHz +HSync +VSync
h: width  1400 start 1488 end 1640 total 1880 skew0 clock   64.9KHz
v: height 1050 start 1052 end 1064 total 1082   clock   60.0Hz
  1400x1050 (0x46)   90.0MHz -HSync -VSync
h: width  1400 start 1448 end 1560 total 1688 skew0 clock   53.3KHz
v: height 1050 start 1051 end 1054 total 1066   clock   50.0Hz
  1280x1024 (0x47)  108.0MHz +HSync +VSync
h: width  1280 start 1328 end 1440 total 1688 skew0 clock   64.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   60.0Hz
  1280x960 (0x48)  108.0MHz +HSync +VSync
h: width  1280 start 1376 end 1488 total 1800 skew0 clock   60.0KHz
v: height  960 start  961 end  964 total 1000   clock   60.0Hz
  1024x768 (0x49)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  800x600 (0x4a)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   37.9KHz
v: height  600 start  601 end  605 total  628   clock   60.3Hz
  800x600 (0x4b)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock   35.2KHz
v: height  600 start  601 end  603 total  625   clock   56.2Hz
  640x480 (0x4c)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   60.0Hz
  640x480 (0x4d)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   59.9Hz
VGA1 connected 

Re: [PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Terje Bergström
On 21.12.2012 15:50, Lucas Stach wrote:
 This has to be resolved before merging. Personally I'm in favour of
 keeping reg access patterns close to what is done in other parts of the
 kernel.

I haven't so far received comments from too many people, so that's why I
left it as is.

  * Uses still CMA helpers. IOMMU support will replace CMA with host1x
specific allocator.
 
 I really want the allocator issue resolved before talking about merging
 those patches. Proper IOMMU support will require a bit of rework of the
 current upstream IOMMU API, so it will still be a bit out.
 
 But if you don't mind I'll try to implement the host1x allocator over
 the holidays and provide an incremental patch.

Do you mean host1x CMA allocator using dma mapping API? That'd be great
if you could help out. I've just tried to concentrate on getting ok for
base essentials before doing any extra work.

Terje

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


Re: [PATCHv4 8/8] gpu: host1x: Register DRM dummy device

2012-12-21 Thread Lucas Stach
Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
 Register a dummy device for tegradrm, and provide a getter to
 access the device.
 
 Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
 ---
[...]
 diff --git a/drivers/gpu/host1x/drm.c b/drivers/gpu/host1x/drm.c
 new file mode 100644
 index 000..eaaaeed
 --- /dev/null
 +++ b/drivers/gpu/host1x/drm.c
 @@ -0,0 +1,51 @@
 +/*
 + * Tegra host1x driver DRM dummy device
 + *
 + * Copyright (c) 2012, NVIDIA Corporation.
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms and conditions of the GNU General Public License,
 + * version 2, as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope 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/.
 + */
 +
 +#include linux/platform_device.h
 +#include linux/dma-mapping.h
 +#include linux/module.h
 +#include drm.h
 +#include dev.h
 +
 +int host1x_register_drm_device(struct host1x *host1x)
 +{
 + struct platform_device *drm_device;
 +
 + drm_device = platform_device_register_simple(tegradrm, -1, NULL, 0);
 + if (!drm_device)
 + return -ENOMEM;
 + dma_set_coherent_mask(drm_device-dev, DMA_BIT_MASK(32));
 +
This might not be necessary once we move the allocator to host1x.

 + host1x-drm_device = drm_device;
 + return 0;
 +}
 +EXPORT_SYMBOL(host1x_register_drm_device);
 +
 +void host1x_unregister_drm_device(struct host1x *host1x)
 +{
 + if (host1x-drm_device)
 + platform_device_unregister(host1x-drm_device);
 +}
 +EXPORT_SYMBOL(host1x_unregister_drm_device);
 +
 +struct platform_device *host1x_drm_device(struct platform_device *pdev)
 +{
 + struct host1x *host = platform_get_drvdata(pdev);
 + return host-drm_device;
 +}
 +EXPORT_SYMBOL(host1x_drm_device);
This should be called host1x_get_drm_device




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


Re: [PATCHv4 0/8] Support for Tegra 2D hardware

2012-12-21 Thread Lucas Stach
Am Freitag, den 21.12.2012, 15:57 +0200 schrieb Terje Bergström:
 On 21.12.2012 15:50, Lucas Stach wrote:
  This has to be resolved before merging. Personally I'm in favour of
  keeping reg access patterns close to what is done in other parts of the
  kernel.
 
 I haven't so far received comments from too many people, so that's why I
 left it as is.
 
   * Uses still CMA helpers. IOMMU support will replace CMA with host1x
 specific allocator.
  
  I really want the allocator issue resolved before talking about merging
  those patches. Proper IOMMU support will require a bit of rework of the
  current upstream IOMMU API, so it will still be a bit out.
  
  But if you don't mind I'll try to implement the host1x allocator over
  the holidays and provide an incremental patch.
 
 Do you mean host1x CMA allocator using dma mapping API? That'd be great
 if you could help out. I've just tried to concentrate on getting ok for
 base essentials before doing any extra work.
 
Yes, exactly that.

I'll provide comments to the other patches when I find time to do so.
Digging in the code might help with this.

Regards,
Lucas

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


System freezes with radeon DRM driver since kernel 3.6

2012-12-21 Thread Stephan Seitz

Hi!

filename: /lib/modules/3.7.0-Dom0/kernel/drivers/gpu/drm/radeon/radeon.ko

hardware:
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730XT 
[Radeon HD 4670] (prog-if 00 [VGA controller])
Subsystem: Hightech Information System Ltd. Device 2003
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at e500 (64-bit, non-prefetchable) [size=64K]
Region 4: I/O ports at b000 [size=256]
[virtual] Expansion ROM at e400 [disabled] [size=128K]
Capabilities: access denied

01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI Audio 
[Radeon HD 4000 series]
Subsystem: Hightech Information System Ltd. Device aa38
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 63
Region 0: Memory at e501 (64-bit, non-prefetchable) [size=16K]
Capabilities: access denied
Kernel driver in use: snd_hda_intel

My system is debian testing with self-made kernels. The system is working 
as Dom0 under Xen 4.1.


Since kernel 3.6 the drm radeon driver freezes the system after some 
time. This time can be 10 minutes or some hours. Since the system is 
completely frozen I don’t know if there are error messages displayed, but 
the log contains nothing. Simply pressing the reset switch won’t reset 
the graphic card (no output), I have to switch off the system to get the 
card working again.


I’m attaching the dmesg output after loading the kernel module.

Merry christmas and happy new year!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
61 2012-12-18T07:38:59.531148+01:00 osgiliath kernel  - - [ 1207.182681] 
[drm] radeon kernel modesetting enabled.
71 2012-12-18T07:38:59.531167+01:00 osgiliath kernel  - - [ 1207.182727] xen: 
registering gsi 16 triggering 0 polarity 1
61 2012-12-18T07:38:59.531169+01:00 osgiliath kernel  - - [ 1207.182731] 
Already setup the GSI :16
61 2012-12-18T07:38:59.533042+01:00 osgiliath kernel  - - [ 1207.183473] 
[drm] initializing kernel modesetting (RV730 0x1002:0x9490 0x1787:0x2003).
61 2012-12-18T07:38:59.533054+01:00 osgiliath kernel  - - [ 1207.183574] 
[drm] register mmio base: 0xE500
61 2012-12-18T07:38:59.533056+01:00 osgiliath kernel  - - [ 1207.183576] 
[drm] register mmio size: 65536
61 2012-12-18T07:38:59.533058+01:00 osgiliath kernel  - - [ 1207.183883] ATOM 
BIOS: RV730XT
61 2012-12-18T07:38:59.533060+01:00 osgiliath kernel  - - [ 1207.183897] 
radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M 
used)
61 2012-12-18T07:38:59.533062+01:00 osgiliath kernel  - - [ 1207.183900] 
radeon :01:00.0: GTT: 512M 0x2000 - 0x3FFF
61 2012-12-18T07:38:59.533065+01:00 osgiliath kernel  - - [ 1207.183901] 
[drm] Detected VRAM RAM=512M, BAR=256M
61 2012-12-18T07:38:59.533067+01:00 osgiliath kernel  - - [ 1207.183903] 
[drm] RAM width 128bits DDR
61 2012-12-18T07:38:59.533069+01:00 osgiliath kernel  - - [ 1207.183947] 
[TTM] Zone  kernel: Available graphics memory: 3496544 kiB
61 2012-12-18T07:38:59.533071+01:00 osgiliath kernel  - - [ 1207.183949] 
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
61 2012-12-18T07:38:59.533073+01:00 osgiliath kernel  - - [ 1207.183950] 
[TTM] Initializing pool allocator
61 2012-12-18T07:38:59.533075+01:00 osgiliath kernel  - - [ 1207.183957] 
[TTM] Initializing DMA pool allocator
61 2012-12-18T07:38:59.533077+01:00 osgiliath kernel  - - [ 1207.183975] 
[drm] radeon: 512M of VRAM memory ready
61 2012-12-18T07:38:59.533080+01:00 osgiliath kernel  - - [ 1207.183977] 
[drm] radeon: 512M of GTT memory ready.
61 2012-12-18T07:38:59.533082+01:00 osgiliath kernel  - - [ 1207.183979] 
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
61 2012-12-18T07:38:59.533084+01:00 osgiliath kernel  - - [ 1207.183980] 
[drm] Driver supports precise vblank timestamp query.
61 2012-12-18T07:38:59.533086+01:00 osgiliath kernel  - - [ 1207.184067] 
radeon :01:00.0: radeon: using MSI.
61 2012-12-18T07:38:59.533088+01:00 osgiliath kernel  - - [ 1207.184097] 
[drm] radeon: irq initialized.
61 2012-12-18T07:38:59.533090+01:00 osgiliath kernel  - - [ 1207.184100] 
[drm] GART: num cpu pages 131072, num gpu pages 131072
61 2012-12-18T07:38:59.533092+01:00 osgiliath kernel  - - [ 1207.184836] 
[drm] probing gen 2 caps for device 8086:2e21 

Re: [PATCHv4 8/8] gpu: host1x: Register DRM dummy device

2012-12-21 Thread Thierry Reding
On Fri, Dec 21, 2012 at 02:53:51PM +0100, Lucas Stach wrote:
 Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
[...]
  +void host1x_unregister_drm_device(struct host1x *host1x)
  +{
  +   if (host1x-drm_device)
  +   platform_device_unregister(host1x-drm_device);
  +}
  +EXPORT_SYMBOL(host1x_unregister_drm_device);
  +
  +struct platform_device *host1x_drm_device(struct platform_device *pdev)
  +{
  +   struct host1x *host = platform_get_drvdata(pdev);
  +   return host-drm_device;
  +}
  +EXPORT_SYMBOL(host1x_drm_device);
 This should be called host1x_get_drm_device

Or maybe even host1x_drm_get_device() to make it more obvious that it
doesn't return a struct drm_device. Also I think it would be better to
make it take a struct device * and return a struct device * instead.
Users of the API will probably call this like so:

struct device *dummy = host1x_drm_get_device(pdev-dev.parent);
struct drm_device *drm = dev_get_drvdata(dummy);

So we save ourselves some needless up-casting.

Thierry


pgpgrXKY3io4d.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: System freezes with radeon DRM driver since kernel 3.6

2012-12-21 Thread Alex Deucher
On Thu, Dec 20, 2012 at 5:09 AM, Stephan Seitz
stse+...@fsing.rootsland.net wrote:
 Hi!

 filename: /lib/modules/3.7.0-Dom0/kernel/drivers/gpu/drm/radeon/radeon.ko

 hardware:
 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
 RV730XT [Radeon HD 4670] (prog-if 00 [VGA controller])
 Subsystem: Hightech Information System Ltd. Device 2003
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
 Region 2: Memory at e500 (64-bit, non-prefetchable) [size=64K]
 Region 4: I/O ports at b000 [size=256]
 [virtual] Expansion ROM at e400 [disabled] [size=128K]
 Capabilities: access denied

 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI
 Audio [Radeon HD 4000 series]
 Subsystem: Hightech Information System Ltd. Device aa38
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin B routed to IRQ 63
 Region 0: Memory at e501 (64-bit, non-prefetchable) [size=16K]
 Capabilities: access denied
 Kernel driver in use: snd_hda_intel

 My system is debian testing with self-made kernels. The system is working as
 Dom0 under Xen 4.1.

 Since kernel 3.6 the drm radeon driver freezes the system after some time.
 This time can be 10 minutes or some hours. Since the system is completely
 frozen I don’t know if there are error messages displayed, but the log
 contains nothing. Simply pressing the reset switch won’t reset the graphic
 card (no output), I have to switch off the system to get the card working
 again.

Did you also change the userspace drivers (mesa, xf86-video-ati)?  If
you only changed the kernel version, can you bisect?  If you updated
multiple components, can you sort out which one caused the issue?

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


Re: [PATCHv4 5/8] drm: tegra: Remove redundant host1x

2012-12-21 Thread Thierry Reding
On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
 From: Arto Merilainen amerilai...@nvidia.com
[...]
 diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
[...]
 +static int tegra_drm_add_client(struct device *dev, void *data)
 +{
 + static const char * const compat[] = {
 + nvidia,tegra20-dc,
 + nvidia,tegra20-hdmi,
 + nvidia,tegra30-dc,
 + nvidia,tegra30-hdmi,
 + };
 + struct tegradrm *tegradrm = data;
 + struct tegra_drm_client_entry *client;
 + unsigned int i;
 +
 + for (i = 0; i  ARRAY_SIZE(compat); i++) {
 + if (of_device_is_compatible(dev-of_node, compat[i]) 
 + of_device_is_available(dev-of_node)) {
 + client = kzalloc(sizeof(*client), GFP_KERNEL);
 + if (!client)
 + return -ENOMEM;
 +
 + INIT_LIST_HEAD(client-list);
 + client-np = of_node_get(dev-of_node);
 +
 + list_add_tail(client-list, tegradrm-drm_clients);
 + dev_set_drvdata(dev, tegradrm);

This should go away now that we have an accessor for this, right?

 +static int tegra_drm_parse_dt(struct tegradrm *tegradrm)
 +{
 + int err;
 + struct device *dev;
 +
 + /* host1x is parent of all devices */
 + dev = bus_find_device_by_name(platform_bus_type, NULL, host1x);
 + if (!dev)
 + return -ENODEV;
 +
 + /* find devices that are available and add them into the 'required'
 +  * list */
 + err = device_for_each_child(dev, tegradrm, tegra_drm_add_client);
 +
 + return err;
 +}

I don't see why we can't keep the original code here. The problem with
your approach is that you'll match on a global device host1x, regardless
of it's relationship to tegra-drm. Instead what you should be doing is
use the hierarchical information that you have to make this work. So the
dummy device should be registered as a child device of host1x, because
that allows the host1x device to be obtained from the dummy's parent. In
that way you can use the host1x device's of_node to search through the
devicetree. That's precisely what the existing code does and I see no
reason to change that.

 +static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
 +{
 +
 +}
 +

This can be removed, right?

 +static struct platform_driver tegra_drm_platform_driver = {
 + .driver = {
 + .name = tegradrm,

This should be tegra-drm to match the module name.

 diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
[...]
 index 3a843a7..34cc3a1 100644
 --- a/drivers/gpu/drm/tegra/drm.h
 +++ b/drivers/gpu/drm/tegra/drm.h
 @@ -17,6 +17,7 @@
  #include drm/drm_gem_cma_helper.h
  #include drm/drm_fb_cma_helper.h
  #include drm/drm_fixed.h
 +#include drm/tegra_drm.h
  
  struct tegra_framebuffer {
   struct drm_framebuffer base;
 @@ -28,17 +29,11 @@ static inline struct tegra_framebuffer 
 *to_tegra_fb(struct drm_framebuffer *fb)
   return container_of(fb, struct tegra_framebuffer, base);
  }
  
 -struct host1x {
 - struct drm_device *drm;
 +struct tegradrm {

Similarly, this should be tegra_drm.

 -struct host1x_client;
 +struct tegra_drm_client;

I don't see the point in renaming this. All of the devices are still
host1x clients, right? This patch would be a whole shorter if we didn't
rename these. None of these symbols are exported either so there's not
much chance for them to clash with anything.

  static int tegra_hdmi_probe(struct platform_device *pdev)
  {
 - struct host1x *host1x = dev_get_drvdata(pdev-dev.parent);
   struct tegra_hdmi *hdmi;
   struct resource *regs;
   int err;
 + struct tegradrm *tegradrm = platform_get_drvdata(pdev);

I think we all agreed already that you shouldn't be mucking with the
driver private data in this way.

 diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
 new file mode 100644
 index 000..8632f49
 --- /dev/null
 +++ b/include/drm/tegra_drm.h
 @@ -0,0 +1,20 @@
 +/*
 + * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms and conditions of the GNU General Public License,
 + * version 2, as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope 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/.
 + */
 +
 +#ifndef _TEGRA_DRM_H_
 +#define _TEGRA_DRM_H_
 +
 +#endif

This can be removed as well.

Thierry


pgpbd2X4IuClE.pgp
Description: PGP signature
___

[PATCH] uxa: Align tiled surface size to an number of tiled rows

2012-12-21 Thread Chris Wilson
Align surface sizes to an even number of tile rows to cater for sampler
prefetch, as shown by enabling GPU invalid PTE detection (i.e. clearing
the valid bit of the PTE).
---

We are investigating bug
https://bugs.freedesktop.org/show_bug.cgi?id=55984 where the only lead
so far is the ordering of eviction under memory pressure. This patch
seems promising because the GPU is detecting that we are accessing invalid
pages beyond the end of our allocations (and so the eviction may lead us
to randomly read the scratch PTE and randomly hang the GPU), however the
only bug that I have seen with such a tell-tale error state is
https://bugzilla.redhat.com/show_bug.cgi?id=877461
-Chris

---
 src/intel_uxa.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index f5ac0a6..2f14173 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -209,7 +209,7 @@ intel_uxa_pixmap_compute_size(PixmapPtr pixmap,
tile_height = 8;
else
tile_height = 32;
-   aligned_h = ALIGN(h, tile_height);
+   aligned_h = ALIGN(h, 2*tile_height);
 
*stride = intel_get_fence_pitch(intel,
ALIGN(pitch, 512),
-- 
1.7.10.4

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


[Bug 58568] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

2012-12-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=58568

Paul Menzel paulepan...@users.sourceforge.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG
 CC||paulepanter@users.sourcefor
   ||ge.net

--- Comment #2 from Paul Menzel paulepan...@users.sourceforge.net ---
(In reply to comment #1)
 Make sure pci quirks are enabled in your kernel config.  Can you bisect?

That was it. I had those disabled! Sorry for the noise.

-- 
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: System freezes with radeon DRM driver since kernel 3.6

2012-12-21 Thread Alex Deucher
On Fri, Dec 21, 2012 at 10:14 AM, Stephan Seitz
stse+...@fsing.rootsland.net wrote:
 On Fri, Dec 21, 2012 at 09:30:39AM -0500, Alex Deucher wrote:

 On Thu, Dec 20, 2012 at 5:09 AM, Stephan Seitz
 stse+...@fsing.rootsland.net wrote:

 filename: /lib/modules/3.7.0-Dom0/kernel/drivers/gpu/drm/radeon/radeon.ko

 hardware:
 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
 RV730XT [Radeon HD 4670] (prog-if 00 [VGA controller])
 Subsystem: Hightech Information System Ltd. Device 2003
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr-
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
 Region 2: Memory at e500 (64-bit, non-prefetchable)
 [size=64K]
 Region 4: I/O ports at b000 [size=256]
 [virtual] Expansion ROM at e400 [disabled] [size=128K]
 Capabilities: access denied

 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI
 Audio [Radeon HD 4000 series]
 Subsystem: Hightech Information System Ltd. Device aa38
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr-
 Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin B routed to IRQ 63
 Region 0: Memory at e501 (64-bit, non-prefetchable)
 [size=16K]
 Capabilities: access denied
 Kernel driver in use: snd_hda_intel

 My system is debian testing with self-made kernels. The system is working
 as
 Dom0 under Xen 4.1.

 Since kernel 3.6 the drm radeon driver freezes the system after some
 time.
 This time can be 10 minutes or some hours. Since the system is completely
 frozen I don’t know if there are error messages displayed, but the log
 contains nothing. Simply pressing the reset switch won’t reset the
 graphic
 card (no output), I have to switch off the system to get the card working
 again.


 Did you also change the userspace drivers (mesa, xf86-video-ati)?  If


 This system is a console system, X is only used sometimes. So while there
 may be updates of other components (it is Debian testing after all) the
 problem occurs in console mode without running X or mesa.
 And rebooting the old 3.5 kernel solves the problem.

 you only changed the kernel version, can you bisect?  If you updated


 Not without some help,. I’m no programmer. You probably mean I should test
 different git commits?

Git provides a a bisect option that allows you to track down when a
problem was introduced.  You'll need a copy of the kernel git tree.
You can follow a tutorial like this one:
http://www.landley.net/writing/git-bisect-howto.html
git will bisect the tree picking commits for you to try.  You
basically build, install, and test the commit git bisect picks for
you.  If it works, you report it to get by saying 'git bisect good',
if it's bad, you tell git by saying 'git bisect bad' after you report,
git will pick another commit and you continue until the problematic
commit has been identified.

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


Re: [PATCHv16 0/7] of: add display helper

2012-12-21 Thread Leela Krishna Amudala
Hello All,
Any comments for this patch set..?

Best Wishes,
Leela Krishna Amudala.

On Tue, Dec 18, 2012 at 10:34 PM, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:

 Hi!

 Finally, right in time before the end of the world on friday, v16 of the
 display helpers.

 Changes since v15:
 - move include/linux/{videomode,display_timing}.h to include/video
 - move include/linux/of_{videomode,display_timing}.h to
 include/video
 - reimplement flags: add VESA flags and data flags
 - let pixelclock in struct videomode be unsigned long
 - rename of_display_timings_exists to of_display_timings_exist
 - revise logging/error messages: replace __func__ with
 np-full_name
 - rename pixelclk-inverted to pixelclk-active
 - revise comments in code

 Changes since v14:
 - fix const struct * warning
 (reported by: Leela Krishna Amudala
 l.kris...@samsung.com)
 - return -EINVAL when htotal or vtotal are zero
 - remove unreachable code in of_get_display_timings
 - include headers in .c files and not implicit in .h
 - sort includes alphabetically
 - fix lower/uppercase in binding documentation
 - rebase onto v3.7-rc7

 Changes since v13:
 - fix const struct * warning
 (reported by: Laurent Pinchart
 laurent.pinch...@ideasonboard.com)
 - prevent division by zero in fb_videomode_from_videomode

 Changes since v12:
 - rename struct display_timing to via_display_timing in via
 subsystem
 - fix refreshrate calculation
 - fix const struct * warnings
 (reported by: Manjunathappa, Prakash prakash...@ti.com)
 - some CodingStyle fixes
 - rewrite parts of commit messages and display-timings.txt
 - let display_timing_get_value get all values instead of just
 typical

 Changes since v11:
 - make pointers const where applicable
 - add reviewed-by Laurent Pinchart

 Changes since v10:
 - fix function name (drm_)display_mode_from_videomode
 - add acked-by, reviewed-by, tested-by

 Changes since v9:
 - don't leak memory when previous timings were correct
 - CodingStyle fixes
 - move blank lines around

 Changes since v8:
 - fix memory leaks
 - change API to be more consistent (foo_from_bar(struct bar,
 struct foo))
 - include headers were necessary
 - misc minor bugfixes

 Changes since v7:
 - move of_xxx to drivers/video
 - remove non-binding documentation from display-timings.txt
 - squash display_timings and videomode in one patch
 - misc minor fixes

 Changes since v6:
 - get rid of some empty lines etc.
 - move functions to their subsystems
 - split of_ from non-of_ functions
 - add at least some kerneldoc to some functions

 Changes since v5:
 - removed all display stuff and just describe timings

 Changes since v4:
 - refactored functions

 Changes since v3:
 - print error messages
 - free alloced memory
 - general cleanup

 Changes since v2:
 - use hardware-near property-names
 - provide a videomode structure
 - allow ranges for all properties (min,typ,max)
 - functions to get display_mode or fb_videomode

 Regards,
 Steffen



 Steffen Trumtrar (7):
   viafb: rename display_timing to via_display_timing
   video: add display_timing and videomode
   video: add of helper for display timings/videomode
   fbmon: add videomode helpers
   fbmon: add of_videomode helpers
   drm_modes: add videomode helpers
   drm_modes: add of_videomode helpers

  .../devicetree/bindings/video/display-timing.txt   |  109 +
  drivers/gpu/drm/drm_modes.c|   70 ++
  drivers/video/Kconfig  |   21 ++
  drivers/video/Makefile |4 +
  drivers/video/display_timing.c |   24 ++
  drivers/video/fbmon.c  |   94 
  drivers/video/of_display_timing.c  |  239
 
  drivers/video/of_videomode.c   |   54 +
  drivers/video/via/hw.c |6 +-
  drivers/video/via/hw.h |2 +-
  drivers/video/via/lcd.c|2 +-
  drivers/video/via/share.h  |2 +-
  drivers/video/via/via_modesetting.c|8 +-
  drivers/video/via/via_modesetting.h|6 +-
  drivers/video/videomode.c  |   39 
  include/drm/drmP.h |9 +
  include/linux/fb.h |8 +
  include/video/display_timing.h |  124 ++
  include/video/of_display_timing.h  |   20 ++
  

Re: [PATCH] drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

2012-12-21 Thread Jerome Glisse
On Thu, Dec 20, 2012 at 9:34 PM,  alexdeuc...@gmail.com wrote:
 From: Alex Deucher alexander.deuc...@amd.com

 It's used in a recent mesa commit:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
 and there may be some other cases in the future where it's required.

 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc: sta...@vger.kernel.org

Reviewed-by: Jerome Glisse jgli...@redhat.com

 ---
  drivers/gpu/drm/radeon/evergreen_cs.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
 b/drivers/gpu/drm/radeon/evergreen_cs.c
 index 5cea852..7a44566 100644
 --- a/drivers/gpu/drm/radeon/evergreen_cs.c
 +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
 @@ -3316,6 +3316,7 @@ static bool evergreen_vm_reg_valid(u32 reg)

 /* check config regs */
 switch (reg) {
 +   case WAIT_UNTIL:
 case GRBM_GFX_INDEX:
 case CP_STRMOUT_CNTL:
 case CP_COHER_CNTL:
 --
 1.7.7.5

 ___
 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 1/2] drm/exynos: fix flags in dma buf exporting

2012-12-21 Thread Inki Dae
Applied.

Thanks,
Inki Dae

2012/12/20 Seung-Woo Kim sw0312@samsung.com

 This patch fixes flags passed to dma buf exporting.

 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 Signed-off-by: Kyungmin.park kyungmin.p...@samsung.com
 ---
 I found exynos drm also sends wrong flag for dma buf exporting. So I send
 this
 based on drm-fixes branch.

  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
 b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
 index fae1f2e..8cb8c56 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
 @@ -185,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct
 drm_device *drm_dev,
 struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);

 return dma_buf_export(exynos_gem_obj, exynos_dmabuf_ops,
 -   exynos_gem_obj-base.size, 0600);
 +   exynos_gem_obj-base.size, flags);
  }

  struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device
 *drm_dev,
 --
 1.7.4.1

 ___
 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: [pull] radeon drm-fixes-3.8

2012-12-21 Thread Alex Deucher
One more patch I just pushed:


commit 668bbc81baf0f34df832d8aca5c7d5e19a493c68
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Thu Dec 20 21:19:32 2012 -0500

drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

It's used in a recent mesa commit:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
and there may be some other cases in the future where it's required.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
Cc: sta...@vger.kernel.org


On Thu, Dec 20, 2012 at 6:39 PM,  alexdeuc...@gmail.com wrote:
 From: Alex Deucher alexander.deuc...@amd.com

 Hi Dave,

   Just a few fixes from the last week or so.

 Alex

 The following changes since commit 0953e76e91f4b6206cef50bd680696dc6bf1ef99:

   drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling 
 (2012-12-20 07:46:20 +1000)

 are available in the git repository at:
   git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8

 Jerome Glisse (4):
   drm/radeon: don't leave fence blocked process on failed GPU reset
   drm/radeon: avoid deadlock in pm path when waiting for fence
   drm/radeon: restore modeset late in GPU reset path
   drm/radeon: add support for MEM_WRITE packet

  drivers/gpu/drm/radeon/evergreen_cs.c  |   29 +++
  drivers/gpu/drm/radeon/r600_cs.c   |   29 +++
  drivers/gpu/drm/radeon/radeon.h|3 +-
  drivers/gpu/drm/radeon/radeon_device.c |   17 +--
  drivers/gpu/drm/radeon/radeon_drv.c|3 +-
  drivers/gpu/drm/radeon/radeon_fence.c  |   49 +--
  drivers/gpu/drm/radeon/radeon_pm.c |   15 --
  7 files changed, 121 insertions(+), 24 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC] drm/exynos: added hdcp driver for contents protection.

2012-12-21 Thread Inki Dae
2012/12/21 Alan Cox a...@lxorguk.ukuu.org.uk

 On Fri, 21 Dec 2012 18:47:57 +0900
 Eunchul Kim chulspro@samsung.com wrote:

  HDCP stands for High-bandwidth Digital Content Protection.
  This is a newer form of Digital Rights Management(secure DRM)

 was.. the master key was leaked long ago 8)

  that was designed to control digital video and audio content.
  Contains an integrated HDCP encryption engine for video/audio content
 protection.
  supports version HDCP v1.1.
  Exynos AP supports embedded HDCP key system.
  The HDCP key value is fused during fabrication, based on customer's
 request.

 For this code to go into the kernel it must do so in GPL form. Can you
 confirm Samsung has the necessary IPR and permissions to grant use of
 this to all third parties as the GPL requires not just to specific
 customers ? (whether they can use it usefully is a different question as
 obviously they need the key.

 I ask this because there are currently a lot of lawyers busy trying to
 sue makers of some HDCP aware devices.

  +
  + dev_info(dev, drm hdcp registered successfully.\n);

 This sort of stuff ought to be dev_dbg, minor item


  diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h
 b/drivers/gpu/drm/exynos/exynos_hdcp.h
  new file mode 100644
  index 000..86d0c79
  --- /dev/null
  +++ b/drivers/gpu/drm/exynos/exynos_hdcp.h
  @@ -0,0 +1,47 @@
  +/*
  + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
  + *
  + * Authors:
  + *   Eunchul Kim chulspro@samsung.com
  + *
  + * 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,
 sublicense,
  + * 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 NONINFRINGEMENT.  IN NO EVENT
 SHALL
  + * VA LINUX SYSTEMS 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.
  + */


 Two things strike me here - firstly kernel code is GPLv2 or later (or
 dual licensed) as per the Signed-off-by: certification. I don't see any
 problem in the above but to be sure you realise.

 Secondly - VA Linux systems ??? has this been copied from some random
 file and not updated correctly or does the old VA Linux Systems really
 own bits of this code.


And also I found out that other exynos files also haven't been updated
correctly. Definitely this was our mistakes.

Thanks,
Inki Dae



 Other questions I'll look at later - in particular
 - I don't see how the work queue is locked against the main thread of
   execution within the driver
 - There is a general DRI question here about HDCP and interfaces -
   several out of tree drivers do HDCP and perhaps a common API would be
   sensible ?

 Alan
 ___
 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


[PATCH] drm/exynos: change file license to GPL

2012-12-21 Thread inki . dae
From: Inki Dae daei...@gmail.com

This patch changes file license to GPL

Most of exynos files had been copied from some random
file and not updated correctly. So this patch corrects
the file license.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_buf.h   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_connector.c | 22 --
 drivers/gpu/drm/exynos/exynos_drm_connector.h | 22 --
 drivers/gpu/drm/exynos/exynos_drm_core.c  | 22 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 22 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  | 22 --
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c| 22 --
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h| 22 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_encoder.h   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 22 --
 drivers/gpu/drm/exynos/exynos_drm_fb.h| 22 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 22 --
 drivers/gpu/drm/exynos/exynos_drm_fimc.h  | 22 --
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_gem.h   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_gsc.h   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  | 22 --
 drivers/gpu/drm/exynos/exynos_drm_iommu.c | 22 --
 drivers/gpu/drm/exynos/exynos_drm_iommu.h | 22 --
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_rotator.h   | 22 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  | 22 --
 drivers/gpu/drm/exynos/exynos_hdmi.h  | 22 --
 include/drm/exynos_drm.h  | 22 --
 include/uapi/drm/exynos_drm.h | 22 --
 30 files changed, 120 insertions(+), 540 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 9601bad..13a8489 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -3,24 +3,10 @@
  * Copyright (c) 2011 Samsung Electronics Co., Ltd.
  * Author: Inki Dae inki@samsung.com
  *
- * 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, sublicense,
- * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
- * VA LINUX SYSTEMS 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.
+ * 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 drm/drmP.h
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.h 
b/drivers/gpu/drm/exynos/exynos_drm_buf.h
index 25cf162..a6412f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.h
@@ -3,24 +3,10 @@
  * Copyright (c) 2011 Samsung Electronics Co., Ltd.
  * Author: Inki Dae inki@samsung.com
  *
- * 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, 

[Bug 52360] [32bit/r600-llvm] Counter Strike 1.6 segfaults on start

2012-12-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=52360

--- Comment #2 from okias d.ok...@gmail.com ---
Created attachment 71943
  -- https://bugs.freedesktop.org/attachment.cgi?id=71943action=edit
R600_DUMP_SHADERS.log

R600_DUMP_SHADERS=1

new kernel 3.7.1, mesa-git, llvm-git and still same problem

-- 
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


[GIT PULL] exynos-drm-fixes-3.8

2012-12-21 Thread inki . dae
Hi Dave,

Just bug fix and code cleanup. And most of exynos files had
been copied from some random file and not updated correctly.
This was our mistakes. So it changes file liecnse to GPL.

If there is any problem, please let me know.

Thanks,
Inki Dae

The following changes since commit 0953e76e91f4b6206cef50bd680696dc6bf1ef99:

  drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling 
(2012-12-20 07:46:20 +1000)

are available in the git repository at:

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

for you to fetch changes up to c3586970ff56f1bc26ecb153042ef495fffc42f1:

  drm/exynos: change file license to GPL (2012-12-18 02:52:59 +0900)


Inki Dae (2):
  drm/exynos: consider no iommu support to console framebuffer
  drm/exynos: change file license to GPL

Seung-Woo Kim (1):
  drm/exynos: fix flags in dma buf exporting

 drivers/gpu/drm/exynos/exynos_drm_buf.c   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_buf.h   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_connector.c | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_connector.h | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_core.c  | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c| 24 +++
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h| 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_encoder.h   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_fb.h| 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 44 +--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.h  | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.h   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_iommu.c | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_iommu.h | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.h   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  | 22 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.h  | 22 +++---
 include/drm/exynos_drm.h  | 22 +++---
 include/uapi/drm/exynos_drm.h | 22 +++---
 30 files changed, 139 insertions(+), 545 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: i-g-t test for gem flink race

2012-12-21 Thread Daniel Vetter
On Fri, Dec 21, 2012 at 3:46 AM, Dave Airlie airl...@gmail.com wrote:
 On Fri, Dec 21, 2012 at 11:49 AM, Dave Airlie airl...@gmail.com wrote:
 As we talked on irc, I decided to write a test case and it actually
 seems to trigger the race.

 Really its insane userspace behaviour and I'm not really sure we
 should care to fix, I can't see it causing an oops, more userspace
 does something insane, it gets a bad result, but I'll contemplate it a
 bit more.

 Yeah after considering this a bit more, I really think its just a
 userspace problem, don''t go closing gem object handles that other
 threads could be using. Lets state any result after doing something
 like that is undefined, and the current behaviour is within spec.

Yeah, I've looked at the code again and I think we can't oops or leak
stuff with the current code. But userspace could end up with a gem
handle and a removed flink name, but I agree now that we don't need to
care about this for flink. Important is just that a non-zero flink
can't be observed without a corresponding reference, for otherwise
we'd need to resurrect zombies. I've looked a the code again and I
think we're safe.

Looking at dma-buf I think the same applies, if userspace races
imports against gem_close it's kinda not our problem. I've thought for
a while that for cross-process situations we need better guarantees
since the dma-buf can exists on its own and doesn't need an open
userspace gem handle to survive like an flink name. But then I think
we just have to be careful with locking at import time to so that we
don't end up with two gem objects for the same dma-buf somehow. Much
simpler than worrying about close vs. import races.

For the racing igt test itself I think that one could still be useful
- just make it never fail and we can use it to hunt for leaks and
other issues in that code.

Cheers, 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


Re: Hangcheck timer elapsed..

2012-12-21 Thread Daniel Vetter
On Fri, Dec 21, 2012 at 4:56 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 This thing isn't repeatable, and it can go days without happening, but
 it has happened several times now over the last several weeks, to the
 point where it is very annoying.

 I get:

   [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
   [drm] capturing error event; look for more information in
 /debug/dri/0/i915_error_state
   [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
   [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
   [drm:i915_reset] *ERROR* Failed to reset chip.

 and then I need to reboot, because restarting X just causes it to be
 slow and unaccelerated.

 I'm attaching the i915_error_state thing, although I suspect it's
 useless, since I got it after an X restart. But maybe it shows why
 even the X restart doesn't do anything.

 This is a Westmere setup: it's a

   Intel(R) Core(TM) i5 CPU 670  @ 3.47GHz

 and dmesg doesn't have anything interesting in it at all. Running
 up-to-date Fedora 17.

Yeah, looks like the ilk death which somehow became much easier to hit
in 3.7. Bug to track the various reporters is at

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

 Any ideas about anything in particular I can do to trigger it and help
 debug it? There's usually nothing special going on when this happens.
 This last one was during a kernel build, but the screen was actually
 locked (and I don't even have a fancy screensaver, it's just a blank
 black screen for me).

As far as we know it requires light gpu load (desktop, 3d compositor
seems to help to hit it) with some form of memory/io load. Kernel
compiles, massive svn checkouts or just filling the pagecache with
crap and cleaning it up again seems to be good at triggering it.
Progress in debugging has been extremely slow, especially after we've
disabled rc6 on ilk (attempted an enable in the 3.7 by default of
that) - without rc6 none of the local machines we devs have here can
reproduce the bug any more, and the rc6 hangs have a slightly
different hang signature, so decent chance it's a different bug.

We're suspecting it's an old one, just made somehow much easier to hit
with the changes in 3.7. Chris has some good evidence already that the
hw has stricter alignment requirements than what we implement, but
patches are only just now gathering testing feedback. And after a few
weeks of searching for the loose piece of ducttape so that we can
reattach it I've finally found a slight change in our shrinker
behaviour which might mitigate things. Patch is in testing since a few
days and hasn't blown up yet - which is a record thus far. So I'm
still hopeful that I can forge this quick hack into a real patch to
reapply the lost ducttape.

 Other times, it's just normal desktop. Quite often it is during a
 kernel compile, with loads in the 30+ range, so maybe it's triggered
 by high loads resulting in some program not being hugely responsive
 (maybe losing the drm state?) but quite frankly, I do a *lot* of
 kernel compiles especially during the merge window, so the it
 happened during a kernel compile is not necessarily indicative of any
 deeper causation - it's just that compiling kernels is what I do ;)

 I've gotten hangcheck timers over the years, but it really seems to
 have been getting worse. Please help. If the reset worked and it would
 clear up after I just logged out and back in again, that would already
 be a big thing.

gpu reset state transitions should be much less racy in 3.8 than 3.7,
but that doesn't help if the gpu hangs to quickly. You can try to
resurrect it in that case with

# echo 0  /sys/kernel/debug/dri/0/i915_wedged

We can't really disable that hanging too fast check, since it helps
tremendously in preventing gpu hangs from spiralling into certain
death of the entire system, and so is important for debugging.

Other workarounds to mitigate things are:
- Don't use a 3d compositor, the ddx should transparently fall over to
sw rendering when the gpu is permanently declared dead.
- Using SNA accelaration instead of UXA in the ddx seems to migitate
the hangs a lot (Option AccelMethod SNA in an xorg.conf snippet) -
we suspect it's due to the different layout of the indirect state
objects. UXA has an entire tree of those, SNA packs them into one
single gem object, which seems to tremendously reduce changes that the
gpu/kernel barfs on them and so hangs the gpu.

Oh, and in case you get the urge to flame your drm/i915 maintainer to
crips over this disaster (it's one imo), I'll be offline the next 2
weeks, snowboarding in the swiss alps ;-)

Cheers, 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


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

2012-12-21 Thread Stephen Warren
On 12/21/2012 01:57 AM, Arto Merilainen wrote:
 On 12/20/2012 07:14 PM, Stephen Warren wrote:

 What's wrong with just having each device ask the host1x (its parent)
 for a pointer to the (dummy) tegradrm device. That seems extremely

 
 We are talking about creating a dummy device because:
 - we need to give something for drm_platform_init(),
 - drm related data should be stored somewhere,

Yes to those too, I believe.

 - some data must be passed to all driver probe() functions. This is not
 hw-related data, but just some lists that are used to ensure that all
 drivers have been initialised before calling drm_platform_init().

I haven't really thought through /when/ host1x would create the dummy
device. I guess if tegradrm really must initialize after all the devices
that it uses (rather than using something like deferred probe) then the
above may be true.

 All these issues are purely tegra-drm related and solving them elsewhere
 (in host1x) would be just wrong! host1x would not even use the dummy
 device for anything so creating it there seems bizarre.

I see the situation more like:

* There's host1x hardware.

* There's a low-level driver just for host1x itself; the host1x driver.

* There's a high-level driver for the entire host1x complex of devices.
That is tegradrm. There may be more high-level drivers in the future
(e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x
sub-devices liek tegradrm does).

* The presence of the host1x DT node logically implies that both the two
drivers in the previous two points should be instantiated.

* Linux instantiates a single device per DT node.

* So, it's host1x's responsibility to instantiate the other device(s). I
think it's reasonable for the host1x driver to know exactly what
features the host1x HW complex supports; raw host1x access being one,
and the higher level concept of a tegradrm being another. So, it's
reasonable for host1x to trigger the instantiation of tegradrm.

* If DRM core didn't stomp on the device object's drvdata (or whichever
field it is), I would recommend not creating a dummy device at all, but
rather having the host1x driver directly implement multiple driver
interfaces. There are many examples like this already in the kernel,
e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >