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
