11:12 <hanetzer> I don't suppose anyone knows what the hell 'BVT' means in the context of hisilicon?

11:22 <HdkR> Bandwidth Variable Transceiver maybe?

12:16 <hanetzer> tbh not sure. maybe I'll email them lmao

14:36 <CounterPumpkin> What's an Asynchronous SError interrupt and why is it haunting me

14:45 <Pali> In most cases it is data abort for some previous instruction which finished just recently.

14:45 <Pali> I'm seeing it with lot of broken PCIe HW controllers.

14:46 <Pali> CounterPumpkin: It depends on what you are doing.

14:46 <CounterPumpkin> writing to a regmap

14:47 <Pali> ESR syndrome number could say more what happened

14:47 <CounterPumpkin> I'm specifically getting this https://gist.github.com/CounterPillow/f469986ea84066667ec050be39c2abf3

14:48 <Pali> 0x00000000be000411 is Double-bit error detected on dirty line in L2 cache (if I decoded number correctly)

14:50 <CounterPumpkin> Hmmm, interesting. Not sure what could be causing that. I'm trying to get the upstream rockchip i2s-tdm driver working for rk3588, and am running into this as soon as anything writes the regmap. Compared with downstream driver, and they don't seem to be doing anything special for this chip

14:51 <CounterPumpkin> Perhaps it's caused by some other part of the SoC support still lacking? This is a few (many) in-review patches pulled in to boot this. More complex things like PCIe are working though, so I still have a feeling it's my fault

14:51 <Pali> Ah, what kind of core you have? This error message is core-specific per ARMv8 spec.

14:51 <Pali> I wrote my ESR decoder for A53 cores. So other cores could have different meaning.

14:51 <CounterPumpkin> 4x A-76 + 4x A-55

14:52 <Pali> Which CPU received that abort? A76 or A55?

14:53 <CounterPumpkin> CPU 6, let me check in the DT what that might be

14:54 <CounterPumpkin> okay that's not evident from the dt, argh

14:55 <CounterPumpkin> oh wait it is

14:55 <CounterPumpkin> A-76

14:57 <Pali> (I'm already trying to find some information about ISS Syndrome Information for both A55 and A76)

15:02 <Pali> Seems that for A76 this ISS (bits [24:0]; 0x000411 in your case) is not documented in public specs.

15:03 <CounterPumpkin> Oh dear.

15:03 <Pali> It should have been in section "ESR_EL1, Exception Syndrome Register, EL1" but there are just two word "Syndrome information."

15:05 <Pali> I'm unable to find something better.

15:05 <CounterPumpkin> Thanks for checking either way :)

15:06 <Pali> online link for A76 ESR_EL1: https://developer.arm.com/documentation/100798/0300/register-descriptions/aarch64-system-registers/esr-el1--exception-syndrome-register--el1

15:06 <CounterPumpkin> Maybe robmur01 or someone else at ARM knows more.

15:07 <Pali> For A53 it is documented: https://developer.arm.com/documentation/ddi0500/j/System-Control/AArch64-register-descriptions/Exception-Syndrome-Register--EL1

15:13 <hanetzer> anyone here familiar with goodix touchscreens? got one, mostly works, but I'm getting 'Invalid config (959, 478, 0), using defaults'. x y touch. I can set the first two in devicetree (I believe they are correct) but not sure about the last bit.

15:14 <hanetzer> based on stock firmware stuff 960/480/5 is what I need.

15:14 <hanetzer> *479 on the first bit

15:18 <broonie> CounterPumpkin: could be power management not set up correctly for the IP (eg, clocks or power domain), that can cause unpredictable behaviour when interacting with it. Just a guess though

15:19 <CounterPumpkin> Yeah, that was my guess before we got regulators and PDs working. I need to double-check they're actually in and working. Clocks is a good idea as well

15:20 <Pali> CounterPumpkin: Now I'm looking into ARMv8 https://developer.arm.com/documentation/ddi0487/latest doc and seems that on page 5695 is something.

15:24 <Pali> For your ISS=0x000411: AET=0b001 (Unrecoverable state (UEU)), DFSC=0b010001 (Asynchronous SError interrupt)

15:26 <Pali> So it just a generic error code

15:26 <CounterPumpkin> Hm, yeah. Thanks

15:26 <CounterPumpkin> Still useful to know it's not something specific

15:26 <Pali> You wrote that it occurs when you try to write to regmap. Could you try to read from regmap?

15:27 <CounterPumpkin> it's a regmap_update_bits so a read followed by a write

15:28 <Pali> Just try to read without writing.

15:29 <Pali> Due to pipelining and early acknowledge of write transactions, most write errors occurs asynchronly after store instruction. And hence there is just imprecise async serror with generic info.

15:30 <Pali> On the other hand this cannot happen for most read operations as load instruction needs to finish and erros can be reported synchronly, with more information.

15:32 <Pali> For debugging purposes it could help to map _problematic_ memory in strong ordered model, to receive most errors synchronly.

15:32 <Pali> But strong ordered model was last time in ARMv7 and was removed from ARMv8. So this kind of debugging is not possible on A76 anymore.

15:34 <CounterPumpkin> Okay, looks like the read succeeds

15:35 <CounterPumpkin> yep, reads the correct reset value

15:35 <CounterPumpkin> so the writes are the problem

15:37 <Pali> Ok, so seems that IP block is alive and react.

15:38 <Pali> Maybe you are trying to write into read-only registers?

15:38 <Pali> Or IP block "crashes" (send some Slave Error to CPU) after you write something into it?

15:39 <CounterPumpkin> bit 24 of that reg is RW, the rest are RO in the TRM, but this code works fine on the implementation found in a very recent lower-tier chip (RK356x)

15:40 <CounterPumpkin> one moment, that register is different... hmmm

15:40 <CounterPumpkin> no wait it's not

15:41 <CounterPumpkin> I just hit a page break in the reg overview

15:41 <Pali> Something which seems to need platform debugger...

15:42 <ardb> Pali: arm64 has ioremap_np() now, which is Device-nGnRnE

15:42 <ardb> this is essentially the same as strongly ordered

15:45 <Pali> I played mostly with A53 and here is IIRC nGnRnE same as nGnRE

15:45 <Pali> Whatever I did I was not able to turn off early ack for write operations.

15:47 <Pali> https://developer.arm.com/documentation/ddi0500/e/level-1-memory-system/support-for-v8-memory-types --> nGnRnE - Treated the same as nGnRE inside a Cortex-A53 processor

15:47 <Pali> So I remember it correctly for A53.

15:49 <CounterPumpkin> oh, duh. I forgot the power-domains property on the i2s node, maybe that plays a role

15:49 <CounterPumpkin> tee-hee

15:49 <CounterPumpkin> wait nevermind, that's not a thing

15:55 <CounterPumpkin> wait nevermind, it is

15:57 <CounterPumpkin> why would you look at that, that was the problem

16:42 <hanetzer> On the subject of modular hardware. There's a devkit which is sold in the form of the main device, which consists of four pcbs joined together with some kind of connector, and a touchscreen with ribbons for the main mipi signals and i2c for the goodix touchscreen. should the 'extra' parts, which don't contain the soc itselff, be part of the final dts/dtb or should one use devicetree overlays for

16:42 <hanetzer> this sort of thing?

18:17 <geertu> hanetzer: Up to you

18:17 <geertu> See e.g. arch/arm64/boot/dts/renesas/Makefile

18:17 <geertu> dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2.dtb

18:17 <geertu> dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2-ex.dtb

18:17 <geertu> dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2-ex-idk-1110wr.dtb

18:35 <hanetzer> geertu: heh. its funny that you should bring up 'hihope'. the device I'm working on is from them :P