https://bugs.freedesktop.org/show_bug.cgi?id=70303
Priority: medium
Bug ID: 70303
Assignee: dri-devel@lists.freedesktop.org
Summary: Kernel stack trace at drivers/gpu/drm/drm_crtc.c:1992
Severity: normal
Classification: Unclassified
On Tue, Oct 1, 2013 at 5:38 PM, Jani Nikula wrote:
> v2: duplicate intel_connector->edid, not uninitialized edid (Dave Airlie).
Okay I merged this one,
Thanks,
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.or
On Wed, Oct 2, 2013 at 7:23 PM, David Herrmann wrote:
> Hi
>
> This cleans up the bus drivers in DRM. Instead of copying the device
> alloc/free
> semantics into each bus driver (drm_{pci,platform,usb}.c) we now have a
> central
> place in drm_stub.c.
>
> This introduces drm_dev_{alloc,free,regi
>> All drivers embed gem-objects into their own buffer objects. There is no
>> reason to keep drm_gem_object_alloc(), gem->driver_private and
>> ->gem_init_object() anymore.
>>
>> New drivers are highly encouraged to do the same. There is no benefit in
>> allocating gem-objects separately.
Merged
>> This series does some house cleaning on struct drm_device.
Merged 1-9, not sure the last pahole moving stuff around is a real
help or not, will mull it over a bit.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesk
On Wed, Oct 9, 2013 at 3:31 PM, Dave Airlie wrote:
> On Wed, Oct 2, 2013 at 7:23 PM, David Herrmann wrote:
>> Hi
>>
>> This cleans up the bus drivers in DRM. Instead of copying the device
>> alloc/free
>> semantics into each bus driver (drm_{pci,platform,usb}.c) we now have a
>> central
>> plac
On 08.10.2013 09:27, Arto Merilainen wrote:
> This series adds runtime pm support for host1x, gr2d and dc. It retains the
> current behaviour if CONFIG_PM_RUNTIME is not enabled.
>
> The gr2d clock is enabled when a new job is submitted and disabled when
> the work is done. Due to parent->child re
Boots Just Fine (tm)!
The only glitch seems to be that at least on Fedora the boot splash
gets confused and doesn't display much at all.
And since there's no ugly console flickering anymore in between, the
flicker while switching between X servers (VT support is still enabled)
is even more jarrin
On Wed, Oct 09, 2013 at 04:00:00PM +1000, Dave Airlie wrote:
> On Wed, Oct 9, 2013 at 3:31 PM, Dave Airlie wrote:
> > On Wed, Oct 2, 2013 at 7:23 PM, David Herrmann
> > wrote:
> >> Hi
> >>
> >> This cleans up the bus drivers in DRM. Instead of copying the device
> >> alloc/free
> >> semantics i
On Wed, Oct 09, 2013 at 09:18:51AM +0200, Daniel Vetter wrote:
> mode_fits_in_fbdev(struct drm_device *dev,
> struct drm_display_mode *mode)
> {
> +#ifdef CONFIG_DRM_I915_FBDEV
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_i915_gem_object *obj;
On Tue, Oct 08, 2013 at 06:12:15PM -0300, Paulo Zanoni wrote:
> 2013/10/1 Ville Syrjälä :
> > On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> The consoles who need to do something when unbinding or binding can
> >> optionally implement these function
It's better to catch such fallout early, and this way we can rely on
the checking done by the drm core on fb->heigh/width at modeset time.
If we ever support planar formats on intel we might want to look into
a common helper to do all this, but for now this is good enough.
Requested-by: Chris Wil
On Wed, Oct 09, 2013 at 09:09:36AM +0100, Chris Wilson wrote:
> On Wed, Oct 09, 2013 at 09:18:51AM +0200, Daniel Vetter wrote:
> > mode_fits_in_fbdev(struct drm_device *dev,
> >struct drm_display_mode *mode)
> > {
> > +#ifdef CONFIG_DRM_I915_FBDEV
> > struct drm_i915_private *
The log messages speak for themselves
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
The evict code may try to swap them out causing a BUG in the destroy
function.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gp
DRI clients that tried to grab the TTM lock when the master (X server) was
switched away during a VT switch were sent the SIGTERM signal by the
kernel. Fix this so that they are only sent that signal when the master has
exited.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Cc: s
On Wed, 09 Oct 2013, Daniel Vetter wrote:
> Boots Just Fine (tm)!
>
> The only glitch seems to be that at least on Fedora the boot splash
> gets confused and doesn't display much at all.
>
> And since there's no ugly console flickering anymore in between, the
> flicker while switching between X se
https://bugs.freedesktop.org/show_bug.cgi?id=69961
Michel Dänzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=69463
Michel Dänzer changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On Wed, Oct 09, 2013 at 10:33:08AM +0200, Daniel Vetter wrote:
> It's better to catch such fallout early, and this way we can rely on
> the checking done by the drm core on fb->heigh/width at modeset time.
>
> If we ever support planar formats on intel we might want to look into
> a common helper
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #13 from Michel Dänzer ---
(In reply to comment #12)
> I noticed something weird: if I start KDE with desktop effects off it is
> *much* faster and there is corruption in the title bar.
The corruption indicates it's using the native
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #14 from Michel Dänzer ---
(In reply to comment #11)
> The root of the problem *isn't* glamor: I just tried Glamor with Intel
> HD4000 and it works flawlessly. The issue is with mesa.
Could also be the glamor glue code in xf86-video-
Make use of the FAULT_FLAG_ALLOW_RETRY flag to allow dropping the
mmap_sem while waiting for bo idle.
FAULT_FLAG_ALLOW_RETRY appears to be primarily designed for disk waits
but should work just as fine for GPU waits..
Only compile-tested so far pending comments.
Signed-off-by: Thomas Hellstrom
I'm afraid your patch sometimes causes the GPU reset to fail, which
had never happened before IIRC.
The dmesg log from the failure is attached.
Marek
On Tue, Oct 8, 2013 at 6:21 PM, Christian König wrote:
> Hi Marek,
>
> please try the attached patch as a replacement for your signaling all fenc
op 08-10-13 18:47, Jerome Glisse schreef:
> On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
>> On 10/08/2013 04:55 PM, Jerome Glisse wrote:
>>> On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
Am 08.10.2013 16:33, schrieb Jerome Glisse:
> On Tue, Oct 08, 2
Mhm, that doesn't looks like anything related but more like the reset of
the compute ring didn't worked.
How often does that happen? And do you still get the problem where X
waits for a fence that never comes back?
Christian.
Am 09.10.2013 12:36, schrieb Marek Olšák:
I'm afraid your patch s
The host1x driver uses currently syncpoints statically from host1x point of
view. If we do a wait inside a job, it always has a constant value to wait.
host1x supports also doing relative syncpoint waits with respect to syncpoint
bases. This allows doing multiple operations inside a single submit a
This patch adds support for hardware syncpoint bases. This creates
a simple mechanism for waiting an operation to complete in the middle
of the command buffer.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/dev.h | 2 ++
drivers/gpu/host1x/hw/channel_hw.c | 19 +
This patch makes the necessary additions to deliver syncpoint base
to the user space.
This patch splits the index field in the drm_tegra_get_syncpt structure
into three separate fields (index, support_base, base_id). This allows
to keep compatibility over kernel versions:
- The placing of index fi
This patch modifies the gr2d to reserve a base for syncpoint.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/gr2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 27ffcf1..f0c3fd5 100644
--- a/dri
The ring test of the first compute ring always fails and it shouldn't
affect the GPU reset in any way.
I can't tell if the deadlock issue is fixed, because the GPU reset
usually fails with your patch. It always succeeded without your patch.
Marek
On Wed, Oct 9, 2013 at 1:09 PM, Christian König
Fix a typo (iotcl -> ioctl) in the debug message when an unknown IOCTL
is encountered.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e79d8d9..e8737c0 1006
op 08-10-13 18:58, Thomas Hellstrom schreef:
> On 10/08/2013 06:47 PM, Jerome Glisse wrote:
>> On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
>>> On 10/08/2013 04:55 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
> Am 08.10.2013
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #20 from Alex Deucher ---
Does attachment 86939 from bug 57919 help?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=70035
Tasev changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://bugs.freedesktop.org/show_bug.cgi?id=70035
--- Comment #14 from Tasev ---
Created attachment 87338
--> https://bugs.freedesktop.org/attachment.cgi?id=87338&action=edit
dmesg-3.12rc4.txt
The lockup occurs at the 34 seconds of the boot process
--
You are receiving this mail because:
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=62721
--- Comment #4 from Alex Deucher ---
(In reply to Egor Y. Egorov from comment #3)
> (In reply to Alex Deucher from comment #2)
> > Please attach your full dmesg output.
>
> Why "journalctl -a" not enough? If that need I'll post dmesg soon.
>
T
Hi Rob,
On Monday 07 October 2013 03:08 PM, Archit Taneja wrote:
With the new omapdss device model. The user(omapdrm/omapfb) of a omap_dss_device
has to call connect() to use the device. A connect() call can request to defer
probe if the device(or the previous entities in the chain) have missing
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #21 from stevenvandenbrandenst...@gmail.com ---
im sorry to ask but the patch is for the kernel or for this ati-dri (in
archlinux) driver?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #22 from Alex Deucher ---
kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesk
Hey,
op 08-10-13 19:37, John Stultz schreef:
> On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling wrote:
>> On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
>> wrote:
>>> Depending on feedback I'll try reflashing my nexus 7 to stock android, and
>>> work on trying to convert android
>>> syncpoint
On Wed, Oct 9, 2013 at 10:31 AM, Russell King - ARM Linux
wrote:
> On Mon, Oct 07, 2013 at 11:47:55PM +0200, Sebastian Hesselbarth wrote:
>> On 10/07/2013 12:07 AM, Russell King - ARM Linux wrote:
>>> The Armada DRM drivers again, along with the TDA998x HDMI output support,
>>> and an illustration
https://bugs.freedesktop.org/show_bug.cgi?id=68792
--- Comment #4 from Dieter Nützel ---
With this landed, I get this with vlc on my RV730 AGP:
vlc /data/Filme/Serenity\ -\ HD\ DVD\ Trailer.mp4
VLC media player 2.1.0 Rincewind (revision 2.1.0-0-gedd8835)
[0x9a2ee58] main interface error: no suit
Rather, the first member of nvbe is ttm (same address). Got it.
Please, disregard this patch. Thank you.
Geyslan Gregório Bem
hackingbits.com
2013/10/7 Ben Skeggs :
> - Original Message -
>> From: "Geyslan Gregório Bem"
>> To: "Felipe Pena"
>> Cc: "Ben Skeggs" , airl...@linux.ie,
>>
On Tue, Oct 08, 2013 at 11:19:13AM +0200, Jean-Francois Moine wrote:
> The Cubox is an open platform, and I use it just like a desktop PC.
> When its required drivers will be in the mainline, I will do the same
> as I do with PCs: I will not recompile a specific kernel each time
> there are kernel
This patch adds kfree() in ttm_agp_tt_create() to avoide the
memory leak, without this there is a chance of memory leak in
ttm_tt_init() fail case.
Signed-off-by: Jeyaraman R
Signed-off-by: Manjunath Goudar
Cc: David Airlie
Cc: "Paul E. McKenney"
Cc: David Howells
Cc: Thomas Gleixner
Cc: Dav
This patch adds a BACKLIGHT_CLASS_DEVICE dependency to configure the
DRM_SHMOBILE. Without this patch, build system can lead to build failure.
This was observed during randconfig testing, in which DRM_SHMOBILE was
enabled w/o BACKLIGHT_CLASS_DEVICE being enabled. Following was the error:
Building
On 10/08 17:44, Daniel Vetter wrote:
>
> mutex_lock(&dev->mode_config.fb_lock);
> list_for_each_entry(fb, &dev->mode_config.fb_list, base.head) {
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index f221631..057ddeb 100644
> --- a/drivers/gpu/drm/i9
On 10/02/2013 03:24 PM, Tomi Valkeinen wrote:
> Hi Andrzej,
>
> On 02/10/13 15:23, Andrzej Hajda wrote:
>
>>> Using Linux buses for DBI/DSI
>>> =
>>>
>>> I still don't see how it would work. I've covered this multiple times in
>>> previous posts so I'm not going into mor
On Mon, Oct 07, 2013 at 11:47:55PM +0200, Sebastian Hesselbarth wrote:
> On 10/07/2013 12:07 AM, Russell King - ARM Linux wrote:
>> The Armada DRM drivers again, along with the TDA998x HDMI output support,
>> and an illustration to show how to add Armada 610 support (and others.)
>>
>> Rob has look
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #27 from Rune Petersen ---
fun observation:
Instead of reverting, setting this at the end of r600_cp_dma_copy_buffer()
appears to fix it for me:
rctx->b.flags |= R600_CONTEXT_INV_VERTEX_CACHE;
(R600_CONTEXT_INV_CONST_CACHE will
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #23 from Mirko ---
(In reply to comment #20)
> Does attachment 86939 [details] [review] from bug 57919 help?
I'll try it tonight. Patch it's for a specific kernel version?
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=68792
--- Comment #5 from Grigori Goronzy ---
You have to enable VDPAU output as well. If you don't do that, in case the
readback method is used, it won't work because the necessary format conversions
have not been implemented yet (I'm working on it).
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #24 from Alex Deucher ---
It was against my drm-fixes tree, but it should apply pretty easily to most
kernels.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #15 from darkbasic ---
Another user with the same distro (Gentoo) and HD7700 (radeonsi) told me he
doesn't have this problem:
http://phoronix.com/forums/showthread.php?85135-GLAMOR-ized-Radeon-Driver-Shows-Hope-Over-EXA&p=361630#post
Khronos is proposing a change affecting EGL attribute lists, and they
are requesting feedback on this forum thread [1]. They have specifically
requested feedback from the opensource community.
[1]
http://www.khronos.org/message_boards/showthread.php/9138-Requesting-feedback-on-disallowing-handle
https://bugs.freedesktop.org/show_bug.cgi?id=70303
Pete Wright changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #28 from Alexandre Demers ---
(In reply to comment #27)
> fun observation:
>
> Instead of reverting, setting this at the end of r600_cp_dma_copy_buffer()
> appears to fix it for me:
> rctx->b.flags |= R600_CONTEXT_INV_VERTEX_CACH
https://bugs.freedesktop.org/show_bug.cgi?id=70327
Priority: medium
Bug ID: 70327
Assignee: dri-devel@lists.freedesktop.org
Summary: Casting floating point variable to integer not working
properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #1 from tony.wasse...@dolphin-emu.org ---
...cf. first attachment "Full rendered scene with bug visible". Second
attachement "Full rendered scene with software renderer" shows the same scene
rendered properly with "LIBGL_ALWAYS_SOFTWAR
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #2 from tony.wasse...@dolphin-emu.org ---
Created attachment 87355
--> https://bugs.freedesktop.org/attachment.cgi?id=87355&action=edit
Full rendered scene with software renderer
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=70327
tony.wasse...@dolphin-emu.org changed:
What|Removed |Added
Attachment #87353|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #4 from tony.wasse...@dolphin-emu.org ---
Created attachment 87357
--> https://bugs.freedesktop.org/attachment.cgi?id=87357&action=edit
dff file to reproduce the issue by rendering a subset of the reference scene in
Dolphin
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #5 from tony.wasse...@dolphin-emu.org ---
Created attachment 87359
--> https://bugs.freedesktop.org/attachment.cgi?id=87359&action=edit
Output of R600_DEBUG=vs,ps,fs,sbdisasm when rendering the reduced scene
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #6 from tony.wasse...@dolphin-emu.org ---
Steps the reproduce the issue:
1. Clone the dolphin repository from the url provided at
http://code.google.com/p/dolphin-emu/source/checkout
2. Checkout the tev_fixes_new branch at commit 5d8cf
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #7 from tony.wasse...@dolphin-emu.org ---
Created attachment 87360
--> https://bugs.freedesktop.org/attachment.cgi?id=87360&action=edit
Sample GLSL shader that is used during rendering the glitched character
Attached you find one of
Hi Dave,
More radeon fixes for 3.12. Regression fixes for audio and UVD, several
hang fixes, and some dpm fixes.
The following changes since commit 1d083bc93d159ebcb46c5cbeca512ddd74a74e4b:
Merge remote-tracking branch 'nouveau/drm-nouveau-next' into drm-fixes
(2013-10-09 16:09:25 +1000)
ar
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #8 from tony.wasse...@dolphin-emu.org ---
Created attachment 87361
--> https://bugs.freedesktop.org/attachment.cgi?id=87361&action=edit
R600_DEBUG=vs,ps,fs,sbdisasm for small scene with the shader that we actually
use
--
You are re
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #9 from tony.wasse...@dolphin-emu.org ---
Created attachment 87362
--> https://bugs.freedesktop.org/attachment.cgi?id=87362&action=edit
R600_DEBUG=vs,ps,fs,sbdisasm for small scene with the shader where I replaced
"fog" with "0.0" in
Whee, I see some crazy paranoia on the news sites, and I figured I'd
chime in having had to deal with weird DVI->HDMI conversion in the
past..
On Tue, Oct 8, 2013 at 3:29 AM, Christian König wrote:
>
> So the poor little one which came with the gfx card should be sufficient,
> but if you want to
On Tuesday, October 08, 2013 02:40:00 PM Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #29 from Alexandre Demers ---
(In reply to comment #27)
> fun observation:
>
> Instead of reverting, setting this at the end of r600_cp_dma_copy_buffer()
> appears to fix it for me:
> rctx->b.flags |= R600_CONTEXT_INV_VERTEX_CACH
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #10 from Vadim Girlin ---
Created attachment 87364
--> https://bugs.freedesktop.org/attachment.cgi?id=87364&action=edit
patch
This patch should fix the issue (only compile-tested so far, I can't test with
r600g card right now, but
https://bugs.freedesktop.org/show_bug.cgi?id=68792
--- Comment #6 from Dieter Nützel ---
(In reply to comment #5)
> You have to enable VDPAU output as well.
Sorry, but where and how?
In VLC?
*.conf file?
> If you don't do that, in case the
> readback method is used,
I read something about it.
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, October 10, 2013 3:29 AM
> To: Inki Dae
> Cc: Olof Johansson; Sean Paul; devicet...@vger.kernel.org; linux-samsung-
> s...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; DRI
On Thu, 10 Oct 2013, Aaron Lu wrote:
> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
>> On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
>>> +bool backlight_device_registered(enum backlight_type type)
>>> +{
>>> + bool found = false;
>>> + struct backlight_device *bd;
>>> +
>>> +
On Thu, 10 Oct 2013, Aaron Lu wrote:
> On 10/10/2013 12:29 PM, Jani Nikula wrote:
>> On Thu, 10 Oct 2013, Aaron Lu wrote:
>>> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
> +bool backlight_device_registered(enum backlight_type
2013/10/10 Alex Deucher :
> drm/radeon: use hw generated CTS/N values for audio
I'd like to see such patches earlier :| I'm OK with the change for
DCE4+ (Evergreen) (I even suggested that change myself recently), but
I didn't have time to check how this should be programmed on
DCE2/3/4...
I
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross
Cc: Andy Gross
Cc: DRI Development
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers
79 matches
Mail list logo
