On 21.09.2023 21:52, Deucher, Alexander wrote:
backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
potential unused fence pointers") to stable kernels resulted in lots of
WARNINGs on some devices. In my case I was getting 3 WARNINGs per
second (~150 lines logged every second).
Hi,
backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
potential unused fence pointers") to stable kernels resulted in lots
of WARNINGs on some devices. In my case I was getting 3 WARNINGs per
second (~150 lines logged every second). Commit ended up being
reverted for stable
On 1.07.2023 14:08, Julius Zint wrote:
The Apple Studio Display does not have any physical buttons and the only
way to get or set the brightness is by sending USB control transfers to a
HID device exposed by the display.
These control transfers take the form of a HID_(GET|SET)_REPORT request
Hi,
I just noticed that "make dt_binding_check" doesn't work in linux-next:
SCHEMA Documentation/devicetree/bindings/processed-schema-examples.json
Traceback (most recent call last):
File "/home/rmilecki/.local/bin/dt-mk-schema", line 38, in
schemas =
On 8 December 2015 at 04:00, Michel Dänzer wrote:
> On 08.12.2015 02:49, Oded Gabbay wrote:
>> On Mon, Dec 7, 2015 at 9:51 AM, Michel Dänzer wrote:
>>> On 05.12.2015 06:09, Oded Gabbay wrote:
@@ -765,7 +765,7 @@ int radeon_vce_ring_test(struct radeon_device *rdev,
struct
My notebook Samsung NP700G7A-S01PL was working stable for more than 2 years.
I was using 3.11, 3.17, 3.18, 3.19 (since rc1) and many more successfully.
First hang has happened on 2015-02-08 (23:30) with 3.19-rc5 I was
using for 3 weeks.
So what I'm seeing are two possibly related problems:
1)
On 21 May 2014 15:51, Alex Deucher wrote:
> On Wed, May 21, 2014 at 1:58 AM, Rafa? Mi?ecki wrote:
>> What about using helper:
>>
>> WREG32_P(HDMI_CONTROL + offset,
>> val,
>> ~(HDMI_DEEP_COLOR_ENABLE | HDMI_DEEP_COLOR_DEPTH_MASK));
>
> We could. I don't think it really makes much difference one
On 21 May 2014 01:17, Alex Deucher wrote:
> + val = RREG32(HDMI_CONTROL + offset);
> + val &= ~HDMI_DEEP_COLOR_ENABLE;
> + val &= ~HDMI_DEEP_COLOR_DEPTH_MASK;
> +
> + switch (bpc) {
> (...)
> + }
> +
> + WREG32(HDMI_CONTROL + offset, val);
What about using
On 17 May 2014 02:14, Rafa? Mi?ecki wrote:
> So it's the fact:
> DCE2 uses 0x74dc
> DCE2 uses 0x740c
I meant:
DCE2 uses 0x74dc
DCE3 uses 0x740c
On 17 May 2014 01:34, Rafa? Mi?ecki wrote:
> On 17 May 2014 00:00, Alex Deucher wrote:
>> On Fri, May 16, 2014 at 5:10 AM, Rafa? Mi?ecki wrote:
>>> +#define DCE3_HDMI0_AUDIO_CRC_CONTROL 0x74dc
>>
>> They aren't swapped in hw, the register defines were just accidentally
>> swapped in the
On 17 May 2014 00:00, Alex Deucher wrote:
> On Fri, May 16, 2014 at 5:10 AM, Rafa? Mi?ecki wrote:
>> +#define DCE3_HDMI0_AUDIO_CRC_CONTROL 0x74dc
>
> They aren't swapped in hw, the register defines were just accidentally
> swapped in the header (probably a copy paste typo). Just swap the
>
DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work
Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231
Signed-off-by: Rafa?
Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
What initially seemed to be a typo in fglrx (using register 0x740c
instead of 0x74dc) appeared to be a correct behavior. DCE3 has ACR and
CRC registers swapped which explains why we needed
WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000);
This has been tested for possible regressions on DCE3
DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work
Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231
Signed-off-by: Rafa?
Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.
This has been tested for possible regressions on:
1) DCE2 D2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231
Signed-off-by: Rafa?
Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.
This has been tested for possible regressions on:
1) DCE2 D2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
What initially seemed to be a typo in fglrx (using register 0x740c
instead of 74dc) appeared to be a correct behavior. Without this
0x740c reg operation DCE 3 doesn't work and it seems we got code for
that already in place.
Recent RE effors allowed to finally understand this magic:
DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work
On 12 May 2014 20:09, Alex Deucher wrote:
> As far as I recall, 3.1 is
> pretty much the same as 3.0 from a programming perspective, but it's
> been a while since I looked at it in detail.
Please take a look at attached dce31.html file. It's a dump from fglrx
operations during HDMI mode setup.
On 12 May 2014 19:42, Rafa? Mi?ecki wrote:
> On 12 May 2014 17:57, Alex Deucher wrote:
>> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote:
>>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>>> in a slightly different way. Moving support to separated file will
>>>
On 12 May 2014 17:57, Alex Deucher wrote:
> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote:
>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>> in a slightly different way. Moving support to separated file will
>> allow use to use rv770d.h header in the future and
On 12 May 2014 16:19, Christian K?nig wrote:
> Am 12.05.2014 15:54, schrieb Rafa? Mi?ecki:
>
>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>> in a slightly different way. Moving support to separated file will
>> allow use to use rv770d.h header in the future and adjust
DCE 3.1 and 3.2 have different HDMI registers and should be programmed
in a slightly different way. Moving support to separated file will
allow use to use rv770d.h header in the future and adjust code as well.
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/dce3_1_afmt.c
On 9 May 2014 20:03, Marek Ol??k wrote:
> This commit which first appeared in 3.15-rc1 causes hangs on Bonaire:
>
> commit 6d2f2944e95e504a7d33385eeeb9bb7fcca72592
> Author: Christian K?nig
> Date: Thu Feb 20 13:42:17 2014 +0100
>
> drm/radeon: use normal BOs for the page tables v4
Also
Please re-send this patch with a correct commit message (subject). Add
at least "drm: " prefix to it.
2014-04-09 23:11 GMT+02:00 Micah Richert :
> Signed-off-by: Micah Richert
You have some weird indent before "Signed-off-by".
2014-02-25 18:04 GMT+01:00 Alex Deucher :
> Does the attached patch help?
It does, thanks!
--
Rafa?
2014-02-06 8:28 GMT+01:00 Rafa? Mi?ecki :
> I can't successfully resume using "low" power_profile. My testing
> looks like this:
> boot
> s & r (result: GOOD)
> s & r (result: GOOD)
> s & r (result: GOOD)
> echo "low" > /sys/class/drm/card0/device/power_profile
> s & r (result: BAD)
>
> BAD means
2014-02-16 19:55 GMT+01:00 Ilia Mirkin :
> On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki wrote:
>> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
>>> (b) bisect. you can (almost) definitely restrict the bisect to
>>> drivers/gpu/drm/nouveau. if you have additional computational power, i
>>> would
2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
> (b) bisect. you can (almost) definitely restrict the bisect to
> drivers/gpu/drm/nouveau. if you have additional computational power, i
> would recommend looking into distcc for speeding up the compiles. it
> may be interesting to also try 3.6.x since 3.7
2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
> On Mon, Feb 10, 2014 at 3:05 PM, Rafa? Mi?ecki wrote:
>> 2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
>>> There was also an issue with libdrm_nouveau for pre-nv50 chips, when
>>> compiled with gcc-4.8 some time back... fixed in... 2.4.48 or so?
>>
>> I use
2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
> (b) bisect. you can (almost) definitely restrict the bisect to
> drivers/gpu/drm/nouveau. if you have additional computational power, i
> would recommend looking into distcc for speeding up the compiles. it
> may be interesting to also try 3.6.x since 3.7
2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
> Lastly, it may be worth trying 3.11.x and 3.12.x to get a better
> handle on when problems happened. The commits you cite are in the
> middle of releases, and may have various badness associated with them
> (e.g. 3.12-rc had a later-disabled MSI
2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
> On Mon, Feb 10, 2014 at 10:12 AM, Rafa? Mi?ecki wrote:
>> 2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
>>> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote:
Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
noticed nasty display
2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote:
>> Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
>> noticed nasty display corruptions when using nouveau. It seems that
>> changing parts of the screen are appearing for a fraction
Hi guys,
Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
noticed nasty display corruptions when using nouveau. It seems that
changing parts of the screen are appearing for a fraction of second in
random places. I've recorded this behavior:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Blackcomb [Radeon HD 6970M/6990M] [1002:6720]
I don't use dpm, but a profile method. Right after booting (without
touching power_profile) I can suspend & resume as many times as I want
(tested with ~50 s routines).
2014/1/7 Alex Deucher :
> + if (radeon_hw_i2c == 1)
> + DRM_INFO("hw_i2c forced on, you may experience display
> detection problems!\n");
What about simple
if (radeon_hw_i2c)
? Values 2, 3, ... also enable i2c.
2013/12/12 Deucher, Alexander :
>> -Original Message-
>> From: Rafa? Mi?ecki [mailto:zajec5 at gmail.com]
>> Sent: Thursday, December 12, 2013 1:10 PM
>> To: Alex Deucher
>> Cc: dri-devel; Deucher, Alexander
>> Subject: Re: [PATCH] drm/radeon/dce6: set correct number of audio pins
>>
>>
2013/12/12 Alex Deucher :
> DCE6.0, 8.x has 6
> DCE6.1 has 4
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/dce6_afmt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c
> b/drivers/gpu/drm/radeon/dce6_afmt.c
> index
This bug in EDID was exposed by:
commit eccea7920cfb009c2fa40e9ecdce8c36f61cab66
Author: Alex Deucher
Date: Mon Mar 26 15:12:54 2012 -0400
drm/radeon/kms: improve bpc handling (v2)
Which resulted in kind of regression in 3.5. This fixes
https://bugs.freedesktop.org/show_bug.cgi?id=70934
2013/11/10 Alex Deucher :
> On Sat, Nov 9, 2013 at 3:20 AM, Rafa? Mi?ecki wrote:
>> 2013/11/8 Alex Deucher :
>>> Revert "drm/radeon/audio: don't set speaker allocation on DCE4+"
>>
>> What about that hangs people reported? Has anything changed meanwhile?
>> Did you fix them with some
2013/11/8 Alex Deucher :
> Revert "drm/radeon/audio: don't set speaker allocation on DCE4+"
What about that hangs people reported? Has anything changed meanwhile?
Did you fix them with some another commit?
2013/10/28 Deucher, Alexander :
>> Did you get any reports about that? Or is that
2013/11/6 Dave Airlie :
> On Wed, Nov 6, 2013 at 9:08 PM, Rafa? Mi?ecki wrote:
>> 2013/11/3 Rafa? Mi?ecki :
>>> 2013/11/1 Alex Deucher :
Christian K?nig (7):
drm/radeon: rework and fix reset detection v2
>>>
>>> Please note this pull request (above patch) break suspending on
2013/11/3 Rafa? Mi?ecki :
> 2013/11/1 Alex Deucher :
>>
>> Christian K?nig (7):
>> drm/radeon: rework and fix reset detection v2
>
> Please note this pull request (above patch) break suspending on my:
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
> nee ATI
Signed-off-by: Rafa? Mi?ecki
---
avivotool.c | 30 --
radeon_reg.h |8 +---
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/avivotool.c b/avivotool.c
index 4c5c1ce..f5b3f72 100644
--- a/avivotool.c
+++ b/avivotool.c
@@ -1697,13 +1697,31 @@
2013/11/5 Christian K?nig :
> From: Christian K?nig
>
> Don't block forever if there is nothing to wait for.
>
> Signed-off-by: Christian K?nig
Tested-by: Rafa? Mi?ecki
--
Rafa?
2013/11/5 Christian K?nig :
> Am 03.11.2013 13:15, schrieb Rafa? Mi?ecki:
>
>> 2013/10/29 Christian K?nig :
>>>
>>> From: Christian K?nig
>>>
>>> Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
>>> Consolidate the two wait sequence implementations into just one function.
2013/10/29 Christian K?nig :
> From: Christian K?nig
>
> Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
> Consolidate the two wait sequence implementations into just one function.
> Activate all waiters and remember if the reset was already done instead of
> trying to
2013/11/1 Alex Deucher :
>
> Christian K?nig (7):
> drm/radeon: rework and fix reset detection v2
Please note this pull request (above patch) break suspending on my:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720]
2013/11/2 Anssi Hannula :
> SAD with channels=6,freqs=32..96kHz,bits=16..24 implies that those freqs
> and bps are supported for all channel counts up to 6 (since it is "Max
> Number of channels"). Therefore the specified rates are supported in
> stereo mode as well and I believe should be
2013/10/29 Anssi Hannula :
> + if (sad->channels > max_channels) {
> + value = MAX_CHANNELS(sad->channels) |
> + DESCRIPTOR_BYTE_2(sad->byte2)
> |
> +
2013/10/29 Anssi Hannula :
> Fix the code to pick the PCM SAD with the highest number of channels,
> while merging the rate masks of PCM SADs with lower amount of channels
> into the additional stereo rate mask byte.
Don't you think that we should use SUPPORTED_FREQUENCIES_STEREO for
stereo
HDMI/audio part looks fine, thanks!
2013/11/1 Rafa? Mi?ecki :
> 2013/10/29 Anssi Hannula :
>> Fix the code to pick the PCM SAD with the highest number of channels,
>> while merging the rate masks of PCM SADs with lower amount of channels
>> into the additional stereo rate mask byte.
>
> Does it mean that now instead of 2 real SADs:
2013/10/29 Anssi Hannula :
> Because of this, only the 2-channel SAD may be used if it appears before
> the 8-channel SAD. Unless other SADs require otherwise, this may cause
> the ALSA HDA driver to allow stereo playback only.
I can confirm that the problem exists. My SADs (Onkyo TX-SR605):
2013/10/28 Deucher, Alexander :
>> -Original Message-
>> From: Rafa? Mi?ecki [mailto:zajec5 at gmail.com]
>> Sent: Monday, October 28, 2013 5:24 AM
>> To: Alex Deucher
>> Cc: dri-devel; Deucher, Alexander
>> Subject: Re: [PATCH] drm/radeon/audio: don't set speaker allocation on
>> DCE4+
>>
2013/10/19 Alex Deucher :
> It causes hangs on some asics. Disable on DCE6+ as well
> just to be on the safe side.
Did you get any reports about that? Or is that based only on mine comment:
> I noticed some hangs on BARTS too, let me test this solution on DCE5.
> Maybe it's not just DCE3.2.
2013/10/17 Alex Deucher :
> It causes hangs on some asics.
>
> Bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=70439
I noticed some hangs on BARTS too, let me test this solution on DCE5.
Maybe it's not just DCE3.2.
2013/10/17 Alex Deucher :
> In 3.12 I changed audio to be enabled by default,
> but you still had to turn it on via xrandr. This
> was confusing to users so change it to minic the
> previous behavior:
>
> - audio option is set to -1 (auto) by default which is
> the current 3.12 behavior (audio
That allow us to use registers defined in evergreend.h.
---
This is another proposal for HDMI code improvment. I'll start testing
my patches soon, so I hope to re-send all of them in the following days.
---
drivers/gpu/drm/radeon/evergreen.c |4 +--
2013/10/13 Alex Deucher alexdeuc...@gmail.com:
On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki zaj...@gmail.com wrote:
That allow us to use registers defined in evergreend.h.
---
This is another proposal for HDMI code improvment. I'll start testing
my patches soon, so I hope to re-send all
2013/10/10 Alex Deucher alexdeuc...@gmail.com:
On Thu, Oct 10, 2013 at 1:39 AM, Rafał Miłecki zaj...@gmail.com wrote:
2013/10/10 Alex Deucher alexdeuc...@gmail.com:
drm/radeon: use hw generated CTS/N values for audio
I'd like to see such patches earlier :| I'm OK with the change
2013/10/10 Alex Deucher alexdeuc...@gmail.com:
Attached. I'll send an updated pull request with the patch added.
Thanks! I promise to work on that, it just takes time to gather so old
hardware and run it (especially fglrx).
--
Rafał
___
dri-devel
2013/10/10 Alex Deucher alexdeuc...@gmail.com:
drm/radeon: use hw generated CTS/N values for audio
I'd like to see such patches earlier :| I'm OK with the change for
DCE4+ (Evergreen) (I even suggested that change myself recently), but
I didn't have time to check how this should be
For the last few days it was I was testing fglrx on various cards to
trace HDMI setup. One thing that was killing me was no HDMI audio when
using some generic/cheap DVI to HDMI adapter with my HD 4850.
I started digging and it has appeared to be common problem when using
Catalyst / fglrx. Windows
2013/10/7 Christian König deathsim...@vodafone.de:
Why didn't you just asked me?
I was told on #radeon you're on holidays ;) I was trying to catch you.
I've figured this out over five years ago by applying brute force to one of
the magic DVI-HDMI adapters that came with my original RV635. And
2013/10/7 Alex Deucher alexdeuc...@gmail.com:
On Sun, Oct 6, 2013 at 4:46 PM, Rafał Miłecki zaj...@gmail.com wrote:
Write to HDMI_VBI_PACKET_CONTROL was duplicated.
Writes to AFMT_AUDIO_CRC_CONTROL and AFMT_RAMP_CONTROL[0-3] came from
DCE2/3 code (copy paste) and were never needed on DCE4
Write to HDMI_VBI_PACKET_CONTROL was duplicated.
Writes to AFMT_AUDIO_CRC_CONTROL and AFMT_RAMP_CONTROL[0-3] came from
DCE2/3 code (copy paste) and were never needed on DCE4+.
See https://bugzilla.kernel.org/show_bug.cgi?id=62591 for details.
---
That patches weren't tested with the HW, please
They were verified to be used by fglrx on PALM, BARTS, CAICOS and VERDE.
VERDE which is DCE6 seems to need also clearing 0x7138 register.
See https://bugzilla.kernel.org/show_bug.cgi?id=62591 for details.
---
That patches weren't tested with the HW, please don't apply them yet.
---
Recent RE with faking reading values allowed us to figure out correct
masks for all R/W ops. Use them following fglrx logic.
See https://bugzilla.kernel.org/show_bug.cgi?id=62591 for details.
---
That patches weren't tested with the HW, please don't apply them yet.
---
Hi guys,
I wanted to verify/improve HDMI (audio) implementation in radeon for
so-called DCE3.2 cards. To achieve that I need a log from fglrx.
Is there anyone around using RV710 / RV730 / RV740 who can install
fglrx for one day and do few simple tests for me?
In case you don't know chipsets:
2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk:
This email is only being sent to the mailing lists in question, not to
anyone personally. The list of individuals is far to great to do that.
I'm hoping no mailing lists reject the patches based on the number of
recipients.
Huh, I
2013/8/18 StompDagger1 at yahoo.com :
> 2013/8/18 StompDagger1 at yahoo.com :
>>> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
>>> setting bits in a register" which you've commited fixes my issue?
>
>>Yes, I believe so! Sorry, I forgot to ping you about that.
>
> thats
2013/8/18 StompDagger1 at yahoo.com :
> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
> setting bits in a register" which you've commited fixes my issue?
Yes, I believe so! Sorry, I forgot to ping you about that.
--
Rafa?
2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
does the following patch: [FIX][PATCH] drm/radeon: fix WREG32_OR macro
setting bits in a register which you've commited fixes my issue?
Yes, I believe so! Sorry, I forgot to ping you about that.
--
Rafał
2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
does the following patch: [FIX][PATCH] drm/radeon: fix WREG32_OR macro
setting bits in a register which you've commited fixes my issue?
Yes, I believe so! Sorry, I forgot to ping
This bug (introduced in 3.10) in WREG32_OR made
commit d3418eacad403033e95e49dc14afa37c2112c134
"drm/radeon/evergreen: setup HDMI before enabling it"
cause a regression. Sometimes audio over HDMI wasn't working, sometimes
display was corrupted.
This fixes:
2013/8/15 Rafa? Mi?ecki :
> 2013/8/15 Alex Deucher :
>> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
>> +{
>> + struct radeon_device *rdev = encoder->dev->dev_private;
>> + struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>> +
2013/8/15 Alex Deucher :
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrj?l?'s comments
> v3: fix copy/paste typo in memory allocation
>
>
> @@ -169,13 +169,17 @@ int r600_audio_init(struct radeon_device *rdev)
> if (!radeon_audio || !r600_audio_chipset_supported(rdev))
> return 0;
>
> - r600_audio_engine_enable(rdev, true);
> + rdev->audio.enabled = true;
> +
> + rdev->audio.num_pins = 1;
>
2013/8/15 Alex Deucher :
> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> +{
> + struct radeon_device *rdev = encoder->dev->dev_private;
> + struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> + struct radeon_encoder_atom_dig *dig
Do it before enabling audio channels (in AFMT_AUDIO_PACKET_CONTROL2
register).
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/dce6_afmt.c | 69 +--
drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++-
2 files changed, 54 insertions(+), 22 deletions(-)
2013/8/14 Alex Deucher :
> + /* program the speaker allocation */
> + tmp = RREG32_ENDPOINT(offset,
> AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
> + tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
> + /* set HDMI mode */
> + tmp |= HDMI_CONNECTION;
> + if
2013/8/14 Alex Deucher :
> Similar to DCE4/5, but supports multiple audio pins
> which can be assigned per afmt block.
Acked-by: Rafa? Mi?ecki
Tested successfully on my HD7750.
> +static void r600_audio_enable(struct radeon_device *rdev,
> + struct r600_audio_pin
2013/8/14 Alex Deucher alexdeuc...@gmail.com:
Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.
Acked-by: Rafał Miłecki zaj...@gmail.com
Tested successfully on my HD7750.
+static void r600_audio_enable(struct radeon_device *rdev
2013/8/14 Alex Deucher alexdeuc...@gmail.com:
+ /* program the speaker allocation */
+ tmp = RREG32_ENDPOINT(offset,
AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
+ tmp = ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+ /* set HDMI mode */
+ tmp |= HDMI_CONNECTION;
+
Do it before enabling audio channels (in AFMT_AUDIO_PACKET_CONTROL2
register).
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/dce6_afmt.c | 69 +--
drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++-
2 files changed, 54 insertions
2013/8/15 Alex Deucher alexdeuc...@gmail.com:
+static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+ struct radeon_device *rdev = encoder-dev-dev_private;
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ struct
@@ -169,13 +169,17 @@ int r600_audio_init(struct radeon_device *rdev)
if (!radeon_audio || !r600_audio_chipset_supported(rdev))
return 0;
- r600_audio_engine_enable(rdev, true);
+ rdev-audio.enabled = true;
+
+ rdev-audio.num_pins = 1;
+
allocation
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Tested-by: Rafał Miłecki zaj...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
2013/8/15 Rafał Miłecki zaj...@gmail.com:
2013/8/15 Alex Deucher alexdeuc...@gmail.com:
+static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+ struct radeon_device *rdev = encoder-dev-dev_private;
+ struct radeon_encoder *radeon_encoder
?id=60687
https://bugzilla.kernel.org/show_bug.cgi?id=60709
https://bugs.freedesktop.org/show_bug.cgi?id=67767
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
2013/8/14 Alex Deucher :
> +static u32 dce6_endpoint_rreg(struct radeon_device *rdev,
> + u32 block_offset, u32 reg)
> +{
> + u32 r;
> +
> + WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> + r = RREG32(AZ_F0_CODEC_ENDPOINT_DATA +
2013/8/14 Alex Deucher alexdeuc...@gmail.com:
+static u32 dce6_endpoint_rreg(struct radeon_device *rdev,
+ u32 block_offset, u32 reg)
+{
+ u32 r;
+
+ WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
+ r = RREG32(AZ_F0_CODEC_ENDPOINT_DATA
2013/8/13 StompDagger1 at yahoo.com :
> following the inclusion of UVD support for and a post I've seen written by
> on of the devs mentioning that the hdmi sound will likely to be activated by
> default in 3.12, I've decided to switch my cards and use the hd5450 as the
> media center card and
2013/8/13 stompdagg...@yahoo.com stompdagg...@yahoo.com:
following the inclusion of UVD support for and a post I've seen written by
on of the devs mentioning that the hdmi sound will likely to be activated by
default in 3.12, I've decided to switch my cards and use the hd5450 as the
media
1 - 100 of 480 matches
Mail list logo
