Re: AMDGPU VCE 1: some info needed
On Fri, 2021-01-08 at 15:00 -0500, Alex Deucher wrote: > On Fri, Jan 8, 2021 at 2:37 PM Alexandre Demers > wrote: > > > > > > On Fri, 2021-01-08 at 10:28 -0500, Alex Deucher wrote: > > > On Fri, Jan 8, 2021 at 3:11 AM Christian König > > > wrote: > > > > > > > > Hi Alexandre, > > > > > > > > Am 08.01.21 um 05:20 schrieb Alexandre Demers: > > > > > Hi there, > > > > > > > > > > Some of you may remember I was working on porting VCE 1 from > > > > > Radeon to > > > > > AMDGPU a few years ago... about 3 and a half years. I hadn't > > > > > had > > > > > time > > > > > to work on it until last Holidays. But why do I persist in > > > > > this > > > > > work? > > > > > Because GCN 1st gen was still used in some GPU produced 4 > > > > > years > > > > > ago > > > > > (Radeon 520 and just before R5 and R7 in the entry level). > > > > > > > > Yes and that is really valued. > > > > > > > > If we can get that working and and it is feature equivalent to > > > > radeon > > > > I'm perfectly fine to merge this. > > > > > > > > > I'm pretty happy with where the code is sitting now, however > > > > > I > > > > > have > > > > > some questions. > > > > > > > > > > 1- should the firmware be validated like it was under Radeon > > > > > and > > > > > as it > > > > > is done for the newly ported UVD 3.1 code? This would mean > > > > > having > > > > > to > > > > > work with keyselect, isn't it? > > > > > > > > No, that should only be necessary for UVD. > > > > > > > > > 2- last time I worked on VCE 1.0, Christian was saying that > > > > > it > > > > > was > > > > > possible a new VCE firmware could be provided for AMDGPU. > > > > > Then, > > > > > it > > > > > wasn't that clear, GCN 1.0 (SI) being in trouble and it was > > > > > considered > > > > > to strip it from AMDGPU. And a few months ago, UVD and DC > > > > > were > > > > > added > > > > > for SI to AMDGPU and a new UVD firmware was released (yeah!). > > > > > So, > > > > > is > > > > > it possible to have a new VCE firmware? I produced an > > > > > "updated" > > > > > tahiti > > > > > VCE file where a header is added (script available on my > > > > > account > > > > > on > > > > > GitHub). Still, if this can be useful, I'd prefer an official > > > > > firmware. > > > > > > > > Leo and I can push once more on this, but no guarantee that > > > > this > > > > will > > > > ever see the day of light. > > > > > > > > It was a really long and taxing process of getting UVD for SI > > > > out > > > > of the > > > > door. > > > > Well, if this doesn't block porting the code, let's just leave > > things > > as they are for now. > > > > > > > > > > > 3- is there any documentation about VCE 1.0 that would help > > > > > me > > > > > complete this work? > > > > > > > > Unfortunately not, we only have what was exposed with the > > > > initial > > > > code drop. > > > > > > > > > 3.1- Some variables that were previously defined are not > > > > > available > > > > > under sid.c, vce_v1_0_d.h, vce_v1_0_sh_mask.h and others. > > > > > Since > > > > > the > > > > > new values (mostly in the range of 0x8xxx) are completely > > > > > different > > > > > from the ones defined under Radeon (in the range of 0x2), > > > > > I'd > > > > > like > > > > > to be sure to use the good ones. I would assume the masks and > > > > > shifts > > > > > are still valid though. > > > > > > > > Do you have an example of what you need? > > > > > > Note that radeon uses byte aligned register headers and amdgpu > > > uses > > > dword aligned registe
Re: AMDGPU VCE 1: some info needed
On Fri, 2021-01-08 at 10:28 -0500, Alex Deucher wrote: > On Fri, Jan 8, 2021 at 3:11 AM Christian König > wrote: > > > > Hi Alexandre, > > > > Am 08.01.21 um 05:20 schrieb Alexandre Demers: > > > Hi there, > > > > > > Some of you may remember I was working on porting VCE 1 from > > > Radeon to > > > AMDGPU a few years ago... about 3 and a half years. I hadn't had > > > time > > > to work on it until last Holidays. But why do I persist in this > > > work? > > > Because GCN 1st gen was still used in some GPU produced 4 years > > > ago > > > (Radeon 520 and just before R5 and R7 in the entry level). > > > > Yes and that is really valued. > > > > If we can get that working and and it is feature equivalent to > > radeon > > I'm perfectly fine to merge this. > > > > > I'm pretty happy with where the code is sitting now, however I > > > have > > > some questions. > > > > > > 1- should the firmware be validated like it was under Radeon and > > > as it > > > is done for the newly ported UVD 3.1 code? This would mean having > > > to > > > work with keyselect, isn't it? > > > > No, that should only be necessary for UVD. > > > > > 2- last time I worked on VCE 1.0, Christian was saying that it > > > was > > > possible a new VCE firmware could be provided for AMDGPU. Then, > > > it > > > wasn't that clear, GCN 1.0 (SI) being in trouble and it was > > > considered > > > to strip it from AMDGPU. And a few months ago, UVD and DC were > > > added > > > for SI to AMDGPU and a new UVD firmware was released (yeah!). So, > > > is > > > it possible to have a new VCE firmware? I produced an "updated" > > > tahiti > > > VCE file where a header is added (script available on my account > > > on > > > GitHub). Still, if this can be useful, I'd prefer an official > > > firmware. > > > > Leo and I can push once more on this, but no guarantee that this > > will > > ever see the day of light. > > > > It was a really long and taxing process of getting UVD for SI out > > of the > > door. Well, if this doesn't block porting the code, let's just leave things as they are for now. > > > > > 3- is there any documentation about VCE 1.0 that would help me > > > complete this work? > > > > Unfortunately not, we only have what was exposed with the initial > > code drop. > > > > > 3.1- Some variables that were previously defined are not > > > available > > > under sid.c, vce_v1_0_d.h, vce_v1_0_sh_mask.h and others. Since > > > the > > > new values (mostly in the range of 0x8xxx) are completely > > > different > > > from the ones defined under Radeon (in the range of 0x2), I'd > > > like > > > to be sure to use the good ones. I would assume the masks and > > > shifts > > > are still valid though. > > > > Do you have an example of what you need? > > Note that radeon uses byte aligned register headers and amdgpu uses > dword aligned registers headers, so you'll need to shift the > definitions appropriately if you need to add any of the offsets to > amdgpu. I think vce_1_0 headers should be fine to use as is in > amdgpu. > > Alex > Ah bummer! That's why. OK, I'll keep that in mind revising my work then. > > > > > 3.2- Some statuses are undefined, sometimes magic values appear > > > here > > > and there without being ever defined or documented (status 0x337f > > > anyone?), even under CIK or they don't seem to be easily portable > > > from > > > other VCE versions. Having a name for a value is really helpful > > > without an official documentation, when the code is supposed to > > > be > > > self-documented. I've been able to identify some of them by > > > looking at > > > variables used under Radeon or under AMDGPU's UVD 3.1. > > > Interestingly, > > > some variables were previously defined under Radeon, but were > > > left > > > aside in AMDGPU... > > > > > > 3.3- Being able to know how to properly set/reset which part, in > > > what > > > order, etc. > > > > Sorry, I don't think we can help with documentation here. What I > > can do > > is to test your stuff on SI hardware if you get stuck with > > something and > > report back what might be the issue. If I ge
AMDGPU VCE 1: some info needed
Hi there, Some of you may remember I was working on porting VCE 1 from Radeon to AMDGPU a few years ago... about 3 and a half years. I hadn't had time to work on it until last Holidays. But why do I persist in this work? Because GCN 1st gen was still used in some GPU produced 4 years ago (Radeon 520 and just before R5 and R7 in the entry level). I'm pretty happy with where the code is sitting now, however I have some questions. 1- should the firmware be validated like it was under Radeon and as it is done for the newly ported UVD 3.1 code? This would mean having to work with keyselect, isn't it? 2- last time I worked on VCE 1.0, Christian was saying that it was possible a new VCE firmware could be provided for AMDGPU. Then, it wasn't that clear, GCN 1.0 (SI) being in trouble and it was considered to strip it from AMDGPU. And a few months ago, UVD and DC were added for SI to AMDGPU and a new UVD firmware was released (yeah!). So, is it possible to have a new VCE firmware? I produced an "updated" tahiti VCE file where a header is added (script available on my account on GitHub). Still, if this can be useful, I'd prefer an official firmware. 3- is there any documentation about VCE 1.0 that would help me complete this work? 3.1- Some variables that were previously defined are not available under sid.c, vce_v1_0_d.h, vce_v1_0_sh_mask.h and others. Since the new values (mostly in the range of 0x8xxx) are completely different from the ones defined under Radeon (in the range of 0x2), I'd like to be sure to use the good ones. I would assume the masks and shifts are still valid though. 3.2- Some statuses are undefined, sometimes magic values appear here and there without being ever defined or documented (status 0x337f anyone?), even under CIK or they don't seem to be easily portable from other VCE versions. Having a name for a value is really helpful without an official documentation, when the code is supposed to be self-documented. I've been able to identify some of them by looking at variables used under Radeon or under AMDGPU's UVD 3.1. Interestingly, some variables were previously defined under Radeon, but were left aside in AMDGPU... 3.3- Being able to know how to properly set/reset which part, in what order, etc. 4- Any input about 40 bit address limitation on VCE 1.0 and how to handle it if it applies? 5- Any chance to have some code reviewed even if it still doesn't work if I send it on this list? 6- I have some patches on the side to help document the code and define variables (even for Radeon), a few typos fixed, etc. Should I send them on this list? Cheers Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 210921)
This fix bug 210921 where DRM_INFO floods log when hitting an unsupported ASIC
in
amdgpu_device_asic_has_dc_support(). This info should be only called once.
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1cb7d73f7317..9246c2ae7b63 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3034,7 +3034,7 @@ bool amdgpu_device_asic_has_dc_support(enum amd_asic_type
asic_type)
#endif
default:
if (amdgpu_dc > 0)
- DRM_INFO("Display Core has been requested via kernel
parameter "
+ DRM_INFO_ONCE("Display Core has been requested via
kernel parameter "
"but isn't supported by ASIC,
ignoring\n");
return false;
}
--
2.30.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC 0/7] UVD support for SI in amdgpu
Hi there, As you may remember, I was working on porting VCE 1.0 to amdgpu around the time Piotr Redlewski sent the UVD patches. I would prefer to go the way proposed by Alex Deucher than to see SI support being dropped. I've been using the amdgpu on a 280X ever since it was possible. While there were some quirks in the beginning, it is plenty usable and performant ever since. Also, using amdgpu comes with some benefits unavailable with the radeon driver on a gaming perspective. Now, if my work on porting VCE 1.0 has stalled, it's because I'm now a father and I had only so little time to work on it. The code I was working on is still dormant (some of it was sent on my github repo) and I'm pretty sure I was almost done with it. Please, don't drop SI support from amdgpu. If it was only for me, amdgpu would be the default driver over radeon and people missing the UVD and VCE features should be the ones overriding the default choice. But this may not work for the majority (I don't know) and I understand that radeon is still the default for GCN 1.0/1.1. Cheers, Alexandre Demers On 2019-12-05 10:32, Deucher, Alexander wrote: [AMD Official Use Only - Internal Distribution Only] You could enable UVD support on amdgpu using the original firmware from radeon, but you'd have to adjust the memory map on the GPU for SI to match radeon. So updated firmware is not a requirement per se, it's just needed to keep the memory map the same as other GPUs. Alex *From:* amd-gfx on behalf of Christian König *Sent:* Thursday, December 5, 2019 10:19 AM *To:* Matthew Taylor ; amd-gfx@lists.freedesktop.org *Subject:* Re: [RFC 0/7] UVD support for SI in amdgpu Hi Matthew, Am 05.12.19 um 15:16 schrieb Matthew Taylor: Hi, Back in November 2017, Piotr Redlewski, provided some patches for UVD support in the SI cards, the thread had the same subject as this message. The outcome of a conversation between himself and other developers on the list was to wait for something in updated firmware. As this was over 2 years ago, I was wondering if the firmware has been updated sufficiently for Piotr's patches to be reconsidered or modified to deliver the UVD support for the SI cards? we discussed that internally quite lengthy and the firmware will probably never be released. To be honest we actually considering dropping SI support completely from amdgpu. Regards, Christian. Thanks for you help Kind Regards Matthew Taylor ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/amd-gfx <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx=02%7C01%7Calexander.deucher%40amd.com%7C14121ef4f0a049ddc3ea08d77996852f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637111559776723411=SpbvepoL17ImHwW7V5spbH46ze%2FNp7ll%2FqV86kE%2BBfU%3D=0> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [amdgpu] script to generate a VCE 1.0 amdgpu compatible firmware
On 2017-11-23 00:53, Alexandre Demers wrote: > Hi, > > I just want to let you know that I'm still alive and still committed to > porting VCE 1.0 from radeon to amdgpu. However, for many reasons, I've > been pretty much unable to work on the code since my last communication. > > That being said, I've created a script based on Piotr Redlewski's work > to generate a compatible VCE 1.0 firmware with amdgpu. The script can be > found on GithubGist: > https://gist.github.com/Oxalin/ba9aa9c1c1912e68f76dadcad436d1a4 > > Now, I've read the patchset sent by Redlewski for adding UVD on GCN 1 > devices. Christian, since you were to see if AMD could release a new UVD > firmware with header and correct 40bit addressing, could you ask if an > official VCE 1.0 firmware with an official header (and whatever else > could be needed) be released at the same time? > > Cheers > The script now lives on github at the following address: g...@github.com:Oxalin/vce-1.0-fw-convertor.git Christian, any news about official VCE and UVD firmwares from AMD? Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[amdgpu] script to generate a VCE 1.0 amdgpu compatible firmware
Hi, I just want to let you know that I'm still alive and still committed to porting VCE 1.0 from radeon to amdgpu. However, for many reasons, I've been pretty much unable to work on the code since my last communication. That being said, I've created a script based on Piotr Redlewski's work to generate a compatible VCE 1.0 firmware with amdgpu. The script can be found on GithubGist: https://gist.github.com/Oxalin/ba9aa9c1c1912e68f76dadcad436d1a4 Now, I've read the patchset sent by Redlewski for adding UVD on GCN 1 devices. Christian, since you were to see if AMD could release a new UVD firmware with header and correct 40bit addressing, could you ask if an official VCE 1.0 firmware with an official header (and whatever else could be needed) be released at the same time? Cheers -- Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/radeon: Small precision when failing to load UVD legacy firmware.
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 7431eb4a11b7..b4fb07ad9f4a 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -175,7 +175,7 @@ int radeon_uvd_init(struct radeon_device *rdev)
if (!fw_name || r) {
r = request_firmware(>uvd_fw, legacy_fw_name, rdev->dev);
if (r) {
- dev_err(rdev->dev, "radeon_uvd: Can't load firmware
\"%s\"\n",
+ dev_err(rdev->dev, "radeon_uvd: Can't load legacy
firmware \"%s\"\n",
legacy_fw_name);
return r;
}
--
2.14.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 0/6] Ground foundation for VCE 1 implementation
Oh and patch 3 "Small precision when failing to load legacy firmware" should have been a standalone patch, it is related to the radeon driver. I'll send it as so with drm/radeon in the title. Alexandre Demers On 2017-09-08 07:55, Alexandre Demers wrote: > Hi Christian! > > On 2017-09-08 04:24, Christian König wrote: >> First of all please prefix all subject lines for amdgpu kernel patches >> with drm/amdgpu. > You're right, I forgot. >> Additional to that I think we won't accept loading firmware files in >> the old format. Instead please just add the header to the files. If >> that turns out to be problematic I can start looking into providing >> those. > Noted, I'll drop the code and I'll create a temporary firmware with the > needed header. However, it would be convenient to see newer firmwares > for both VCE and UVD (cheers Trevor) coming from an official source > (AMD). Let's remove the old firmware loading patch and propose a glued > firmware. >> Apart from that thanks a lot for this work, this is really welcome. >> But does it actually work? Have you tested it with mesa? > This work doesn't activate any VCE functionality. On the other hand, it > shouldn't break anything either. It needs the next series of patches. > While the firmware loading and initialization seem to go through > correctly, I'm encountering hangs at boot. That's where I'll need some help. > > I'll post the next series in the next few days as a RFC so others can > help me go through. I just need to split the code in a few patches. > > Cheers, > Alex >> Thanks, >> Christian. >> >> Am 08.09.2017 um 04:48 schrieb Alexandre Demers: >>> This is the foundation for VCE 1 implementation, mostly ported from >>> radeon to >>> amdgpu. This should have no impact for now on the usability of the >>> driver. This >>> is the pretty straight-forward part. The heavier part is coming as a >>> RFC. >>> >>> I'd like to have this first part available to all, since I don't have >>> as much >>> time as I'd like to work on VCE 1 for now, but this could help others >>> to help me >>> on the task. >>> >>> If you are not satisfied with this first series, this can also be >>> considered as >>> a RFC. Please, comment as needed. >>> >>> Alexandre Demers (6): >>> Add initial VCE_V1_0 files. >>> Reorganize, rename, move and split some VCE 1 defines. >>> Small precision when failing to load legacy firmware. >>> Moving read and write pointer functions from radeon to amdgpu >>> Add support for SI's VCE firmwares (with and without header) >>> Fix indentation. >>> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 100 -- >>> drivers/gpu/drm/amd/amdgpu/si.c | 17 +- >>> drivers/gpu/drm/amd/amdgpu/si_dma.c | 5 +- >>> drivers/gpu/drm/amd/amdgpu/si_ih.c | 21 +- >>> drivers/gpu/drm/amd/amdgpu/sid.h | 70 >>> drivers/gpu/drm/amd/amdgpu/vce_v1_0.c | 394 >>> + >>> drivers/gpu/drm/amd/amdgpu/vce_v1_0.h | 29 ++ >>> .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h | 80 +++-- >>> .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h | 13 +- >>> drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- >>> 10 files changed, 589 insertions(+), 142 deletions(-) >>> create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.c >>> create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.h >>> > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 0/6] Ground foundation for VCE 1 implementation
Hi Christian! On 2017-09-08 04:24, Christian König wrote: > First of all please prefix all subject lines for amdgpu kernel patches > with drm/amdgpu. You're right, I forgot. > > Additional to that I think we won't accept loading firmware files in > the old format. Instead please just add the header to the files. If > that turns out to be problematic I can start looking into providing > those. Noted, I'll drop the code and I'll create a temporary firmware with the needed header. However, it would be convenient to see newer firmwares for both VCE and UVD (cheers Trevor) coming from an official source (AMD). Let's remove the old firmware loading patch and propose a glued firmware. > > Apart from that thanks a lot for this work, this is really welcome. > But does it actually work? Have you tested it with mesa? This work doesn't activate any VCE functionality. On the other hand, it shouldn't break anything either. It needs the next series of patches. While the firmware loading and initialization seem to go through correctly, I'm encountering hangs at boot. That's where I'll need some help. I'll post the next series in the next few days as a RFC so others can help me go through. I just need to split the code in a few patches. Cheers, Alex > > Thanks, > Christian. > > Am 08.09.2017 um 04:48 schrieb Alexandre Demers: >> This is the foundation for VCE 1 implementation, mostly ported from >> radeon to >> amdgpu. This should have no impact for now on the usability of the >> driver. This >> is the pretty straight-forward part. The heavier part is coming as a >> RFC. >> >> I'd like to have this first part available to all, since I don't have >> as much >> time as I'd like to work on VCE 1 for now, but this could help others >> to help me >> on the task. >> >> If you are not satisfied with this first series, this can also be >> considered as >> a RFC. Please, comment as needed. >> >> Alexandre Demers (6): >> Add initial VCE_V1_0 files. >> Reorganize, rename, move and split some VCE 1 defines. >> Small precision when failing to load legacy firmware. >> Moving read and write pointer functions from radeon to amdgpu >> Add support for SI's VCE firmwares (with and without header) >> Fix indentation. >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 100 -- >> drivers/gpu/drm/amd/amdgpu/si.c | 17 +- >> drivers/gpu/drm/amd/amdgpu/si_dma.c | 5 +- >> drivers/gpu/drm/amd/amdgpu/si_ih.c | 21 +- >> drivers/gpu/drm/amd/amdgpu/sid.h | 70 >> drivers/gpu/drm/amd/amdgpu/vce_v1_0.c | 394 >> + >> drivers/gpu/drm/amd/amdgpu/vce_v1_0.h | 29 ++ >> .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h | 80 +++-- >> .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h | 13 +- >> drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- >> 10 files changed, 589 insertions(+), 142 deletions(-) >> create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.c >> create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.h >> > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/6] Add initial VCE_V1_0 files.
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/vce_v1_0.c | 384 ++
drivers/gpu/drm/amd/amdgpu/vce_v1_0.h | 29 +++
2 files changed, 413 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.h
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
new file mode 100644
index ..f541a4b5ac51
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
@@ -0,0 +1,384 @@
+/*
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * Authors: Christian König <christian.koe...@amd.com>
+ */
+
+#include
+#include
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "sid.h"
+
+#define VCE_V1_0_FW_SIZE (256 * 1024)
+#define VCE_V1_0_STACK_SIZE(64 * 1024)
+#define VCE_V1_0_DATA_SIZE (7808 * (RADEON_MAX_VCE_HANDLES + 1))
+
+struct vce_v1_0_fw_signature
+{
+ int32_t off;
+ uint32_t len;
+ int32_t num;
+ struct {
+ uint32_t chip_id;
+ uint32_t keyselect;
+ uint32_t nonce[4];
+ uint32_t sigval[4];
+ } val[8];
+};
+
+/**
+ * vce_v1_0_get_rptr - get read pointer
+ *
+ * @rdev: radeon_device pointer
+ * @ring: radeon_ring pointer
+ *
+ * Returns the current hardware read pointer
+ */
+uint32_t vce_v1_0_get_rptr(struct radeon_device *rdev,
+ struct radeon_ring *ring)
+{
+ if (ring->idx == TN_RING_TYPE_VCE1_INDEX)
+ return RREG32(VCE_RB_RPTR);
+ else
+ return RREG32(VCE_RB_RPTR2);
+}
+
+/**
+ * vce_v1_0_get_wptr - get write pointer
+ *
+ * @rdev: radeon_device pointer
+ * @ring: radeon_ring pointer
+ *
+ * Returns the current hardware write pointer
+ */
+uint32_t vce_v1_0_get_wptr(struct radeon_device *rdev,
+ struct radeon_ring *ring)
+{
+ if (ring->idx == TN_RING_TYPE_VCE1_INDEX)
+ return RREG32(VCE_RB_WPTR);
+ else
+ return RREG32(VCE_RB_WPTR2);
+}
+
+/**
+ * vce_v1_0_set_wptr - set write pointer
+ *
+ * @rdev: radeon_device pointer
+ * @ring: radeon_ring pointer
+ *
+ * Commits the write pointer to the hardware
+ */
+void vce_v1_0_set_wptr(struct radeon_device *rdev,
+ struct radeon_ring *ring)
+{
+ if (ring->idx == TN_RING_TYPE_VCE1_INDEX)
+ WREG32(VCE_RB_WPTR, ring->wptr);
+ else
+ WREG32(VCE_RB_WPTR2, ring->wptr);
+}
+
+void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable)
+{
+ u32 tmp;
+
+ if (enable && (rdev->cg_flags & RADEON_CG_SUPPORT_VCE_MGCG)) {
+ tmp = RREG32(VCE_CLOCK_GATING_A);
+ tmp |= CGC_DYN_CLOCK_MODE;
+ WREG32(VCE_CLOCK_GATING_A, tmp);
+
+ tmp = RREG32(VCE_UENC_CLOCK_GATING);
+ tmp &= ~0x1ff000;
+ tmp |= 0xff80;
+ WREG32(VCE_UENC_CLOCK_GATING, tmp);
+
+ tmp = RREG32(VCE_UENC_REG_CLOCK_GATING);
+ tmp &= ~0x3ff;
+ WREG32(VCE_UENC_REG_CLOCK_GATING, tmp);
+ } else {
+ tmp = RREG32(VCE_CLOCK_GATING_A);
+ tmp &= ~CGC_DYN_CLOCK_MODE;
+ WREG32(VCE_CLOCK_GATING_A, tmp);
+
+ tmp = RREG32(VCE_UENC_CLOCK_GATING);
+ tmp |= 0x1ff000;
+ tmp &= ~0xff80;
+ WREG32(VCE_UENC_CLOCK_GATING, tmp);
+
+ tmp = RREG32(VCE_UENC_REG_CLOCK_GATING);
+ tmp |= 0x3ff;
+ WREG32(VCE_UENC_REG_CLOCK_GATING, tmp);
+ }
+}
+
+static void vce_v1_0_init_cg(struct radeon_dev
[PATCH 5/6] Add support for SI's VCE firmwares (with and without header)
Inspired on how it is done under radeon for UVD firmwares.
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 100
1 file changed, 75 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 735c38d7db0d..6d65fab6a4af 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -39,6 +39,10 @@
#define VCE_IDLE_TIMEOUT msecs_to_jiffies(1000)
/* Firmware Names */
+#ifdef CONFIG_DRM_AMDGPU_SI
+#define FIRMWARE_TAHITI_LEGACY "radeon/TAHITI_vce.bin"
+#define FIRMWARE_TAHITI"radeon/tahiti_vce.bin"
+#endif
#ifdef CONFIG_DRM_AMDGPU_CIK
#define FIRMWARE_BONAIRE "radeon/bonaire_vce.bin"
#define FIRMWARE_KABINI"radeon/kabini_vce.bin"
@@ -56,6 +60,10 @@
#define FIRMWARE_VEGA10"amdgpu/vega10_vce.bin"
+#ifdef CONFIG_DRM_AMDGPU_SI
+MODULE_FIRMWARE(FIRMWARE_TAHITI_LEGACY);
+MODULE_FIRMWARE(FIRMWARE_TAHITI);
+#endif
#ifdef CONFIG_DRM_AMDGPU_CIK
MODULE_FIRMWARE(FIRMWARE_BONAIRE);
MODULE_FIRMWARE(FIRMWARE_KABINI);
@@ -86,12 +94,21 @@ int amdgpu_vce_sw_init(struct amdgpu_device *adev, unsigned
long size)
{
struct amdgpu_ring *ring;
struct amd_sched_rq *rq;
- const char *fw_name;
+ const char *fw_name = NULL, *legacy_fw_name = NULL;
const struct common_firmware_header *hdr;
unsigned ucode_version, version_major, version_minor, binary_id;
int i, r;
switch (adev->asic_type) {
+#ifdef CONFIG_DRM_AMDGPU_SI
+ case CHIP_TAHITI:
+ case CHIP_VERDE:
+ case CHIP_PITCAIRN:
+ case CHIP_OLAND:
+ legacy_fw_name = FIRMWARE_TAHITI_LEGACY;
+ fw_name = FIRMWARE_TAHITI;
+ break;
+#endif
#ifdef CONFIG_DRM_AMDGPU_CIK
case CHIP_BONAIRE:
fw_name = FIRMWARE_BONAIRE;
@@ -138,32 +155,55 @@ int amdgpu_vce_sw_init(struct amdgpu_device *adev,
unsigned long size)
return -EINVAL;
}
- r = request_firmware(>vce.fw, fw_name, adev->dev);
- if (r) {
- dev_err(adev->dev, "amdgpu_vce: Can't load firmware \"%s\"\n",
- fw_name);
- return r;
- }
+ if (fw_name) {
+ /* Let's try to load the newer firmware first */
+ r = request_firmware(>vce.fw, fw_name, adev->dev);
+ if (r) {
+ dev_err(adev->dev, "amdgpu_vce: Can't load firmware
\"%s\"\n",
+ fw_name);
+ // return r;
+ } else {
- r = amdgpu_ucode_validate(adev->vce.fw);
- if (r) {
- dev_err(adev->dev, "amdgpu_vce: Can't validate firmware
\"%s\"\n",
- fw_name);
- release_firmware(adev->vce.fw);
- adev->vce.fw = NULL;
- return r;
- }
+ r = amdgpu_ucode_validate(adev->vce.fw);
+ if (r) {
+ dev_err(adev->dev, "amdgpu_vce: Can't validate
firmware \"%s\"\n",
+ fw_name);
+ release_firmware(adev->vce.fw);
+ adev->vce.fw = NULL;
+ return r;
+ }
- hdr = (const struct common_firmware_header *)adev->vce.fw->data;
+ hdr = (const struct common_firmware_header
*)adev->vce.fw->data;
- ucode_version = le32_to_cpu(hdr->ucode_version);
- version_major = (ucode_version >> 20) & 0xfff;
- version_minor = (ucode_version >> 8) & 0xfff;
- binary_id = ucode_version & 0xff;
- DRM_INFO("Found VCE firmware Version: %hhd.%hhd Binary ID: %hhd\n",
- version_major, version_minor, binary_id);
- adev->vce.fw_version = ((version_major << 24) | (version_minor << 16) |
+ ucode_version = le32_to_cpu(hdr->ucode_version);
+ version_major = (ucode_version >> 20) & 0xfff;
+ version_minor = (ucode_version >> 8) & 0xfff;
+ binary_id = ucode_version & 0xff;
+ DRM_INFO("Found VCE firmware Version: %hhd.%hhd Binary
ID: %hhd\n",
+ version_major, version_minor, binary_id);
+ adev->vce.fw_version = ((version_major << 24) |
(version_minor << 16) |
(binary_id << 8));
+ }
+ }
+
+ /*
+* In c
[PATCH 6/6] Fix indentation.
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com> --- drivers/gpu/drm/amd/amdgpu/si.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c index 08998639daeb..bb860faa8a95 100644 --- a/drivers/gpu/drm/amd/amdgpu/si.c +++ b/drivers/gpu/drm/amd/amdgpu/si.c @@ -1268,7 +1268,7 @@ static int si_common_early_init(void *handle) AMD_CG_SUPPORT_HDP_LS | AMD_CG_SUPPORT_HDP_MGCG; adev->pg_flags = 0; - adev->external_rev_id = (adev->rev_id == 0) ? 1 : + adev->external_rev_id = (adev->rev_id == 0) ? 1 : (adev->rev_id == 1) ? 5 : 6; break; case CHIP_PITCAIRN: -- 2.14.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 0/6] Ground foundation for VCE 1 implementation
This is the foundation for VCE 1 implementation, mostly ported from radeon to amdgpu. This should have no impact for now on the usability of the driver. This is the pretty straight-forward part. The heavier part is coming as a RFC. I'd like to have this first part available to all, since I don't have as much time as I'd like to work on VCE 1 for now, but this could help others to help me on the task. If you are not satisfied with this first series, this can also be considered as a RFC. Please, comment as needed. Alexandre Demers (6): Add initial VCE_V1_0 files. Reorganize, rename, move and split some VCE 1 defines. Small precision when failing to load legacy firmware. Moving read and write pointer functions from radeon to amdgpu Add support for SI's VCE firmwares (with and without header) Fix indentation. drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 100 -- drivers/gpu/drm/amd/amdgpu/si.c| 17 +- drivers/gpu/drm/amd/amdgpu/si_dma.c| 5 +- drivers/gpu/drm/amd/amdgpu/si_ih.c | 21 +- drivers/gpu/drm/amd/amdgpu/sid.h | 70 drivers/gpu/drm/amd/amdgpu/vce_v1_0.c | 394 + drivers/gpu/drm/amd/amdgpu/vce_v1_0.h | 29 ++ .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h | 80 +++-- .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h | 13 +- drivers/gpu/drm/radeon/radeon_uvd.c| 2 +- 10 files changed, 589 insertions(+), 142 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.c create mode 100644 drivers/gpu/drm/amd/amdgpu/vce_v1_0.h -- 2.14.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4/6] Moving read and write pointer functions from radeon to amdgpu
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/vce_v1_0.c | 62 ---
1 file changed, 36 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
index f541a4b5ac51..ab3b834758c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v1_0.c
@@ -27,10 +27,20 @@
#include
#include
-#include "radeon.h"
-#include "radeon_asic.h"
+#include "amdgpu.h"
+#include "amdgpu_vce.h"
#include "sid.h"
+#include "vce/vce_1_0_d.h"
+#include "vce/vce_1_0_sh_mask.h"
+
+#include "smu/smu_7_0_1_d.h"
+#include "smu/smu_7_0_1_sh_mask.h"
+
+#include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
+
+
#define VCE_V1_0_FW_SIZE (256 * 1024)
#define VCE_V1_0_STACK_SIZE(64 * 1024)
#define VCE_V1_0_DATA_SIZE (7808 * (RADEON_MAX_VCE_HANDLES + 1))
@@ -49,54 +59,54 @@ struct vce_v1_0_fw_signature
};
/**
- * vce_v1_0_get_rptr - get read pointer
+ * vce_v1_0_ring_get_rptr - get read pointer
*
- * @rdev: radeon_device pointer
- * @ring: radeon_ring pointer
+ * @ring: amdgpu_ring pointer
*
* Returns the current hardware read pointer
*/
-uint32_t vce_v1_0_get_rptr(struct radeon_device *rdev,
- struct radeon_ring *ring)
+static uint64_t vce_v1_0_ring_get_rptr(struct amdgpu_ring *ring)
{
- if (ring->idx == TN_RING_TYPE_VCE1_INDEX)
- return RREG32(VCE_RB_RPTR);
+ struct amdgpu_device *adev = ring->adev;
+
+ if (ring == >vce.ring[0])
+ return RREG32(mmVCE_RB_RPTR);
else
- return RREG32(VCE_RB_RPTR2);
+ return RREG32(mmVCE_RB_RPTR2);
}
/**
- * vce_v1_0_get_wptr - get write pointer
+ * vce_v1_0_ring_get_wptr - get write pointer
*
- * @rdev: radeon_device pointer
- * @ring: radeon_ring pointer
+ * @ring: amdgpu_ring pointer
*
* Returns the current hardware write pointer
*/
-uint32_t vce_v1_0_get_wptr(struct radeon_device *rdev,
- struct radeon_ring *ring)
+static uint64_t vce_v1_0_ring_get_wptr(struct amdgpu_ring *ring)
{
- if (ring->idx == TN_RING_TYPE_VCE1_INDEX)
- return RREG32(VCE_RB_WPTR);
+ struct amdgpu_device *adev = ring->adev;
+
+ if (ring == >vce.ring[0])
+ return RREG32(mmVCE_RB_WPTR);
else
- return RREG32(VCE_RB_WPTR2);
+ return RREG32(mmVCE_RB_WPTR2);
}
/**
- * vce_v1_0_set_wptr - set write pointer
+ * vce_v1_0_ring_set_wptr - set write pointer
*
- * @rdev: radeon_device pointer
- * @ring: radeon_ring pointer
+ * @ring: amdgpu_ring pointer
*
* Commits the write pointer to the hardware
*/
-void vce_v1_0_set_wptr(struct radeon_device *rdev,
- struct radeon_ring *ring)
+static void vce_v1_0_ring_set_wptr(struct amdgpu_ring *ring)
{
- if (ring->idx == TN_RING_TYPE_VCE1_INDEX)
- WREG32(VCE_RB_WPTR, ring->wptr);
+ struct amdgpu_device *adev = ring->adev;
+
+ if (ring == >vce.ring[0])
+ WREG32(mmVCE_RB_WPTR, lower_32_bits(ring->wptr));
else
- WREG32(VCE_RB_WPTR2, ring->wptr);
+ WREG32(mmVCE_RB_WPTR2, lower_32_bits(ring->wptr));
}
void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable)
--
2.14.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 3/6] Small precision when failing to load legacy firmware.
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 7431eb4a11b7..b4fb07ad9f4a 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -175,7 +175,7 @@ int radeon_uvd_init(struct radeon_device *rdev)
if (!fw_name || r) {
r = request_firmware(>uvd_fw, legacy_fw_name, rdev->dev);
if (r) {
- dev_err(rdev->dev, "radeon_uvd: Can't load firmware
\"%s\"\n",
+ dev_err(rdev->dev, "radeon_uvd: Can't load legacy
firmware \"%s\"\n",
legacy_fw_name);
return r;
}
--
2.14.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/6] Reorganize, rename, move and split some VCE 1 defines.
For consistency with other files under amdgpu driver.
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/si.c| 15 +++-
drivers/gpu/drm/amd/amdgpu/si_dma.c| 5 +-
drivers/gpu/drm/amd/amdgpu/si_ih.c | 21 +++---
drivers/gpu/drm/amd/amdgpu/sid.h | 70 ---
.../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h | 80 +-
.../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h | 13 +++-
6 files changed, 89 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index c0b1aabf282f..08998639daeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -38,15 +38,26 @@
#include "gmc_v6_0.h"
#include "si_dma.h"
#include "dce_v6_0.h"
+#include "vce_v1_0.h"
#include "si.h"
#include "dce_virtual.h"
+
#include "gca/gfx_6_0_d.h"
-#include "oss/oss_1_0_d.h"
+
#include "gmc/gmc_6_0_d.h"
+
#include "dce/dce_6_0_d.h"
-#include "uvd/uvd_4_0_d.h"
+
#include "bif/bif_3_0_d.h"
+#include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
+
+#include "uvd/uvd_4_0_d.h"
+
+#include "smu/smu_7_0_1_d.h"
+#include "smu/smu_7_0_1_sh_mask.h"
+
static const u32 tahiti_golden_registers[] =
{
mmAZALIA_SCLK_CONTROL, 0x0030, 0x0011,
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dma.c
b/drivers/gpu/drm/amd/amdgpu/si_dma.c
index 112969f3301a..fd50ab9933c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dma.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dma.c
@@ -26,6 +26,9 @@
#include "amdgpu_trace.h"
#include "sid.h"
+#include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
+
const u32 sdma_offsets[SDMA_MAX_INSTANCE] =
{
DMA0_REGISTER_OFFSET,
@@ -587,7 +590,7 @@ static int si_dma_resume(void *handle)
static bool si_dma_is_idle(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- u32 tmp = RREG32(SRBM_STATUS2);
+ u32 tmp = RREG32(mmSRBM_STATUS2);
if (tmp & (DMA_BUSY_MASK | DMA1_BUSY_MASK))
return false;
diff --git a/drivers/gpu/drm/amd/amdgpu/si_ih.c
b/drivers/gpu/drm/amd/amdgpu/si_ih.c
index e66084211c74..8fb9d00beea8 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_ih.c
@@ -26,6 +26,9 @@
#include "sid.h"
#include "si_ih.h"
+#include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
+
static void si_ih_set_interrupt_funcs(struct amdgpu_device *adev);
static void si_ih_enable_interrupts(struct amdgpu_device *adev)
@@ -39,7 +42,7 @@ static void si_ih_enable_interrupts(struct amdgpu_device
*adev)
WREG32(IH_RB_CNTL, ih_rb_cntl);
adev->irq.ih.enabled = true;
}
-
+
static void si_ih_disable_interrupts(struct amdgpu_device *adev)
{
u32 ih_rb_cntl = RREG32(IH_RB_CNTL);
@@ -207,7 +210,7 @@ static int si_ih_resume(void *handle)
static bool si_ih_is_idle(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- u32 tmp = RREG32(SRBM_STATUS);
+ u32 tmp = RREG32(mmSRBM_STATUS);
if (tmp & SRBM_STATUS__IH_BUSY_MASK)
return false;
@@ -233,23 +236,23 @@ static int si_ih_soft_reset(void *handle)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
u32 srbm_soft_reset = 0;
- u32 tmp = RREG32(SRBM_STATUS);
+ u32 tmp = RREG32(mmSRBM_STATUS);
if (tmp & SRBM_STATUS__IH_BUSY_MASK)
srbm_soft_reset |= SRBM_SOFT_RESET__SOFT_RESET_IH_MASK;
if (srbm_soft_reset) {
- tmp = RREG32(SRBM_SOFT_RESET);
+ tmp = RREG32(mmSRBM_SOFT_RESET);
tmp |= srbm_soft_reset;
- dev_info(adev->dev, "SRBM_SOFT_RESET=0x%08X\n", tmp);
- WREG32(SRBM_SOFT_RESET, tmp);
- tmp = RREG32(SRBM_SOFT_RESET);
+ dev_info(adev->dev, "mmSRBM_SOFT_RESET=0x%08X\n", tmp);
+ WREG32(mmSRBM_SOFT_RESET, tmp);
+ tmp = RREG32(mmSRBM_SOFT_RESET);
udelay(50);
tmp &= ~srbm_soft_reset;
- WREG32(SRBM_SOFT_RESET, tmp);
- tmp = RREG32(SRBM_SOFT_RESET);
+ WREG32(mmSRBM_SOFT_RESET, tmp);
+ tmp = RREG32(mmSRBM_SOFT_RESET);
udelay(50);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/sid.h b/drivers/gpu/drm/amd/amdgpu/sid.h
index c57eff159374..279d183f06c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/sid.h
+++ b/drivers/gpu/drm/amd/amdgpu/sid.h
@@ -331,7 +331,6 @@
# define DMIF_BUFFERS_ALLOCATED(x) ((x) << 0)
# de
Re: [PATCH 0/1] [rfc] Port UVD from radeon for SI
Hi Trevor, I'm working on the VCE port side, which is pretty similar to UVD in many ways. I'll send some patches about this port soon, but I'll also need some RFC in the lot and help to get over hangs I hit with VCE rings. It's just not going as fast as I'd like, we had a baby a few months ago and my spare time is now mostly for her. ;) UVD was next on my to-do list, si I'd like to work with you on this because I think we could both get help from each others works. If I may suggest two things: try to segregate your work in a few patches instead of a big one. It is easier to review, comment, test and isolate problems. Also, about the header you added to the UVD firmware, this is one way to do it, or you could backport how it is done under radeon. This is the path I've chosen for now under VCE. I'll give a look at your patch. Cheers. -- Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: Question about porting VCE1 to amdgpu
On Wed, 14 Jun 2017 at 13:09 Deucher, Alexander <alexander.deuc...@amd.com> wrote: > > > *From:* amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] *On Behalf > Of *Christian König > *Sent:* Wednesday, June 14, 2017 12:37 PM > *To:* Alexandre Demers; Freedesktop - AMD-gfx > *Subject:* Re: Question about porting VCE1 to amdgpu > > > > - Would we need a different firmware version with a different "hdr" for > the amdgpu driver? > > Yes, we should probably release the latest one instead of reusing the one > used with radeon. > > Actually, we should probably stick the same one as radeon for now until we > can verify the new firmware in general. Easier to start with a known > working case. > OK. Then, is it expected to have a validation failure with the current firmware? Is the header compatible with how the validation is done under VCE2 and others or should I keep how it was done under radeon? > > > BTW: Does VCE work on CIK? Alex, don't we run into the same issue there as > well? > > VCE works on CIK. We ported VCE and UVD to CIK as part of the initial > amdgpu bring up. > I've been using VCE2 port as my template for VCE1. My initial intention was to work on UVD, but I ended up plugging in VCE in the first place. UVD is on my todo list right next, I was expecting to working on it after fixing the VCE part. > > Alex > > > > - Wouldn't it be better to continue loading the driver while having VCE > disabled IF we fail when loading or validating the FW? Completely failing > to load the driver for this reason seems overkill IMO, since nothing has > been loaded in memory and no registry have been modified up to that point. > > UVD and VCE are actually needed for correct power management. When the > blocks fail to initialize you usually sooner or later run into problems > with power management (e.g. stuck inside a certain power level). > > OK, but right now it is disabled, so the situation wouldn't be worst isn't it? > - Would it be a good idea to send a patch as a RFC so some of you could > help me finish the job and maybe pinpoint where the last modifications need > to be done? > > Well you could, but to be honest without AMD releasing new firmware that > is most likely a futile effort. > I'll send a patch then, and we'll navigate from there. This will allow me to work on UVD in parallel. Alexandre Demers > > Regards, > Christian. > > Am 14.06.2017 um 18:22 schrieb Alexandre Demers: > > Hi, > > > > I've been working on porting VCE1 from radeon to amdgpu in the last few > weeks. I'm pretty much done and I've enabled the functionality to see how > it goes. However, I ended up with an error on the firmware validation (size > doesn't seem to fit), thus failing completely in loading the driver. I'm > testing on a R9 280X (Tahiti). > > > > Three questions then: > > - Would we need a different firmware version with a different "hdr" for > the amdgpu driver? > > - Wouldn't it be better to continue loading the driver while having VCE > disabled IF we fail when loading or validating the FW? Completely failing > to load the driver for this reason seems overkill IMO, since nothing has > been loaded in memory and no registry have been modified up to that point. > > - Would it be a good idea to send a patch as a RFC so some of you could > help me finish the job and maybe pinpoint where the last modifications need > to be done? > > > > Thank you! > > Alexandre Demers > > > > > ___ > > amd-gfx mailing list > > amd-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Question about porting VCE1 to amdgpu
Hi, I've been working on porting VCE1 from radeon to amdgpu in the last few weeks. I'm pretty much done and I've enabled the functionality to see how it goes. However, I ended up with an error on the firmware validation (size doesn't seem to fit), thus failing completely in loading the driver. I'm testing on a R9 280X (Tahiti). Three questions then: - Would we need a different firmware version with a different "hdr" for the amdgpu driver? - Wouldn't it be better to continue loading the driver while having VCE disabled IF we fail when loading or validating the FW? Completely failing to load the driver for this reason seems overkill IMO, since nothing has been loaded in memory and no registry have been modified up to that point. - Would it be a good idea to send a patch as a RFC so some of you could help me finish the job and maybe pinpoint where the last modifications need to be done? Thank you! Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards
On Thursday, February 23, 2017, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Thu, Feb 23, 2017 at 5:50 PM, Alexandre Demers > <alexandre.f.dem...@gmail.com <javascript:;>> wrote: > > First, sorry for not replying directly as I should normally, but I'm not > on > > my usual computer, so I can't. That being said... > > > > I may have my eyes in the same socket right now, but I think > > fiji_setup_dpm_led_config() always returns 0. > > > >> + if (mask) > >> + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr, > >> +PPSMC_MSG_LedConfig, > >> +mask); > >> + return 0; > >> +} > > > > Even when "if (mask)" is true, whether smum_send_msg_to_smc_with_ > parameter() > > succeeds or not, fiji_setup_dpm_led_config() spits a 0 at the end. > > > > Thus, > > > >> + result = fiji_setup_dpm_led_config(hwmgr); > >> + PP_ASSERT_WITH_CODE(0 == result, > >> +"Failed to setup dpm led config", return result); > > > > will always lead to "result" being set to 0... Am I missing something? > > > > Yes, that function can't fail. I suppose we could just make it a void > function, but I was following the same pattern of all the other > functions in that file. > > Alex > I see. Well, if there is no forseseeable change that would justify to return a different value, I would be tempted to go with the void. But either way, I'll live with it. Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards
First, sorry for not replying directly as I should normally, but I'm not on my usual computer, so I can't. That being said... I may have my eyes in the same socket right now, but I think fiji_setup_dpm_led_config() always returns 0. > + if (mask) > + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr, > +PPSMC_MSG_LedConfig, > +mask); > + return 0; > +} Even when "if (mask)" is true, whether smum_send_msg_to_smc_with_parameter() succeeds or not, fiji_setup_dpm_led_config() spits a 0 at the end. Thus, >* +result = fiji_setup_dpm_led_config(hwmgr); *>* + PP_ASSERT_WITH_CODE(0 == result, *>* + "Failed to setup dpm led config", return result); * will always lead to "result" being set to 0... Am I missing something? Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amdgpu's dce_vX_0_afmt_setmode(): why so different from radeon's
While looking at dce_v8_0_afmt_setmode(), I was thinking how crammed it was and how unintuitive it looked. I compared it to its radeon counterpart and I realized how readable this last one was. I had a look at the other dce_vX_0_afmt_setmode() under amdgpu and they all look alike. Can somebody explain why the amdgpu's side just includes everything in dce_vX_0_afmt_setmode() instead of having a nicely structured and readable presentation as it is under radeon? I'm trying to structure the thing a bit more like the radeon's side for dce6, but their are some differences in the step order and even a few more registry read and write calls. Any clue will be welcomed. Cheers. -- Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH drm/amdgpu] Fix indentation in dce_v8_0_audio_write_sad_regs()
Will do, thanks!
I'll make the change for the others already baking for DCE6. I still have a
thing or two to clean up, but it's almost there.
On Mon, 22 Aug 2016 at 09:19 Deucher, Alexander <alexander.deuc...@amd.com>
wrote:
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Alexandre Demers
> > Sent: Sunday, August 21, 2016 8:38 PM
> > To: amd-gfx@lists.freedesktop.org
> > Subject: [PATCH drm/amdgpu] Fix indentation in
> > dce_v8_0_audio_write_sad_regs()
>
> For these and future patches, please include drm/amdgpu: in the patch
> title.
>
> Alex
>
> >
> > Fixed indentation for readability.
> >
> > Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
> > ---
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > index 3ff1258..c7e5d5f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > @@ -1501,13 +1501,13 @@ static void
> > dce_v8_0_audio_write_sad_regs(struct drm_encoder *encoder)
> >
> > if (sad->format == eld_reg_to_type[i][1]) {
> > if (sad->channels > max_channels) {
> > - value = (sad->channels <<
> > -
> > AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__MAX_CHANNEL
> > S__SHIFT) |
> > - (sad->byte2 <<
> > -
> > AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__DESCRIPTOR_BY
> > TE_2__SHIFT) |
> > - (sad->freq <<
> > -
> > AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__SUPPORTED_FR
> > EQUENCIES__SHIFT);
> > - max_channels = sad->channels;
> > + value = (sad->channels <<
> > +
> > AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__MAX_CHANNEL
> > S__SHIFT) |
> > + (sad->byte2 <<
> > +
> > AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__DESCRIPTOR_BY
> > TE_2__SHIFT) |
> > + (sad->freq <<
> > +
> > AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__SUPPORTED_FR
> > EQUENCIES__SHIFT);
> > + max_channels = sad->channels;
> > }
> >
> > if (sad->format ==
> > HDMI_AUDIO_CODING_TYPE_PCM)
> > --
> > 2.9.3
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH drm/amdgpu] Use correct mask in dce_v8_0_afmt_setmode() and fix comment typos.
We were using the same mask twice. Looking at radeon, it seems we should be using HDMI_AVI_INFO_CONT instead as the second mask. Being there, fix typos in comments and improved readability. I haven't looked at other DCEs, the mask may also be wrong for them. Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com> --- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c index c7e5d5f..e424ecc 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c @@ -1693,6 +1693,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder *encoder, /* Silent, r600_hdmi_enable will raise WARN for us */ if (!dig->afmt->enabled) return; + offset = dig->afmt->offset; /* hdmi deep color mode general control packets setup, if bpc > 8 */ @@ -1817,7 +1818,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder *encoder, WREG32_OR(mmHDMI_INFOFRAME_CONTROL0 + offset, HDMI_INFOFRAME_CONTROL0__HDMI_AVI_INFO_SEND_MASK | /* enable AVI info frames */ - HDMI_INFOFRAME_CONTROL0__HDMI_AVI_INFO_SEND_MASK); /* required for audio info values to be updated */ + HDMI_INFOFRAME_CONTROL0__HDMI_AVI_INFO_CONT_MASK); /* required for audio info values to be updated */ WREG32_P(mmHDMI_INFOFRAME_CONTROL1 + offset, (2 << HDMI_INFOFRAME_CONTROL1__HDMI_AVI_INFO_LINE__SHIFT), /* anything other than 0 */ @@ -1826,13 +1827,13 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder *encoder, WREG32_OR(mmAFMT_AUDIO_PACKET_CONTROL + offset, AFMT_AUDIO_PACKET_CONTROL__AFMT_AUDIO_SAMPLE_SEND_MASK); /* send audio packets */ - /* it's unknown what these bits do excatly, but it's indeed quite useful for debugging */ + /* it's unknown what these bits do exactly, but it's indeed quite useful for debugging */ WREG32(mmAFMT_RAMP_CONTROL0 + offset, 0x00FF); WREG32(mmAFMT_RAMP_CONTROL1 + offset, 0x007F); WREG32(mmAFMT_RAMP_CONTROL2 + offset, 0x0001); WREG32(mmAFMT_RAMP_CONTROL3 + offset, 0x0001); - /* enable audio after to setting up hw */ + /* enable audio after setting up hw */ dce_v8_0_audio_enable(adev, dig->afmt->pin, true); } -- 2.9.3 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH drm/amdgpu] Fix indentation in dce_v8_0_audio_write_sad_regs()
Fixed indentation for readability.
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3ff1258..c7e5d5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1501,13 +1501,13 @@ static void dce_v8_0_audio_write_sad_regs(struct
drm_encoder *encoder)
if (sad->format == eld_reg_to_type[i][1]) {
if (sad->channels > max_channels) {
- value = (sad->channels <<
-
AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__MAX_CHANNELS__SHIFT) |
- (sad->byte2 <<
-
AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__DESCRIPTOR_BYTE_2__SHIFT) |
- (sad->freq <<
-
AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__SUPPORTED_FREQUENCIES__SHIFT);
- max_channels = sad->channels;
+ value = (sad->channels <<
+
AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__MAX_CHANNELS__SHIFT) |
+ (sad->byte2 <<
+
AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__DESCRIPTOR_BYTE_2__SHIFT) |
+ (sad->freq <<
+
AZALIA_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0__SUPPORTED_FREQUENCIES__SHIFT);
+ max_channels = sad->channels;
}
if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
--
2.9.3
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: radeon VS amdgpu: _afmt_init() behavior if kzalloc fails
Maybe, but it's already done, so. ;) By the way, I haven't sent my patches yet for SI's unimplemented dce functions, I'm still cleaning/tuning them up between other tasks at home, i t should be sent in the next few days. Lesson learned though: I should have planned what I wanted to do one thing at a time instead of many things at the same time... It would have been more efficient for patch creation. Cheers, Alexandre On Fri, 12 Aug 2016 at 13:41 StDenis, Tom <tom.stde...@amd.com> wrote: > Hi Alexandre, > > > That's probably fine. Though if it's touching on ASICs that amdgpu is > meant to support and it's not a critical bugfix (or API update) maybe time > is better spent getting support on the amdgpu side going for that hardware > instead. > > > Cheers, > > Tom > > > -- > *From:* Alexandre Demers <alexandre.f.dem...@gmail.com> > *Sent:* Friday, August 12, 2016 13:39 > > *To:* StDenis, Tom; Freedesktop - AMD-gfx > *Cc:* Alexander Deucher > *Subject:* Re: radeon VS amdgpu: _afmt_init() behavior if kzalloc fails > Hi again, > > I'm talking about modifying radeon's side to mimic amdgpu's behavior, > sorry for the confusion. > > Cheers, > Alexandre > > On Fri, 12 Aug 2016 at 12:17 StDenis, Tom <tom.stde...@amd.com> wrote: > >> Hi Alex, >> >> >> I'm unsure of what patch you have specifically. Are you suggesting to >> modify the radeon side to mimic the behaviour? Or to revert the amdgpu >> changes? I think reverting the amdgpu side won't go over well. It's >> churn and the current approach is arguably better for a number of reasons >> namely it's better defined behaviour and generally speaking if during >> module init a kmalloc of 100 bytes fails something bad is happening and you >> want to abort init anyways (so failing to load just because part of DCE >> fails is probably a good thing). >> >> >> Tom >> >> >> >> >> >> -- >> *From:* Alexandre Demers <alexandre.f.dem...@gmail.com> >> *Sent:* Friday, August 12, 2016 12:11 >> *To:* StDenis, Tom; Freedesktop - AMD-gfx >> *Cc:* Alexander Deucher >> *Subject:* Re: radeon VS amdgpu: _afmt_init() behavior if kzalloc fails >> >> Thanks for the quick answer Tom. I was thinking mostly as you do, but >> before sending the patch to the list, I wanted to be sure it was worth it. >> >> I'll send the patch later then, unless someone says otherwise. >> >> Cheers, >> Alexandre >> >> On Fri, 12 Aug 2016 at 11:50 StDenis, Tom <tom.stde...@amd.com> wrote: >> >>> Hi, >>> >>> >>> I wrote those changes back in March as part of a cleanup sweep. The >>> idea being was that if some had failed the state of the driver would be >>> unknown so it was cleaner to simply abort allocating any memory and set all >>> of the pointers to NULL. >>> >>> >>> Generally speaking if you fail to kmalloc a few bytes you've got bigger >>> problems to worry about than your audio not working ideally. >>> >>> >>> Tom >>> >>> >>> -- >>> *From:* amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of >>> Alexandre Demers <alexandre.f.dem...@gmail.com> >>> *Sent:* Friday, August 12, 2016 11:43 >>> *To:* Freedesktop - AMD-gfx >>> *Cc:* Alexander Deucher >>> *Subject:* radeon VS amdgpu: _afmt_init() behavior if kzalloc fails >>> >>> Hi, >>> >>> While comparing radeon's radeon_afmt_init() to dce_vX_0_afmt_init() on >>> the amdgpu's side, I saw that on the latter: >>> 1- when kzalloc fails to allocate mem for all afmt, an ENOMEM is returned >>> 2- all previously allocated afmt are freed >>> >>> So on the amdgpu's side, it is an "all or none allocated" situation, >>> while on the radeon's side, some afmt may be allocated and initialized. >>> >>> Moreover, returning an ENOMEM prevents any other function calls in >>> dce_vX_0_sw_init() on the amdgpu's side, while it continues on the >>> radeon's side. >>> >>> What is the expected behavior here? Should we rewind the memory >>> allocation as it is done under amdgpu when we can't allocate memory for all >>> afmt or is it OK to do as it is done on radeon? Should we stop any >>> remaining steps in radeon_modeset_init() if it fails (thus, returning a >>> ENOMEM from radeon_afmt_init())? >>> >>> The patch is already ready if needed, I could send it later from home if >>> the amdgpu's behavior is the one that we are looking for. >>> >>> Cheers, >>> Alexandre Demers >>> >> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Wrong shift in dce_v8_0_afmt_update_ACR() under dce_v8_0.c?
Hi, While looking into dce_v8_0.c, I stumbled upon something that might be wrong dce_v8_0_afmt_update_ACR(). We can read: WREG32(mmHDMI_ACR_32_0 + offset, (acr.cts_32khz << HDMI_ACR_44_0__HDMI_ACR_CTS_44__SHIFT)); However, I'm mostly sure it should be (luckily, the shift is of the same value): WREG32(mmHDMI_ACR_32_0 + offset, (acr.cts_32khz << HDMI_ACR_32_0__HDMI_ACR_CTS_32__SHIFT)); Cheers -- Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] Standardizing the info message for unimplemented functions
Signed-off-by: Alexandre Demers <alexandre.f.dem...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index 07e0475..9e327be 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -106,14 +106,14 @@ static const uint32_t hpd_int_control_offsets[6] = {
static u32 dce_v6_0_audio_endpt_rreg(struct amdgpu_device *adev,
u32 block_offset, u32 reg)
{
- DRM_INFO(": dce_v6_0_audio_endpt_rreg no impl\n");
+ DRM_INFO(": dce_v6_0_audio_endpt_rreg --- not implemented!\n");
return 0;
}
static void dce_v6_0_audio_endpt_wreg(struct amdgpu_device *adev,
u32 block_offset, u32 reg, u32 v)
{
- DRM_INFO(": dce_v6_0_audio_endpt_wreg no impl\n");
+ DRM_INFO(": dce_v6_0_audio_endpt_wreg --- not implemented!\n");
}
static bool dce_v6_0_is_in_vblank(struct amdgpu_device *adev, int crtc)
@@ -459,7 +459,7 @@ static u32 dce_v6_0_hpd_get_gpio_reg(struct amdgpu_device
*adev)
static bool dce_v6_0_is_display_hung(struct amdgpu_device *adev)
{
- DRM_INFO(": dce_v6_0_is_display_hung no imp!\n");
+ DRM_INFO(": dce_v6_0_is_display_hung --- not implemented!\n");
return true;
}
@@ -1321,17 +1321,17 @@ static void dce_v6_0_afmt_audio_select_pin(struct
drm_encoder *encoder)
static void dce_v6_0_audio_write_latency_fields(struct drm_encoder *encoder,
struct drm_display_mode *mode)
{
- DRM_INFO(": dce_v6_0_audio_write_latency_fields---no imp!\n");
+ DRM_INFO(": dce_v6_0_audio_write_latency_fields --- not
implemented!\n");
}
static void dce_v6_0_audio_write_speaker_allocation(struct drm_encoder
*encoder)
{
- DRM_INFO(": dce_v6_0_audio_write_speaker_allocation---no
imp!\n");
+ DRM_INFO(": dce_v6_0_audio_write_speaker_allocation --- not
implemented!\n");
}
static void dce_v6_0_audio_write_sad_regs(struct drm_encoder *encoder)
{
- DRM_INFO(": dce_v6_0_audio_write_sad_regs---no imp!\n");
+ DRM_INFO(": dce_v6_0_audio_write_sad_regs --- not implemented!\n");
}
*/
@@ -1339,7 +1339,7 @@ static void dce_v6_0_audio_enable(struct amdgpu_device
*adev,
struct amdgpu_audio_pin *pin,
bool enable)
{
- DRM_INFO(": dce_v6_0_audio_enable---no imp!\n");
+ DRM_INFO(": dce_v6_0_audio_enable --- not implemented!\n");
}
static const u32 pin_offsets[7] =
@@ -1376,12 +1376,12 @@ static void dce_v6_0_afmt_update_ACR(struct drm_encoder
*encoder, uint32_t clock
static void dce_v6_0_afmt_update_avi_infoframe(struct drm_encoder *encoder,
void *buffer, size_t size)
{
- DRM_INFO(": dce_v6_0_afmt_update_avi_infoframe---no imp!\n");
+ DRM_INFO(": dce_v6_0_afmt_update_avi_infoframe --- not
implemented!\n");
}
static void dce_v6_0_audio_set_dto(struct drm_encoder *encoder, u32 clock)
{
- DRM_INFO(": dce_v6_0_audio_set_dto---no imp!\n");
+ DRM_INFO(": dce_v6_0_audio_set_dto --- not implemented!\n");
}
*/
/*
@@ -1390,7 +1390,7 @@ static void dce_v6_0_audio_set_dto(struct drm_encoder
*encoder, u32 clock)
static void dce_v6_0_afmt_setmode(struct drm_encoder *encoder,
struct drm_display_mode *mode)
{
- DRM_INFO(": dce_v6_0_afmt_setmode no impl \n");
+ DRM_INFO(": dce_v6_0_afmt_setmode --- not implemented!\n");
}
static void dce_v6_0_afmt_enable(struct drm_encoder *encoder, bool enable)
@@ -2553,7 +2553,7 @@ static int dce_v6_0_wait_for_idle(void *handle)
static int dce_v6_0_soft_reset(void *handle)
{
- DRM_INFO(": dce_v6_0_soft_reset --- no impl!!\n");
+ DRM_INFO(": dce_v6_0_soft_reset --- not implemented!\n");
return 0;
}
--
2.9.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Any chance of seeing a merge from drm-next-4.8-wip-si?
Hi Alex, I'd like to know if there is any chance to see a merge / pull request for the SI code from drm-next-4.8-wip-si into mainline kernel for 4.8? Nothing seems to have been added to the branch since the end of May. I haven't seen any thing merged from that branch into drm-next-4.8(-wip) either. What is its status? Is it considered completed and ready for merge / test / tune up? As you know, I'm interested in helping on the task. However, I stopped any work on porting SI to amdgpu when I learned someone at AMD was working on it. It would have been too long for me to do it in comparison. Now, if I can be of any help, let me know, my R9 280X is waiting for some tests. Cheers, -- Alexandre Demers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
