I didn't fix this in the earlier patch -- it would have broken the
build due to the now-deleted garbage in drm_os_linux.h.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/drm_bufs.c | 9 +
drivers/gpu/drm/drm_ioctl.c | 15 ++-
2 files changed,
There are no users left in drivers/gpu.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
i
The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).
UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
add
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..15cd34b 100644
--- a/drive
i915 open-coded logic that was essentially equivalent to the new API.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
Changes from v1: Don't zero the mtrr handle after freeing it
drivers/gpu/drm/i915/i915_dma.c | 42 -
1 file changed, 4 in
I'm not sure I understand the intent of the previous behavior. mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable. But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.
The new behavior
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.
Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
driver
Several drivers currently use mtrr_add through various #ifdef guards
and/or drm wrappers. The vast majority of them want to add WC MTRRs
on x86 systems and don't actually need the MTRR if PAT (i.e.
ioremap_wc, etc) are working.
arch_phys_wc_add and arch_phys_wc_del are new functions, available
on
A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.
This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
x86 systems with MTRRs, add MTRRs and report errors, and that do
Hi,
On Monday 13 of May 2013 20:24:01 Inki Dae wrote:
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
> > Sent: Monday, May 13, 2013 6:52 PM
> > To: Inki Dae
> > Cc: 'Rob Clark'; 'Daniel Vetter'; 'DRI mailing list'; linux-arm-
> > kernel at li
> -Original Message-
> From: linux-fbdev-owner at vger.kernel.org [mailto:linux-fbdev-
> owner at vger.kernel.org] On Behalf Of Maarten Lankhorst
> Sent: Monday, May 13, 2013 8:41 PM
> To: Inki Dae
> Cc: 'Rob Clark'; 'Daniel Vetter'; 'DRI mailing list'; linux-arm-
> kernel at lists.infrad
>
> /var/log/Xorg.0.log doesn't contain anything differiing at all that is
> related to video output.
>
> And hints on how I could pursue this issue?
Try installing xf86-video-modesetting driver or whatever your distro calls it.
Dave.
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
> Sent: Monday, May 13, 2013 6:52 PM
> To: Inki Dae
> Cc: 'Rob Clark'; 'Daniel Vetter'; 'DRI mailing list'; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org; 'linux-fbdev';
> -Original Message-
> From: Rob Clark [mailto:robdcl...@gmail.com]
> Sent: Tuesday, May 14, 2013 2:58 AM
> To: Inki Dae
> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> Cho; linux-arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org
> Subject: Re: Intro
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/b0f193c4/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/8814fee6/attachment.html>
From: Dave Airlie
So qxl has ioports, but it really really really doesn't want you
to write to them twice, but if you write and get a signal before
the irq arrives to let you know its completed, you have to think
ahead and avoid writing another time.
However this works fine for update area where
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
> Sent: Monday, May 13, 2013 5:01 PM
> To: Inki Dae
> Cc: Rob Clark; Daniel Vetter; DRI mailing list; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org; linux-fbdev;
> Kyung
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #10 from Peter 2013-05-13 17:44:56 ---
Created an attachment (id=101311)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101311)
kdm.log file
File from arch partition on main mac disk. Seems to show problem with kdm_greet
aft
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #9 from Peter 2013-05-13 17:40:37 ---
Created an attachment (id=101301)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101301)
dmesg.txt file
Booted system from arch boot CD. Mounted main mac disk partition for arch (that
do
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #8 from Peter 2013-05-13 17:36:33 ---
Created an attachment (id=101291)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101291)
Xorg.0.log file
Xorg.0.log obtained from attempt to boot my iMac by efi (directly from kernel
ima
Oops, I did mistype. I have an 8086:8108:
# lspci --n | head -n 2
00:00.0 Host bridge [0600]: Intel Corporation System Controller Hub
(SCH Poulsbo) [8086:8100] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation System
Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108]
I didn't fix this in the earlier patch -- it would have broken the
build due to the now-deleted garbage in drm_os_linux.h.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/drm_bufs.c | 9 +
drivers/gpu/drm/drm_ioctl.c | 15 ++-
2 files changed,
There are no users left in drivers/gpu.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
i
The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).
UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
add
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..15cd34b 100644
--- a/drive
i915 open-coded logic that was essentially equivalent to the new API.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
Changes from v1: Don't zero the mtrr handle after freeing it
drivers/gpu/drm/i915/i915_dma.c | 42 -
1 file changed, 4 in
I'm not sure I understand the intent of the previous behavior. mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable. But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.
The new behavior
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.
Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
driver
Several drivers currently use mtrr_add through various #ifdef guards
and/or drm wrappers. The vast majority of them want to add WC MTRRs
on x86 systems and don't actually need the MTRR if PAT (i.e.
ioremap_wc, etc) are working.
arch_phys_wc_add and arch_phys_wc_del are new functions, available
on
A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.
This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
x86 systems with MTRRs, add MTRRs and report errors, and that do
From: Alex Deucher
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index c2af598..bb1bc48 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 122 +++
1 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4b07820..f6c1399 100644
--- a/drive
From: Alex Deucher
Skip UVD handling on them.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/si.c | 72 ---
2 files changed, 45 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 6417132..44a7a41 100644
--- a/drivers/gpu/drm/r
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 58 +++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 9878071..798b8b3 100644
--- a/driver
From: Alex Deucher
Hainan has no display hardware:
- no DCE (crtc, uniphy, dac, etc.)
- no VGA
v2: fix bios fetch
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 27 +--
drivers/gpu/drm/radeon/radeon_bios.c | 28
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index f0b6c2f..9fbfb89 100644
--- a/drivers/gpu/drm/radeon/si.c
+
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_device.c |1 +
drivers/gpu/drm/radeon/radeon_family.h |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/
On Mon, May 13, 2013 at 3:02 PM, Holger Schurig
wrote:
> I installed xserver-xorg-video-modesettings (from Debian Wheezy) and also
> updated xserver-core, -evdev, -vesa and -fbdev. The I started X11. Seems
> that Debian doesn't yet contain the addition of the modesettings driver to
> the auto-pro
?]
> >
> > the display just freezes although the system boots up fine otherwise as
> > I could in over a serial line. Plugging the VGA into the port of the
> > external graphics card did not seem to help either as the monitor stayed
> > black.
> >
> > Please find the output of `sudo lspci -vvv -xx` without and with the
> > external card plugged in attached.
> >
> > Do you have any suggestions, what the problem could be? Should coreboot
> > set something up differently? Any suggestion what?
> Issue is with coreboot, when you plug in the pcie card it does not
> disable fully the integrated gpu and especialy it disable the vram bar
> of it that confuse the hell out of the radeon driver.
I see. Thank you for the fast response and clarification.
So it is not supported to have several graphic devices like for
multi-seat setups?
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/5bb28c73/attachment.pgp>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/62d0cae6/attachment.html>
DCE3.x and 32 bits on
DCE4.x
--
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/20130513/0b4df10c/attachment.html>
id, that would also be worth a try.
--
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/20130513/1e3bbaf6/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/4694e3ae/attachment.html>
t; related to video output.
> >
> > And hints on how I could pursue this issue?
>
> Try installing xf86-video-modesetting driver or whatever your distro calls
> it.
>
> Dave.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/47ee22d8/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/7a530a55/attachment.html>
nts/20130513/97b90b82/attachment.html>
|--- |FIXED
--
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/20130513/91b3698a/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/bedff5d3/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #7 from Alex Deucher 2013-05-13
14:30:15 ---
Can you attach your xorg log and dmesg output with the radeon driver (without
nomodeset)?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are re
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #6 from Alex Deucher 2013-05-13
14:29:03 ---
Does it work ok if you boot with bootcamp? Also, you might try a 3.10 kernel
there were some fixes for EFI systems.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?t
mily 12h/14h Processor
Function 4
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/30f126fd/attachment-0001.pgp>
From: Alex Deucher
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index c2af598..bb1bc48 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 122 +++
1 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4b07820..f6c1399 100644
--- a/drive
From: Alex Deucher
Skip UVD handling on them.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/si.c | 72 ---
2 files changed, 45 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 6417132..44a7a41 100644
--- a/drivers/gpu/drm/r
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 58 +++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 9878071..798b8b3 100644
--- a/driver
From: Alex Deucher
Hainan has no display hardware:
- no DCE (crtc, uniphy, dac, etc.)
- no VGA
v2: fix bios fetch
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 27 +--
drivers/gpu/drm/radeon/radeon_bios.c | 28
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index f0b6c2f..9fbfb89 100644
--- a/drivers/gpu/drm/radeon/si.c
+
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_device.c |1 +
drivers/gpu/drm/radeon/radeon_family.h |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/
On Mon, May 13, 2013 at 1:18 PM, Inki Dae wrote:
>
>
> 2013/5/13 Rob Clark
>>
>> On Mon, May 13, 2013 at 8:21 AM, Inki Dae wrote:
>> >
>> >> In that case you still wouldn't give userspace control over the fences.
>> >> I
>> >> don't see any way that can end well.
>> >> What if userspace never si
Op 13-05-13 13:24, Inki Dae schreef:
>> and can be solved with userspace locking primitives. No need for the
>> kernel to get involved.
>>
> Yes, that is how we have synchronized buffer between CPU and DMA device
> until now without buffer synchronization mechanism. I thought that it's best
> to ma
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #7 from Marc Dietrich ---
Created attachment 79270
--> https://bugs.freedesktop.org/attachment.cgi?id=79270&action=edit
output of R600_DEBUG=vs,fp,ps with "dark" glxgears
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #6 from Marc Dietrich ---
Created attachment 79269
--> https://bugs.freedesktop.org/attachment.cgi?id=79269&action=edit
output of R600_DEBUG=vs,fp,ps working glxgears
--
You are receiving this mail because:
You are the assignee fo
Hi,
On Monday 13 of May 2013 20:24:01 Inki Dae wrote:
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
> > Sent: Monday, May 13, 2013 6:52 PM
> > To: Inki Dae
> > Cc: 'Rob Clark'; 'Daniel Vetter'; 'DRI mailing list'; linux-arm-
> > ker...@lists.in
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/20130513/dd261c9a/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130513/ad884175/attachment.html>
896 1056 600 601 603 628 0x48 0xa
[drm:drm_crtc_helper_set_mode], [CRTC:4]
[drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 60 39790 800 824
896 1056 600 601 603 628 0x48 0xa
[drm:drm_crtc_helper_set_mode], [ENCODER:8:LVDS-8] set [MODE:10:800x600]
[drm:drm_crtc_helper_set_confi
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/ec049a34/attachment.html>
Op 13-05-13 11:21, Inki Dae schreef:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
>> Sent: Monday, May 13, 2013 5:01 PM
>> To: Inki Dae
>> Cc: Rob Clark; Daniel Vetter; DRI mailing list; linux-arm-
>> kernel at lists.infradead.org; linux-med
From: Alex Deucher
May produce better results with some modes and also avoids
overflows on DCE2.x/3.x devices.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++
drivers/gpu/drm/radeon/r600_hdmi.c | 11 +--
2 fil
ktop.org/archives/dri-devel/attachments/20130513/bcb77e78/attachment.html>
On Mon, May 13, 2013 at 1:18 PM, Inki Dae wrote:
>
>
> 2013/5/13 Rob Clark
>>
>> On Mon, May 13, 2013 at 8:21 AM, Inki Dae wrote:
>> >
>> >> In that case you still wouldn't give userspace control over the fences.
>> >> I
>> >> don't see any way that can end well.
>> >> What if userspace never si
On Mon, May 13, 2013 at 1:00 AM, Kees Cook wrote:
> The "boxes" parameter points into userspace memory. It should be verified
> like any other operation against user memory.
>
> Signed-off-by: Kees Cook
> Cc: stable at vger.kernel.org
Thanks. Applied.
Alex
> ---
> drivers/gpu/drm/radeon/r300
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #10 from Peter 2013-05-13 17:44:56 ---
Created an attachment (id=101311)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101311)
kdm.log file
File from arch partition on main mac disk. Seems to show problem with kdm_greet
aft
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #9 from Peter 2013-05-13 17:40:37 ---
Created an attachment (id=101301)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101301)
dmesg.txt file
Booted system from arch boot CD. Mounted main mac disk partition for arch (that
do
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #8 from Peter 2013-05-13 17:36:33 ---
Created an attachment (id=101291)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101291)
Xorg.0.log file
Xorg.0.log obtained from attempt to boot my iMac by efi (directly from kernel
ima
On Mon, May 13, 2013 at 10:01 AM, Paul Menzel
wrote:
> Am Montag, den 13.05.2013, 09:51 -0400 schrieb Jerome Glisse:
>> On Mon, May 13, 2013 at 8:15 AM, Paul Menzel wrote:
>
>> > using the ASRock E350M1 with coreboot [1] and plugging in an external
>> > AMD graphics card,
>> >
>> > 01:00.0
2013/5/13 Rob Clark
> On Mon, May 13, 2013 at 8:21 AM, Inki Dae wrote:
> >
> >> In that case you still wouldn't give userspace control over the fences.
> I
> >> don't see any way that can end well.
> >> What if userspace never signals? What if userspace gets killed by oom
> >> killer. Who keeps
e.
--
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/20130513/30e21050/attachment.html>
Op 09-05-13 09:33, Inki Dae schreef:
> Hi all,
>
> This post introduces a new helper framework based on dma fence. And the
> purpose of this post is to collect other opinions and advices before RFC
> posting.
>
> First of all, this helper framework, called fence helper, is in progress
> yet so migh
On Mon, May 13, 2013 at 8:15 AM, Paul Menzel
wrote:
> Dear Linux graphics folks,
>
>
> using the ASRock E350M1 with coreboot [1] and plugging in an external
> AMD graphics card,
>
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
> ATI Cedar PRO [Radeon HD 5450/6350] (
On Mon, May 13, 2013 at 8:21 AM, Inki Dae wrote:
>
>> In that case you still wouldn't give userspace control over the fences. I
>> don't see any way that can end well.
>> What if userspace never signals? What if userspace gets killed by oom
>> killer. Who keeps track of that?
>>
>
> In all cases,
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/ca71a1be/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/bb35abe2/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/c7661a2e/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130513/13ab8f43/attachment.html>
From: Alex Deucher
May produce better results with some modes and also avoids
overflows on DCE2.x/3.x devices.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++
drivers/gpu/drm/radeon/r600_hdmi.c | 11 +--
2 files
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #10 from Alex Deucher ---
Created attachment 79258
--> https://bugs.freedesktop.org/attachment.cgi?id=79258&action=edit
use 10khz units for dto
E.g., something like this.
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #9 from Alex Deucher ---
Yeah, I'm just wondering if there is perhaps a sweet spot in the dividers
(e.g., using 10 or 1 khz units rather than mhz . Also the DTO_PHASE and and
DTO_MODULE fields are 16 bits on DCE2.x, 24 bits on DCE3.x
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #8 from Christian König ---
(In reply to comment #7)
> What is the issue?
I simply assume the clocks get more stable with smaller numbers, and we haven't
implemented reducing the fractions yet.
Alex comment is quite valid, that woul
https://bugzilla.kernel.org/show_bug.cgi?id=44851
--- Comment #5 from Peter 2013-05-13 08:27:10 ---
Just upgraded my arch installation on iMac from kernel 3.8.13 to 3.9.2.
Was working, still with the fbdev driver, but now cannot boot properly, either
by grub efi or by pure efi (image select
can cause audio glitches.
--
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/20130513/991cc35d/attachment-0001.html>
Oops, I did mistype. I have an 8086:8108:
# lspci --n | head -n 2
00:00.0 Host bridge [0600]: Intel Corporation System Controller Hub
(SCH Poulsbo) [8086:8100] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation System
Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108]
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #7 from Pierre Ossman ---
What is the issue? The raw ratio should be:
24 * 10^6
-
c
And the code is putting in:
24 * 10^5
-
c * 10^-1
which is the same thing.
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #50 from Marco Trevisan (Treviño) ---
(In reply to comment #48)
> Noticed the same issue in unity (compiz, actually) as soon as the opengl
> plugin is loaded.
>
> It seems to happen mostly in multi-monitor: http://paste.ubuntu.com/56
On Mon, May 13, 2013 at 1:00 AM, Kees Cook wrote:
> The "boxes" parameter points into userspace memory. It should be verified
> like any other operation against user memory.
>
> Signed-off-by: Kees Cook
> Cc: sta...@vger.kernel.org
Thanks. Applied.
Alex
> ---
> drivers/gpu/drm/radeon/r300_cm
1 - 100 of 132 matches
Mail list logo