On Thu, Jan 24, 2013 at 10:15:54AM +1000, Dave Airlie wrote:
> >> > Hi!
> >> >
> >> > There was still no maintainer, that commented, ack'd, nack'd, apply'd the
> >> > series. So, this is just a resend.
> >> > The patches were tested with:
> >> >
> >> > - v15 on Tegra by Thierry
> >> >
From: Dave Airlie
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when we then load the native KMS
driver, the first thing it does is tear down the generic framebuffer driver.
The thing is the generic code is doing the right t
We should clear this bit presumably on switching either from or to 512-char
mode, since the bit doesn't really make sense either way.
Dave Airlie wrote:
>From: Dave Airlie
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being reinterpre
We should clear this bit presumably on switching either from or to 512-char
mode, since the bit doesn't really make sense either way.
Dave Airlie wrote:
>From: Dave Airlie
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being reinterpre
Steffen,
You can add my tested-by for this series.. :)
I have been using them for Exynos: smdk5250 board.
On Wed, Jan 23, 2013 at 2:42 PM, Steffen Trumtrar
wrote:
> On Tue, Jan 22, 2013 at 03:50:48PM -0600, Rob Clark wrote:
>> On Mon, Jan 21, 2013 at 5:07 AM, Steffen Trumtrar
>> wrote:
>> > Hi!
V2: Add mutex protection, while read.
The hdmi and mixer win_commit calls currently are
not checking the status of IP before updating the
respective registers, this patch adds this check.
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +++
drivers/gpu/drm/exynos/exyn
From: xueminsu
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu
---
drivers/gpu/drm/drm_crtc.c |2 ++
1 files changed, 2 insertions(+),
-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Wednesday, January 23, 2013 5:54 PM
>To: Su, Xuemin
>Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
>linux-ker...@vger.kernel.org; yanmin_zh...@linux.intel.com; He, Bo
>Subject
On 01/23/2013 03:56 PM, Maarten Lankhorst wrote:
> Thanks for the review, how does this delta look?
>
> diff --git a/include/linux/fence.h b/include/linux/fence.h
> index d9f091d..831ed0a 100644
> --- a/include/linux/fence.h
> +++ b/include/linux/fence.h
> @@ -42,7 +42,10 @@ struct fence_cb;
> *
V2: Add mutex protection, while read.
The hdmi and mixer win_commit calls currently are
not checking the status of IP before updating the
respective registers, this patch adds this check.
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +++
drivers/gpu/drm/exynos/exyn
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/29ee980d/attachment.html>
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/f05adcca/attachment.html>
--
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/20130123/a8029fe0/attachment.html>
From: Dave Airlie
When we switch from 256->512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.
The problem case we see is grub2 writes
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/a3c1e53d/attachment.html>
On Wed, Jan 23, 2013 at 8:18 PM, Sean Paul wrote:
> On Wed, Jan 23, 2013 at 5:10 AM, Shirish S wrote:
> > The hdmi and mixer win_commit calls currently are
> > not checking the status of IP before updating the
> > respective registers, this patch adds this check.
> >
> > Signed-off-by: Shirish S
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/0b0451b9/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/40424a1a/attachment-0001.html>
On 01/23/2013 03:56 PM, Maarten Lankhorst wrote:
> Thanks for the review, how does this delta look?
>
> diff --git a/include/linux/fence.h b/include/linux/fence.h
> index d9f091d..831ed0a 100644
> --- a/include/linux/fence.h
> +++ b/include/linux/fence.h
> @@ -42,7 +42,10 @@ struct fence_cb;
> *
On Wed, Jan 23, 2013 at 5:38 PM, Takashi Iwai wrote:
> At Wed, 23 Jan 2013 17:25:08 +0100,
> Daniel Vetter wrote:
>>
>> From: Alan Cox
>>
>> Adjust the console layer to allow a take over call where the caller already
>> holds the locks. Make the fb layer lock in order.
>>
>> This s partly a band
At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
>
> From: Alan Cox
>
> Adjust the console layer to allow a take over call where the caller already
> holds the locks. Make the fb layer lock in order.
>
> This s partly a band aid, the fb layer is terminally confused about the
> locking r
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/c332b96d/attachment.html>
One of the early return cases missed the mutex unlocking. Hilarity
ensued.
This regression has been introduced in
commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
Author: Daniel Vetter
Date: Wed Dec 12 00:35:33 2012 +0100
drm: don't hold crtc mutexes for connector ->detect callbacks
Bugzi
From: Alan Cox
Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.
This s partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.
Signed-off-by: Alan Cox
[danvet
Hi Dave,
First patch is a resend of Alan's fbcon vs. fb notifier deadlock fix.
Without this lockdep is pretty much useless for debugging drm locking
issues, and it looks like quite a few bootup hangs could be blamed on this
one, too.
Since the fbdev maintainer seems to be awol, please merge this
On 01/23/2013 02:21 AM, Jon Mayo wrote:
> On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding
> wrote:
>> Implement support for the VBLANK IOCTL. Note that Tegra is somewhat
>> special in this case because it doesn't use the generic IRQ support
>> provided by the DRM core (DRIVER_HAVE_IRQ) but rather
https://bugzilla.kernel.org/show_bug.cgi?id=43751
am.devel at gmail.com changed:
What|Removed |Added
CC||am.devel at gmail.com
--- Comm
>> > Hi!
>> >
>> > There was still no maintainer, that commented, ack'd, nack'd, apply'd the
>> > series. So, this is just a resend.
>> > The patches were tested with:
>> >
>> > - v15 on Tegra by Thierry
>> > - sh-mobile-lcdcfb by Laurent
>> > - MX53QSB by Marek
>> >
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/b16afee9/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/a4c3cc6a/attachment.html>
Op 22-01-13 16:13, Francesco Lavra schreef:
> Hi,
>
> On 01/15/2013 01:34 PM, Maarten Lankhorst wrote:
> [...]
>> diff --git a/include/linux/fence.h b/include/linux/fence.h
>> new file mode 100644
>> index 000..d9f091d
>> --- /dev/null
>> +++ b/include/linux/fence.h
>> @@ -0,0 +1,347 @@
>> +/*
eceiving 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/20130123/e9a8d622/attachment.html>
On Wed, Jan 23, 2013 at 12:21:29PM -0500, Ilija Hadzic wrote:
> On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
> wrote:
> > On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
> >> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> >> > Actually, the code path affected b
On Wed, Jan 23, 2013 at 1:59 PM, Ilija Hadzic
wrote:
> If one (but not both) allocations of p->chunks[].kpage[]
> in radeon_cs_parser_init fail, the error path will free
> the successfully allocated page, but leave a stale pointer
> value in the kpage[] field. This will later cause a
> double-free
On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> > Actually, the code path affected by your patch is not executed in UMS mode
> > at all. Notice that radeon_cs_parser_fini is only called from
> > radeon_cs_ioctl which is a KMS-
https://bugs.freedesktop.org/show_bug.cgi?id=59431
--- Comment #24 from Seth Forshee ---
Created attachment 73542
--> https://bugs.freedesktop.org/attachment.cgi?id=73542&action=edit
Add quirk to efifb for iMac 12,1
Here's a patch to try. But after some more poking around I'm wondering why thi
If one (but not both) allocations of p->chunks[].kpage[]
in radeon_cs_parser_init fail, the error path will free
the successfully allocated page, but leave a stale pointer
value in the kpage[] field. This will later cause a
double-free when radeon_cs_parser_fini is called.
This patch fixes the issu
dummy one.
--
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/20130123/917f5472/attachment.html>
On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine
> wrote:
> > Hi Rob,
> >
> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> > I had a look at your IT LCD driver. Comments below.
>
> Just fyi, you can re-
https://bugs.freedesktop.org/show_bug.cgi?id=59588
--- Comment #12 from Andy Furniss ---
(In reply to comment #10)
> Can you test with this new patch ? (Remove the previous one)
> It adds dummy export to vs outputs
It works OK with the new patch.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=59431
--- Comment #23 from William ---
Here the information from the output:
<"Apple Inc.">
<"iMac12,1">
FrameBuff erBase: 0x9001
PixelsPerScanLine: 1920
HorizontalResolution: 1920
VerticalResolution: 1080
--
You are receiving this mail becaus
On Mit, 2013-01-23 at 11:38 +0300, Dan Carpenter wrote:
> On Tue, Jan 22, 2013 at 10:42:25AM +0100, Paul Menzel wrote:
> >
> > Did you find this by manual inspection or did you use some tool?
>
> I found this because it caused a problem in a parser I was working
> on but Sparse warns about "warni
On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
wrote:
> On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
>> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
>> > Actually, the code path affected by your patch is not executed in UMS mode
>> > at all. Notice that radeon
Hi,
I have kmemleak detector enabled since 3.7.1 but now, with 3.7.4 I get the
following:
comm "X", pid 5475, jiffies 4294992244 (age 133695.910s)
hex dump (first 32 bytes):
69 39 31 35 40 70 63 69 3a 30 30 30 30 3a 30 30 i915 at pci::00
3a 30 32 2e 30 00 6b 6b 6b 6b 6b 6b 6b 6
On Wed, Jan 23, 2013 at 1:59 PM, Ilija Hadzic
wrote:
> If one (but not both) allocations of p->chunks[].kpage[]
> in radeon_cs_parser_init fail, the error path will free
> the successfully allocated page, but leave a stale pointer
> value in the kpage[] field. This will later cause a
> double-free
https://bugs.freedesktop.org/show_bug.cgi?id=59431
--- Comment #22 from Seth Forshee ---
(In reply to comment #21)
> Hi Seth,
>
> the output is:
> bios vendor: Apple Inc.
> system product name: iMac12,1
Rats, it turns out there's more information required. If you can boot into OS X
and run the
On Tue, Jan 22, 2013 at 10:42:25AM +0100, Paul Menzel wrote:
>
> Did you find this by manual inspection or did you use some tool?
>
I found this because it caused a problem in a parser I was working
on but Sparse warns about "warning: expression using sizeof(void)".
It's sort of hard to run Spa
"data" is a void pointer and "args" is "data" after we have casted it to
a struct. We care about the size of the struct here. Btw,
sizeof(*data) is 1.
Signed-off-by: Dan Carpenter
---
v2: tweaked the commit message
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
b/drivers/gpu/drm
From: xueminsu
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu
---
drivers/gpu/drm/drm_crtc.c |7 +++
1 files changed, 7 insertions
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/c2c778d6/attachment.html>
If one (but not both) allocations of p->chunks[].kpage[]
in radeon_cs_parser_init fail, the error path will free
the successfully allocated page, but leave a stale pointer
value in the kpage[] field. This will later cause a
double-free when radeon_cs_parser_fini is called.
This patch fixes the issu
On Wed, Jan 23, 2013 at 11:19:27AM +0800, Su, Xuemin wrote:
> From: xueminsu
> Date: Tue, 22 Jan 2013 22:39:39 +0800
> Subject: [PATCH] drm_crtc: check if fb_create return NULL
>
> Some buggy driver may still return NULL in fb_create,
> which leads to kernel panic.
>
> Signed-off-by: xueminsu
On Tue, 22 Jan 2013 16:36:23 -0600
Rob Clark wrote:
> Driver for the NXP TDA998X i2c hdmi encoder slave.
>
> v1: original
> v2: fix npix/nline programming
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/i2c/Makefile | 3 +
> drivers/gpu/drm/i2c/tda998x_drv.c | 908
> +
Hi Rob,
As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
I had a look at your IT LCD driver. Comments below.
On Tue, 22 Jan 2013 16:36:22 -0600
Rob Clark wrote:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc)
https://bugs.freedesktop.org/show_bug.cgi?id=59431
--- Comment #21 from William ---
Hi Seth,
the output is:
bios vendor: Apple Inc.
system product name: iMac12,1
Could that also explain why X is not working?
--
You are receiving this mail because:
You are the assignee for the bug.
___
From: xueminsu
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu
---
drivers/gpu/drm/drm_crtc.c |6 ++
1 files changed, 6 insertions(
From: xueminsu
Date: Tue, 22 Jan 2013 22:16:53 +0800
Subject: [PATCH] radeon_display: Use pointer return error codes
drm_mode_addfb() expects fb_create return error code
instead of NULL.
Signed-off-by: xueminsu
---
drivers/gpu/drm/radeon/radeon_display.c |2 +-
1 files changed, 1 insertion
https://bugs.freedesktop.org/show_bug.cgi?id=59431
--- Comment #20 from Seth Forshee ---
Okay, thanks.
I suspect at least part of the problem may be related to efifb. I don't see
that it's being used on your machine, and I note that it has a bunch of quirks
for making it work with various Mac ha
On Tue, Jan 22, 2013 at 03:50:48PM -0600, Rob Clark wrote:
> On Mon, Jan 21, 2013 at 5:07 AM, Steffen Trumtrar
> wrote:
> > Hi!
> >
> > There was still no maintainer, that commented, ack'd, nack'd, apply'd the
> > series. So, this is just a resend.
> > The patches were tested with:
> >
> >
On 22.01.2013 21:59, Mario Kleiner wrote:
> The current swap scheduling is based on having an accurate software
> vblank counter. Atm. that counter is maintained in software, incremented
> during vblank irq. At irq off -> on transition we need a hw counter to
> reinitialize. And there is a timeo
On Wed, Jan 23, 2013 at 5:10 AM, Shirish S wrote:
> The hdmi and mixer win_commit calls currently are
> not checking the status of IP before updating the
> respective registers, this patch adds this check.
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 3 +++
> driv
On Wed, Jan 23, 2013 at 12:21:29PM -0500, Ilija Hadzic wrote:
> On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
> wrote:
> > On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
> >> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> >> > Actually, the code path affected b
https://bugs.freedesktop.org/show_bug.cgi?id=59431
--- Comment #19 from William ---
Hi Seth,
i have been testing with raring using 3.8 kernel.
On 64 bit kernel i get a console screen using the i915.disable=1 but not on the
32bit kernel. see also the dmesg files attached.
When using the 3.5 ker
On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
wrote:
> On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
>> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
>> > Actually, the code path affected by your patch is not executed in UMS mode
>> > at all. Notice that radeon
On Tue, Jan 22, 2013 at 9:27 PM, Su, Xuemin wrote:
> From: xueminsu
> Date: Tue, 22 Jan 2013 22:16:53 +0800
> Subject: [PATCH] radeon_display: Use pointer return error codes
>
> drm_mode_addfb() expects fb_create return error code
> instead of NULL.
>
> Signed-off-by: xueminsu
Thanks. Added to
https://bugzilla.kernel.org/show_bug.cgi?id=43751
am.de...@gmail.com changed:
What|Removed |Added
CC||am.de...@gmail.com
--- Comment #7
On Wed, Jan 23, 2013 at 5:38 PM, Takashi Iwai wrote:
> At Wed, 23 Jan 2013 17:25:08 +0100,
> Daniel Vetter wrote:
>>
>> From: Alan Cox
>>
>> Adjust the console layer to allow a take over call where the caller already
>> holds the locks. Make the fb layer lock in order.
>>
>> This s partly a band
Hi Rob,
On Tue, Jan 22, 2013 at 04:36:21PM -0600, Rob Clark wrote:
>
> drivers/gpu/drm/Kconfig| 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/i2c/Makefile | 3 +
> drivers/gpu/drm/i2c/tda998x_drv.c | 908
> +++
Op 22 jan. 2013, om 23:36 heeft Rob Clark het volgende
geschreven:
> Driver for the NXP TDA998X i2c hdmi encoder slave.
>
> v1: original
> v2: fix npix/nline programming
>
> Signed-off-by: Rob Clark
Tested on a beaglebone-black:
Tested-by: Koen Kooi
Op 22 jan. 2013, om 23:36 heeft Rob Clark het volgende
geschreven:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
> CMA helpers. Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone
On Wed, Jan 23, 2013 at 02:29:25AM +0100, Laurent Pinchart wrote:
> Hi Rob,
>
> On Monday 21 January 2013 09:54:01 Rob Clark wrote:
> > On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart wrote:
> > > On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
> > >> One thing I've run into in the past when
At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
>
> From: Alan Cox
>
> Adjust the console layer to allow a take over call where the caller already
> holds the locks. Make the fb layer lock in order.
>
> This s partly a band aid, the fb layer is terminally confused about the
> locking r
On Wed, Jan 23, 2013 at 8:13 AM, Rob Clark wrote:
> On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
> wrote:
>> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine
>>> wrote:
>>> > Hi Rob,
>>> >
>>> > As I wanted to re-us
One of the early return cases missed the mutex unlocking. Hilarity
ensued.
This regression has been introduced in
commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
Author: Daniel Vetter
Date: Wed Dec 12 00:35:33 2012 +0100
drm: don't hold crtc mutexes for connector ->detect callbacks
Bugzi
From: Alan Cox
Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.
This s partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.
Signed-off-by: Alan Cox
[danvet
Hi Dave,
First patch is a resend of Alan's fbcon vs. fb notifier deadlock fix.
Without this lockdep is pretty much useless for debugging drm locking
issues, and it looks like quite a few bootup hangs could be blamed on this
one, too.
Since the fbdev maintainer seems to be awol, please merge this
On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
wrote:
> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine
>> wrote:
>> > Hi Rob,
>> >
>> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
>> > I ha
On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> > Actually, the code path affected by your patch is not executed in UMS mode
> > at all. Notice that radeon_cs_parser_fini is only called from
> > radeon_cs_ioctl which is a KMS-
https://bugs.freedesktop.org/show_bug.cgi?id=59588
--- Comment #11 from vincent ---
Created attachment 73532
--> https://bugs.freedesktop.org/attachment.cgi?id=73532&action=edit
Add dummy vs export
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=59588
--- Comment #10 from vincent ---
Can you test with this new patch ? (Remove the previous one)
It adds dummy export to vs outputs
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=59431
Seth Forshee changed:
What|Removed |Added
CC||seth.fors...@canonical.com
--- Comment #1
On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine wrote:
> On Tue, 22 Jan 2013 16:36:23 -0600
> Rob Clark wrote:
>
>> Driver for the NXP TDA998X i2c hdmi encoder slave.
>>
>> v1: original
>> v2: fix npix/nline programming
>>
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/i2c/Makefile
On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine wrote:
> Hi Rob,
>
> As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> I had a look at your IT LCD driver. Comments below.
Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
(just in case that wasn't c
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/0b848160/attachment.html>
Op 22-01-13 16:13, Francesco Lavra schreef:
> Hi,
>
> On 01/15/2013 01:34 PM, Maarten Lankhorst wrote:
> [...]
>> diff --git a/include/linux/fence.h b/include/linux/fence.h
>> new file mode 100644
>> index 000..d9f091d
>> --- /dev/null
>> +++ b/include/linux/fence.h
>> @@ -0,0 +1,347 @@
>> +/*
On Wed, Jan 23, 2013 at 5:10 AM, Shirish S wrote:
> The hdmi and mixer win_commit calls currently are
> not checking the status of IP before updating the
> respective registers, this patch adds this check.
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 3 +++
> driv
On Wed, Jan 23, 2013 at 8:13 AM, Rob Clark wrote:
> On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
> wrote:
>> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine
>>> wrote:
>>> > Hi Rob,
>>> >
>>> > As I wanted to re-us
On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine wrote:
> > Hi Rob,
> >
> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> > I had a look at your IT LCD driver. Comments below.
>
> Just fyi, you can re-use
On Mit, 2013-01-23 at 11:38 +0300, Dan Carpenter wrote:
> On Tue, Jan 22, 2013 at 10:42:25AM +0100, Paul Menzel wrote:
> >
> > Did you find this by manual inspection or did you use some tool?
>
> I found this because it caused a problem in a parser I was working
> on but Sparse warns about "warni
The hdmi and mixer win_commit calls currently are
not checking the status of IP before updating the
respective registers, this patch adds this check.
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 3 +++
drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
2 files changed, 6 inse
On Tue, 22 Jan 2013 16:36:23 -0600
Rob Clark wrote:
> Driver for the NXP TDA998X i2c hdmi encoder slave.
>
> v1: original
> v2: fix npix/nline programming
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/i2c/Makefile | 3 +
> drivers/gpu/drm/i2c/tda998x_drv.c | 908
> +
Hi Rob,
As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
I had a look at your IT LCD driver. Comments below.
On Tue, 22 Jan 2013 16:36:22 -0600
Rob Clark wrote:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc)
Op 22 jan. 2013, om 23:36 heeft Rob Clark het volgende
geschreven:
> Driver for the NXP TDA998X i2c hdmi encoder slave.
>
> v1: original
> v2: fix npix/nline programming
>
> Signed-off-by: Rob Clark
Tested on a beaglebone-black:
Tested-by: Koen Kooi
_
Op 22 jan. 2013, om 23:36 heeft Rob Clark het volgende
geschreven:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
> CMA helpers. Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone
On Tue, Jan 22, 2013 at 9:27 PM, Su, Xuemin wrote:
> From: xueminsu
> Date: Tue, 22 Jan 2013 22:16:53 +0800
> Subject: [PATCH] radeon_display: Use pointer return error codes
>
> drm_mode_addfb() expects fb_create return error code
> instead of NULL.
>
> Signed-off-by: xueminsu
Thanks. Added to
On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
wrote:
> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine wrote:
>> > Hi Rob,
>> >
>> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
>> > I had a
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130123/e7b568bb/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=59588
--- Comment #9 from Alex Deucher ---
Regarding the conversation on IRC, the vertex shader has to export at least one
generic param (not counting special exports like position). So if the vertex
shader doesn't export any params, you need a dummy
On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine wrote:
> On Tue, 22 Jan 2013 16:36:23 -0600
> Rob Clark wrote:
>
>> Driver for the NXP TDA998X i2c hdmi encoder slave.
>>
>> v1: original
>> v2: fix npix/nline programming
>>
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/i2c/Makefile
On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine wrote:
> Hi Rob,
>
> As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> I had a look at your IT LCD driver. Comments below.
Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
(just in case that wasn't c
1 - 100 of 114 matches
Mail list logo
