W dniu 17 lipca 2010 11:27 u?ytkownik Dave Airlie
napisa?:
> 2010/7/17 Rafa? Mi?ecki :
>> Dave, last time you decided to push this fix for 2.6.35, then
>> resigned. After additional fix from Alex I can see this in drm-next
>> only, not in drm-fixes or Linus's tree. Did you change your mind to
>>
I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added
2.6.35-rc5 from package. In both cases suspending and resuming works
fine.
Then I downloaded 2.6.35-rc5 and compiled it myself. Suspending and
resuming works fine.
When trying d-r-t with the same config my machine locks up on
s
W dniu 20 lipca 2010 18:21 u?ytkownik Alex Deucher
napisa?:
> The last upstream -rc to get merged into d-r-t was 2.6.35-rc4. ?If
> -rc4 works, you could try bisecting from that point:
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=815c4163b6c8ebf8152f42b0a5fd015cfdc
W dniu 20 lipca 2010 20:44 u?ytkownik Alex Deucher
napisa?:
> Then merge Linus' tree into your local tree:
> git pull linus
It was just about adding "master" after last one. Thanks a lot! :)
--
Rafa?
W dniu 20 lipca 2010 13:15 u?ytkownik Marius Gr?ger
napisa?:
> Am 20.07.2010 12:14, schrieb Rafa? Mi?ecki:
>>
>> I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added
>> 2.6.35-rc5 from package. In both cases suspending and resuming works
>> fine.
>>
>> Then I downloaded 2.6.35-rc5
OK, next question :/ How can I rebase local d-r-t onto Linus's tree?
I've Linus's remote tree added and fetched but can not rebase against
it.
# git rebase linus
Current branch drm-radeon-testing is up to date.
# git rebase --onto linus drm-radeon-testing
Current branch drm-radeon-testing is up t
W dniu 21 lipca 2010 00:36 u?ytkownik Dave Airlie
napisa?:
> On Tue, 2010-07-20 at 23:37 +0200, Rafa? Mi?ecki wrote:
>> OK, next question :/ How can I rebase local d-r-t onto Linus's tree?
>> I've Linus's remote tree added and fetched but can not rebase against
>> it.
>>
>> # git rebase linus
>>
W dniu 21 lipca 2010 11:30 u?ytkownik Rafa? Mi?ecki
napisa?:
> First bisect try gave me:
> bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
> drm/radeon: optimize default 3D state for r6xx/r7xx blits
>
> I'm leaving today, not sure if I manage to confirm this before next week.
I switched back to
W dniu 21 lipca 2010 19:23 u?ytkownik Alex Deucher
napisa?:
> 2010/7/21 Rafa? Mi?ecki :
>> W dniu 21 lipca 2010 11:30 u?ytkownik Rafa? Mi?ecki
>> napisa?:
>>> First bisect try gave me:
>>> bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
>>> drm/radeon: optimize default 3D state for r6xx/r7xx bli
W dniu 24 lipca 2010 22:41 u?ytkownik Alex Deucher
napisa?:
> 2010/7/24 Rafa? Mi?ecki :
>> W dniu 21 lipca 2010 19:23 u?ytkownik Alex Deucher
>> napisa?:
>>> 2010/7/21 Rafa? Mi?ecki :
W dniu 21 lipca 2010 11:30 u?ytkownik Rafa? Mi?ecki
napisa?:
> First bisect try gave me:
> ba
W dniu 26 lipca 2010 07:57 u?ytkownik Alex Deucher
napisa?:
> How about v4 (attached)? ?Any better?
I counted up to 9 flashes after resume this time. Didn't try this
again (maybe different amount of flashses).
--
Rafa?
W dniu 26 lipca 2010 20:55 u?ytkownik Alex Deucher
napisa?:
> 2010/7/26 Rafa? Mi?ecki :
>> W dniu 26 lipca 2010 07:57 u?ytkownik Alex Deucher
>> napisa?:
>>> How about v4 (attached)? ?Any better?
>>
>> I counted up to 9 flashes after resume this time. Didn't try this
>> again (maybe different amo
W dniu 27 lipca 2010 17:27 u?ytkownik Alex Deucher
napisa?:
> I'm an idiot. ?The sampler state needs to be there as it's not emitted
> subsequently; ?I was thinking it got emitted with the texture fetch
> constants like it does in the ddx. ?That was the issue all along.
> Thanks for tracking that
W dniu 27 lipca 2010 23:53 u?ytkownik Rafa? Mi?ecki
napisa?:
> W dniu 27 lipca 2010 17:27 u?ytkownik Alex Deucher
> napisa?:
>> I'm an idiot. ?The sampler state needs to be there as it's not emitted
>> subsequently; ?I was thinking it got emitted with the texture fetch
>> constants like it does
W dniu 28 lipca 2010 01:01 u?ytkownik Alex Deucher
napisa?:
> 2010/7/27 Rafa? Mi?ecki :
>> W dniu 27 lipca 2010 17:27 u?ytkownik Alex Deucher
>> napisa?:
>>> I'm an idiot. ?The sampler state needs to be there as it's not emitted
>>> subsequently; ?I was thinking it got emitted with the texture fe
2010/5/27 Alex Deucher :
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 7b5e10d..102c744 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -2454,7 +2454,12 @@ default_mode:
> ? ? ?
2010/5/28 Alex Deucher :
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index dac2534..d84d7cf 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -475,6 +475,12 @@ void r600_pm_init_profile(struct radeon_device *rdev)
>
> ?void r6
2010/6/4 Jerome Glisse :
> Instead of dumping unprocessed dwords, dump the last 64
> dwords of the ring. This make debugging of some case easier.
>
> Signed-off-by: Jerome Glisse
> ---
> ?drivers/gpu/drm/radeon/r600.c | ? ?6 +++---
> ?1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
W dniu 4 czerwca 2010 21:55 u?ytkownik Jerome Glisse
napisa?:
> On Fri, Jun 04, 2010 at 02:54:42PM +0200, Rafa? Mi?ecki wrote:
>> 2010/6/4 Jerome Glisse :
>> > Instead of dumping unprocessed dwords, dump the last 64
>> > dwords of the ring. This make debugging of some case easier.
>> >
>> > Signed
Signed-off-by: Rafa? Mi?ecki
---
This fixes FDO bug #28375, must have for .35
---
drivers/gpu/drm/radeon/r600.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d84d7cf..94c27d0 100644
--- a/drivers
Signed-off-by: Rafa? Mi?ecki
---
This fixes FDO bug #28375, must have for .35
V2: Fix on RV770+ as well. All other chipsets have only one clock mode per
state.
---
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/rv770.c |7 ---
2 files changed, 8 insertions(+), 7 d
Signed-off-by: Rafa? Mi?ecki
---
This fixes FDO bug #28375, it's kind of regression, so quite important to have
it for .35.
V2: Fix on RV770+ as well. All other chipsets have only one clock mode per
state.
V3: I'm out of luck today. Grepped for voltage in r*.c and missed evergreen.
---
drivers/
Patches simply add tracking of voltage and debug setting it. While it may look
trivial and not important, having it would save a lot of time in debugging
FDO bug #36081. This way I try to say it could be nice to have it in .35 as
voltage stuff is new and we still may discover some bugs around it.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen.c |1 +
drivers/gpu/drm/radeon/r600.c |1 +
drivers/gpu/drm/radeon/radeon_pm.c |2 ++
drivers/gpu/drm/radeon/rv770.c |1 +
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/rade
We have similar tracking for engine and memory. We could think about some
solution for older GPUs as well, however there are not strict voltage values
set.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen.c |8 ++--
drivers/gpu/drm/radeon/r600.c |8 ++--
dri
Signed-off-by: Rafa? Mi?ecki
---
Alex you dropped this in "rework power management". Did you have some reason
for doing that? Or was that just accident?
---
drivers/gpu/drm/radeon/radeon_pm.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --gi
W dniu 7 czerwca 2010 07:00 u?ytkownik Alex Deucher
napisa?:
> 2010/6/6 Rafa? Mi?ecki :
>> We have similar tracking for engine and memory. We could think about some
>> solution for older GPUs as well, however there are not strict voltage values
>> set.
>>
>> Signed-off-by: Rafa? Mi?ecki
>
> I act
W dniu 7 czerwca 2010 18:09 u?ytkownik Alex Deucher
napisa?:
> 2010/6/7 Rafa? Mi?ecki :
>> W dniu 7 czerwca 2010 07:00 u?ytkownik Alex Deucher
>> napisa?:
>>> 2010/6/6 Rafa? Mi?ecki :
We have similar tracking for engine and memory. We could think about some
solution for older GPUs as we
W dniu 7 czerwca 2010 18:24 u?ytkownik Alex Deucher
napisa?:
> Only VOLTAGE_SW uses current_vddc so it's irrelevant for other voltage types.
I introduced displaying this value in radeom_pm_info debugfs in next patch.
--
Rafa?
Any news on that? Maybe you can get it as is (for d-r-t) Dave and
eventually get another patch later?
--
Rafa?
W dniu 9 czerwca 2010 16:25 u?ytkownik Alex Deucher
napisa?:
> 2010/6/9 Rafa? Mi?ecki :
>> Any news on that? Maybe you can get it as is (for d-r-t) Dave and
>> eventually get another patch later?
>
> I have a set of rebased patches built against drm-fixes (including
> Matt's suggestion), but there
2010/6/14 Rafael J. Wysocki :
> On Monday, June 14, 2010, Alex Deucher wrote:
>> On Mon, Jun 14, 2010 at 10:53 AM, Rafael J. Wysocki wrote:
>> > Alex, Dave,
>> >
>> > I'm afraid hibernation is broken on all machines using radeon/KMS with r300
>> > after commit ce8f53709bf440100cb9d31b1303291551cf5
2010/6/18 Rafael J. Wysocki :
> From: Rafael J. Wysocki
Thanks for you recent involvement in radeon driver! I can see you used
way shorter commit title this time ;) Just as a minor note, maybe you
could follow prefix-style we used to see around? Like simple
"drm/radeon/pm"? Or eventually somethin
This is needed to enable audio support on devices using polling. In case user
decides to disable audio (module parameter) we still will try to use timer in
r600_audio_enable_polling. This would lead to BUG in kernel/timer.c.
Signed-off-by: Rafa? Mi?ecki
---
Dave: I think we should not hit this wi
We will need method of selecting encoder that should receive HDMI block. For
now we assign HDMI block to first enabled encoder. Hopefully there are not many
RS6x0 chips with two digital encoders.
Signed-off-by: Rafa? Mi?ecki
---
Is there anyone with RS6x0 and HDMI audio received around?
---
driv
Signed-off-by: Rafa? Mi?ecki
---
Nothing serious, just annoying lack of \n made me touch this. Trivial fixes.
That's of course for some next merge window.
---
drivers/gpu/drm/radeon/r600_audio.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
2010/6/25 Alex Deucher :
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=28745
>
> Signed-off-by: Alex Deucher
Tested-by: Rafa? Mi?ecki
--
Rafa?
2010/6/25 Alex Deucher :
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=28745
>
> Signed-off-by: Alex Deucher
This fixes div by 0 which kills my machine, so I really would like to
see this in .35
--
Rafa?
2010/5/5 Jerome Glisse :
> If the memory is not iomem we should not try to
> ioremap it. Should fix :
>
> https://bugs.freedesktop.org/show_bug.cgi?id=27822
>
> Signed-off-by: Jerome Glisse
Tested-by: Rafa? Mi?ecki
Thanks!
--
Rafa?
2010/5/6 :
> Bisected down to:
>
> 82c5da6bf8b55a931b042fb531083863d26c8020 is the first bad commit
> commit 82c5da6bf8b55a931b042fb531083863d26c8020
> Author: Jerome Glisse
> Date: ? Fri Apr 9 14:39:23 2010 +0200
>
> ? ?drm/ttm: ttm_fault callback to allow driver to handle bo placement V6
Can t
2010/5/10 Andy Furniss :
>> The module parameter is obsolete. you can enable it dynamically via
>> sysfs (power_method). ?The default pm method is profile.
>
> OK, I know dynpm was removed - but this is dynclks are the two the same?
dynclks is for disabling clocking unused blocks. It means you don
2010/5/19 Alex Deucher :
> Some LVDS connectors don't have a ddc bus, so reset the
> ddc bus to invalid before parsing the next connector
> to avoid using stale ddc bus data. ?Should fix
> fdo bug 28164.
It does, thanks :)
Tested-by: Rafa? Mi?ecki
--
Rafa?
2010/10/3 Rafael J. Wysocki :
> Bug-Entry ? ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=19302
> Subject ? ? ? ? : PROBLEM: kernel crash on USB-modem (Huawei E1750) hangup.
> Submitter ? ? ? : O01eg
> Date ? ? ? ? ? ?: 2010-09-26 19:50 (8 days old)
> Message-ID ? ? ?:
> References ? ? ?: http
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:
RV7
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 d
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.
---
drivers/gpu/dr
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.
---
drivers/gpu/drm/radeon/ever
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 :
> 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 it
> indeed conta
2013/10/7 Alex Deucher :
> On Sun, Oct 6, 2013 at 4:46 PM, Rafał Miłecki 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
2013/10/10 Alex Deucher :
> 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 programmed on
DCE2/3/4...
I
2013/10/10 Alex Deucher :
> On Thu, Oct 10, 2013 at 1:39 AM, Rafał Miłecki wrote:
>> 2013/10/10 Alex Deucher :
>>> 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
>> D
2013/10/10 Alex Deucher :
> 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 mailing list
dri-devel@
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 +--
drivers/gpu/drm/radeon/evergreen_hdmi.c
2013/10/13 Alex Deucher :
> On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki 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 a
2010/8/8 Dan Carpenter :
> Smatch complained that the ERR_PTR from hwmon_device_register() wasn't
> handled. ?I added some error handling in radeon_hwmon_init() to silence
> the warning.
>
> Unfortunately errors from radeon_pm_init() aren't handled so this
> doesn't really make a difference beyond
2010/8/10 Benjamin Herrenschmidt :
> +#ifdef CONFIG_X86
> + ? ? ? primary = dev->pdev->resource[PCI_ROM_RESOURCE].flags &
> IORESOURCE_ROM_SHADOW;
> +#endif
It won't compile for CONFIG_X86, no "dev".
--
Rafa?
2010/8/16 Alex Deucher :
> Add options necessary bits for:
> - SS on DP
> - SS on LVDS
And SS stands for... ? ;)
--
Rafa?
2010/12/16 Mark Marshall :
> On 16/12/2010 05:54, Dave Airlie wrote:
>>
>> From: Dave Airlie
>> ?int pci_set_vga_state(struct pci_dev *dev, bool decode,
>> - ? ? ? ? ? ? ? ? ? ? unsigned int command_bits, bool change_bridge)
>> + ? ? ? ? ? ? ? ? ? ? unsigned int command_bits, u32 flags)
>> ?{
>> ?
2010/12/17 Alex Deucher :
> Users with TVs or monitors that don't overscan by default would prefer
> to not have underscan enabled, while users with overscanning TVs prefer
> underscan. ?This should hopefully make everyone happy as most monitors
> with audio tend to be TVs which overscan by default
2010/12/20 Alex Deucher :
> On resume, we were attemping to unblank the displays before the
> timing and plls had be reprogrammed which led to atom timeouts
> waiting for things that are not yet programmed. ?Re-program
> the mode first, then reset the dpms state.
>
> This fixes the infamous atombio
2011/2/18 Anca Emanuel :
> Nouveau OpenGL regresion
>
> Tools used: http://packages.ubuntu.com/maverick/misc/glmark2
>
> With 2.6.38-rc5 latest git:
> nv50_screen_get_param:162 - ?Unknown PIPE_CAP 11
> ===
> ? ?glmark2 10.07.1
> ==
2011/1/5 Alex Deucher :
> Lots of HDMI TVs overscan the incoming image by default.
> The underscan option was added as a way to compensate for
> that by underscanning the image so that the edges would
> not be cut off on an overscanning TV. ?However, the TV
> provides no way of knowing whether it i
2011/7/11 Alex Deucher :
> Skip connectors that do not have an HPD pin.
>
> Should fix:
> https://bugs.freedesktop.org/show_bug.cgi?id=39027
>
> Signed-off-by: Alex Deucher
Tested-by: Rafa? Mi?ecki
Fixes the regression.
--
Rafa?
Hi Konrad,
2011/6/8 Konrad Rzeszutek Wilk :
> The bug-fix "ttm: Do not increment the amount of pages in a pool by the
> current amount"
> I never observed, but found while looking at the code. The cleanup patch:
> "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier
> and
2014-02-25 18:04 GMT+01:00 Alex Deucher :
> Does the attached patch help?
It does, thanks!
--
Rafa?
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 re
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 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
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 a
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
>>> al
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.
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
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:
WREG32(HDMI0_AUD
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:
https://bugzilla.kernel.org/show_bug
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? M
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:
https://bugzilla.kernel.org/show_bu
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?
I was surprised that my BARTS in a Samsung notebook doesn't have a
RADEON_IS_IGP flag.
Are there any DCE5 devices that are IGP?
Btw. who does set that "flags" anyway? Flags are passed to the
radeon_driver_load_kms function from drm_pci.c:
dev->driver->load(dev, ent->driver_data);
(so driver_data
Some devices (ATI/AMD cards) don't want passing ELD struct to the
hardware but just require filling specific registers and then
hardware/firmware does the rest. In such a cases we need to read info
from SAD blocks and put them in the correct registers.
---
drivers/gpu/drm/drm_edid.c | 55 +++
2013/4/7 Boszormenyi Zoltan :
> will there be a followup patch where this function is actually used?
Sure :) It's just early patch post, with RFC, to see if I'm doing it
the right way.
--
Rafa?
2013/4/7 Rafa? Mi?ecki :
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
> hardware but just require filling specific registers and then
> hardware/firmware does the rest. In such a cases we need to read info
> from SAD blocks and put them in the correct registers.
If you wish
Thanks for comments!
2013/4/7 Paul Menzel :
> Am Sonntag, den 07.04.2013, 12:52 +0200 schrieb Rafa? Mi?ecki:
>> +struct cea_sad *drm_edid_to_sad(struct edid *edid)
>> +{
>> + struct cea_sad *sads = NULL;
>
> No need to set it NULL, as it gets assigned later on? Looks like in the
> end there is
---
drivers/gpu/drm/radeon/r600_hdmi.c | 16 ++--
drivers/gpu/drm/radeon/radeon.h|2 ++
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 21ecc0e..91582a5 100644
--- a/drivers/gpu/drm
Some devices (ATI/AMD cards) don't support passing ELD struct to the
hardware but just require filling specific registers and then the
hardware/firmware does the rest. In such cases we need to read the info
from SAD blocks and put them in the correct registers.
---
V2: fix commit message
return
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index ed46dad..81db8b9 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/dr
2013/4/8 Ville Syrj?l? :
>> + *sads = kzalloc(count * sizeof(*sads), GFP_KERNEL);
>
> Still looks a bit wrong.
>
> kcalloc(count, sizeof(**sads), GFP_KERNEL);
>
> Also a minor nit, but the scope of some variables is needlessly large.
> db and dbl are only needed inside the outer
I've managed to track fglrx operations on HDMI regs, so we can finally setup
everything in (hopefully) the correct way and order.
This changes HDMI setup on Evergreen to mostly match fglrx and was tested on:
1) AMD Radeon HD 6320 (PALM == DCE41)
2) AMD Radeon HD 6970M (BARTS == DCE5)
No regression
Signed-off-by: Rafa? Mi?ecki
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/r600_hdmi.c | 16 ++--
drivers/gpu/drm/radeon/radeon.h|2 ++
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio info manually.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen.c | 127 +---
1 file changed, 1 insertion(+), 126 deletions(-)
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
drivers/gpu/drm/radeon/radeon_display.c |5 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 4fdecc2..
Closed source driver fglrx seems to enable infoframes and audio packets
at the end, which makes sense, do the same.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 15 +++
drivers/gpu/drm/radeon/evergreend.h |1 +
2 files changed, 12 insertions(+)
Driver fglrx setups audio and ACR packets after basic initialization,
which sounds sane, do the same.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeo
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 24d13ac..ed46dad 100644
--- a/drivers/gpu/drm/radeon/ever
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>> We need interrupts on format change for R6xx only, where hardware seems
>> to be somehow bugged and requires setting audio info manually.
>
> How should this be tested?
Just play some audio using different
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>> Closed source driver fglrx seems to enable infoframes and audio packets
>> at the end, which makes sense, do the same.
>
> Any functionality change? Does not sound like it, but being unambiguous
> is better.
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>
> Maybe for a more descriptive summary:
>
> drm/radeon: Add some HDMI (audio) comments about fglrx? reg reads
I also comment sth in radeon_display.c.
--
Rafa?
Signed-off-by: Rafa? Mi?ecki
---
V2: fix typo and add extra \n
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
drivers/gpu/drm/radeon/radeon_display.c |6 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/rade
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>
> Maybe use the following for a more descriptive summary:
>
> drm/radeon/evergreen: Set up audio and ACR packets after basic init
That extra message you can see in my patch:
> Driver fglrx setups audio and A
Driver fglrx setups audio and ACR packets after basic initialization,
which sounds sane, do the same.
Signed-off-by: Rafa? Mi?ecki
---
V2: typo in "sufficient"
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff
301 - 400 of 506 matches
Mail list logo
