Am 2020-06-09 08:47, schrieb Lee Jones:
On Mon, 08 Jun 2020, Michael Walle wrote:
Am 2020-06-08 20:56, schrieb Lee Jones:
> On Mon, 08 Jun 2020, Michael Walle wrote:
>
> > Am 2020-06-08 12:02, schrieb Andy Shevchenko:
> > > +Cc: some Intel people WRT our internal discussion about similar
> > > problem and solutions.
> > >
> > > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote:
> > > > On Sat, 06 Jun 2020, Michael Walle wrote:
> > > > > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > >
> > > ...
> > >
> > > > Right. I'm suggesting a means to extrapolate complex shared and
> > > > sometimes intertwined batches of register sets to be consumed by
> > > > multiple (sub-)devices spanning different subsystems.
> > > >
> > > > Actually scrap that. The most common case I see is a single Regmap
> > > > covering all child-devices.
> > >
> > > Yes, because often we need a synchronization across the entire address
> > > space of the (parent) device in question.
> > >
> > > > It would be great if there was a way in
> > > > which we could make an assumption that the entire register address
> > > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> > > > each of the devices described by its child-nodes. Probably by picking
> > > > up on the 'simple-mfd' compatible string in the first instance.
> > > >
> > > > Rob, is the above something you would contemplate?
> > > >
> > > > Michael, do your register addresses overlap i.e. are they intermingled
> > > > with one another? Do multiple child devices need access to the same
> > > > registers i.e. are they shared?
> >
> > No they don't overlap, expect for maybe the version register, which is
> > just there once and not per function block.
>
> Then what's stopping you having each device Regmap their own space?
Because its just one I2C device, AFAIK thats not possible, right?
Not sure what (if any) the restrictions are.
You can only have one device per I2C address. Therefore, I need one
device
which is enumerated by the I2C bus, which then enumerates its
sub-devices.
I thought this was one of the use cases for MFD. (Regardless of how a
sub-device access its registers). So even in the "simple-regmap" case
this
would need to be an i2c device.
E.g.
&i2cbus {
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>;
};
...
};
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.
