On Tue, 09 Jun 2020, Michael Walle wrote:

Am 2020-06-09 17:19, schrieb Lee Jones:

quoted

On Tue, 09 Jun 2020, Michael Walle wrote:

quoted

Am 2020-06-09 08:47, schrieb Lee Jones:

quoted

On Mon, 08 Jun 2020, Michael Walle wrote:

quoted

Am 2020-06-08 20:56, schrieb Lee Jones:

quoted

On Mon, 08 Jun 2020, Michael Walle wrote:

quoted

Am 2020-06-08 12:02, schrieb Andy Shevchenko:

quoted

+Cc: some Intel people WRT our internal discussion about similar
problem and solutions.

On Mon, Jun 8, 2020 at 11:30 AM Lee Jones [off-list ref] wrote:

quoted

On Sat, 06 Jun 2020, Michael Walle wrote:

quoted

Am 2020-06-06 13:46, schrieb Mark Brown:

quoted

On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:

quoted

Am 2020-06-05 12:50, schrieb Mark Brown:

...

quoted

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.

quoted

 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.

Here (see below)

Yes, it should still be an I2C device.

quoted

quoted

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 = <&regmap>;
  };
};

Similar to the current syscon (which is MMIO only..).

We do not need a 'simple-regmap' solution for your use-case.

Since your device's registers are segregated, just split up the
register map and allocate each sub-device with it's own slice.

I don't get it, could you make a device tree example for my
use-case? (see also above)

    &i2cbus {
        mfd-device@10 {
            compatible = "simple-mfd";
            reg = <10>;

            sub-device@10 {
                compatible = "vendor,sub-device";
                reg = <10>;
            };
   };

The Regmap config would be present in each of the child devices.

Each child device would call devm_regmap_init_i2c() in .probe().

quoted

quoted

quoted

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.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel