Hi Lee, > Subject: Re: [PATCH RFC 3/7] dt-bindings: mfd: rz-mtu3: Document > RZ/G2L MTU3 PWM > > On Sat, 01 Oct 2022, Biju Das wrote: > > > Hi Lee Jones, > > > > > Subject: Re: [PATCH RFC 3/7] dt-bindings: mfd: rz-mtu3: Document > > > RZ/G2L MTU3 PWM > > > > > > On Thu, 29 Sep 2022, Biju Das wrote: > > > > > > > Hi Lee Jones, > > > > > > > > Thanks for the feedback. > > > > > > > > > Subject: Re: [PATCH RFC 3/7] dt-bindings: mfd: rz-mtu3: > Document > > > > > RZ/G2L MTU3 PWM > > > > > > > > > > On Thu, 29 Sep 2022, Biju Das wrote: > > > > > > > > > > > Document RZ/G2L MTU3 PWM support. It supports following pwm > > > modes. > > > > > > 1) PWM mode 1 > > > > > > 2) PWM mode 2 > > > > > > 3) Reset-synchronized PWM mode > > > > > > 4) Complementary PWM mode 1 (transfer at crest) > > > > > > 5) Complementary PWM mode 2 (transfer at trough) > > > > > > 6) Complementary PWM mode 3 (transfer at crest and trough) > > > > > > > > > > Shouldn't all this go in the PWM driver binding? > > > > > > > > Looks like at top level MTU3 IP provides similar HW > functionality > > > like > > > > below binding [1], where there is a core MFD driver and pwm, > > > > counter and timer as child devices. > > > > > > Previous mistakes are not good references for what should happen > in > > > the present and the future. =;) > > > > Why do you think that reference is not a good one? I believe there > > should be some reason for it. > > I didn't even look at it. > > What I "believe" is that documentation for each functionality > belonging to a particular subsystem should live in subsystem's > associated documentation directory and be reviewed/maintained by that > subsystem's associated maintainer. If I am correct, MFD is subsystem for calling shared resources across subsystems. Here shared resources are channels which is shared by timer, counter and pwm They are child objects of MFD subsystems. That is the reason it is in MFDndings. Cheers, Biju
