From: Darren Salt <devspam@moreofthesa.me.uk>
To: christian.koenig@amd.com
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] amdgpu: resize BAR0 to the maximum available size, even if it doesn't cover VRAM
Date: Fri, 11 Dec 2020 19:48:08 +0000 [thread overview]
Message-ID: <58E2C3B550%devspam@moreofthesa.me.uk> (raw)
In-Reply-To: <77805324-8fdc-8d72-f033-7d75ae04947e@gmail.com>
I demand that Christian König may or may not have written...
> Am 11.12.20 um 02:42 schrieb Darren Salt:
>> I demand that Christian König may or may not have written...
> [SNIP]
> Well I did wrote that :)
“did write”, surely…
>> I used dd:
>> # dd if=/sys/kernel/debug/dri/0/amdgpu_vram bs=1048576 count=1 skip=6127 | hexdump -C |tail
> That won't work. amdgpu_vram uses a MMIO register pair to access VRAM which
> works even when it isn't CPU visible.
> Thinking more about it umr would probably use this as well, so that won't
> work either.
> You could try to use dd on /dev/mem with the offset of the BAR.
Looks like that's RAM accessed by physical address, so that won't work
either. And I do see dd reporting ‘bad address’.
>> Anyway I agree that a PCI subsystem quirk might be appropriated.
> I'm going to discuss AMD internally why you have such strange values in
> the RBAR registers.
I'm thinking probably an error by somebody at Sapphire, but we'll see…
Hopefully, that'll sort it out, at least for new cards. I doubt that mine's
the only one like this, and it seems likely that most already out there won't
be updated (shoudl there be new VBIOS releases as a reault).
Anyway, I have a quirk patch written now – untested as yet, and probably
going to be changed due to other changes before I do test it.
[snip]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
prev parent reply other threads:[~2020-12-11 19:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 0:57 [PATCH] amdgpu: resize BAR0 to the maximum available size, even if it doesn't cover VRAM Darren Salt
2020-12-10 10:17 ` Christian König
2020-12-10 13:59 ` Darren Salt
2020-12-10 20:41 ` Christian König
2020-12-11 1:42 ` Darren Salt
2020-12-11 16:46 ` Christian König
2020-12-11 19:48 ` Darren Salt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58E2C3B550%devspam@moreofthesa.me.uk \
--to=devspam@moreofthesa.me.uk \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.