Morning Mark, On Tue, 2020-02-11 at 19:06 +0000, Mark Brown wrote: > On Mon, Feb 10, 2020 at 02:13:13PM +0200, Matti Vaittinen wrote: > > > Provide a linear_range helper which can do conversion from user > > value > > to register value 'selector'. > > Mark, this is loosely bound to register handling... Do you think > > the regmap could host these helpers? > > There's no real tie to regmap here, something like this could quite > happily be used by memory mapped devices where regmap has limited > uses > and would be a lot to pull in. A separate library would probably > make > more sense. Ugh. I know you are right. I can admit that I just saw it easier to get this included in something that is already existing (besides, I have found co-operating with the regmap/regulator maintainer pretty straightforward - there has been no extra hassle required to get things done, just the necessary fixes). I'm a bit afraid that adding a new piece of library just for this might require a lot more social influencing ^_^; But you are correct. Devices with this kind of registers can easily be connected to memory mapped bus. > Not sure how many users there would be outside of power > related stuff, I don't recall seeing the pattern elsewhere. I think there must be other stuff too. Bunch of NCOs (numeric controller oscillators) from my clock/synchronization related career comes to mind first. AFAIR they had linear frequency response. In comparison tuning clock with DAC voltage was not linar - although voltage change was linear :) But I would expect that there is bunch of things (although I can not guarantee it). > Note also that we already have quite extensive helpers for this sort > of > stuff in the regulator API which I sense may have been involved in > this > implementation You sense well xD This has been inspired by REGULATOR_LINEAR_RANGES in regulator framework. I thought I did write that to somewhere so that the credits would go to regulator code :) But maybe I did only write that when I first introduced this code to BD70528 power-supply code. I thought that we should add generic helpers and that the regulator framework could switch to use them internally if it seemed like a good idea. But another option - which I thought only now - would be to see if current regulator implementation could be re-named to more generic and placed under some more generic component (I thought of regmap but as you pointed out this is equally usefull for devices connected to memory mapped buses - so maybe under lib - if static inline functions in a header are not a good option). I just have a feeling that the linear- ranges is currently kind of embedded in the code which is internal to regulator framework so it is probably not easily extracted from regulator code? > and to an extent in ALSA which takes a different approach > with TLVs since it baked selectors directly into the ABI. I've never played with any media subsystems. Sound, camera and video are completely unknown to me :/ So if we do not start pulling the range code out of regulator framework (for now at least) - and if we do not place this under regmap - then I can drop you out of the recipient list for this charger driver in order to not pollute your inbox ;) How do you feel Mark, do you want to be following this series? Best Regards, Matti Vaittinen
