Hi Biju,
On Tue, Mar 14, 2023 at 12:33 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > Subject: Re: [PATCH v6 01/13] pinctrl: core: Add pinctrl_get_device()
> > 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.
OK, so using DT for that would be fine.
> > 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??
Using a char device for that sounds fine to me.
If you just needed to clear the fault, you could use a device property in sysfs.
But that would still leave us without a way to provide events to userspace.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
