João Paulo Rechi Vita wrote:
> Still no sound with the branch you've pointed. Logs can be found here
> in case you're interested:
> https://gist.github.com/jprvita/7966532c7a4b67c74621c9374e20a418
You could try 4.6-wip-dal
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.6-wip-dal
Kai Wasserbäch wrote:
> Kai Wasserbäch wrote on 15.11.2014 22:22:
>> Kai Wasserbäch wrote on 15.11.2014 16:33:
>>> Is there anything besides a bisect you would need to debug this?
>>
>> Ok, I did a bisection, but that time was wasted for sure. My "first
>> bad commit" isn't bad at all. Is there
Kai Wasserbäch wrote:
> Kai Wasserbäch wrote on 15.11.2014 16:33:
>> Is there anything besides a bisect you would need to debug this?
>
> Ok, I did a bisection, but that time was wasted for sure. My "first bad
> commit"
> isn't bad at all. Is there any way to improve that experience? I'm really
Andy Furniss wrote:
>> I didn't have time to bisect this yet, but maybe you have an idea
>> what might cause this right away. I'm also not sure if it's a bug
>> in the DRI portion of the kernel.
>>
>> Is there anything besides a bisect you would need to debug this?
Kai Wasserbäch wrote:
> Dear Alex, I've built your drm-next-3.19-wip branch (commit
> be762d181e130d0e6e630f823400e9e1ba3bafd8) and with that kernel and
> the graphics stack detailed below, I can't run any of my Steam games
> anymore. All of them immediately go into the defunct state, when
>
Alex Deucher wrote:
> From: Mario Kleiner
>
> Check the HDMI cea block for deep color mode bits. If available,
> assign the highest supported bpc for a hdmi display, corresponding
> to the given deep color modes.
I haven't had time to test further, but with all 5 applied on top of
deathsimple
Alex Deucher wrote:
> I ran into similar issues right after dpm support was released. I'd
> done most of my development on gcc 4.6 and everything worked fine
> and upon upgrading to 4.7 or 4.8, tons of stuff broke. It ended up
> at least partially being related to indexing variable sized
Alex Deucher wrote:
> There seem to be stability issues on a number of cards.
>
> bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286
> https://bugzilla.redhat.com/show_bug.cgi?id=1085785
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
Well TBH I don't know whether the following
Built drm next yesterday was running drm fixes from a couple of weeks
ago previously, card is rv790.
Have powered up twice since and both times seen logged -
[drm:rv770_dpm_set_power_state] *ERROR*
rv770_restrict_performance_levels_before_switch failed
Today was 79 sec after boot, though I
Noticed this in dmesg today, it doesn't seem to break anything and it's
not reproducable.
[ 2605.261326] Forbidden register 0x0030 in cs at 9
[ 2605.261335] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
Seems it was triggered by mplayer using vdpau just for display, though
grepping
Alex Deucher wrote:
> On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss wrote:
>> Alex Deucher wrote:
>>>
>>> On Wed, Jun 26, 2013 at 9:21 AM, wrote:
>>>>
>>>> From: Alex Deucher
>>>>
>>>> These are the radeon patches for
Alex Deucher wrote:
On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss adf.li...@gmail.com wrote:
Alex Deucher wrote:
On Wed, Jun 26, 2013 at 9:21 AM, alexdeuc...@gmail.com wrote:
From: Alex Deucher alexander.deuc...@amd.com
These are the radeon patches for 3.11. Some of these patches
Alex Deucher wrote:
> On Wed, Jun 26, 2013 at 9:21 AM, wrote:
>> From: Alex Deucher
>>
>> These are the radeon patches for 3.11. Some of these patches
>> are huge so, it might be easier to review things here:
>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip
>
> Updated
Alex Deucher wrote:
On Wed, Jun 26, 2013 at 9:21 AM, alexdeuc...@gmail.com wrote:
From: Alex Deucher alexander.deuc...@amd.com
These are the radeon patches for 3.11. Some of these patches
are huge so, it might be easier to review things here:
CC drivers/video/console/vgacon.o
drivers/video/console/vgacon.c: In function ?vgacon_do_font_op?:
drivers/video/console/vgacon.c:1129:5: error: implicit declaration of
function ?cond_resched? [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: ***
CC drivers/video/console/vgacon.o
drivers/video/console/vgacon.c: In function ‘vgacon_do_font_op’:
drivers/video/console/vgacon.c:1129:5: error: implicit declaration of
function ‘cond_resched’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: ***
Alex Deucher wrote:
> On Sat, Jun 1, 2013 at 5:13 AM, Andy Furniss wrote:
>> Daniel Vetter wrote:
>>
>>> Interlaced modes are supported on all intel platforms (except i8xx, hw
>>> can't do it there) and we have full support for CEA modes.
>>> -Danie
Alex Deucher wrote:
On Sat, Jun 1, 2013 at 5:13 AM, Andy Furniss adf.li...@gmail.com wrote:
Daniel Vetter wrote:
Interlaced modes are supported on all intel platforms (except i8xx, hw
can't do it there) and we have full support for CEA modes.
-Daniel
OK, thanks, I guess it's an AMD driver
Ville Syrj?l? wrote:
> On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
>> ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrj?l?
>>>
>>> Having both modes can be beneficial for video playback cases. If you can
>>> match the vid
ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> Having both modes can be beneficial for video playback cases. If you can
> match the video framerate exactly, and the audio and video clocks come
> from the same source, you should be able to avoid dropped/repeated
> frames without
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid
Ville Syrjälä wrote:
On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio
Daniel Vetter wrote:
> Interlaced modes are supported on all intel platforms (except i8xx, hw
> can't do it there) and we have full support for CEA modes.
> -Daniel
OK, thanks, I guess it's an AMD driver issue rather than a more generic
drm thing then.
Daniel Vetter wrote:
Interlaced modes are supported on all intel platforms (except i8xx, hw
can't do it there) and we have full support for CEA modes.
-Daniel
OK, thanks, I guess it's an AMD driver issue rather than a more generic
drm thing then.
Daniel Vetter wrote:
> On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrjala at linux.intel.com
> wrote:
>> From: Ville Syrj?l?
>>
>> Having both modes can be beneficial for video playback cases. If you can
>> match the video framerate exactly, and the audio and video clocks come
>> from the
Daniel Vetter wrote:
On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
Christian K?nig wrote:
> Hi Andy,
>
> crap! I feared that something like this would happen. IIRC we never
> tested UVD on an rv790, and this hardware isn't easy to get any more.
>
> RV770/RV790 have a separate UVD hardware generation (that's why they
> have their own firmware) and there possible
Thanks AMD for getting this out :-)
I have an issue, though.
On HD4890 drm-fixes kernel (before yesterdays updates) got the new
R700_rlc.bin
RV770_uvd.bin
but on boot I get -
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
Thanks AMD for getting this out :-)
I have an issue, though.
On HD4890 drm-fixes kernel (before yesterdays updates) got the new
R700_rlc.bin
RV770_uvd.bin
but on boot I get -
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 11:01:37AM +0000, Andy Furniss wrote:
>> no_wb=1 should work.
>
> Yeah, maybe all those radeon and other GPU module parameters' syntax
> should be documented somewhere - Documentation/kernel-parameters.txt for
> example, o
Borislav Petkov wrote:
> [ 28.191072] radeon: `0' invalid for parameter `wb'
>
> although the whole driver blubber didn't appear on the console fterwards
> aso something got turned off allright.
>
> Then, I went and tried "radeon.no_wb" where the driver blubber appeared
> but AGP writeback was
Markus Trippelsdorf wrote:
>> Does booting with radeon.wb=0 fix the issue? Please make sure your
>> kernel has this patch:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246
>
> My kernel has this patch and radeon.wb=0 doesn't
Markus Trippelsdorf wrote:
Does booting with radeon.wb=0 fix the issue? Please make sure your
kernel has this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246
My kernel has this patch and radeon.wb=0 doesn't help.
I
Borislav Petkov wrote:
[ 28.191072] radeon: `0' invalid for parameter `wb'
although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.
Then, I went and tried radeon.no_wb where the driver blubber appeared
but AGP writeback was still
Borislav Petkov wrote:
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote:
no_wb=1 should work.
Yeah, maybe all those radeon and other GPU module parameters' syntax
should be documented somewhere - Documentation/kernel-parameters.txt for
example, or a GPU-specific file, whatever
Alex Deucher wrote:
> On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote:
>> Alex Deucher wrote:
>>>
>>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote:
>>>>
>>>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4
Alex Deucher wrote:
On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss andy...@ukfsn.org wrote:
Alex Deucher wrote:
On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote:
For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
and a (native 50Hz) HDMI TV I've
Alex Deucher wrote:
> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote:
>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
>> and then turn TV on and -
>>
>
For the last 2 years when running a DVI 60Hz monitor with a radeon
HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with
the TV off and then turn TV on and -
xrandr --output DVI-0 --auto
to bring up the the TV and get a clone of monitor.
This still works with drm-core-next but
For the last 2 years when running a DVI 60Hz monitor with a radeon
HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with
the TV off and then turn TV on and -
xrandr --output DVI-0 --auto
to bring up the the TV and get a clone of monitor.
This still works with drm-core-next
Alex Deucher wrote:
On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote:
For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
and then turn TV on and -
xrandr --output DVI-0 --auto
Andy Furniss wrote:
> HDMI TV - lots of new modes but it already advertised all the CVT that
> it supports and all the new are bogus.
Oops CEA not CVT.
Takashi Iwai wrote:
>> The xrandr command shows various bogus modes.
>
> Can't these values be displayed on your monitor at all?
> If they can be displayed, they are valid modes, not really bogus.
> After all, they are values that EDID of your montor advertises as
> available ranges.
I have
Takashi Iwai wrote:
The xrandr command shows various bogus modes.
Can't these values be displayed on your monitor at all?
If they can be displayed, they are valid modes, not really bogus.
After all, they are values that EDID of your montor advertises as
available ranges.
I have already
Andy Furniss wrote:
HDMI TV - lots of new modes but it already advertised all the CVT that
it supports and all the new are bogus.
Oops CEA not CVT.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
Daniel Vetter wrote:
> On Fri, May 18, 2012 at 12:37:51PM +0100, Andy Furniss wrote:
>> Joakim Plate wrote:
>>> Joakim Plate<elupus ecce.se> writes:
>>>
>>>>
>>>> Christian Schmidt<schmidt digadd.de> writes:
>>>>
Daniel Vetter wrote:
On Fri, May 18, 2012 at 12:37:51PM +0100, Andy Furniss wrote:
Joakim Plate wrote:
Joakim Plateelupusat ecce.se writes:
Christian Schmidtschmidtat digadd.de writes:
TFT/plasma televisions and projectors have become commonplace, and so
has the use of PCs
Joakim Plate wrote:
> Joakim Plate writes:
>
>>
>> Christian Schmidt writes:
>>
>>>
>>> TFT/plasma televisions and projectors have become commonplace, and so
>>> has the use of PCs to drive them. Add the video modes specified by an
>>> EDID's CEA extension to
Joakim Plate wrote:
Joakim Plateelupusat ecce.se writes:
Christian Schmidtschmidtat digadd.de writes:
TFT/plasma televisions and projectors have become commonplace, and so
has the use of PCs to drive them. Add the video modes specified by an
EDID's CEA extension to the mode database
I guess the extra modes with the new code in drm-core-next are crucial
for some, but it does generate a lot of extra non working modes for me.
With the previous behavior xrandr would list modes that all worked -
although there are a few new ones that work on my monitor there are a
lot that
I guess the extra modes with the new code in drm-core-next are crucial
for some, but it does generate a lot of extra non working modes for me.
With the previous behavior xrandr would list modes that all worked -
although there are a few new ones that work on my monitor there are a
lot that
Christian Schmidt wrote:
Tested with all three applied and they work well on my TV all modes
work, which was not the case previously if I added manually the modes
listed in xorg log (I have three bogus/not working modes logged by xorg).
I do have a small problem with the interlaced modes - I
Christian Schmidt wrote:
Tested with all three applied and they work well on my TV all modes
work, which was not the case previously if I added manually the modes
listed in xorg log (I have three bogus/not working modes logged by xorg).
I do have a small problem with the interlaced modes - I
Michel D?nzer wrote:
>>> That does sound like the GPU locks up. Do you get any messages in dmesg
>>> about lockups and attempts to reset the GPU at any time?
>>
>> No.
>
> Hmm, I guess the constant SIGALRMs might prevent the lockup detection
> from kicking in... Maybe you can try starting the X
Michel Dänzer wrote:
That does sound like the GPU locks up. Do you get any messages in dmesg
about lockups and attempts to reset the GPU at any time?
No.
Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
Alex Deucher wrote:
> The texture base address registers are in units of 256 bytes.
> The original CS checker treated these offsets as bytes, so the
> original check was wrong. I fixed the units in a patch during
> the 2.6.36 cycle, but this ended up breaking some existing
> userspace (probably
Alex Deucher wrote:
The texture base address registers are in units of 256 bytes.
The original CS checker treated these offsets as bytes, so the
original check was wrong. I fixed the units in a patch during
the 2.6.36 cycle, but this ended up breaking some existing
userspace (probably due to a
Alex Deucher wrote:
> Does this patch help?
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm/radeon/r600_cs.c
> index d886494..e83fc88 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -1046,7 +1046,6 @@ static void
Alex Deucher wrote:
> On Wed, Aug 18, 2010 at 7:45 AM, Andy Furniss wrote:
>> Andy Furniss wrote:
>>
>>> No, it does make the nunbers bigger, though -
>>>
>>> radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 ->
>>> 1048576 have
Andy Furniss wrote:
> No, it does make the nunbers bigger, though -
>
> radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 ->
> 1048576 have 1409024)
Further (non exhaustive) testing shows it regresses some mesa demos as
well - lodbias,reflect & shadowtex -
Alex Deucher wrote:
> Does reverting this part of the patch fix it?
>
> @@ -1055,10 +1055,10 @@ static void r600_texture_size(unsigned nfaces,
> unsigned blevel, unsigned nlevels
> }
> *l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;
> *mipmap_size = offset;
> -
Alex Deucher wrote:
Does reverting this part of the patch fix it?
@@ -1055,10 +1055,10 @@ static void r600_texture_size(unsigned nfaces,
unsigned blevel, unsigned nlevels
}
*l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;
*mipmap_size = offset;
- if (!blevel)
Andy Furniss wrote:
No, it does make the nunbers bigger, though -
radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 -
1048576 have 1409024)
Further (non exhaustive) testing shows it regresses some mesa demos as
well - lodbias,reflect shadowtex -
mipmap bo too small (256
Jon Sturm wrote:
> ut2004 has been having issues for a while so I wouldn't blame this
> patch 100%, Then again my issues seem to be similar to
> https://bugs.freedesktop.org/show_bug.cgi?id=27443 which may or may
> not be related.
Only having the demo and not seriously playing all levels (or
Jon Sturm wrote:
ut2004 has been having issues for a while so I wouldn't blame this
patch 100%, Then again my issues seem to be similar to
https://bugs.freedesktop.org/show_bug.cgi?id=27443 which may or may
not be related.
Only having the demo and not seriously playing all levels (or much at
Alex Deucher wrote:
> - buffer offsets in the base regs are 256b aligned so
> shift properly when comparing, fixed by Andre Maasikas
> - mipmap size was calculated wrong when nlevel=0
> - texture bo offsets were used after the bo base address was added
> - vertex resource size register is size -
Alex Deucher wrote:
> Send me a copy of your vbios, I may need to adjust the profile table
> for rv670. As root:
> cd /sys/bus/pci/devices/
> echo 1> rom
> cat rom> /tmp/vbios.rom
> echo 0> rom
Sent
>> One separate question - do I need to use the module param dynclks=1 or is it
>> the
Alex Deucher wrote:
> The "profile" method exposes 4 profiles that can be selected from:
> 1. "default"
> 2. "auto"
> 3. "low"
> 4. "high"
> Select the profile by echoing the selected profile to
> /sys/class/drm/card-0/device/power_profile.
Testing on a rv670 desktop it seems that low does not
Alex Deucher wrote:
The profile method exposes 4 profiles that can be selected from:
1. default
2. auto
3. low
4. high
Select the profile by echoing the selected profile to
/sys/class/drm/card-0/device/power_profile.
Testing on a rv670 desktop it seems that low does not force the card to
low
Alex Deucher wrote:
Send me a copy of your vbios, I may need to adjust the profile table
for rv670. As root:
cd /sys/bus/pci/devices/pci bus id
echo 1 rom
cat rom /tmp/vbios.rom
echo 0 rom
Sent
One separate question - do I need to use the module param dynclks=1 or is it
the default?
70 matches
Mail list logo
