Hi Linus W, Thanks for feedback. > 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? Currently Pin control driver is used for identifying the pwm device by using pwm gname/fname and configuring the various use cases as mentioned above[1] for a system. > > > For that, we need to find a provider device (which provides gpt-pins). > > > > pinctrl_get_device() returns "current provider device" associated with > fname/gname. > > If " current provider device" == "pwm device" do the configuration. > > I don't understand this, sorry. Andy mentioned, the same fname/gname can be used in many *pin control* (provider) devices. But when checking the code(/sys/kernel/debug/pinctrl/pinctrl-handles), at a given time, there will be only one device claims Pins associated with a given fname/gname. Currently pinctrl_get_device() returns the current *pin control* (provider) device that claimed pins associated with a given fname/gname. Cheers, Biju
