The Ocelot chips (specifically the VSC7512 I'm using) have a method of
accessing their registers internally via MMIO, or externally via SPI.
When accessing these registers externally, a 24-bit address is used and
downshifted by two. The manual references it as:

SI_ADDR = (REG_ADDR & 0x00FFFFFF) >> 2;

By adding this configurable downshift, and a configurable register base
address, the regmap definitions can be shared between MMIO and SPI
configurations.

This also allows regmap to be used in a bus configuration. My initial
testing shows that even at a much slower bus speed of 500KHz, I'm seeing
an improvement of 10ms (was 14... now 4) to perform bulk read operations.

The relevant MMIO code can be found in drivers/net/mscc/ocelot_io.c:

static struct regmap_config ocelot_regmap_config = {
        .reg_bits       = 32,
        .val_bits       = 32,
        .reg_stride     = 4,
};

struct regmap *ocelot_regmap_init(struct ocelot *ocelot, struct resource *res)
{
        void __iomem *regs;

        regs = devm_ioremap_resource(ocelot->dev, res);
        if (IS_ERR(regs))
                return ERR_CAST(regs);

        ocelot_regmap_config.name = res->name;

        return devm_regmap_init_mmio(ocelot->dev, regs, &ocelot_regmap_config);
}


And the SPI counterpart is slightly more complex:


static const struct regmap_config ocelot_spi_regmap_config = {
        .reg_bits = 24,
        .reg_stride = 4,
        .reg_downshift = 2,
        .val_bits = 32,

        .write_flag_mask = 0x80,

        .max_register = 0xffffffff,
        .use_single_write = true,
        .can_multi_write = false,

        .reg_format_endian = REGMAP_ENDIAN_BIG,
        .val_format_endian = REGMAP_ENDIAN_NATIVE,
};

static const struct regmap_bus ocelot_spi_regmap_bus = {
       .write = ocelot_spi_regmap_bus_write,
       .read = ocelot_spi_regmap_bus_read,
};

struct regmap *
ocelot_spi_devm_get_regmap(struct ocelot_core *core, struct device *child,
                           const struct resource *res)
{
        struct regmap_config regmap_config;

        memcpy(&regmap_config, &ocelot_spi_regmap_config,
               sizeof(ocelot_spi_regmap_config));

        regmap_config.name = res->name;
        regmap_config.max_register = res->end - res->start;
        regmap_config.reg_base = res->start;

        return devm_regmap_init(child, &ocelot_spi_regmap_bus, core,
                                &regmap_config);
}


If there's anything I missed, or if there's a different way to go about
this, please let me know. I can also drag this along with my VSC7512
development or I can send this patch (or whatever it might become) after
the merge window.


Colin Foster (2):
  regmap: add configurable downshift for addresses
  regmap: allow a defined reg_base to be added to every address

 drivers/base/regmap/internal.h |  2 ++
 drivers/base/regmap/regmap.c   | 11 +++++++++++
 include/linux/regmap.h         |  6 ++++++
 3 files changed, 19 insertions(+)

-- 
2.25.1

On Sun, 13 Mar 2022 15:45:22 -0700, Colin Foster wrote:
> The Ocelot chips (specifically the VSC7512 I'm using) have a method of
> accessing their registers internally via MMIO, or externally via SPI.
> When accessing these registers externally, a 24-bit address is used and
> downshifted by two. The manual references it as:
> 
> SI_ADDR = (REG_ADDR & 0x00FFFFFF) >> 2;
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next

Thanks!

[1/2] regmap: add configurable downshift for addresses
      commit: 86fc59ef818beb0e1945d17f8e734898baba7e4e
[2/2] regmap: allow a defined reg_base to be added to every address
      commit: 0074f3f2b1e43d3cedd97e47fb6980db6d2ba79e

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

On Fri, Mar 18, 2022 at 08:57:54PM +0000, Mark Brown wrote:
> On Sun, 13 Mar 2022 15:45:22 -0700, Colin Foster wrote:
> > The Ocelot chips (specifically the VSC7512 I'm using) have a method of
> > accessing their registers internally via MMIO, or externally via SPI.
> > When accessing these registers externally, a 24-bit address is used and
> > downshifted by two. The manual references it as:
> > 
> > SI_ADDR = (REG_ADDR & 0x00FFFFFF) >> 2;
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
> 
> Thanks!
> 
> [1/2] regmap: add configurable downshift for addresses
>       commit: 86fc59ef818beb0e1945d17f8e734898baba7e4e
> [2/2] regmap: allow a defined reg_base to be added to every address
>       commit: 0074f3f2b1e43d3cedd97e47fb6980db6d2ba79e
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.

Thanks Mark! Based on your initial feedback I wasn't expecting patch 1
to be applied and was expecting to have to work around it (which could
be done) but I don't think patch 2 could have been reasonably worked
around. Hopefully these are patches that nobody notices... unless they
need them too :-D

> 
> Thanks,
> Mark