Hi Biju,

On Tue, Mar 14, 2023 at 12:33 PM Biju Das [off-list ref] wrote:

quoted

Subject: Re: [PATCH v6 01/13] pinctrl: core: Add pinctrl_get_device()
On Tue, Mar 14, 2023 at 9:27 AM Biju Das [off-list ref] wrote:

quoted

quoted

Subject: Re: [PATCH v6 01/13] pinctrl: core: Add
pinctrl_get_device() On Thu, Mar 9, 2023 at 3:19 PM Biju Das

[off-list ref] wrote:

quoted

quoted

quoted

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.

quoted

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

quoted

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.

quoted

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.

quoted

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@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