> commit 1fcf23d361375645d586756d126b436796ba4fba
> Author: James Simmons
> Date: Sat Jun 8 09:31:57 2013 -0400
>
> via: New KMS ioctls and hardware to support.
>
> Add new VIA pci ids to support newer hardware. Cleanup userspace
> api structs to remove kernel types and add the new K
Hi Linus,
just some GMA500 memory leaks and i915 regression fix due to regression
fix.
Dave.
The following changes since commit ab0296319a8cb970f4e42659472bb40fbfae3e56:
Merge tag 'spi-v3.10-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi (2013-06-10 13:28:39
-0700)
are
Op 28-05-13 16:48, Maarten Lankhorst schreef:
> Version 4 already?
>
> Small api changes since v3:
> - Remove ww_mutex_unlock_single and ww_mutex_lock_single.
> - Rename ww_mutex_trylock_single to ww_mutex_trylock.
> - Remove separate implementations of ww_mutex_lock_slow*, normal
> functions can
From: Michel Dänzer
It takes an unsigned value. This happens not to blow up on 64-bit
architectures, but it does on 32-bit, causing
drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
timestamps for vblank events. Which in turn causes e.g. gnome-shell to
hang after a DPMS off cycle
On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
> If the device is idle for over ten seconds, then the next attempt to do
> anything can race with the lockup detector and cause a bogus lockup
> to be detected.
>
> Oddly, the situation is well-described in the lockup detector's comments
>
On 11.06.2013 15:09, Daniel Vetter wrote:
> Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
> is used to restart the ioctl if we had to kick a thread (to make sure
> it doesn't hold any locks), e.g. for a blocking wait on oustanding
> rendering. The codepaths taken work exactly
On Wed, Jun 12, 2013 at 11:58:44AM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It takes an unsigned value. This happens not to blow up on 64-bit
> architectures, but it does on 32-bit, causing
> drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
> timestamps for vblank e
On Wed, 2013-06-12 at 11:58 +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It takes an unsigned value. This happens not to blow up on 64-bit
> architectures, but it does on 32-bit, causing
> drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
> timestamps for vblank events.
On Wed, Jun 12, 2013 at 12:28 PM, Terje Bergström wrote:
> On 11.06.2013 15:09, Daniel Vetter wrote:
>> Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
>> is used to restart the ioctl if we had to kick a thread (to make sure
>> it doesn't hold any locks), e.g. for a blocking w
On Wed, Jun 12, 2013 at 11:48:13AM +0100, Chris Wilson wrote:
> On Wed, Jun 12, 2013 at 11:58:44AM +0200, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > It takes an unsigned value. This happens not to blow up on 64-bit
> > architectures, but it does on 32-bit, causing
> > drm_calc_vbltimest
Am 12.06.2013 12:26, schrieb Michel Dänzer:
On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
If the device is idle for over ten seconds, then the next attempt to do
anything can race with the lockup detector and cause a bogus lockup
to be detected.
Oddly, the situation is well-describe
Hi,
GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
dma_buf. We can use prime helpers for dma_buf by commit
89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so
this patchset is to replace from using GEM CMA specific functions to
using prime helpers.
Tha
This adds to call low-level mmap() from prime helpers.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 5 -
include/drm/drmP.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853
Instead of using the dma_buf functionality for GEM CMA, we can use prime
helpers if we can provide low-level hook functions for GEM CMA.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_gem_cma_helper.c | 76
include/drm/drm_gem_cma_helper.h | 9 +++
We can use prime helpers instead.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_gem_cma_helper.c | 283 ---
include/drm/drm_gem_cma_helper.h | 6 -
2 files changed, 289 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/dr
Hi Joonyoung,
Thank you for the patches. I'll try to review and test them next week.
On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote:
> Hi,
>
> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
> dma_buf. We can use prime helpers for dma_buf by commit
> 89177644a7b
On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
>> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
>> wrote:
>> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> >> I'd like to see all the AR
On Wed, Jun 12, 2013 at 6:26 AM, Michel Dänzer wrote:
> On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
>> If the device is idle for over ten seconds, then the next attempt to do
>> anything can race with the lockup detector and cause a bogus lockup
>> to be detected.
>>
>> Oddly, the si
On Wed, Jun 05 2013, Christopher Harvey wrote:
> Running mgag200_driver_unload when the driver init fails early on
> causes functions like drm_mode_config_cleanup to be called. The
> problem is, drm_mode_config_cleanup crashes because the corresponding
> init hasn't happend yet. There really isn't
On Wed, Jun 05 2013, Christopher Harvey wrote:
> G200 cards support, at best, 16 colour palleted images for the cursor
> so we do a conversion in the cursor_set function, and reject cursors
> with more than 16 colours, or cursors with partial transparency. Xorg
> falls back gracefully to software
This code was ported from the old xorg mga driver. These limits were
implemented as a solution to a number of problems that were seen. These
problems were linked to the bandwidth limitations of the g200e series.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 41
At the larger resolutions, the g200e series sometimes struggles with
maintaining a proper output. Problems like flickering or black bands appearing
on screen can occur. In order to avoid this, limitations regarding resolutions
and bandwidth have been added for the different variations of the g20
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #49 from vincent ---
Created attachment 80739
--> https://bugs.freedesktop.org/attachment.cgi?id=80739&action=edit
Force max tex size of 8
Does this patch help ?
I assumed a max tex clause size of 16 for anything from HD4000 using
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #50 from Alex Deucher ---
6xx has a max tex/vtx clause size of 8.
7xx+ has a max tex/vtx clause size of 16.
In CF_WORD1, make sure you are setting the MSB of the count field. Bits 12:10
and bit 19 make up the total count field. I s
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #5 from Marek Olšák ---
I have implemented it, but there is a problem. If I enable the optimization,
EXT_separate_shader_objects must be disabled. Is it okay with you?
This is a valid sequence with EXT_sso:
glUseProgram(prog_with_vs_
https://bugs.freedesktop.org/show_bug.cgi?id=64257
vincent changed:
What|Removed |Added
Attachment #80739|0 |1
is obsolete|
On Wed, Jun 12, 2013 at 1:05 PM, Russell King - ARM Linux
wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
>> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
>> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
>> > wrote:
>> > > And having t
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #52 from Andy Furniss ---
(In reply to comment #51)
> Created attachment 80740 [details] [review]
> Properly set COUNT_3
>
> Indeed, I was always setting COUNT_3 to 0.
>
> This new patch should solve the issue (at least if it's rela
Dear Christopher,
Am Mittwoch, den 05.06.2013, 11:29 -0400 schrieb Christopher Harvey:
> Running mgag200_driver_unload when the driver init fails early on
> causes functions like drm_mode_config_cleanup to be called. The
> problem is, drm_mode_config_cleanup crashes because the corresponding
> in
On Wed, Jun 12, 2013 at 7:00 PM, Russell King - ARM Linux
wrote:
> And here's another one - look carefully at this path:
>
> buf = dev->driver->gem_prime_export(dev, obj, flags);
> if (IS_ERR(buf)) {
> /* normally the created dma-buf takes ow
https://bugs.freedesktop.org/show_bug.cgi?id=64257
vincent changed:
What|Removed |Added
Attachment #80740|0 |1
is obsolete|
Mr. Dae,
Thanks for your valuable inputs.
I posted it as RFC because, I also have received comments to register
hdmiphy as a clock controller. As we always configure it for specific
frequency, hdmi-phy looks similar to a PLL. But it really doesn't
belong to that class. Secondly prior to exynos542
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> wrote:
> > And having thought about this driver, DRM some more, I'm now of the
> > opinion that DRM is not suitable for driving hardware where the GPU is
> > an entirely separat
On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > wrote:
> > > And having thought about this driver, DRM some more, I'm now of the
> > > opinion th
On Wed, Jun 12, 2013 at 06:05:12PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > > wrote:
> > > >
And here's another one - look carefully at this path:
buf = dev->driver->gem_prime_export(dev, obj, flags);
if (IS_ERR(buf)) {
/* normally the created dma-buf takes ownership of the
ref,
* but if that fails then drop
On Tue, Jun 11, 2013 at 10:17 PM, Maarten Lankhorst
wrote:
> Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
> internally".
> nvidia always seems to do this flush after writing values.
Thanks, patch applied.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drive
> mixer_ctx->win_data[win].enabled = false;
> }
>
> -static int mixer_check_timing(void *ctx, struct fb_videomode *timing)
> +static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
> {
> u32 w, h;
>
> - w = timing->xres;
> - h = timing->yres;
> + w = mode->hdisplay;
> + h = mode->vdisplay;
>
> - DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
> - __func__, timing->xres, timing->yres,
> - timing->refresh, (timing->vmode &
> - FB_VMODE_INTERLACED) ? true : false);
> + DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%d\n",
> + mode->hdisplay, mode->vdisplay, mode->vrefresh,
> + (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>
> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> @@ -978,7 +977,7 @@ static struct exynos_mixer_ops mixer_ops = {
> .win_disable= mixer_win_disable,
>
> /* display */
> - .check_timing = mixer_check_timing,
> + .check_mode = mixer_check_mode,
> };
>
> static irqreturn_t mixer_irq_handler(int irq, void *arg)
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130612/ed8969ee/attachment-0001.html>
nel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130612/e2130c01/attachment.html>
gt;> linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130612/b557afea/attachment.html>
64, ATI 4850x2
Agra
--
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/20130612/6de130fb/attachment.html>
> commit 1fcf23d361375645d586756d126b436796ba4fba
> Author: James Simmons
> Date: Sat Jun 8 09:31:57 2013 -0400
>
> via: New KMS ioctls and hardware to support.
>
> Add new VIA pci ids to support newer hardware. Cleanup userspace
> api structs to remove kernel types and add the new K
Hi Linus,
just some GMA500 memory leaks and i915 regression fix due to regression
fix.
Dave.
The following changes since commit ab0296319a8cb970f4e42659472bb40fbfae3e56:
Merge tag 'spi-v3.10-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi (2013-06-10 13:28:39
-0700)
are
Op 28-05-13 16:48, Maarten Lankhorst schreef:
> Version 4 already?
>
> Small api changes since v3:
> - Remove ww_mutex_unlock_single and ww_mutex_lock_single.
> - Rename ww_mutex_trylock_single to ww_mutex_trylock.
> - Remove separate implementations of ww_mutex_lock_slow*, normal
> functions can
From: Michel D?nzer
It takes an unsigned value. This happens not to blow up on 64-bit
architectures, but it does on 32-bit, causing
drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
timestamps for vblank events. Which in turn causes e.g. gnome-shell to
hang after a DPMS off cycle
On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
> If the device is idle for over ten seconds, then the next attempt to do
> anything can race with the lockup detector and cause a bogus lockup
> to be detected.
>
> Oddly, the situation is well-described in the lockup detector's comments
>
On 11.06.2013 15:09, Daniel Vetter wrote:
> Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
> is used to restart the ioctl if we had to kick a thread (to make sure
> it doesn't hold any locks), e.g. for a blocking wait on oustanding
> rendering. The codepaths taken work exactly
On Wed, Jun 12, 2013 at 11:58:44AM +0200, Michel D?nzer wrote:
> From: Michel D?nzer
>
> It takes an unsigned value. This happens not to blow up on 64-bit
> architectures, but it does on 32-bit, causing
> drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
> timestamps for vblank e
On Wed, 2013-06-12 at 11:58 +0200, Michel D?nzer wrote:
> From: Michel D?nzer
>
> It takes an unsigned value. This happens not to blow up on 64-bit
> architectures, but it does on 32-bit, causing
> drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
> timestamps for vblank events.
On Wed, Jun 12, 2013 at 12:28 PM, Terje Bergstr?m
wrote:
> On 11.06.2013 15:09, Daniel Vetter wrote:
>> Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
>> is used to restart the ioctl if we had to kick a thread (to make sure
>> it doesn't hold any locks), e.g. for a blocking
On Wed, Jun 12, 2013 at 11:48:13AM +0100, Chris Wilson wrote:
> On Wed, Jun 12, 2013 at 11:58:44AM +0200, Michel D?nzer wrote:
> > From: Michel D?nzer
> >
> > It takes an unsigned value. This happens not to blow up on 64-bit
> > architectures, but it does on 32-bit, causing
> > drm_calc_vbltimest
Am 12.06.2013 12:26, schrieb Michel D?nzer:
> On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
>> If the device is idle for over ten seconds, then the next attempt to do
>> anything can race with the lockup detector and cause a bogus lockup
>> to be detected.
>>
>> Oddly, the situation is
Hi,
GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
dma_buf. We can use prime helpers for dma_buf by commit
89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so
this patchset is to replace from using GEM CMA specific functions to
using prime helpers.
Than
This adds to call low-level mmap() from prime helpers.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 5 -
include/drm/drmP.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853
Instead of using the dma_buf functionality for GEM CMA, we can use prime
helpers if we can provide low-level hook functions for GEM CMA.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_gem_cma_helper.c | 76
include/drm/drm_gem_cma_helper.h | 9 +++
We can use prime helpers instead.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_gem_cma_helper.c | 283 ---
include/drm/drm_gem_cma_helper.h | 6 -
2 files changed, 289 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/dr
Hi Joonyoung,
Thank you for the patches. I'll try to review and test them next week.
On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote:
> Hi,
>
> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
> dma_buf. We can use prime helpers for dma_buf by commit
> 89177644a7b
On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
>> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
>> wrote:
>> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> >> I'd like to see all the AR
On Wed, Jun 12, 2013 at 6:26 AM, Michel D?nzer wrote:
> On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
>> If the device is idle for over ten seconds, then the next attempt to do
>> anything can race with the lockup detector and cause a bogus lockup
>> to be detected.
>>
>> Oddly, the si
On Wed, Jun 05 2013, Christopher Harvey wrote:
> Running mgag200_driver_unload when the driver init fails early on
> causes functions like drm_mode_config_cleanup to be called. The
> problem is, drm_mode_config_cleanup crashes because the corresponding
> init hasn't happend yet. There really isn't
On Wed, Jun 05 2013, Christopher Harvey wrote:
> G200 cards support, at best, 16 colour palleted images for the cursor
> so we do a conversion in the cursor_set function, and reject cursors
> with more than 16 colours, or cursors with partial transparency. Xorg
> falls back gracefully to software
This code was ported from the old xorg mga driver. These limits were
implemented as a solution to a number of problems that were seen. These
problems were linked to the bandwidth limitations of the g200e series.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 41
At the larger resolutions, the g200e series sometimes struggles with
maintaining a proper output. Problems like flickering or black bands appearing
on screen can occur. In order to avoid this, limitations regarding resolutions
and bandwidth have been added for the different variations of the g20
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130612/a7470984/attachment.html>
suspect you are not setting bit 19
properly.
--
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/20130612/146edd9c/attachment.html>
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/20130612/fce722e5/attachment.html>
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130612/0bfff57e/attachment.html>
On Wed, Jun 12, 2013 at 1:05 PM, Russell King - ARM Linux
wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
>> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
>> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
>> > wrote:
>> > > And having t
her patch - Force max tex size of 8 does fix it.
--
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/20130612/9cf48340/attachment.html>
es
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130612/4ffa12a5/attachment.pgp>
On Wed, Jun 12, 2013 at 7:00 PM, Russell King - ARM Linux
wrote:
> And here's another one - look carefully at this path:
>
> buf = dev->driver->gem_prime_export(dev, obj, flags);
> if (IS_ERR(buf)) {
> /* normally the created dma-buf takes ow
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> wrote:
> > And having thought about this driver, DRM some more, I'm now of the
> > opinion that DRM is not suitable for driving hardware where the GPU is
> > an entirely separat
On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > wrote:
> > > And having thought about this driver, DRM some more, I'm now of the
> > > opinion th
On Wed, Jun 12, 2013 at 06:05:12PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > > wrote:
> > > >
76 matches
Mail list logo
