From: "Lazar, Lijo" <lijo.lazar@amd.com>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>,
amd-gfx@lists.freedesktop.org,
Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [PATCH] drm/amd: Add the capability to mark certain firmware as "required"
Date: Thu, 5 Dec 2024 09:29:30 +0530 [thread overview]
Message-ID: <176abc17-3f0e-4b9d-8043-0674a9cb6f7a@amd.com> (raw)
In-Reply-To: <CADnq5_PvErRnCQp-oTR1Qw46H6vo9BuWzH76ERqQ5XDzA1dkoQ@mail.gmail.com>
On 12/4/2024 10:15 PM, Alex Deucher wrote:
> On Wed, Dec 4, 2024 at 11:18 AM Lazar, Lijo <lijo.lazar@amd.com> wrote:
>>
>>
>>
>> On 12/4/2024 9:30 PM, Alex Deucher wrote:
>>> On Wed, Dec 4, 2024 at 10:56 AM Lazar, Lijo <lijo.lazar@amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 12/4/2024 7:51 PM, Alex Deucher wrote:
>>>>> On Wed, Dec 4, 2024 at 12:47 AM Lazar, Lijo <lijo.lazar@amd.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/4/2024 10:44 AM, Mario Limonciello wrote:
>>>>>>>
>>>>>>>>> +enum amdgpu_ucode_required {
>>>>>>>>> + AMDGPU_UCODE_NOT_REQUIRED,
>>>>>>>>> + AMDGPU_UCODE_REQUIRED,
>>>>>>>>
>>>>>>>> Couldn't this be handled in another API instead of having to flag every
>>>>>>>> load? By default, every ucode is required and if optional may be skipped
>>>>>>>> with amdgpu_ucode_request_optional() API?
>>>>>>>>
>>>>>>>
>>>>>>> I guess this would be a smaller patch, but 6 eggs one hand, half dozen
>>>>>>> in the other?
>>>>>>>
>>>>>>
>>>>>> I thought only ISP and gpu_info (no longer there for newer SOCs) fall
>>>>>> into the optional ones so far. The usage is rare, similar to the
>>>>>> nowarn() API usage.
>>>>>>
>>>>>> Also, as far as I know, the cap microcode is a must whenever used. That
>>>>>> is not optional.
>>>>>>
>>>>>
>>>>> The cap firmware is definitely optional. Some customers use it, some don't.
>>>>>
>>>>
>>>> I thought optional is something that can be ignored even if FW is not
>>>> found and then driver load proceeds.
>>>>
>>>> What is the expected driver action if we classify cap firmware as
>>>> optional and then it fails on a customer system that expects it?
>>>
>>> I guess if the customer expects it, they can make sure it's there.
>>
>> I don't think customer really can do that without any diagnostic message
>> from the driver. Driver has to show the right message. If it passes that
>> silently and fails at some other point, it could be a totally different
>> signature.
>
> yeah, I haven't seen any bug reports about the cap firmware so the
> current behavior seems to be fine.
>
In this case, need to have a info level message when a firmware
classified as optional is not found. As it is only during driver load, I
don't think that message will be an annoyance. On the other hand, it
gives useful info if it runs into trouble at a later point during load.
Thanks,
Lijo
> Alex
>
>>
>>> I'm not sure how you can have both without it being optional. For
>>> customers that don't use it, requiring it would break them if it
>>> wasn't present.
>>>
>>
>> It's working so far. Having all is better as long as loading that is
>> harmless.
>>
>> Thanks,
>> Lijo
>>
>>> Alex
>>>
>>>>
>>>> Thanks,
>>>> Lijo
>>>>
>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Lijo
>>>>>>
>>>>>>> Alex - what's your take?
>>>>>>
>>>>
>>
next prev parent reply other threads:[~2024-12-05 3:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 18:14 [PATCH] drm/amd: Add the capability to mark certain firmware as "required" Mario Limonciello
2024-12-03 21:34 ` Alex Deucher
2024-12-03 21:38 ` Mario Limonciello
2024-12-04 3:35 ` Lazar, Lijo
2024-12-04 5:14 ` Mario Limonciello
2024-12-04 5:37 ` Lazar, Lijo
2024-12-04 14:21 ` Alex Deucher
2024-12-04 15:56 ` Lazar, Lijo
2024-12-04 16:00 ` Alex Deucher
2024-12-04 16:02 ` Mario Limonciello
2024-12-04 16:18 ` Lazar, Lijo
2024-12-04 16:45 ` Alex Deucher
2024-12-05 3:59 ` Lazar, Lijo [this message]
2024-12-05 4:06 ` Mario Limonciello
2024-12-05 4:30 ` Lazar, Lijo
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=176abc17-3f0e-4b9d-8043-0674a9cb6f7a@amd.com \
--to=lijo.lazar@amd.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=mario.limonciello@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.