04:25 <Forty-Bot> are "autoplaced" bytes in the nand oob area covered by ecc?

04:25 <Forty-Bot> from what I can tell they aren't

04:30 <Forty-Bot> this seems rather odd, since errors can occur anywhere

06:44 <Kwiboo> alpernebbi: sjg1: your issue with video and regulator may be because of d99fb64a98af "power: regulator: Only run autoset once for each regulator", autoset now return -EALREADY on second autoset call

06:46 <Kwiboo> thought I checked all autoset calls and most just ignored return value, may have missed some call to regulator_autoset_by_name(), will take a closer look

06:47 <Kwiboo> on rockchip the use of regulator_autoset_by_name() should also be unnecessary because of earlier call to regulators_enable_boot_on()

06:51 <Kwiboo> yep, rk_vop_probe_regulators() could possible be removed or should be reworked to fix regulator enable count related issues

06:55 <Kwiboo> on second look, same is true for rk_hdmi_probe_regulators() any possible return code by regulator autoset/enable is just ignored

13:47 <Tartarus> Forty-Bot: It's been a while since I had to think about NAND stuff. Are you sure it's not part of the ECC? I know having the right OOB definition is required to get the ecc to then be correct. Maybe it depends on the controller (and sw vs hw BCH or whatever algo is used) ?

13:47 <Forty-Bot> at least for swecc it's just the data and the ecc bytes

13:47 <Forty-Bot> see e.g. nand_read_page_swecc

13:48 <Forty-Bot> the ecc is calculated in eccsteps of eccsize on the data area, and those are based on the writesize

13:49 <Forty-Bot> there's also nand_check_erased_ecc_chunk which could kinda work (at least for detecting erased pages) but nothing calls it with extraoob set

13:53 <Forty-Bot> definitely possible to write a controller which covers the rest of the oob

13:56 <Forty-Bot> e.g. https://www.micron.com/-/media/client/global/documents/products/technical-note/nand-flash/tn2975_enable_on-die-ecc_nand_jffs2.pdf talks about how it has some protected metadata bytes in the oob

13:57 <Sout_> wow an actual decent appnote

13:57 <Tartarus> Ah, swecc

13:58 <Tartarus> It's been since the am335x nand driver was new that I had to poke the details here

14:33 <Tartarus> Clamor: I'm going to look at those as soon as I can just in general

14:39 <Clamor> Tartarus: sure, np. I waited 3 months, a week or 2 will not be an issue

14:40 <Tartarus> Clamor: Yeah, thanks and sorry

14:40 <Tartarus> I'd like to see that stuff get in for v2024.01, so I'll email tagr too later, I just poked him on irc now (but I don't know how active he is)

14:47 <Clamor> Tartarus: tagr picked all my follow up patches into tegra custodian tree, just did not initiate merge. Though defconfig resync from that patchset may conflict on merge.

14:48 <Clamor> I am more concerned about Jaehoon then tagr though.

17:24 <alpernebbi> Kwiboo: thanks for the hints, luckily my case is solved by 251ff3493233 "video: pwm_backlight: use regulator_set_enable_if_allowed"

17:34 <alpernebbi> and it indeed keeps working if I remove rk_vop_probe_regulators(). the one it tries to enable isn't on any rk3399 device-trees, but on some rk3288-veyron and rk3368 ones

18:20 <sjg1> Kwiboo: Thanks for the info. It turns out that my monitor (which works OK on rpi4) does not work on rockpro64. When I changed to a different monitor, HDMI came up in U-Boot (and Linux)

18:34 <Clamor> marex: those video patches were handy not only for me ;)

18:37 <alpernebbi> Clamor: thank you :D

18:38 <Clamor> I am glad that they made it in time