Mapping of CSRs in Linux

This will break compatibility (addressing for 8-bit CSR data width and maybe order of CSR simples) but it could make our life a lot easier in the future (and avoid such discussion :)), what do you think?

On Mon, 2020-06-15 at 01:26 -0700, Tim 'mithro' Ansell wrote:
> If you want to share gateware between the widest range of firmware,
> 8bit CSRs is the correct current option.

We are talking about Linux-supported setups where the CSRs are exposed
to the kernel. This is no reason we can think of (I think Florent and I
agree here) where 8-bit CSRs would have any value.

> Both emulation in QEMU (RISC-V, or1k and lm32) and Renode upstream
> only support 8-bit CSR widths at the moment.

That's easily fixed.

> This is also the mode that both Zephyr upstream and NuttX upstream
> use.

Is there a LiteX driver upstream already ? Can you point me to it ?

> Linux only supporting 32bit width CSRs will require all the above to
> be adapted too.
>
> Having a common peripheral bus shared between a core running Linux
> and a core running Zephyr (which is a known configuration we want to
> support) would also become impossible.

Allright, I have no idea what Zephyr is,

For 2) well... not supporting means the simple choice, direct MMIO from devices.

If we go the regmap route instead, which would support all sorts of crazy setups,
then we need to add plumbing to create the regmaps etc.. it complicates things and
it adds I think at least 2 indirect calls on the path to every IO.

We could try to add a "layer" than can do either inlined ... ie, create some kind
of (pseudo-code). [Note: I don't actually *like* this, but it's an option...]

  struct litex_csr_region {
          enum { LITEX_IO_DIRECT, LITEX_IO_REGMAP } model;
          union {
                  void __iomem  *direct_addr;
                  struct regmap *regmap;
          } arg;
  };

And have some helpers to set that up form the DT, which could initially be simple
and only support the direct model, and acessors do something like:

  static inline void litex_write_csr(u32 val, struct litex_csr_region *r,
                                     unsigned int offset)
  {
          if (r->model == LITEX_IO_DIRECT)
                  writel(val, r->arg.direct_addr + offset);
          else
                  regmap_stuff(.....);
  }

And a helper drivers can use to create such region objects from the DT.

But since this new CSR2 bus would be the one used by Linux and would not support 8-bit (since no longer recommended/useful), why not just keep the current CSR, keep 8-bit support for Baremetal/existing software, but just use the 32-bit data-width for Linux SoCs? This would meen Linux drivers could use full MMIO and we would just have to rework the existing Linux software support, which should be doable and less painful than having to use/support accessors.

> Could this be implemented as two "instances" of the same module
> (liteeth-mmio, liteeth-regmap) which use different sets of assessors
> so there isn't even a runtime cost here? There are multiple ways this
> could be implemented -- off the top of my head;

It's easier to do the accessor trick I mentioned earlier.

The main thing to figure out then is what does the DT representation of
a non-MMIO device look like. An MMIO one logically lives below the SoC
bus with the standard address ranges mapping for "reg" properties.

Now, if we create the concept of a "CSR bus", do we move LiteX below it
? That would cause weird representation issues for things like LiteEth
that have both CSRs and non-CSR memory ranges.

I'm a bit busy today but give me a few days to try to whip up something
that I think makes sense and we'll see where that goes.

--
You received this message because you are subscribed to the Google Groups "Linux for LiteX FPGA SoC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-litex...@googlegroups.com.

You received this message because you are subscribed to the Google Groups "Linux for LiteX FPGA SoC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-litex...@googlegroups.com.