On Tue, 2 Nov 2021 at 22:17, Emil Renner Berthing [off-list ref] wrote:

On Tue, 2 Nov 2021 at 21:14, Andy Shevchenko [off-list ref] wrote:

quoted

On Tue, Nov 2, 2021 at 9:59 PM Emil Renner Berthing [off-list ref] wrote:

quoted

On Tue, 2 Nov 2021 at 20:43, Andy Shevchenko [off-list ref] wrote:

quoted

On Tue, Nov 2, 2021 at 6:50 PM Emil Renner Berthing [off-list ref] wrote:

...

quoted

quoted

quoted

+/*
+ * the registers work like a 32bit bitmap, so writing a 1 to the m'th bit of
+ * the n'th ASSERT register asserts line 32n + m, and writing a 0 deasserts the
+ * same line.
+ * most reset lines have their status inverted so a 0 in the STATUS register
+ * means the line is asserted and a 1 means it's deasserted. a few lines don't
+ * though, so store the expected value of the status registers when all lines
+ * are asserted.
+ */

Besides missing capitalization,

I'm confused. it was you who wanted all comments to capitalized the same..

Yes and there are two types of the comments, one-liners and
multi-line. In multi-line you usually use proper English grammar,
where capitalization means what it means. For the one-liners just
choose either small letters or capital letters to start them with.

That sounds reasonable, it was just that you complained about
inconsistent comments in the pinctrl driver that follows the above.

quoted

quoted

if it sounds like bitmap, use bitmap.

quoted

I have checked DT definitions and it seems you don't even need the
BIT_MASK() macro,

quoted

+static const u32 jh7100_reset_asserted[4] = {
+       /* STATUS0 register */
+       BIT_MASK32(JH7100_RST_U74) |
+       BIT_MASK32(JH7100_RST_VP6_DRESET) |
+       BIT_MASK32(JH7100_RST_VP6_BRESET),
+       /* STATUS1 register */
+       BIT_MASK32(JH7100_RST_HIFI4_DRESET) |
+       BIT_MASK32(JH7100_RST_HIFI4_BRESET),
+       /* STATUS2 register */
+       BIT_MASK32(JH7100_RST_E24),
+       /* STATUS3 register */
+       0,
+};

Yury, do we have any clever (clean) way to initialize a bitmap with
particular bits so that it will be a constant from the beginning? If
no, any suggestion what we can provide to such users?

The problem is, that even if we could initialize this without the
monstrosity in our last conversation a 64bit bitmap would still
produce worse code. As it is now it's simply a 32bit load and mask
with index and mask already calculated for the registers. In the
status callback the mask can even be folded into the register read
mask. With a 64bit bitmap you'd need to calculate new 64bit index and
masks, and then conditionally shift the bits into position.

Why? You may use 8 byte IO (writeq() / readq() or their relaxed versions), no?

quoted

If this reflection of the 32bit registers bothers you that much

What bothers me is hidden endianess issues (yeah, here it might be
theoretical, but consider that somebody will look at your code and use
it as the best example ever).

Wouldn't endian issues be a reason to make sure we read 32bit
registers with 32bit reads? Or do you expect a hypothetical big-endian
StarFive SoC to also change the order of the registers?

Hi Andy.

I'd really like to understand your reasoning here. As far as I can
tell reading 2 adjacent 32bit registers with a 64bit read as you're
proposing is exactly what would cause endian issues. Eg. on little
endian you'd get reg0 | reg1 << 32 whereas on big-endian you'd get
reg0 << 32 | reg1.

/Emil