From: Mario Limonciello <mario.limonciello@amd.com>
To: Sebastian Reichel <sre@kernel.org>
Cc: "amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"Deucher, Alexander" <Alexander.Deucher@amd.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Ma, Jun" <Jun.Ma2@amd.com>
Subject: Re: [PATCH 2/3] power: supply: Don't count 'unknown' scope power supplies
Date: Thu, 5 Oct 2023 14:51:39 -0500 [thread overview]
Message-ID: <3eae4aad-37ff-43ae-9d1d-20850ed8c3ca@amd.com> (raw)
In-Reply-To: <20231004231003.z55btgajmixxadqo@mercury.elektranox.org>
On 10/4/2023 18:10, Sebastian Reichel wrote:
> Hi,
>
> On Sun, Oct 01, 2023 at 07:00:11PM -0500, Mario Limonciello wrote:
>> Let me try to add more detail.
>>
>> This is an OEM system that has 3 USB type C ports. It's an Intel system,
>> but this doesn't matter for the issue.
>> * when ucsi_acpi is not loaded there are no power supplies in the system and
>> it reports power_supply_is_system_supplied() as AC.
>> * When ucsi_acpi is loaded 3 power supplies will be registered.
>> power_supply_is_system_supplied() reports as DC.
>>
>> Now when you add in a Navi3x AMD dGPU to the system the power supplies don't
>> change. This particular dGPU model doesn't contain a USB-C port, so there
>> is no UCSI power supply registered.
>>
>> As amdgpu is loaded it looks at device initialization whether the system is
>> powered by AC or DC. Here is how it looks:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c?h=linux-6.5.y#n3834
>>
>> On the OEM system if amdgpu loads before the ucsi_acpi driver (such as in
>> the initramfs) then the right value is returned for
>> power_supply_is_system_supplied() - AC.
>>
>> If amdgpu is loaded after the ucsi_acpi driver, the wrong value is returned
>> for power_supply_is_system_supplied() - DC.
>>
>> This value is very important to set up the dGPU properly. If the wrong
>> value is returned, the wrong value will be notified to the hardware and the
>> hardware will not behave properly. On the OEM system this is a "black
>> screen" at bootup along with RAS errors emitted by the dGPU.
>>
>> With no changes to a malfunctioning kernel or initramfs binaries I can add
>> modprobe.blacklist=ucsi_acpi to kernel command line avoid registering those
>> 3 power supplies and the system behaves properly.
>>
>> So I think it's inappropriate for "UNKNOWN" scope power supplies to be
>> registered and treated as system supplies, at least as it pertains to
>> power_supply_is_system_supplied().
>
> So the main issue is, that the ucsi_acpi registers a bunch of
> power-supply chargers with unknown scope on a desktop systems
> and that results in the system assumed to be supplied from battery.
>
> The problem with your change is, that many of the charger drivers
> don't set a scope at all (and thus report unknown scope). Those
> obviously should not be skipped. Probably most of these drivers
> could be changed to properly set the scope, but it needs to be
> checked on a case-by-case basis. With your current patch they would
> regress in the oposite direction of your use-case.
>
> Ideally ucsi is changed to properly describe the scope, but I
> suppose this information is not available in ACPI?
>
> Assuming that the above are not solvable easily, my idea would be to
> only count the number of POWER_SUPPLY_TYPE_BATTERY device, which have
> !POWER_SUPPLY_SCOPE_DEVICE and exit early if there are none.
> Basically change __power_supply_is_system_supplied(), so that it
> looks like this:
>
> ...
> if (!psy->desc->get_property(psy, POWER_SUPPLY_PROP_SCOPE, &ret))
> if (ret.intval == POWER_SUPPLY_SCOPE_DEVICE)
> return 0;
>
> if (psy->desc->type == POWER_SUPPLY_TYPE_BATTERY)
> (*count)++;
> else
> if (!psy->desc->get_property(psy, POWER_SUPPLY_PROP_ONLINE,
> &ret))
> return ret.intval;
> ...
>
> That should work in both cases.
>
I tested both your suggestion as well as modifying UCSI driver to set
the scope. Both worked.
I've sent out v2 modifying the scope for UCSI driver. If for some
reason that ends up not working out we can revert to your generic
suggestion.
https://lore.kernel.org/linux-usb/20231005175230.232764-1-mario.limonciello@amd.com/T/#m9543f1f2c3767c0e88135c2e3f15ced65cfdf004
> -- Sebastian
>
>>>> drivers/power/supply/power_supply_core.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
>>>> index d325e6dbc770..3de6e6d00815 100644
>>>> --- a/drivers/power/supply/power_supply_core.c
>>>> +++ b/drivers/power/supply/power_supply_core.c
>>>> @@ -349,7 +349,7 @@ static int __power_supply_is_system_supplied(struct device *dev, void *data)
>>>> unsigned int *count = data;
>>>> if (!psy->desc->get_property(psy, POWER_SUPPLY_PROP_SCOPE, &ret))
>>>> - if (ret.intval == POWER_SUPPLY_SCOPE_DEVICE)
>>>> + if (ret.intval != POWER_SUPPLY_SCOPE_SYSTEM)
>>>> return 0;
>>>> (*count)++;
>>>> --
>>>> 2.34.1
>>>>
>>
next prev parent reply other threads:[~2023-10-05 19:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 22:59 [PATCH 0/3] Fix Navi3x boot and hotplug problems Mario Limonciello
2023-09-26 22:59 ` [PATCH 1/3] drm/amd: Fix detection of _PR3 on the PCIe root port Mario Limonciello
2023-09-28 16:58 ` Deucher, Alexander
2023-09-26 22:59 ` [PATCH 2/3] power: supply: Don't count 'unknown' scope power supplies Mario Limonciello
2023-09-30 20:18 ` Sebastian Reichel
2023-10-02 0:00 ` Mario Limonciello
2023-10-04 23:10 ` Sebastian Reichel
2023-10-05 19:51 ` Mario Limonciello [this message]
2023-09-26 22:59 ` [PATCH 3/3] Revert "drm/amd/pm: workaround for the wrong ac power detection on smu 13.0.0" Mario Limonciello
2023-09-28 18:00 ` [PATCH 0/3] Fix Navi3x boot and hotplug problems Alex Deucher
2023-09-28 20:01 ` Mario Limonciello
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=3eae4aad-37ff-43ae-9d1d-20850ed8c3ca@amd.com \
--to=mario.limonciello@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Jun.Ma2@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=sre@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®