On 6/14/17, Alexandre Demers <alexandre.f.demers at gmail.com> wrote: > On Wed, 14 Jun 2017 at 13:09 Deucher, Alexander <Alexander.Deucher at amd.com> > wrote: > >> >> >> *From:* amd-gfx [mailto:amd-gfx-bounces at 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? > CIK uses the same firmware as radeon just with a header added(you can compare BONAIRE_uvd.bin and bonaire_uvd.bin to see). I had started working on getting UVD working but had to put that work off due to moving(still not to a point where I can resume work). I had just tried adding the header but was getting a failure on ringtest before I had to put it off. If you don't add the header you'll need to add a fallback path that tries loading firmware without the header. Trevor >> >> >> 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 at lists.freedesktop.org >> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> >> >> >
