[PATCH] riscv: support CPUs having only "zalrsc" but no "zaamo"

[Vladimir Kondratiev]

> > Historically, "a" was first, and Linux was relying on "a";
> > then "zaamo"/"zalrsc" was introduced. It is possible to implement
> > most atomic operations with either AMO or LR/SC. AMO if more efficient
> > however more complex flows are possible with LR/SC only.
> >
> > Platforms supporting only part of atomics starting to appear.
> > Notable is MIPS P8700 CPU [1] having only "zalrsc".
> 
> Are there any others?

I don't know, I am working with the Mobileye platform only

> Are development boards available yet for these kinds of designs?

Sorry, no. Mobileye does not release (as of now) boards to the public, it
works only with automotive companies

<skip> 
> > Implementation is generic, inspired by the patch [2]
> > by developers listed below, implementing similar patch as errata
> > for the MIPS P8700 CPU
> 
> This doesn't look like an erratum.  The designers of this core just chose
> not to implement A support in this CPU, and that's why that AMO_II bit
> exists in the mipsconfig6 register, correct?

Absolutely agree; this is why I re-factored this as a generic feature
rather than errata.

<skip>
> I guess the proposal here is for the upstream kernel community to weaken
> our A support requirement to support these special cores that only support
> LR/SC? 

Yes indeed. In fact, any AMO instruction may be re-implemented as an LR/SC
sequence provided memory area is LR/SC capable; opposite is not true.
Actually "a" is not a real requirement to implement atomics, we just need
some way to do so, and "LR/SC only" is sufficient.

> If so, I suppose the question is, should anyone in the upstream kernel
> community care about this case?  It wouldn't be enough for the kernel
> alone to support this.  A special userspace would also be needed.

Userspace should provide "-march=rv64imc_zalrsc" instead of "-march=rv64imac"
for all compilation; this will instruct compiler to use LR/SC for atomic_t and alike

<skip>
> If we take these changes, it increases the complexity of the upstream
> kernel, and increases our testing matrix as maintainers (and, in theory,
> for any patch submitters, who should theoretically be testing their work
> on the configurations that we support).  It's not clear what the gain
> would be for the broader community.  As maintainers, we're already
> considering stripping out other code that doesn't seem to have significant
> community support, like no-MMU, for similar reasons.
> 
> On the other hand, if boards with Zalrsc-only cores seemed popular in the
> marketplace, and some sort of support existed in common userspaces, such
> that we could be sure that there was some sort of commitment to maintain
> this across the entire ecosystem, the discussion could be more favorable,
> I guess?

I understand the argument, but I can't say for all risc-v community or how
important is Mobileye chip to justify special support.
CPU vendor is MIPS, perhaps they can share arguments about decision to
implement only LR/SC but not AMO.
Good if people crafting LR/SC only platforms will comment here. 

> 
> Palmer might have some other thoughts here.

Thanks, Vladimir