RE: [PATCH v6 01/13] pinctrl: core: Add pinctrl_get_device()

[Biju Das <biju.das.jz@xxxxxxxxxxxxxx>]

Hi Linus W,

Thanks for feedback.

> Subject: Re: [PATCH v6 01/13] pinctrl: core: Add pinctrl_get_device()
> 
> On Thu, Mar 9, 2023 at 3:19 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> 
> > I have an IP which detects short circuit between the output terminals
> > and disable the output from pwm pins ,when it detects short circuit to
> > protect from system failure.
> >
> > pwm-pins are involved in this operation.
> >
> > From user space we need to configure the type of protection for this
> > pins (eg: disable PWM output, when both pwm outputs are high at same
> time).
> 
> Why do you want to do this from user space?

To take care of the below features provided by Port Output Enable for GPT(a.k.a PWM)
(POEG) IP. 

The output pins of the general PWM timer (GPT) can be disabled by
using the port output enabling function for the GPT (POEG). 
Specifically, either of the following ways can be used[1].

[1]

Use case 1)
● Input level detection of the GTETRGA to GTETRGD pins (i.e: detect short circuit in switching circuit
externally and use an external pin(GTETRGA to GTETRGD) to disable the output pins of PWM)

Use case 2)
● Output-disable request from the GPT (GPT detects short circuit in switching circuit internally and 
disable the output pins of PWM)

Use case 3)
● Register settings(Detect short circuit in switching circuit
externally and use internal register to disable the output pins of PWM)

The advantage of providing these options from user space is, it is flexible.
Runtime user can configure the use case he wants to use for his product.

+Rob, + Krzysztof Kozlowski

If we cannot do it in user space, then we need to make it as part of
Dt bindings and users will define the use case they need in DT.

Some of the failure conditions in switching circuits are like below

when you use PWM push-pull configuration you SHOULD have a dead time.
When + mosfet is turned off - mosfet can't be immediately turned on
because you will create a direct path (short circuit) between + and -
as parasitic capacitance will leave + mosfet turned on for a while .
This will destroy your mosfets.

Dead time is the delay measured from turning off the driver switch
connected to one rail of the power supply to the time the switch
connected to the other rail of the power supply is turned on. 
Switching devices like MOSFETs and IGBTs turn off after a delay 
when the gate drive is turned off. If the other switch on the half
bridge is turned on immediately, both upper and lower switches may be 
in a conductive region for a brief moment, shorting the power rail. 
In order to avoid this, a dead time is maintained between turning off
of one switch and turning on the other in a half bridge.

POEG IP provides the below protections,

1) When the GTIOCA pin and the GTIOCB pin(PWM pins) are driven to an active level simultaneously, the
PWM generates an output-disable request to the POEG. Through reception of these requests,
the POEG can control whether the GTIOCA and GTIOCB pins are output-disabled

2) PWM output pins can be set to be disabled when the PWM output pins detect a dead time error
or short circuit detection between the output terminals

> 
> It sounds like something the kernel should be doing.

If we cannot do the above use cases[1] in user space, then we need to make it as part of
Dt bindings and it will be fully taken care in kernel.

> 
> The kernel has a PWM subsystem, and a pin control subsystem, and we don't
> even have a userspace ABI for pin control.
> Pin control is designed to avoid electrical disasters and a driver can add
> further policy for sure.
> 
> If you want to add policy of different types to avoid electrical disaster
> into the pin control driver, go ahead, just run it by Geert so he's on board
> with the ideas.

OK. Geert Can you please provide valuable suggestion how to address this use cases[1]
As mentioned above?

Currently Pin control driver is used for identifying the pwm device by using
pwm gname/fname and configuring the various use cases as mentioned above[1]
for a system.

> 
> > For that, we need to find a provider device (which provides gpt-pins).
> >
> > pinctrl_get_device() returns "current provider device" associated with
> fname/gname.
> > If " current provider device" == "pwm device" do the configuration.
> 
> I don't understand this, sorry.

Andy mentioned, the same fname/gname can be used in many *pin control* (provider) devices.

But when checking the code(/sys/kernel/debug/pinctrl/pinctrl-handles), at a given time, 
there will be only one device claims Pins associated with a given fname/gname. 

Currently pinctrl_get_device() returns the current *pin control* (provider) device
that claimed pins associated with a given fname/gname.

Cheers,
Biju