From: "Christian König" <christian.koenig@amd.com>
To: "Jerome Glisse" <j.glisse@gmail.com>,
"Christian König" <deathsimple@vodafone.de>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.
Date: Wed, 16 Mar 2016 16:19:16 +0100 [thread overview]
Message-ID: <56E97974.4050107@amd.com> (raw)
In-Reply-To: <CAH3drwZbJSuU_1WDv2pUz3siaAzeavBz7-V7O5WJ-W+6M7zjNg@mail.gmail.com>
Am 16.03.2016 um 15:59 schrieb Jerome Glisse:
> On Wed, Mar 16, 2016 at 2:03 PM, Christian König
> <deathsimple@vodafone.de> wrote:
>> Am 16.03.2016 um 13:48 schrieb Jérôme Glisse:
>>> From: Jérome Glisse <jglisse@redhat.com>
>>>
>>> This consolidate uvd/vce into a common shape for all generation. It
>>> also leverage the rdev->has_uvd flags to know what it is useless to
>>> try to resume/suspend uvd/vce block.
>>>
>>> There is no functional changes when there is no error. On error the
>>> device driver will behave differently than before after this patch.
>>> It should now safely ignore uvd/vce errors and keeps normal operation
>>> of others engine. This is an improvement over current situation where
>>> we have different behavior depending on GPU generation and on what
>>> fails.
>>>
>>> Finaly this is a preparatory step for a patch which allow to disable
>>> uvd/vce as a driver option.
>>>
>>> This have only been tested on southern island so please test it on
>>> other generations (i do not have hardware handy for now).
>>>
>>> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>
>> NAK, skipping UVD and VCE suspend/resume when initialization fails should
>> already be implemented.
>>
>> There might be some (quite some) bugs in there, but that doesn't justify
>> reworking the initialization over all different generations. Especially
>> since you don't have hardware to test all of them.
>>
>> Just make sure that radeon_uvd/vce_fini() is called when something goes
>> wrong and/or that the UVD/VCE BO is properly released.
>>
>> Regards,
>> Christian.
> Current code is a mess when it comes to handling error related to
> uvd/vce. This patch consolidate control flow in something easy to
> follow. You can check that there is absolulety no control flow change
> for the case where uvd/vce works and thus it does not break anything
> that works. It will only gracefully fails and cleanup if things go
> wrong. So while i have not tested on other hw i am confident that this
> does not introduce regression.
>
> I tried to do it without consolidation but it ended up in adding even
> more if() levels that line did begins after 80colums. So please
> reconsider because this is an improvement over existing code.
Well then please point out at the example of the SI or CIK code what
exactly is missing here.
Please also note that VCE/UVD has dependencies on power management, so
that when they are once initialized they should NOT be turned off again.
I only briefly skimmed over your patch, but it actually looks like to me
that you broken that by trying to cleanup the initialization routine.
Regards,
Christian.
>
> Jérôme
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-03-16 15:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-16 12:48 [PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend Jérôme Glisse
2016-03-16 13:03 ` Christian König
2016-03-16 14:59 ` Jerome Glisse
2016-03-16 15:19 ` Christian König [this message]
2016-03-16 15:56 ` Jerome Glisse
2016-03-16 17:06 ` Christian König
2016-03-16 17:43 ` Jerome Glisse
2016-03-16 18:51 ` Christian König
2016-03-16 20:41 ` Dave Airlie
2016-03-16 20:58 ` Deucher, Alexander
2016-03-17 7:36 ` Daniel Vetter
2016-03-18 4:00 ` Michel Dänzer
2016-03-18 8:16 ` Daniel Vetter
2016-03-19 9:41 ` Daniel Vetter
2016-03-19 10:46 ` Daniel Vetter
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=56E97974.4050107@amd.com \
--to=christian.koenig@amd.com \
--cc=alexander.deucher@amd.com \
--cc=deathsimple@vodafone.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=j.glisse@gmail.com \
--cc=jglisse@redhat.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.