nohit has quit [Read error: Connection reset by peer]
nohit has joined #maemo-leste
sunshavi has quit [Ping timeout: 245 seconds]
zhxt has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
Twig has joined #maemo-leste
pere has joined #maemo-leste
<freemangordon>
merging letux-pvrsrvkm-5.10-rc1 on top of letux-pvrsrvkm-5.9-rc2+linux-5.10.y, still works, I am starting to suspect tmlind's patches :)
xmn has quit [Quit: ZZZzzz…]
Twig has quit [Ping timeout: 252 seconds]
pere has quit [*.net *.split]
joerg has quit [*.net *.split]
zhxt has quit [*.net *.split]
peetah has quit [*.net *.split]
Daanct12 has quit [*.net *.split]
LjL has quit [*.net *.split]
tmlind has quit [*.net *.split]
Daanct12 has joined #maemo-leste
peetah has joined #maemo-leste
joerg has joined #maemo-leste
tmlind has joined #maemo-leste
LjL has joined #maemo-leste
zhxt has joined #maemo-leste
pere has joined #maemo-leste
<freemangordon>
tmlind: mystery is solved: with -DSYS_USING_INTERRUPTS removed 5.15 kmscube does not hang
<freemangordon>
tmlind: this is 7db47dbf1e1b539b8880b4a1d68fa05f674d419b
<tmlind>
freemangordon: ok so maybe the interrupt is misconfigured if it's not firing for omap3? bbl later tonight..
<freemangordon>
trying to find which interrupt no it is trying to use
<freemangordon>
tmlind: just a second, please
<freemangordon>
interrupts = <21>
inky_ has joined #maemo-leste
<freemangordon>
does not sound correct to me, IIRC we shall add some value to that
<uvos>
thats a hack to allow the device to ilde when the display is off
<uvos>
or part of it anyways
<uvos>
ti disabled all powermanagement in ddk1.14+
_inky has joined #maemo-leste
<uvos>
thus sgx never idles
<uvos>
this is in the blobs
<uvos>
by lieing to pvr_k and enableing active powermangement the device can idle again
<freemangordon>
doesn't seem to work properly though
<bencoh>
"thus sgx never idles" this sounds ... terrible, tbh
<uvos>
this works on the d4 blobs
<uvos>
but it might be broken on the omap3 blobs yeah
<freemangordon>
uvos: who is supposed to enable the clocks?
<freemangordon>
I would rather say that on d4 it is broken as well, but for some reason clocks are always running
<uvos>
it works on d4
<freemangordon>
[build] use-vbo=false: FPS: 56 FrameTime: 17.857 ms
<freemangordon>
[build] use-vbo=true: FPS: 57 FrameTime: 17.544 ms
<uvos>
the clock register changes
<uvos>
not sure who disables the clocks sorry
<uvos>
ask tmlind he wrote the hack
<uvos>
if this hack dosent work witht he omap3 blobs its over basicly
<freemangordon>
yeah, I am waiting for him :evil_grin:
<uvos>
no powermangement of any kind is possible then
<freemangordon>
not really
<uvos>
hmm?
<uvos>
sgx will block the whole chip from entering ret
<freemangordon>
driver manages the clocks and idles the device as needed
<uvos>
no this is disabled in the blobs
<uvos>
at least the omap4 ones
<freemangordon>
but, is enabled in the driver
<uvos>
right due to the hack
<freemangordon>
SgxClocksEnable/Disable
<bencoh>
any idea why TI did that?
<freemangordon>
lets wait for tony
<Wizzup>
freemangordon: I think I did yeah, let me check
<freemangordon>
Wizzup: no need
<Wizzup>
ok
<freemangordon>
I know what happens
<freemangordon>
we have SUPPORT_ACTIVE_POWER_MANAGEMENT enabled, which basically tells the driver:"do not manage the clocks", thus we hit ISR with clocks disabled
<freemangordon>
I disabled SUPPORT_ACTIVE_POWER_MANAGEMENT and it works perfectly so far, will post glmark score as soon as it finishes
<freemangordon>
IRQ counter incerments
<freemangordon>
also, I think I know th reason for bad use-vbo=true performance with 5.9 and earlier - it was that IRQs were not used
<freemangordon>
now I am waiting to discuss with tmlind what SUPPORT_ACTIVE_POWER_MANAGEMENT is expected to do
<uvos>
kind of wierd that vbo makes no difference still
<uvos>
bottelneck some else i gues
<uvos>
i mean vbos breaking perf was even wierder
<uvos>
but yeah looks like ok ish numberws
<freemangordon>
uvos: sorry, but we can;t have more than 60 fps
<freemangordon>
unless I am misunderstanding what you say
<uvos>
ok i thought it wasent limited by vsync
<uvos>
becasue 57fps is a bit wierd
<uvos>
but yeah ok
<uvos>
makes sense then
<freemangordon>
with 5.9 use-vbo=true fps was like 1.5
<uvos>
yeah i know
<freemangordon>
now it is 57
<freemangordon>
also, we need to check sgx fck runs on the correct rate
<freemangordon>
but that's not so important now
<uvos>
did you figure out whats causeign the boot problems too?
<freemangordon>
no
<uvos>
:( ok
<freemangordon>
probably it is unrelated
<freemangordon>
but we have oops trace so should be easily fixable
zhxt has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 245 seconds]
<freemangordon>
hmm, wait, seems I got it wrong
<freemangordon>
SUPPORT_ACTIVE_POWER_MANAGEMENT disables clocks management in some parts of the driver but enables in other parts
<freemangordon>
so, it looks like there is a bug somewhere
<freemangordon>
:D
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #maemo-leste
<Wizzup>
so, apart from fixing those kernel bugs, the next parts are potentially to go through all of glamor and replace EGL_KHR_image into glTexSubImage2D with something that works with the blobs?
<Wizzup>
or is this still valid:
<Wizzup>
22:29 < uvos> on n900 nothing works for some reason, wrt rendering to gbm textures from gles, fmg mentioned.
<Wizzup>
22:29 < uvos> but idk what the state is there
<Wizzup>
22:30 < uvos> thats pretty mutch all i have
<uvos>
just 2 places need changeing
<uvos>
the n900 bug is the bug fmg is currently on
<uvos>
just 2 places need changeing wrt the KHR_image problem
<uvos>
but then there is the additional problems with chomeos mesa
<uvos>
wrt reported texture formats
<uvos>
fix all of those and glamor works
<uvos>
maybe you also need the shim we dont know if thats needed at all with chromeos mesa, at least egl reports x11 support if you use it
<uvos>
but it might not work beacuse maybe this goes nowhere in blobs
<uvos>
side note on d4 we gain 350 ish mW unavoidable additionaly power usage with ddk1.17
<Wizzup>
in addition to what
<uvos>
over ddk1.9
<uvos>
beacsue ti disabled all pm in the blobs
<uvos>
so the gpu dosent clock down or gate
<uvos>
(except when the display is off)
<uvos>
(with the hack)
<Wizzup>
uhh
sunshavi has joined #maemo-leste
<Wizzup>
no working around that?
<uvos>
you could ignore the blobs and clock down/ gate the gpu anyhow
<uvos>
no idea how they would react
<uvos>
its imo not that bad since the gating was kind of broken in ddk1.9 too
<uvos>
ts only more power consumption if the display was totaly static
<uvos>
*its
<uvos>
otherwise if anything was going on on the display the gpu was active anyhow
<Wizzup>
mm
<uvos>
this is different from the android driver
<uvos>
it gates the gpu as soon as the frame is finished rendering
<uvos>
untill it needs the next frame
<uvos>
that saves a bounch of power
<uvos>
so ddk 1.9 was pretty suboptimal allready
pere has quit [Ping timeout: 252 seconds]
<Wizzup>
mhm
<Wizzup>
well if we can hit RET (and OFF) with 1.17 on n900 and d4 that will already be huge, with modern X/modesetting
<Wizzup>
uvos: are those serial device files useful?
<uvos>
well...
<uvos>
1. i dont like the design in generall 2. the single dxf file he gave us is really incompleat
<uvos>
3. i dont understand some of the features the file has
<uvos>
like whats up with the 3 big holes
<uvos>
and it has the big central ejection hole for the battery holder but has the holes for the pogo pins too
<uvos>
so what part is this supposed to be
<uvos>
the battery holder or the fake battery
<uvos>
the outer perimiter can be the same
<uvos>
*cant
<uvos>
makes no sense as is, also where is the frame that goes around the bottom plate of the battery holder?
<uvos>
Wizzup: so no
<uvos>
its not usefull
<Wizzup>
the frame that goes around the battery doesn't really matter, right?
<uvos>
no
<uvos>
but the dxf file has bits of both pieces
<Wizzup>
regarding liking the design or not, it's more about it being useful/functional I think :p
<uvos>
so idk what part is supposed to be
<Wizzup>
I think he said that wrt 'puzzle'
<uvos>
i would not construct it like that
<uvos>
if all you have is a laser cutter it make some sense
<uvos>
but otherwise its pretty insane
<uvos>
if i where to do this i would maybe take his mesurements
<uvos>
but otherwise i would machine the battery bit out of some pom
<uvos>
and a pcb to mount the contacts
<uvos>
proparly
<uvos>
or do the flat flex thing
<uvos>
since thats really easy
<uvos>
for others to repoduce by odering it from a pcb house
<uvos>
can we promote profilesx to core
<uvos>
and install it by default?
<Wizzup>
I'm not super happy with profilex, would maybe rather have the RE version, but I suppose
<uvos>
i think its indefintly better than having no way to setup the settings sphone and mis use
<uvos>
the ui is not great ill give you that
<uvos>
also adding profiles fails
<uvos>
not sure why
<Wizzup>
yeah
<Wizzup>
didn't debug that either, but did notice it
<sicelo>
wow, amazing work freemangordon :-)
<sicelo>
"Never fear. I is here"
<Wizzup>
we don't have glamor/h-d yet, but hey, it's progress for sure :)
<uvos>
btw
<uvos>
wrt vm behavior
<uvos>
we should have leste-config for vm/desktop style devices
<uvos>
you can configure mce to enforce sane bahvior (ie xorg style lock only)
<uvos>
also would allow configureing more sane shortcuts for h-d
<uvos>
ie alt-f4 for close window etc
<freemangordon>
so, basically, what I see so far is that on n900 with enabled SUPPORT_ACTIVE_POWER_MANAGEMENT, when ISR gets called, ther is a check if SGX is powered on or not. So (and that's something I should verify), it seems on init driver assumes that SGX is powered on, but I am not sure that's the case
<freemangordon>
...
<freemangordon>
so, it thinks the device is powered on (clocks are running) and does not call SGXClocksEnable()
<freemangordon>
but, because clocks are nit running, we have that abort
<freemangordon>
Wizzup: OTOH - I managed to enable all the logs (this time for real :) ), do you mind if I provide that kernel for you to gather traces on abort?
<freemangordon>
that way I'll have hard evidence that clocks are not enabled because driver thinks they are already enabled
<freemangordon>
ont the question what remains - the issue we have is with glTexSubImage2D - this is not allowed on BO backed textures, but glamor does it
<freemangordon>
so, we need to somehow workaround that - the lame solution I came up with is to have another texture that BO texture is copied to
<freemangordon>
unfortunately, this will ruin the performance dramatically
<freemangordon>
re X support - blobs have that compiled out, period
<uvos>
no
<freemangordon>
pvr_dri is just a wrapper
<uvos>
i know
<uvos>
but this isent where x support is required at all
<freemangordon>
uvos: been there done that, I'd love to prove me wrong, but I am afraid this is the situation - no X support in the blobs
<freemangordon>
uvos: in blobs eglGetDisplay implementation, only gbm and wl are supported
<uvos>
last time we disscussed this in pm we both agreed in the end that we dont know atm, so unless something changed there the only places we know the blobs have x compiled out
<uvos>
are those that are compleatly replaced by mesas
<uvos>
in the mesa path
<freemangordon>
no
<uvos>
and eglGetDisplay is implemented by mesa
<uvos>
in the chomeos path
<uvos>
with x support intact
<freemangordon>
it is not, it is just a wrapper
<freemangordon>
again, I would really love to be proved wrong
<Wizzup>
freemangordon: sure, can run whatever, let me know
<freemangordon>
uvos: if you have ideas how to test X support, please share, I will cooperate
<freemangordon>
Wizzup: sec
<uvos>
no since
<uvos>
you would have to have x running on the same dri node first
<freemangordon>
Wizzup: same link
<freemangordon>
it is a no issue, as X runs with MS/glamor
<uvos>
gbm might be partally broken idk i dident investigate as sutch
<uvos>
at least your usage works
joerg has joined #maemo-leste
<freemangordon>
ok, could you create a simple test app that opens :0 and calls eglGetDisplay( (EGLNativeDisplayType) xdpy ); .ofc you have to have Xorg running
<uvos>
well there is no way to start xorg with accel
<uvos>
so it will end up in dri2
<freemangordon>
why?
<uvos>
with will end up in llvmpipe
<uvos>
it dosent start
<freemangordon>
I was able to start it
<uvos>
on plain pvr yeah
<uvos>
on chomeos mesa
<freemangordon>
yeah
<uvos>
it bails immidatly
<uvos>
it complains it cant find a valid textureformat
<uvos>
and just bails
<freemangordon>
you can start Xorg on IMG blobs and then run test app on mesa blobs
<uvos>
i gues
<uvos>
but it dont have a working img blobs settup
<uvos>
rn
<freemangordon>
sure, no hurry
<freemangordon>
I can share my blobs dir from my d4
<freemangordon>
uvos: OTOH, do you have any idea why pvr driver assumes SGX is powered-up (and with clocks running) on loading?
<uvos>
no
<Wizzup>
freemangordon: will do it in a bit, sry, something came up
<freemangordon>
NP
Pali has joined #maemo-leste
<tmlind>
freemangordon: oh cool you narrowed it down that pm hack patch
<tmlind>
strange that the devices behave in a different way
<freemangordon>
tmlind: I don't think it is the patch itself that brings the problem. it is either DTS or the driver itself that is buggy
<freemangordon>
d4 dts has some stuff in dts that is missing form omap3
<freemangordon>
*for
<freemangordon>
some ti,sysc stuff
<freemangordon>
no idea what it is or if it should be there
<freemangordon>
I am waiting Wizzup to capture traces via serial before deciding what to do
<tmlind>
freemangordon: let me check the dts config
<freemangordon>
ok
<tmlind>
freemangordon: well the 34xx pvr module sysconfig is either broken or write-only and i recall it's best to not mess with it
<tmlind>
it could be that omap4 is working because we have configured SYSC_IDLE_SMART_WKUP
_inky has quit [Ping timeout: 252 seconds]
<tmlind>
i'll try again with the omap36xx.dtsi gpu config
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
<Wizzup>
freemangordon: need another 30mins then I'll do it
sunshavi has quit [Remote host closed the connection]
<freemangordon>
tmlind: look at ^^^
<freemangordon>
actually driver tries to enable the clocks
<freemangordon>
something wrong with pm_runtime_get_sync()?
<tmlind>
yeah ok, i'll take a look
R0b0t1` has quit [Ping timeout: 265 seconds]
R0b0t1` has joined #maemo-leste
Twig has quit [Ping timeout: 252 seconds]
l_bratch has quit [Read error: Connection reset by peer]
l_bratch has joined #maemo-leste
l_bratch has quit [Client Quit]
l_bratch has joined #maemo-leste
Twig has joined #maemo-leste
<Wizzup>
freemangordon: tmlind: just a heads up I catted the wrong two files together, it doesn't really matter for the panic log (the second file was already correct, first was not) but here's the proper one https://wizzup.org/panic-log-2.txt