Hi,
this time after I appended the right file.
regression fixers for the big 3:
nouveau: hdmi audio, dac load detect, s/r regressions fixed
radeon: long standing system hang fixed, hdmi audio and rs780 fast fb
fixes
intel: one old regression, a WARN removal, and a stop X dying fix
otherwise one
On Thu, Jun 6, 2013 at 3:22 PM, Linus Torvalds
wrote:
> On Thu, Jun 6, 2013 at 2:14 PM, Dave Airlie wrote:
>>
>> 7 files changed, 32 insertions(+), 42 deletions(-)
>
> That's not at all what I get (including shortlog). I got
>
> 29 files changed, 188 insertions(+), 68 deletions(-)
>
> from a lo
On Thu, Jun 6, 2013 at 2:14 PM, Dave Airlie wrote:
>
> 7 files changed, 32 insertions(+), 42 deletions(-)
That's not at all what I get (including shortlog). I got
29 files changed, 188 insertions(+), 68 deletions(-)
from a lot of commits you don't list.
Linus
__
Hi Linus,
regression fixers for the big 3:
nouveau: hdmi audio, dac load detect, s/r regressions fixed
radeon: long standing system hang fixed, hdmi audio and rs780 fast fb
fixes
intel: one old regression, a WARN removal, and a stop X dying fix
otherwise one mgag200 fix, a couple of arm build f
On 05/19/2013 08:32 PM, Tomasz Figa wrote:
Hi,
On Wednesday 01 of May 2013 22:00:25 Daniel Vetter wrote:
On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Figa wrote:
This patch modifies the driver to perform two stage parsing of video
timings from device tree, to get timing information as stru
On 06/06/2013 03:14 AM, Tomasz Figa wrote:
On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
Hi,
On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
Much of the code in Exynos DRM subsystem is generic enough to use
it for older (non-Exynos) Samsung SoCs as well, after minor
modification
On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
> Hi,
>
> On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
> > Much of the code in Exynos DRM subsystem is generic enough to use
> > it for older (non-Exynos) Samsung SoCs as well, after minor
> > modifications.
> >
> > This series start
On Wednesday 01 of May 2013 21:06:09 Tomasz Figa wrote:
> This patch modifies the driver to perform two stage parsing of video
> timings from device tree, to get timing information as struct videomode,
> which contains more data than struct fb_videomode.
>
> Thanks to this change, information abou
https://bugs.freedesktop.org/show_bug.cgi?id=65254
--- Comment #9 from Vladi ---
Created attachment 80378
--> https://bugs.freedesktop.org/attachment.cgi?id=80378&action=edit
xbmc log
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=65438
Rafael Castillo changed:
What|Removed |Added
Priority|medium |highest
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=65438
Priority: medium
Bug ID: 65438
Assignee: dri-devel@lists.freedesktop.org
Summary: GTK apps crash X11 since last update of LLVMM
Severity: blocker
Classification: Unclassified
org/archives/dri-devel/attachments/20130605/255fb2c5/attachment.html>
ng 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/20130605/b50b5453/attachment.html>
right?
--
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/20130605/185265e5/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #3 from Marek Olšák ---
I think the GLSL compiler only eliminates unused user-defined varyings, unused
legacy varyings are not eliminated. I'm taking this task.
--
You are receiving this mail because:
You are the assignee for the bu
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/8eb13f97/attachment.html>
ouble check that you got the right versions of the firmware files.
--
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/20130605/627014de/attachment.html>
The typical procedure after a hotplug event is then to enumerate all the
new modes. In the existing code, this is achieved by performing a forced
detection cycle over all connectors. Ideally, we should just be able to
use the current detection status and only enumerate the modes on the
connectors t
From: YoungJun Cho
This patch cleans up logs for DRM_ERROR / DRM_DEBUG_KMS to avoid
logging duplicated function name because the macros already contain
__func__.
Signed-off-by: YoungJun Cho
Signed-off-by: Seung-Woo Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c| 113 ++
From: YoungJun Cho
This patch removes tracking log functions which were used to debug
in the early development stage and are not so important as were.
So remove them for code clean up.
Signed-off-by: YoungJun Cho
Signed-off-by: Seung-Woo Kim
---
drivers/gpu/drm/exynos/exynos_drm_buf.c |
This patch set removes tracking logs and function name duplications.
This is for the next tree and based on exynos-drm-next branch.
YoungJun Cho (2):
drm/exynos: Remove tracking log functions
drm/exynos: Clean up logs for DRM_ERROR / DRM_DEBUG_KMS
drivers/gpu/drm/exynos/exynos_drm_buf.c
This patch adds exynos_drm_crtc_mode_set_commit function
to update mode data and it makes page flip call this function
instead of calling exynos_drm_crtc_mode_set_base function directly.
exynos_drm_crtc_mode_set_base function is called by drm subsystem
as a callback so we don't have to call this f
_
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/5da93aad/attachment.html>
From: Ville Syrj?l?
v2: Follow the drm_crtc documentation fixes
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 857acf2..4b8953c 10064
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..857acf2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/d
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 cursors in this case.
We can't disable/enable the curso
Op 31-05-13 10:54, Seung-Woo Kim schreef:
> dma-buf attachment has only exporter private data, but importer private data
> can be useful for importer especially to re-import the same dma-buf.
> To use importer private data in attachment of the device, the function to
> search attachment in the atta
On some chipset we try to avoid possibly invasive output detection
methods (like load detect which can cause flickering elsewhere) in the
output poll work. Drivers could hence return unknown when a previous
full ->detect call returned a different state.
This change will generate a hotplug event, f
There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).
To avoid this, check whether the connector state changes in all o
find the panel devices somehow
(how? modalias is probably somehow involved..), and load their
respective modules.
Later, when X is started, omapdrm and omapdss are loaded, and at that
point all the panels are already there.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/4e867790/attachment.pgp>
On Sun, May 26, 2013 at 11:00 PM, Daniel Vetter wrote:
> On Sun, May 26, 2013 at 10:31 PM, Patrik Jakobsson
> wrote:
>> On Sun, May 26, 2013 at 9:07 PM, Daniel Vetter wrote:
>>> On Sun, May 26, 2013 at 08:03:53PM +0200, Patrik Jakobsson wrote:
A framebuffer is pinned when it's set as pipe b
On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > >> On Tue, Jun 04, 2013 at 04:53:40AM
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but libdrm
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Problem noticed by and patch from Mark Kettenis.
Signed-off-by: Jonathan Gray
---
radeon/radeon_bo
On Wed, Jun 05, 2013 at 04:13:01AM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Tuesday 04 June 2013 10:58:35 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l?
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > drivers/gpu/drm/drm_crtc.c | 31
t --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/05d841c9/attachment.pgp>
The definition of regulator_bulk_enable is fixed with __must_check
and this causes following build warning.
warning: ignoring return value of 'regulator_bulk_enable',
declared with attribute warn_unused_result
This patch fixes to check return value of the function.
Signed-off-by: Seung-Woo Kim
--
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/677f3ba6/attachment.pgp>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/8b401e3b/attachment.html>
eading
the first texture coordinate input, which does exist).
--
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/2013
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/073b11e7/attachment-0001.html>
sure if that counts as
booting in EFI mode or in BIOS mode.
--
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/20130605/
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 cursors in this case.
We can't disable/enable the curso
https://bugs.freedesktop.org/show_bug.cgi?id=65270
Gerben Welter changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=65270
--- Comment #6 from Gerben Welter ---
(In reply to comment #5)
> You not only need the new one the initrd updater is complaining about, you
> also need the new RLC firmware. Otherwise the hardware would produce exactly
> the error you are describ
https://bugs.freedesktop.org/show_bug.cgi?id=65274
--- Comment #5 from russianneuroman...@ya.ru ---
> For TURKS you need to update BTC_rlc.bin, not SUMO_rlc.bin.
Ok, I update BTC_rlc.bin: ~$ md5sum /lib/firmware/radeon/BTC_rlc.bin
25d61fad839b30b263f52328c1f678fb /lib/firmware/radeon/BTC_rlc.bin
#2: (&__lockdep_no_validate__){..}, at: []
driver_detach+0x4c/0xc0
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.or
On 2013? 06? 04? 21:55, Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 07:42:22PM +0900, ??? wrote:
>>
>>
>> On 2013? 06? 01? 00:29, Daniel Vetter wrote:
>>> On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote:
Hello Daniel,
Thanks for your comment.
On 2013? 05? 31? 18:14
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 anything to cleanup after
mgag200_device_init, so we ca
On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
> Hi,
>
> On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
> > Much of the code in Exynos DRM subsystem is generic enough to use
> > it for older (non-Exynos) Samsung SoCs as well, after minor
> > modifications.
> >
> > This series start
On Wednesday 01 of May 2013 21:06:09 Tomasz Figa wrote:
> This patch modifies the driver to perform two stage parsing of video
> timings from device tree, to get timing information as struct videomode,
> which contains more data than struct fb_videomode.
>
> Thanks to this change, information abou
https://bugs.freedesktop.org/show_bug.cgi?id=65274
--- Comment #4 from Christian König ---
For TURKS you need to update BTC_rlc.bin, not SUMO_rlc.bin.
Only the SUMO UVD firmware is used for both generations.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=65270
--- Comment #5 from Christian König ---
(In reply to comment #4)
> (In reply to comment #1)
> > Make sure you've installed the updated rlc and uvd microcode and that it is
> > available to the driver during boot (in your initrd, etc.). You can g
On Wed, Jun 5, 2013 at 8:16 AM, Tomi Valkeinen wrote:
> On 05/06/13 14:52, Rob Clark wrote:
>> On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen
>> wrote:
>>> On 05/06/13 13:57, Rob Clark wrote:
>>>
1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
need to rename the .ko
On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > >> On Tue, Jun 04, 2013 at 04:53:40AM
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/335a52dc/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/2e717447/attachment.html>
On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
> wrote:
> > Hi Rob,
> >
> > On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
> >> couple small comments, other than those it looks ok
> >
> > Thanks for the review.
> >
> >> On Mon, Jun
ves/dri-devel/attachments/20130605/d6947760/attachment.html>
On Wed, Jun 05, 2013 at 11:52:59AM +0900, ??? wrote:
>
>
> On 2013? 06? 04? 21:55, Daniel Vetter wrote:
> > On Tue, Jun 04, 2013 at 07:42:22PM +0900, ??? wrote:
> >>
> >>
> >> On 2013? 06? 01? 00:29, Daniel Vetter wrote:
> >>> On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote:
> Hello Dani
=webgl
--
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/20130605/7d46d51f/attachment-0001.html>
On 05/06/13 14:52, Rob Clark wrote:
> On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen wrote:
>> On 05/06/13 13:57, Rob Clark wrote:
>>
>>> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
>>> need to rename the .ko
>>
>> Has something been changed that broke that? Or was "omapdrm
On 05/06/13 13:57, Rob Clark wrote:
> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
> need to rename the .ko
Has something been changed that broke that? Or was "omapdrm" just a
badly chosen name from the start? If drmOpen("omapdrm") works now,
doesn't changing the module nam
On 05/06/13 13:43, Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> I did some testing with omapdrm on v3.10-rc1. Here are some issues I
>> encountered.
>> For most of them I don't have any idea where to even start looking for a
>> problem,
>> so I hope that
Hi,
I did some testing with omapdrm on v3.10-rc1. Here are some issues I
encountered.
For most of them I don't have any idea where to even start looking for a
problem,
so I hope that you may have some ideas.
dispc_runtime_get/put used in irq context
=
d
On Tue, Jun 4, 2013 at 9:51 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
>> On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
>> > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
>> >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laure
Hey,
Op 04-06-13 20:38, Ilia Mirkin schreef:
> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
>> These chipsets include the VP2 engine which is composed of a bitstream
>> processor (BSP) that decodes H.264 and a video processor (VP) which can
>> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-
On Wed, Jun 5, 2013 at 8:39 AM, wrote:
> From: Ville Syrj?l?
>
> Signed-off-by: Ville Syrj?l?
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_crtc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.
The typical procedure after a hotplug event is then to enumerate all the
new modes. In the existing code, this is achieved by performing a forced
detection cycle over all connectors. Ideally, we should just be able to
use the current detection status and only enumerate the modes on the
connectors t
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 anything to cleanup after
mgag200_device_init, so we ca
On Wed, Jun 5, 2013 at 8:16 AM, Tomi Valkeinen wrote:
> On 05/06/13 14:52, Rob Clark wrote:
>> On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen wrote:
>>> On 05/06/13 13:57, Rob Clark wrote:
>>>
1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
need to rename the .ko
>>>
On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen wrote:
> On 05/06/13 13:57, Rob Clark wrote:
>
>> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
>> need to rename the .ko
>
> Has something been changed that broke that? Or was "omapdrm" just a
> badly chosen name from the start?
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/3581c223/attachment.html>
On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
>> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
>> wrote:
>> > Hi Rob,
>> >
>> > On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
>> >> couple small comments, other than those it
On Wed, Jun 5, 2013 at 6:43 AM, Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen
> wrote:
>> Hi,
>>
>> I did some testing with omapdrm on v3.10-rc1. Here are some issues I
>> encountered.
>> For most of them I don't have any idea where to even start looking for a
>> problem,
>
On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen wrote:
> Hi,
>
> I did some testing with omapdrm on v3.10-rc1. Here are some issues I
> encountered.
> For most of them I don't have any idea where to even start looking for a
> problem,
> so I hope that you may have some ideas.
>
>
> dispc_runtime_
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #2 from Alex Deucher ---
Couldn't this be done in a device independent manner in mesa when linking
shaders? Drop outputs if there is no matching input in the subsequent shader
stage?
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #1 from Stefan Dösinger ---
Fwiw, I don't know if r600g is affected. The HW has enough varyings to run the
unoptimized shaders, and the applications affected by this performance wise are
CPU limited on my r600g system.
Wine has some
https://bugs.freedesktop.org/show_bug.cgi?id=65416
Priority: medium
Bug ID: 65416
Assignee: dri-devel@lists.freedesktop.org
Summary: r300g does not eliminate unread varyings
Severity: normal
Classification: Unclassified
OS: A
Op 31-05-13 10:54, Seung-Woo Kim schreef:
> dma-buf attachment has only exporter private data, but importer private data
> can be useful for importer especially to re-import the same dma-buf.
> To use importer private data in attachment of the device, the function to
> search attachment in the atta
On Tue, Jun 4, 2013 at 9:51 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
>> On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
>> > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
>> >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laure
On Sun, May 26, 2013 at 11:00 PM, Daniel Vetter wrote:
> On Sun, May 26, 2013 at 10:31 PM, Patrik Jakobsson
> wrote:
>> On Sun, May 26, 2013 at 9:07 PM, Daniel Vetter wrote:
>>> On Sun, May 26, 2013 at 08:03:53PM +0200, Patrik Jakobsson wrote:
A framebuffer is pinned when it's set as pipe b
On Wed, Jun 5, 2013 at 8:39 AM, wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_crtc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..857acf2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/d
From: Ville Syrjälä
v2: Follow the drm_crtc documentation fixes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 857acf2..4b8953c 10064
https://bugs.freedesktop.org/show_bug.cgi?id=65377
--- Comment #4 from Henri Verbeet ---
I think it depends a bit on the specific model, but many Macs will only boot
EFI from USB. Refind (http://www.rodsbooks.com/refind/index.html) is
potentially a way around that, although I'm not entirely sure
On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > >> On Tue, Jun 04, 2013 at 04:53:40AM
On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen wrote:
> On 05/06/13 13:57, Rob Clark wrote:
>
>> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
>> need to rename the .ko
>
> Has something been changed that broke that? Or was "omapdrm" just a
> badly chosen name from the start?
On Wed, Jun 05, 2013 at 04:13:01AM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Tuesday 04 June 2013 10:58:35 ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_crtc.c | 31 +++
Hi Ville,
Thank you for the patch.
On Tuesday 04 June 2013 10:58:35 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_crtc.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/driv
On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
>> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
>> wrote:
>> > Hi Rob,
>> >
>> > On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
>> >> couple small comments, other than those it
On Wed, Jun 5, 2013 at 6:43 AM, Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> I did some testing with omapdrm on v3.10-rc1. Here are some issues I
>> encountered.
>> For most of them I don't have any idea where to even start looking for a
>> problem,
>> s
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #34 from Mike Lothian ---
Out of interest has the previous two patches been applied upstream?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailin
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #33 from Marc Dietrich ---
looks like my chrome version (27) has a bug with coordinates, so ignore this
browser. still firefox doesn't render anything at all.
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Daniel,
On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
>
> [snip]
>
> >> Should we add that to crtc
On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen wrote:
> Hi,
>
> I did some testing with omapdrm on v3.10-rc1. Here are some issues I
> encountered.
> For most of them I don't have any idea where to even start looking for a
> problem,
> so I hope that you may have some ideas.
>
>
> dispc_runtime_
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #32 from Andy Furniss ---
(In reply to comment #30)
> Can you try this branch:
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=r600-gen-fixes
>
> I think it should fix the remaining issues.
Doesn't fix heaven or pearl boy on my
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/3b79eb3c/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #31 from Marc Dietrich ---
still the same.
chrome still shows the triangles instead of the boy in the boat (even worse
than before) and firefox does not render the boy at all.
http://www.chromeexperiments.com/detail/pearl-boy/?f=we
Hi Rob,
On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
> couple small comments, other than those it looks ok
Thanks for the review.
> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/drm_gem_cma_helper.c | 321
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 04-06-13 20:38, Ilia Mirkin schreef:
>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
>>> These chipsets include the VP2 engine which is composed of a bitstream
>>> processor (BSP) that decodes H.264 and a video processor
1 - 100 of 110 matches
Mail list logo
