On Mon, Feb 01, 2016 at 10:59:52AM -0800, Tony Lindgren wrote: > Hi, > > * David Rivshin (Allworx) <drivshin.allworx@xxxxxxxxx> [160201 10:23]: > > On Sat, 30 Jan 2016 15:51:06 +0100 > > Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote: > > > > > 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx) > > > <drivshin.allworx@xxxxxxxxx>: > > > > From: David Rivshin <drivshin@xxxxxxxxxxx> > > > > > > > > After going through the math and constraints checking to compute > > > > load and match values, it is helpful to know what the resultant > > > > period and duty cycle are. > > > > > > > > Signed-off-by: David Rivshin <drivshin@xxxxxxxxxxx> > > > > --- > > > > > > > > I found this helpful while testing the other changes, so I included > > > > it in case it may be of use to someone in the future. I would have > > > > no issues with dropping this if it's not considered worthwhile. > > > > > > It's useful, but converting it as a sysfs attribute would be great ! > > > > Hrm, yes that is an interesting thought. I imagine that many PWM > > devices have similar constraints, so perhaps that would be best > > handled generically in the pwm core? Maybe as new optional get_*() > > ops, a modification to the config() op to add output params, or just > > updating new fields in the struct pwm directly? > > Yeah for /sys entry it should be Linux generic. The other option > is to use debugfs for driver specific things. Let's go with debugfs for this one. This is used for diagnostic purposes and not typically needed when configuring a PWM. While other drivers may compute similar hardware-specific values, there's nothing generic to them. The period and duty cycle are the generic input values and those are already exposed via sysfs. Thierry
Attachment:
signature.asc
Description: PGP signature
