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

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

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v6 01/13] pinctrl: core: Add pinctrl_get_device()
> 
> Hi Biju,
> 
> On Tue, Mar 14, 2023 at 9:27 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > > 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?
> 
> Is this configuration you need to do once, based on the hardware, or do you
> need to change it at run-time?

I think this configuration needed only once based on the hardware.

> 
> Before, I was under the impression you needed to change the configuration at
> run-time, hence the need for a sysfs API.
> If configuration is static, DT is the way to go.

At that time, I was not explored the possibility of creating poeg char device.

For eg: After the initial setting in DT, I guess with poeg char device we should be able to
achieve below use cases.

Use case 1)
 We can provide user space event indicating, Output-disable request from the GTETRGn pin occurred.
and provide some options (rd/wr file ops) to user space to clear the fault.

Use case 2)
 We can provide user space event indicating, Output-disable request from GPT disable request occurred.
 and provide some options(rd/wr file ops) to user space to clear the fault.

Use case 3)
 User space to control Output-disable through rd/wr file ops.

Please let me know is it ok or am I missing something here??

Cheers,
Biju