My card is an AMD HD5470 (AMD CEDAR)
If any more information is needed, just ask.
--
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/attachm
On Fri, Mar 21, 2014 at 08:31:29AM +0530, Vandana Kannan wrote:
> Populate PAR in infoframe structure. If there is a user setting for PAR, then
> that value is set. Else, value is taken from CEA mode list if VIC is found.
> Else, PAR is calculated from resolution. If none of these conditions are
>
On Fri, Mar 28, 2014 at 4:32 AM, Daniel Vetter wrote:
>
>> + /*
>> + * set_config() adjusts crtc->primary->fb; however the DRM setplane
>> + * code that called us expects to handle the framebuffer update and
>> + * reference counting; save and restore the current fb before
>> +
nt is calculated by the OSS driver?
What about Alex' idea in comment 43? Would tat help Christian?
--
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/20140331/1028ba82/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=73291
Mike Cloaked changed:
What|Removed |Added
Regression|No |Yes
--
You are receiving this mail becaus
On Mon, Mar 31, 2014 at 04:40:47PM +0100, Chris Wilson wrote:
> On Mon, Mar 31, 2014 at 06:08:51PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > Currently drm_cflush_virt_rage() takes a char* so the caller probably
> > has to do pointless casting to avoid compi
e atombios always works with 10khz pixel clock which always sets the target
clocks last digit to zero.
--
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/20140331/edfa0382/attachment-0001.html>
From: Ville Syrj?l?
Currently drm_cflush_virt_rage() takes a char* so the caller probably
has to do pointless casting to avoid compiler warnings. Make the
argument void* instead to avoid such issues.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_cache.c | 3 ++-
include/drm/drmP.h
On Fri, Mar 28, 2014 at 09:32:06AM +0100, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote:
...
> > +* N.B., we call set_config() directly here rather than using
> > +* drm_mode_set_config_internal. We're reprogramming the same
> > +* connectors that we
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion
On Mon, 31 Mar 2014 14:41:05 +0200
Lucas Stach wrote:
> Am Montag, den 31.03.2014, 15:28 +0300 schrieb Lauri Kasanen:
> > Allocating small bos from one end and large ones from the other helps
> > improve the quality of fragmentation.
> >
> > This depends on "drm: Optionally create mm blocks from
Am 31.03.2014 17:19, schrieb Alex Deucher:
> This needs to be done to update some of the fields in
> the connector structure used by the audio code.
>
> Noticed by several users on irc.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
Added to my drm-next-3.15 branch.
Thanks,
Chri
Am Montag, den 31.03.2014, 17:51 +0300 schrieb Lauri Kasanen:
> On Mon, 31 Mar 2014 14:41:05 +0200
> Lucas Stach wrote:
>
> > Am Montag, den 31.03.2014, 15:28 +0300 schrieb Lauri Kasanen:
> > > Allocating small bos from one end and large ones from the other helps
> > > improve the quality of frag
On Mon, Mar 31, 2014 at 06:08:51PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Currently drm_cflush_virt_rage() takes a char* so the caller probably
> has to do pointless casting to avoid compiler warnings. Make the
> argument void* instead to avoid such issues.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #11 from Mike Cloaked ---
For completeness I removed the radeon module from the initial ramdisk, and
added:
install radeon /bin/false
to the file /etc/modprobe.d/blacklist.conf
Now the system boots to a working graphical screen for
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #10 from Mike Cloaked ---
Created attachment 13
--> https://bugzilla.kernel.org/attachment.cgi?id=13&action=edit
systemd journal with 3.13.7 booted with radeon module blacklisted
--
You are receiving this mail because:
You
PLL using fb=927.2, post_div=10 and
ref_div=125
--
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/20140331/be7fa3c4/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #9 from Mike Cloaked ---
Booting with modprobe.blacklist=radeon added to the kernel line in the rEFInd
boot manager gives a successful boot to a graphical screen. So thank you, this
is a workaround for the present.
I can upload the s
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #8 from Mike Cloaked ---
What I am seeing seems to be the same as in the Fedora bug at:
https://bugzilla.redhat.com/show_bug.cgi?id=1070219
I don't have the system set up for bisecting. However I will boot with the
radeon driver blac
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #7 from Alex Deucher ---
(In reply to Mike Cloaked from comment #6)
> Perhaps this warning will not occur when kernel 3.14.x is used when it is
> released to arch in the near future. I presume that new patches in kernel
> 3.13.7 makes
mages from above represents crash backtrace messages after modprobe
fails.
Hope it helps,
Thank you.
--
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
This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases improved slightly (openarena, urban
terror).
512kb was measured as the most optimal threshold for 3d workloads
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #6 from Mike Cloaked ---
Perhaps this warning will not occur when kernel 3.14.x is used when it is
released to arch in the near future. I presume that new patches in kernel
3.13.7 makes the difference between a successful boot to graph
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/f474f628/attachment.html>
This updates the other drivers to build, no-op behavior-wise.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ast/ast_ttm.c | 3 ++-
drivers/gpu/drm/bochs/bochs_mm.c | 3 ++-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/d
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/83a766cd/attachment.html>
Allocating small bos from one end and large ones from the other helps
improve the quality of fragmentation.
This depends on "drm: Optionally create mm blocks from top-to-bottom" by
Chris Wilson.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
drivers/gpu/drm/ttm
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/e07f5449/attachment.html>
Cheers,
This patchset is respun on top of today's drm-next. It has only been
compile-tested, since my test computer is currently on strike in
support of Ukraine.
It was a simple spin though, so Mr. Murphy will likely stay away. Only
Radeon behavior is affected, all other drivers have just compili
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/458cfa9b/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140331/9ddd5a7c/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/63a9a842/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=73291
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #5 fr
nts/20140331/23560376/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #4 from Mike Cloaked ---
The system is dual boot arch linux and Windows 8.1, boot is UEFI using the
rEFInd boot manager, but that should not be relevant to the fail mode reported
in this bugzilla.
--
You are receiving this mail becau
Am Montag, den 31.03.2014, 15:28 +0300 schrieb Lauri Kasanen:
> Allocating small bos from one end and large ones from the other helps
> improve the quality of fragmentation.
>
> This depends on "drm: Optionally create mm blocks from top-to-bottom" by
> Chris Wilson.
>
You are breaking bisectabili
vv
dmesg
inxi -G
glxinfo
xrandr --listproviders
fglrx Xorg.1.log
Hope it helps.
Thank you in advance,
Mike.
--
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/20140331/1bd99a9a/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #3 from Mike Cloaked ---
Created attachment 131101
--> https://bugzilla.kernel.org/attachment.cgi?id=131101&action=edit
xorg log for kernel 3.13.7
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #2 from Mike Cloaked ---
Created attachment 131091
--> https://bugzilla.kernel.org/attachment.cgi?id=131091&action=edit
systemd journal for current boot with kernel 3.13.7
--
You are receiving this mail because:
You are watching th
https://bugzilla.kernel.org/show_bug.cgi?id=73291
--- Comment #1 from Mike Cloaked ---
Created attachment 131081
--> https://bugzilla.kernel.org/attachment.cgi?id=131081&action=edit
xorg log for kernel 3.13.6
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=73291
Bug ID: 73291
Summary: Kernel 3.13.7 boots with hybrid Intel/ATI but to blank
graphical screen
Product: Drivers
Version: 2.5
Kernel Version: 3.13.7
Hardware: x86-64
||
--
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/20140331/45faf8bc/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/56b1bd99/attachment.html>
esktop.org/archives/dri-devel/attachments/20140331/3a53ac2d/attachment.html>
Hi Ajay,
On 03/19/2014 03:22 PM, Ajay Kumar wrote:
> Exynos variants support post pocessors(PP) for FIMD (MDNIE and IELCD)
> which work closely with fimd. These post processors have strict
> dependency on FIMD for poweron/poweroff. This patch adds an
> infrastructure in FIMD driver to accomodate
I thought I'd kick off a thread to better discuss how to deal with
"large" displays which need multiple crtcs/planes merged to deal
without output larger than a certain width.
What I have in mind basically amounts to driver-custom-properties and
shouldn't really need much/anything in the way of dr
On Mon, 20 Jan 2014 19:07:23 +0200
Ville Syrj?l? wrote:
> On Mon, Dec 23, 2013 at 11:27:40AM +0530, Vandana Kannan wrote:
> > Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
> > CEA-861E Table 4. This is useful for filling up the detail in AVI
> > infoframe.
> >
> > v2: Vi
On Fri, 21 Mar 2014 08:31:29 +0530
Vandana Kannan wrote:
> Populate PAR in infoframe structure. If there is a user setting for PAR, then
> that value is set. Else, value is taken from CEA mode list if VIC is found.
> Else, PAR is calculated from resolution. If none of these conditions are
> satis
On Sun, Mar 30, 2014 at 4:22 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> This completely reworks how the PLL parameters are generated and
> should result in better matching dot clock frequencies.
>
> Probably needs quite a bit of testing.
>
> bugs: https://bugs.freedesktop.org/show_bug
This needs to be done to update some of the fields in
the connector structure used by the audio code.
Noticed by several users on irc.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/driver
Dave,
Here are the msm patches for 3.15, plus one omapdrm patch from Laurent.
I checked with Tomi and he didn't have anything to send at the moment
for 3.15-rc1, so I'm including Laurent's patch as a favor.
BR,
-R
The following changes since commit c32fc9c803f8ed90a7548810de48ca33a3020168:
M
e hit a pixel clock that is exactly representable.
--
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/20140331/ffc2a837/attachment.html>
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/20140331/de7dafa0/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/24a4eef5/attachment.html>
55 matches
Mail list logo
