JohnnyonFlame has quit [Ping timeout: 245 seconds]
montjoie has quit [Ping timeout: 246 seconds]
montjoie has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
JohnnyonFlame has joined #linux-amlogic
JohnnyonFlame has quit [Ping timeout: 245 seconds]
JohnnyonFlame has joined #linux-amlogic
JohnnyonFlame has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 245 seconds]
hexdump0815 has joined #linux-amlogic
Daanct12 has quit [Quit: WeeChat 4.0.2]
Daanct12 has joined #linux-amlogic
JohnnyonFlame has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
JohnnyonFlame has quit [Read error: Connection reset by peer]
mturquette has quit [Ping timeout: 260 seconds]
mturquette has joined #linux-amlogic
shoragan_ has joined #linux-amlogic
gis has quit [Ping timeout: 260 seconds]
hays has quit [Ping timeout: 260 seconds]
gis has joined #linux-amlogic
shoragan has quit [Ping timeout: 260 seconds]
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
rockosov has quit [Ping timeout: 245 seconds]
rockosov has joined #linux-amlogic
luka177 has quit [Ping timeout: 240 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Read error: Connection reset by peer]
luka177 has joined #linux-amlogic
luka177 has quit [Read error: Connection reset by peer]
luka177 has joined #linux-amlogic
tomeu has quit [Remote host closed the connection]
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
<narmstrong>
minute: nice video :-)
<minute>
narmstrong: glad you like it! btw i don't know if interesting for you, but i had some issues with mipi-dsi, in that after re-initializing the display kills the output. so the display only ever worked _once_ and one could not for example exit "sway"
<minute>
narmstrong: i figured out a workaround which is removing all "disable" code in ti sn65dsi86 driver. so there is an issue of sn65dsi86 not being able to lock to the stream a _second_ time
<minute>
now it is reliable, i can switch back and forth between hdmi and dsi without problems
hexdump0815 has quit [Ping timeout: 245 seconds]
hexdump0815 has joined #linux-amlogic
<c0rnelius>
minute: I see you have made changes to the `&sd_emmc_a` and added a cap among other things. In my testing on the bpi-cm4 adding a cap opens a door for instabilities there. Have you tried reverting ur changes and using the `rtw88: sdio: Honor the host max_req_size in the RX path` patch?
f11f12 has joined #linux-amlogic
ck_98 has joined #linux-amlogic
<f11f12>
hi ck_98
<c0rnelius>
also the bluetooth bit is wrong. should be `enable-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;` and `host-wake-gpios` can just be removed.
<minute>
c0rnelius: oh, thanks for checking
<minute>
c0rnelius: i'll double check all of these today
<minute>
c0rnelius: on your bpi cm4 you did not change _anything_ in &sd_emmc_a?
<c0rnelius>
no... because after trying it just seemed to make things worse.
<narmstrong>
minute: ack, thx for sharing the changes, it's hard for me bevause lack of hw :-p for burst mode yes we should handle the non-burst mode and enhance the bandwidth in !burst mode
<narmstrong>
for the disable, it's kind of fishy... perhaps a sequencing issue somehow
Daanct12 has quit [Quit: WeeChat 4.0.2]
<minute>
narmstrong: we decided to send you a laptop as soon as we have some more units with a311d here, if you like
<narmstrong>
minute: wow cool, I won't say no :-)
<minute>
narmstrong: awesome, please send me your address in an email then :)
<narmstrong>
minute: sure!
<minute>
thx!
<rockosov>
minute: It's really cool! I'm very suprised to see laptop with good gfx based on A311D! Wow!
<rockosov>
minute: Which opengl libraries do you use? As I know Amlogic doesn't open their gl versions
<narmstrong>
rockosov: mainline mesa :-)
<rockosov>
narmstrong: Not bad!!!
<narmstrong>
Alyssa & co did an awesome r-e work here
<narmstrong>
And ARM officially helps collabora, ARM recently announced Panfrost is now their official non-android driver for Linux
<narmstrong>
which is quite super awesome
<minute>
yes
<minute>
really happy about that
<rockosov>
narmstrong: minute I'm thrilled to hear this good news! I fully understand, how much hard work it's... My respect to the team! By the way, I'm curious about its compatibility with the Android gfx stack. Would it work seamlessly within that framework?
<minute>
rockosov: i have no idea about android, sorry! the only thing i'm interested in in this regard is waydroid
<minute>
we have a smaller pocket version of the laptop with cell modem and it could be cool to run some android apps on it
<rockosov>
minute: I see.. I think "some" is main keyword here :-) I'm not sure that waydroid will support all things. BTW, where can I buy your laptops to play with it?
<narmstrong>
rockosov: android works fine with that, it's only tricky to integrate, but there's an AOSP fork that does that https://glodroid.github.io/
<narmstrong>
mesa requires some special steps for building, that doesn't work well with aosp build system
<rockosov>
Okay, I will try to go deeper to glodroid. Thank you for point me out! We want to try mesa in the our internal projects.
<rockosov>
minute: I'm not sure, that I will not have problems with delivery... Aliexpress is more easy way for now
<rockosov>
minute: But it looks like very awesome! New ThinkPad generation! Wow!
<minute>
c0rnelius: you are correct, the card is indeed probing now without any changes to sd_emmc_a
<c0rnelius>
minute: Awesome. These are the only adjustments I make. You can ignore the reboot bits; https://paste.debian.net/1287780/
<minute>
c0rnelius: weird that BT works for me without that change
<minute>
c0rnelius: is it needed only to turn it _off_ properly?
<c0rnelius>
it would come up for me before but it didn't actually function.
<minute>
oh huh
<c0rnelius>
scan on
<c0rnelius>
see what it does
<minute>
for me it works really well, i was using PAN with my iphone
<c0rnelius>
interesting.
<c0rnelius>
it comes back on reboots as well?
<c0rnelius>
Pretty sure the vendor kernel is doing it the same as well. Accept they are using a reset, which doesn't seem to work on mainline.
<c0rnelius>
The schematic also has it on 19 as well, if I remember correctly.
<minute>
c0rnelius: haven't really looked at reboots in that regard, will do
<minute>
c0rnelius: wifi seems pretty good now, but i still have rx aggregation disabled, will try without that
anessen971 has joined #linux-amlogic
anessen97 has quit [Ping timeout: 246 seconds]
anessen971 is now known as anessen97
<c0rnelius>
minute: i still get `failed to get tx report from firmware` from time to time, so I turn that off. But i also see that on the USB drivers.
<minute>
c0rnelius: what do you turn of? rx aggregation in rtw88 driver?
<minute>
c0rnelius: ok, got an skb_panic now after around 1 hour of use
<c0rnelius>
minute: got a dmesg?
<minute>
no, i turned it off, i will enable rx aggregation again and put in the logging mentioned in the mailing list thread for another round of testing
<minute>
(rebuilding kernel now)
<c0rnelius>
which kernel are you using? rtw88 isn't complete in 6.4.y.
<minute>
6.4.4 plus rtw88 patch stack
<minute>
(the reason is that we are integrated with the debian kernel)
<minute>
xdarklight: i put in your suggested debugging incl the hexdump, but it's not triggered because !ret and count>1000 are never true at the same time there
<minute>
i'm changing the code so that buf and count are saved to temp vars at the beginning
<minute>
and also put in a global condition that turns on this debug only after "Failed to read" happens for the first time
<c0rnelius>
minute: do you use the cma= because you don't use the reserved mem marked nomap patch?
<minute>
c0rnelius: haven't heard about that one! i'm used to using that for etnaviv
<minute>
c0rnelius: not needed for panfrost?
<c0rnelius>
Basically u-boot will reserve the mem not allowing for the kernel to populate the correct reserved mem during hand off. It can create stability problems for some boards. Most notable was on the N2. Not much diff than this SoC.
<c0rnelius>
unless you don't mind playing russian roulette with random lock ups
<minute>
c0rnelius: i'm not 100% following. what's causing the problem? using cma=?
<minute>
c0rnelius: is this a patch i should include in my patchstack or is this in mainline?
<c0rnelius>
no... u-boot. but I just noticed you were using cma and and then saw the following bit. `OF: reserved mem: 0x0000000005000000..0x00000000052fffff (3072 KiB) nomap non-reusable secmon@5000000`
<c0rnelius>
hmm. maybe it doesn't matter.
<minute>
ah, so i should apply this patch to mainline uboot?
<c0rnelius>
I would, yes.
<c0rnelius>
But if you aren't having issues. I guess it isn't a huge deal.
<minute>
not yet... only with wifi, and ethernet is a bit weird ^^
<xdarklight>
minute: with the higher speed SDIO bus the pull up may be needed to get a clean signal. at least this is my theory (and keep in mind: I'm not a HW engineer - so my though may be trash)
<minute>
xdarklight: well, it sounds reasonable
<xdarklight>
and it would explain why it's seemingly random (apart from opening that one URL in chromium :D)
<minute>
so what happens is, if it fails once with "Failed to read...", the next packet(s) will just contain a little bit of data and then all zeroes
<minute>
but there's no read error then
<minute>
what i'm doing is i'm scanning for blocks of at least 256 zeroes and then report that and hexdump that and return EILSEQ as well
<minute>
xdarklight: what i'm wondering is, if sdio_memcpy_fromio fails, what happens to the rest of the data? because we're leaving the loop early
<minute>
will the card just forget about it, or does it expect us to read everything anyway?
<xdarklight>
minute: hmm, interesting thought. tbh I don't know what's happening - this is a good question for Ping-Ke
<minute>
xdarklight: because it could be that the rest of the data ends up in the next transmission, getting things out of phase, so to speak
<minute>
(just a theory)
<minute>
from the card POV it doesn't know that there's a problem... we're just not reading all the data
<xdarklight>
minute: hmm, you can verify this by replacing the break with something like: err = ret; and then let the whole function return the new err variable
<minute>
yep, trying almost exactly that now
montjoie has quit [Ping timeout: 260 seconds]
montjoie has joined #linux-amlogic
ck_98 has quit [Ping timeout: 245 seconds]
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
<minute>
ok interesting, it's different now, but i'm getting drowned in hexdumps, will disable 'em for now
jacobk has quit [Ping timeout: 260 seconds]
<minute>
xdarklight: this was it
<minute>
xdarklight: we just have to read all the data and return an error if there was an SDIO error in the batch
<minute>
xdarklight: so now i just see one SDIO error in dmesg and everything just continues working
luka177 has quit [Ping timeout: 252 seconds]
luka177 has joined #linux-amlogic
<minute>
funny thing also that single SDIO error happened only once so far...
<xdarklight>
minute: note the sdio_recv_and_drop() call
vagrantc has joined #linux-amlogic
<xdarklight>
minute: I have updated my patch to this: http://ix.io/4Ci8 - it compiles find but I'm running out of time to test this today. I'll do that tomorrow and then send this as v2 (unless you have any objection(s) )
zkrx has quit [Ping timeout: 246 seconds]
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Read error: Connection reset by peer]
luka177 has joined #linux-amlogic
<minute>
xdarklight: cool, will test it tomorrow
JohnnyonFlame has quit [Ping timeout: 246 seconds]