lkml.org 
[lkml]   [2023]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file
From
On 22/08/2023 17:18, Shenwei Wang wrote:
>
>
>> -----Original Message-----
>> From: Rob Herring <robh+dt@kernel.org>
>> Sent: Monday, August 21, 2023 1:50 PM
>> To: Shenwei Wang <shenwei.wang@nxp.com>
>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>; Krzysztof Kozlowski
>> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>;
>> Ulf Hansson <ulf.hansson@linaro.org>; Liam Girdwood
>> <lgirdwood@gmail.com>; Mark Brown <broonie@kernel.org>;
>>> Thank you for providing the link. After reviewing the entire thread, I
>>> still don't understand how to proceed. What is the conclusion
>>> regarding this commonly used use case but overlooked feature in the
>> upstream kernel?
>>
>> Overlooked implies we missed and ignored it, but the same concept has been
>> submitted twice and rejected twice. What use case cannot be supported?
>>
>
> No offend. :) Sorry for my poor word. To provide more context, a common use case
> example is using a GPIO pin as a power switch. The current implementation operates
> as a fixed regulator, which makes it difficult to control the on/off timing without modifying
> its driver.

So it is a problem of a driver?

> It also lacks power management support.

Which is not related to bindings but implementation in given driver.

>
>> The detail that power-domains get handled automatically is an implementation
>> detail in the kernel (currently). That could easily change and you'd be in the same
>> position as with regulator supplies.
>
> The proposed regulator-pd driver follows the standard PD driver framework, so it for sure
> relies on certain kernel implementation details. If those underlying implementation details
> change in the future, this driver as well as other PD drivers built on the same framework
> would need to be updated accordingly.

We talk about bindings which you would not be allowed to change. Thus
your case would stop working...

>
>> We could just as easily decide to make the driver core turn on all supplies in a
>> node. That would give you the same "feature". Why would you design your DT
>> around implementation decisions of the OS?
>>
>
> This DT properties are proposed solely for this specific driver, not to hack the OS. This
> is no different than other PD drivers like gpc/scu-pd/imx93-pd.

I am not sure if you got Rob's point, I have feelings that not. Argument
that some OS implements something some way, is not an argument for a new
binding, barely hardware related.

Best regards,
Krzysztof

\
 
 \ /
  Last update: 2023-08-22 17:26    [W:0.070 / U:1.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site