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

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Biju,

On Tue, Mar 14, 2023 at 9:27 AM Biju Das <biju.das.jz@bp.renesas.com> 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@bp.renesas.com> 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?

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.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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