Messages in this thread | | | Date | Tue, 09 Jun 2020 17:01:17 +0200 | From | Michael Walle <> | Subject | Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller |
| |
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
| |