Am 2020-06-09 16:42, schrieb Mark Brown:
On Tue, Jun 09, 2020 at 04:38:31PM +0200, Michael Walle wrote:mfd-device@10 { compatible = "simple-regmap", "simple-mfd"; reg = <10>; regmap,reg-bits = <8>; regmap,val-bits = <8>; sub-device@0 { compatible = "vendor,sub-device0"; reg = <0>; };A DT binding like this is not a good idea, encoding the details of the register map into the DT binding makes it an ABI which is begging for trouble. I'd also suggest that any device using a generic driver like this should have a specific compatible string for the device so we can go back and add quirks later if we need them.
Like in the spidev case, yes. But OTOH if I _just_ encode the parameters for the regmap a MFD, Lee don't agree because its just a shim. So either way I seem to be stuck here. Where should I put the code to create an i2c driver, init a regmap and populate its childen? -michael
... }; Or if you just want the regmap: &soc { regmap: regmap@fff0000 { compatible = "simple-regmap"; reg = <0xfff0000>; regmap,reg-bits = <16>; regmap,val-bits = <32>; }; enet-which-needs-syscon-too@1000000 { vendor,ctrl-regmap = <®map>; }; }; Similar to the current syscon (which is MMIO only..). -michael > > I can't think of any reasons why not, off the top of my head. > > Does Regmap only deal with shared accesses from multiple devices > accessing a single register map, or can it also handle multiple > devices communicating over a single I2C channel? > > One for Mark perhaps. > > > > The issues I wish to resolve using 'simple-mfd' are when sub-devices > > > register maps overlap and intertwine. > > [...] > > > > > > > What do these bits configure? > > > > > > > > - hardware strappings which have to be there before the board powers > > > > up, > > > > like clocking mode for different SerDes settings > > > > - "keep-in-reset" bits for onboard peripherals if you want to save > > > > power > > > > - disable watchdog bits (there is a watchdog which is active right > > > > from > > > > the start and supervises the bootloader start and switches to > > > > failsafe > > > > mode if it wasn't successfully started) > > > > - special boot modes, like eMMC, etc. > > > > > > > > Think of it as a 16bit configuration word. > > > > > > And you wish for users to be able to view these at run-time? > > > > And esp. change them. > > > > > Can they adapt any of them on-the-fly or will the be RO? > > > > They are R/W but only will only affect the board behavior after a > > reset. > > I see. Makes sense. This is board controller territory. Perhaps > suitable for inclusion into drivers/soc or drivers/platform.
-- -michael
