00:36 <TomTheDragon> I'm stuck using the armsoc xorg driver because I can't run the latest mainline on my system... trying to figure out the best way to obtain multiseat capability. armsoc doesn't have zaphodheads support.

00:37 <TomTheDragon> i really don't want the extra power consumption of an addon GPU, just for another display. another board would be simpler, cheaper, and probably use less power. but I really want to get the most out of my rockpro64, which has 2 video outputs

02:28 <wens> AFAIK armsoc is pretty much dead

02:29 <TomTheDragon> wens: is... there an alternative if I'm stuck on a manufacturer kernel?

02:30 <TomTheDragon> last i checked, had no sound or pcie and video was... terribly hard to initialize

02:31 <TomTheDragon> like, video as in actually being able to see anything, not even accelerated.

02:33 <TomTheDragon> wens: if there's another way to get accelerated video, i'm very curious. even if it's kinda hackish.

02:37 <wens> probably not ...

02:38 <TomTheDragon> armsoc has little attention, then, but it is hardly dead in terms of userbase

02:43 <TomTheDragon> It doesn't look too hard to actually create the split display support... still don't see why x developers made it a part of the DDX

02:49 <TomTheDragon> wens: what system are you using?

02:54 <wens> TomTheDragon: my boards are headless

02:55 <TomTheDragon> ah, that would make things easy

02:55 <TomTheDragon> gpu support on these boards are kinda iffy. well, so is the videocodec.

03:28 <wens> complex proprietary hardware blocks with no public documentation :)

16:13 <nomis> robmur01: I just found a smoking gun and fixed it - but it didn't help.

16:13 <nomis> apparently "ciu-drv" has been renamed to "ciu-drive".

16:14 <nomis> But nevertheless, speeding up the communication to the wireless module does not work. I get EILSEQ and ETIMEDOUT errors

16:16 <robmur01> Ah, I was thinking "I know I fixed that years ago", but of course that was in the upstream DTSI where sdmmc_ext isn't :)

16:17 <robmur01> have you tried cranking up the drive strength on the data and clock lines in pinctrl?

16:18 <nomis> not yet. My thinking was that it seems to work in the rockchip-image and the values in the devicetree there are the same as in mine.

16:19 <robmur01> I have a nagging feeling that that's one of those places where there might be a subtle difference in how the upstream and downstream drivers interpret the raw values

16:19 <nomis> robmur01: what raw values?

16:21 <nomis> Hm. I actually fail to understand the register descriptions for CRU_CRU_SDMMC_EXT_CON0 and CRU_CRU_SDMMC_EXT_CON1.

16:26 <robmur01> I mean for "drive-strength = <x>", whether is x the raw GRF value, or a milliAmp value that the driver converts internally

16:26 <robmur01> looks like RK3328 is probably OK in that regard, so I must be thinking of something older

16:26 <nomis> ah, ok.

16:27 <robmur01> and it might have actually been the pull-up config or something else ;)

16:28 <nomis> I guess I'll have a stare at the waveform shapes on the oscilloscope tomorrow. I'll then also compare the actual values of the registers for pullup/drivestrength.

16:28 <robmur01> but I definitely remember having to read a crusty out-of-tree pinctrl driver to decode a DTB for *some* reason...

16:33 <nomis> robmur01: do you know of any register description for the above mentioned clock-registers? I fail to understand how to interpret the values in them.

16:35 <nomis> It is kind of suspicous that the rockchip-kernel registers both of these clocks with shift 1.

16:40 <nomis> there is a weird series of commits on Oct 12 / Nov 29 2018: https://github.com/rockchip-linux/kernel/commits/develop-4.4/drivers/clk/rockchip/clk-rk3328.c

16:45 <robmur01> yup, there's every possibility that the upstream code is minimally-tested and wrong, and that the TRM is wrong, and that trusting whatever empirical result the BSP kernel relies on is the right thing to do

17:27 <robmur01> hmm, in fact it seems upstream got that "fix", but not the subsequent revert, so I'm now mostly wondering how my box has been managing to work as well as it does...

17:27 <robmur01> guess I should crack out the scope and verify my clocks too :D

17:52 <nomis> robmur01: I'd appreciate your input on that.

18:08 <robmur01> come to think of it, at one point I did notice that limiting the eMMC frequency to 150MHz made it crap out more often than not, whereas letting it stay at 200MHz is rock solid despite being nominally way out-of-spec for the I/O pins. That never did make sense... :/

23:39 <robmur01> nomis: bingo - the clock signals look fine and the SD card at 50MHz doesn't show any visible difference either way, but applying that revert makes my eMMC work perfectly at 150MHz rather than constantly throwing errors and retuning

23:40 <robmur01> I guess at 200MHz it just happens to use a phase where the shift error didn't matter

23:42 <robmur01> now I can go to bed with a sense of accomplishment :D