00:37 <broonie> CounterPillow: There's some media drivers IIRC, and they were originally added for the R-Car audio drivers.

00:40 <CounterPillow> I'll look into the R-Car audio drivers and check if I like what I see, for now I've gone with the usual macro approach.

00:40 <broonie> They were added to cope with some IPs which are software compatible between versions but randomly rearranged the field layout between revisions, if you don't have that specific problem then you're probably better off with just using update_bits() directly.

00:41 <CounterPillow> Ah, that explains it

00:41 <broonie> One issue with fields is that they make it much harder to update multiple fields in a single write, if you're on a slow bus like I2C or performance critical that'll hurt.

00:42 <CounterPillow> Yeah I did notice that similar registers but with some permutations between variants is the only real usecase I could think of where they'd make sense

00:43 <CounterPillow> I was hoping there was some abstraction in the kernel that'd let me describe bitfield register accesses in a more declarative way so I can have things like "this value is too large" or "this value is not in this set of values" checked statically, but I assume the limitation here is C

00:45 <broonie> Hrm, we could probably make update_bits() detect if you overflow the mask and warn on it (or have a mode for that anyway).

00:46 <broonie> regmap doesn't have a concept of enums so that'd need an API extension.

00:46 <CounterPillow> Another thing I was hoping to look into is some way we can generalise the "this register has a write-enable mask in the upper 16 bits" thing Rockchip likes to do, see `rg -A1 '#define\s+HIWORD_UPDATE\('` for all the duplicated macros to deal with that

00:48 <CounterPillow> that they all have slightly different semantics doesn't help either :V

00:48 <broonie> That sounds like a sensible thing to add an API for. There are a bunch of drivers that just set a "do the write" bit in their caches.

00:51 <broonie> But that only works where it's just a simple thing you can cache in the same register.

00:54 <CounterPillow> I'm also not entirely sure whether I should even use a regmap for the PWM driver I'm writing. As I understand it, the big benefit of regmap is the caching so that accesses don't just wait for the bus. But with PWM, when writes take effect is critical enough that this hardware actually has values you write to certain registers only take effect after you toggle a bit in a control register, so I'm not sure if another layer inbetween is a

00:54 <CounterPillow> good idea.

03:17 <u0_a567> Ay i arrived at armlinux

08:57 <LCWchat> Hello