Hi Uwe, > From: Uwe Kleine-König, Sent: Wednesday, December 12, 2018 4:38 PM <snip> > > > In the past I suggested to weaken the requirements after pwm_disable, > > > but Thierry didn't like it. > > > > I read the following discussion once: > > https://patchwork.ozlabs.org/patch/959776/ > > Yeah, that's (part of) the discussion I meant. Thierry doesn't agree > though, so for now that's a dead end. My plan is to watch the pwm list > for a while to get a better picture about the different pwm > implementations because just one or two problematic cases are not > enough to justify a generic solution in the core in his eyes. I got it. > > I could not understand all this yet, but I think I should try to add a special gpio handling > > to the pwm-rcar.c driver instead of a generic approach because as you mentioned above, > > such special handling needs for the hardware. > > Being able to set PHO to zero would be still better, so I hope you > follow up on the question to your hardware guys if this is really > forbidden. (If I had access to such hardware, I'd bluntly try what > happens.) The hardware guy said that the output level is always high if PH0 is set to 0. However, the PH0 bitfields means "PWM High-Level Period" so that the behavior of the zero differs between the document and the hardware. So, we have to assume this is really forbidden unfortunately... Best regards, Yoshihiro Shimoda > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | http://www.pengutronix.de/ |
