Add support for Radeon 7480D (A4 5300 APU) ?

[lukove]

Would be posible add support for Radeon 7480D (A4 5300 APU) ?

[lukove]

screen of device info with ID

[kallisti5]

added in hrev47257. Let us know if you see any issues.

[ttcoder]

Does it work for you lukove ?

It causes a regression here : revisions prior to hrev47257 worked in VESA; in the latest nightlies however, radeon_hd is loaded and we get a flash of white followed by a black screen, so we're blacklisting the driver for now.

Asus F2A55M/CSM motherboard, with device:

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
  vendor 1002: Advanced Micro Devices, Inc. [AMD/ATI]
  device 9993: Trinity [Radeon HD 7480D]

Syslog coming up.

[ttcoder]

radeon_hd error messages toward the end (causes a black screen)

[lukove]

Sry i dont have this mainboard and cpu becouse ai upgraded to SoC AMD AM1 5350.

[ttcoder]

Let's at least comment-out the 0x7480 ID before alpha5 (otherwise we have to edit a blacklist on each shipping unit), and implementing/fixing the actual support for that chipset can wait until after alpha5, VESA works fairly well for us.

[ttcoder]

Back to being an enhancement I guess since the boot-up bug was fixed in #10565

[waddlesplash]

... and migrating off the alpha5 milestone since it's not needed.

[waddlesplash]

Some more info from Alex:

<waddlesplash> kallisti5: would http://cgit.haiku-os.org/haiku/commit/?id=72ec5a3630aa77a763c645e698c18259b8892953 apply to older chipsets too?
<kallisti5> 100MBit -> internet
<kallisti5> waddlesplash: no idea... I didn't make that change
<waddlesplash> Because, Julian said to me when I asked that he had the exact same symptoms that ttcoder/Dane were getting in that old ticket
<waddlesplash> I know
<kallisti5> looking at the code it doesn't apply
<kallisti5> although
<kallisti5> ... wonder why he didn't use the defines there
<kallisti5> PCI_BAR_MMIO
<waddlesplash> so changing chipsetID < RADEON_BONAIRE to whatever Dane had would not affect it?
<kallisti5> and PCI_BAR_MMIO_whatever5 is
<kallisti5> oh.. it was a local define
<kallisti5> nevermind :P
<kallisti5> ooooooooooooooooooooh
<kallisti5> he's checking chipset there
<kallisti5> that's a bad idea
<waddlesplash> well, it fixed the bug for him and someone else
<waddlesplash> so if it's half wrong, please tell how to fix
<kallisti5> should be looking at dceMajor and dceMinor
<kallisti5> the ordering of the chipsets in linux vs us differs
<kallisti5> linux is a confusing mess... they aren't ordered by release
<kallisti5> they're ordered by internally how the cards are related
<kallisti5> at amd
<kallisti5> each generation does have a dce version though
<kallisti5> I look at that in the driver as it makes wayy more sense
<kallisti5> could be that the card you have is out of order
<waddlesplash> not my problem
<waddlesplash> this was the black-screen-onboot problem
<waddlesplash> lemme find that ticket
<kallisti5> given the logic the following should happen:
<kallisti5> look up a RADEON_BONAIRE card
<kallisti5> find the DCE major / minor
<kallisti5> do a < DCE major + minor
<waddlesplash> kallisti5: here, this was the card not working http://cgit.haiku-os.org/haiku/commit/?id=6289332b7bc38bab2518ab4a719e80a3ed9ede15
<kallisti5> bonare is DCE 8.2
<kallisti5> so yeah.. don't think that is the solution unless aruba comes after bonare in linux
<kallisti5> http://osxr.org/linux/source/drivers/gpu/drm/radeon/radeon.h#2541
<kallisti5> < DCE 8.0
<kallisti5> even though bonare is 8.2
<kallisti5> crappy linux drivers

[kallisti5]

heh.. I bet you're using VGA?

<kallisti5> whipsers "nutmeg" (#8626)

[ttcoder]

My development Asus F2A55 desktop is connected to the monitor with a POVC (plain old VGA cable ;-) indeed, and IIRC it's true also for F2A55 stations assembled by dsuden for production (sales).. If I read you correctly you're saying things would work better with one of those newfangled digital monitors thingamadokie those youg'uns people use nowadays? :-P Ticket:8626 is greek to me, apart from the mention concerning laptops (we sell only desktops)..

[waddlesplash]

Preliminary patch I recieved from Alex.

[waddlesplash]

Here's a preliminary patch that partially fixes some of the problems that were caused in hrev47758. It *might* help with this problem.

ttcoder, can you apply/build/test it? You'll need to also readd this device ID to the list again (was removed in hrev47640).

[ttcoder]

Negative on that patch, Did a few minor fixes so that it compiles, setup the compiled driver, and at boot-up I reliably get a flash of white followed by the vga monitor switching off (so need to do a hard reset)

KERN: radeon_hdPATCHED: device_open: open(name = graphics/radeon_hd_000100)
KERN: radeon_hdPatch: card(0): radeon_hd_init: called
KERN: radeon_hd: radeon_hd_init: card(0): Radeon Aruba 1002:9993
KERN: add_memory_type_range(3795, 0xfeb00000, 0x40000, 0)
KERN: set MTRRs to:
KERN:   mtrr:  0: base: 0x5cc00000, size:   0x400000, type: 0
KERN:   mtrr:  1: base: 0x5d000000, size:   0x800000, type: 0
KERN:   mtrr:  2: base: 0xe0000000, size: 0x20000000, type: 0
KERN:   mtrr:  3: base: 0x80000000, size: 0x80000000, type: 1
KERN: radeon_hd: radeon_hd_init: Error: found 0MB video ram, using PCI bar size...
KERN: radeon_hdPatch: radeon_hd_init: mapping a frame buffer of 256MB out of 0MB video ram
KERN: add_memory_type_range(3796, 0xc0000000, 0x10000000, 0)
KERN: set MTRRs to:
(..more..)

Posting syslog soon

[ttcoder]

radeon_hd with patch: flash of white then black

[waddlesplash]

I'm gonna be a bit crazy here and suggest that you change the last part of radeon_hd_locate_bars from:

barMap.mmio = info.shared_info->dceMajor < 8 ? 2 : 5; 
barMap.doorbell = info.shared_info->dceMajor >= 8 ? 2 : -1; 

to

barMap.mmio = info.shared_info->dceMajor < 6 ? 2 : 5; 
barMap.doorbell = info.shared_info->dceMajor >= 6 ? 2 : -1; 

(I changed the two "8"s to "6"s -- as the 7480D was from DCE 6).

[ttcoder]

I can no longer compile here, seemingly following my pkgman update of yesterday, and doing a git pull changes nothing.. If this does not ring a bell to anybody I'll try just wiping out my git repo and doing a from-scratch git pull/clone of the whole source tree again:

/Haiku3/_develop_hrev/haiku/src/add-ons/kernel/drivers/graphics/radeon_hd> jam
Starting build of type regular ... 
WebKit build feature not available for x86_gcc2 
...patience...
don't know how to make <x86_gcc2>crtbeginS.o
don't know how to make <x86_gcc2>crtendS.o
...found 6064 target(s)...
...updating 143 target(s)...
...can't find 2 target(s)...
...can't make 1 target(s)...
 ..

/bin/sh: line 1: /packages/gcc-2.95.3_2014_07_26-1/.self/develop/tools/i586-pc-haiku/bin/ld: No such file or directory

.. etc

[pulkomandy]

You need to run configure --update to adjust for a new version of the gcc package.

[ttcoder]

Threshold set to 6 instead of 8: same behavior

[ttcoder]

Merci Adrien, that did the trick!

Augustin/Kallisti, no change in behavior with the patch. Syslog posted. Can also attach a git diff for review if you think it's necessary.

[kallisti5]

Replying to kallisti5:

heh.. I bet you're using VGA?

<kallisti5> whipsers "nutmeg" (#8626)

This isn't going to work until we properly support external displayport bridge devices. This also won't work until display port is functional. Sorry :-(

Card -> DisplayPort -> internal DP to VGA converter (NUTMEG) -> VGA -> Monitor

Getting to your display is a long and complex journey if you see TRAVIS or NUTMEG.

Not all newer cards use DisplayPort bridge devices... but they are getting a lot more common as cards move to being all digital. (Cards only supporting digital outputs such as DisplayPort devices internally and using cheap bridge devices to output video to legacy DVI, VGA, etc makes sense, it's also a lot more complex :-))

[kallisti5]

please try the attached patch (and toss the previous one) I *think* this patch should fix the error about a broken atombios function and could improve things greatly.

[ttcoder]

128 to 192 KB shadow ROM: flash of white still

[ttcoder]

Little behavior change with the new patch; cleaning up the syslog with grep -v, my uneducated eye seems some changes, but mainly stuff removed (due to my removing the previous patch?), little stuff added.

Edit: making quiet note that hrev48267 changes the radeon_hd accelerant and would help atom_allocate_fb_scratch() ..etc, though I don't think I get the "can't parse xyz" errors in my syslog

[kallisti5]

hm.. 0 impact. Lets toss that second patch.

I wonder where your system hides the AtomBIOS? This might be one that needs the ACPI ATRM checks completed.

[irtusb]

I got one APU with these graphics, how can I help?

[kallisti5]

Our display port support should be greatly improved in recent builds of Haiku. One issue on this ticket is still #10505.

I saw jessicah working on #10505 here: ​https://github.com/jessicah/haiku-private/commit/6d9649dab681a211ecd6d6c411d6d28d3e87105e

Not sure what the state of it is however.