Message-ID: <daf6ae39-3c5f-41a1-b061-498346de6fe1@oss.qualcomm.com>
Date: Sat, 28 Jun 2025 16:35:32 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Jens Glathe <jens.glathe@...schoolsolutions.biz>,
        Mark Brown <broonie@...nel.org>,
        Aleksandrs Vinarskis <alex.vinarskis@...il.com>,
        Manivannan Sadhasivam <mani@...nel.org>
Cc: linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Subject: Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

On 6/28/25 8:14 AM, Jens Glathe wrote:
> Hi there,
> 
> On 10.06.25 15:51, Mark Brown wrote:
>> On Mon, Jun 09, 2025 at 11:15:09PM +0200, Aleksandrs Vinarskis wrote:
>>> But how would we approach the lack of particular information, in this
>>> case all possible VID/PID for an embedded camera? VID/PID was
>>> identified by checking the actual device, which does not rule out OEM
>>> switching camera SKU on the next batch, same way they do with other
>>> peripherals.
>> I'm not saying this a particularly great or pleasant solution, just that
>> it's where things are at.  You're trying to solve an OS problem with a
>> firmware description which is a bit of a mismatch, ideally the firmware
>> descriptions would be better but that's just not how ACPI laptops work
>> unfortunately.
> 
> Just like dummy-regulator is an (undesired, but apparently life-saving) solution to the issue of not having enough info to correctly specify the power supply, it is in this use case, so to speak. You found the enable pin to make the peripheral work, you make an educated guess and define it as a regulator. For power management to handle it, you need a consumer. For all this its nearly irrelevant what the device id is (USB discovery runs via the USB host controller in this camera case) nor is it really relevant what the voltage is (also an educated guess what stand-alone USB devices would get via the bus).
> 
> Of course, it would be better to get the correct info and describe it accordingly. But more often than not, reality bites.
> 
> On that note, another example. I replaced the WLAN and NIC m.2 cards on the Snapdragon Dev Kit with an Intel i226v m.2 card that fits into the A slot where the WCN7850 was. To reliably enable it, I had to:
> 
> - either keep the whole pmu-wcn7850 definition (with wcn7850 consumer description, regulators apparently on the card and all) in the tree
> 
> - or "wire up" the vreg_wcn_3p3 so that it is activated and accepts any consumer.
> 
> This didn't go well.
> 
> vddpe-3v3-supply on the pcie slot: works, but no USB-A for whatever reason.
> 
> Dummy consumer for the regulator like this
> 
>     lan {
>         compatible = "regulator-dummy-consumer";
> 
>         vdd-supply = <&vreg_wcn_3p3>;
>     };

In this case, it's more or less easy because the 3v3 supply should
probably be bound to the PCIe port (+Mani)

Konrad

> 
> This works, reliably. The i226v card doesn't have a node, nor does it need one. The driver for this card (igc) seems to be at odds with power management, so you need additional kernel parameters anyway.
> 
> I'm in favor of having a driver like dummy-consumer to make things work when the info for a better definition isn't there. Like dummy-regulator.
> 
>> It does seem a lot easier to just mark the supplies as always on if
>> there's no integration with an actual client driver TBH.
> 
> Exacerbating power consumption when suspended.
> 
> with best regards
> 
> Jens
> 

Powered by blists - more mailing lists