<sicelo>
you meant adding 'dma_set_mask_and_coherent(&ssi->device, DMA_BIT_MASK(32));' in the `ssi_start_dma(struct hsi_msg *msg, int lch)` function?
<Wizzup>
sicelo: who is this aimed at? me?
<Wizzup>
sicelo: god I totally forgot about this mail
<Wizzup>
I don't even remember if I tried this fix or not
<sicelo>
:-D
<Wizzup>
:(
<Wizzup>
too much going on :)
<sicelo>
that says you did ... anyway, i'll post and see what kernel people have to say. maybe the output from 'ssi-protocol' will ring a bell to sre, if he'll have time
<Wizzup>
sicelo: reading my email I don't mention that I tested it
<sicelo>
ah, ok. i misread.
<Wizzup>
if it is helpful I can try to test tomorrow perhaps, although I'd prefer to do it based on our kernel tree somehow
<Wizzup>
our being the shared mapphone/n900 one
<sicelo>
sure
<sicelo>
although it didn't make a noticeable difference in my case, unless i made a mistake
<Wizzup>
However, looking at the omap3-n900.dts it looks to me that the ssi_pins
<Wizzup>
definition suggests that it should use pio, rather than DMA.
<Wizzup>
hmm
<sicelo>
anyway, let's see what new info we will get
<Wizzup>
mhm
mardy has quit [Quit: WeeChat 3.5]
norayr has left #maemo-leste [Error from remote client]
<freemangordon>
Wizzup: sicelo: yes, IIRC on n900 ssi shall use PIO
<Wizzup>
sicelo: so it looks like it to me that the whole dma path should not be taken
<freemangordon>
:nod:
<Wizzup>
and something changed I guess in dma code that makes it not hard error and suddenly the n900 tries to take dma path
<freemangordon>
Wizzup: why is modest no installed by default (at least on VM)?
<Wizzup>
freemangordon: is it not? let's add it if it's not in hildon-meta
<Wizzup>
I think it should be fwiw
<Wizzup>
maybe it wasn't ported yet in your vm image
<freemangordon>
could be
<freemangordon>
maemo-leste-1.0-amd64-20221213
<Wizzup>
quite likely I think
<freemangordon>
ok
<Wizzup>
let me verify
<freemangordon>
but yeat, my VM is upgraded
<freemangordon>
*yet
<freemangordon>
and no modest
<Wizzup>
I don't see it is in hildon-meta
<Wizzup>
I'll add it then
<freemangordon>
mhm
<sicelo>
what makes you guys say this should be PIO? not disagreeing - just trying to understand where it comes from (this stuff is higher than my pay grade, tbh)
<freemangordon>
sicelo: my memories back from the days I was plying with that
<freemangordon>
*playing
<freemangordon>
I remember we had discussions back then
<freemangordon>
argh
<freemangordon>
no /seen command here
<freemangordon>
anyway
<freemangordon>
also, IIRC fremantle kernel does PIO
<Wizzup>
sicelo: maybe you can force nerf the dma path just as a test
<freemangordon>
so DMA was never tested
<sicelo>
i see
<freemangordon>
sicelo: BTW, for reference, please check if the last working upstream kernel does DMA or PIO
<Wizzup>
yeah that was also where I was at at the time
<sicelo>
yes, in fact i'm considering to compile 5.7, which i know worked fine
<sicelo>
how will i tell if it's dma or pio btw?
<sicelo>
printks in each of the functions? or there's easier/better way?
<freemangordon>
sec
<freemangordon>
hmm, not sure why
<freemangordon>
maybe put printks in ssi_start_transfer
<freemangordon>
ssi_start_dma/ssi_start_pio
sunshavi_ has quit [Remote host closed the connection]
sunshavi_ has joined #maemo-leste
<sicelo>
mmm, seems gcc (or something else) not happy with kernel 5.7
<Wizzup>
I'm finally getting somewhere with the news post btw
<Wizzup>
probably tomorrow it will be done
<sicelo>
compilation in progress, finally
<sicelo>
great @post
<Wizzup>
sicelo: sweet, let's see if it works, if it does use pio, a quick hack would be to change ssi_start_transfer to have it always call ssi_start_pio
norayr has joined #maemo-leste
<sicelo>
mmm, bootloader (or something else) doesn't like my kernel. i get big green letters shortly after kernel log starts scrolling past: "Malfunction - device shutdown in 10 s"
<Wizzup>
:/
<sicelo>
maybe low battery. even maemo won't boot now. i hope device is not bork
<sicelo>
will see after charging for a bit
<Wizzup>
btw, it would be kinda cute if we perhaps made some page that shows the latest built packages
xmn has quit [Ping timeout: 264 seconds]
<Wizzup>
freemangordon: wow qtwebbrowser feels much more snappy with the 3d backend I think
<Wizzup>
feels like it anyway
xmn_ has joined #maemo-leste
xmn_ has quit [Client Quit]
xmn has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
<sicelo>
i really wonder what's up with that 'malfunction' ... anyway, building 6.2 again, with dma path commented out in ssi_start_transfer
<Wizzup>
sicelo: let's see
<Wizzup>
uvos: http://dpaste.com/8WQF2CBSJ - this makes the qt web browser rotate to either landscape or portrait depending on the phone
<Wizzup>
's orientation
<sicelo>
and ... it works :-)
<sicelo>
ty Wizzup, freemangordon
<Wizzup>
sicelo: yes!
<Wizzup>
sicelo: if you're up for it, we should patch that in droid4-linux asap
<Wizzup>
sicelo: yeah but I can use this patch too and fix it
<sicelo>
let me update my repos
<sicelo>
what branch to make PR against?
<Wizzup>
sicelo: hm, let me check
<Wizzup>
I think maemo-6.1
<sicelo>
cool
<Wizzup>
we could add it to debian/patches/ so we might not have to re-tag, but we can also re-tag
<Wizzup>
(then I would put it in maemo/chimaera)
<Wizzup>
sicelo: thanks for figuring this out btw
<Wizzup>
I totally forgot that I ever wrote those emails
sunshavi_ has quit [Read error: Connection reset by peer]
<sicelo>
maybe instead of MR, just use this diff, at least you'll know better which route to take (tag/no tag) - i guess it's clean enough: https://paste.debian.net/1266460/