Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-msm
<Marijn[m]>
alfayt: it is blocking on DSC 1.2 DSI support in DPU
<alfayt[m]>
Oof
<alfayt[m]>
What is blocking
Danct12 is now known as Guest12324
Danct12 has joined #linux-msm
Guest12324 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: WeeChat 3.8]
pespin has joined #linux-msm
<Marijn[m]>
alfayt: it is being worked on
<Marijn[m]>
Meanwhile Nagara has a cmdmode panel for which we also have many fixes and improvements (e.g. I just sent INTF TE v4 support yesterday). It all needs to come together now
svarbanov has quit [Ping timeout: 480 seconds]
<Tooniis[m]>
would it make sense to turn qrtr into a bus similar to apr?
<Tooniis[m]>
it would allow for making drivers for specific qmi services which would probe as soon as the service becomes available
<Tooniis[m]>
currently it seems that most things using qrtr are platform drivers and they access other stuff apart from qmi services, mainly mmio
<Tooniis[m]>
im working on a driver which exclusively deals with a qmi service. i have it as a platform driver and its matched through dt
<Tooniis[m]>
it doesn't make a lot of sense to describe it in dt however
<Tooniis[m]>
im thinking of registering qrtr services as devices with the qrtr smd edge providing them as their parent, basically the same way apr is currently implemented
<Tooniis[m]>
however, they wouldn't need to be described in dt, and would be registered dynamically by the name service
<Tooniis[m]>
I looked into ways to implement it but with the way things currently are, it doesn't seem like there is a clear path to take
<Tooniis[m]>
the smd driver, name service and core qrtr implementation are all highly isolated so it's difficult to match services discovered in the name service with their smd edges
<alfayt[m]>
<Marijn[m]> "Meanwhile Nagara has a cmdmode..." <- Great
deathmist1 has joined #linux-msm
deathmist has quit [Ping timeout: 480 seconds]
nashpa has joined #linux-msm
dliviu has quit [Ping timeout: 480 seconds]
<bamse>
Tooniis[m]: that's an interesting idea, back when i introduced it most/all use cases was in userspace...so it didn't make that much sense...i haven't given it much thought since
<bamse>
Tooniis[m]: but as you say, it feels like most use cases uses qmi in addition to some other primary bus...
pespin has quit [Remote host closed the connection]
<Tooniis[m]>
bamse: I'm writing a driver for sensor manager which needs integration with iio. if iio had a userspace driver api I would've switched to userspace
<Tooniis[m]>
and I'm guessing making such an api would be a much bigger task than turning qrtr into a bus. idk even if it'd be considered acceptable
<bamse>
Tooniis[m]: ahh nice
<bamse>
Tooniis[m]: you wouldn't be able to turn qrtr into a bus, it would have to be both a packetfamily and a bus (or just a bus ontop of the current implementation...)...otherwise you'll break all current use cases
<bamse>
Tooniis[m]: should be fairly straight forward though to add a bus implementation which is backed by the current api
<bamse>
Tooniis[m]: my suggestion would be to start with hacking something up that works in the form of a platform_driver, and then look into the qrtr_bus and migrate things...
<Tooniis[m]>
I already have a platform driver, it's just that probing it is kind of awkward
<bamse>
having to have a dumb node in dt just for the sake of probing it?
<Tooniis[m]>
yes
<bamse>
yeah, that's ugly...
<bamse>
but is sensors a single qrtr service? or there's some primary service you could hang the device on?
<Tooniis[m]>
sensor manager is the main service, and only one I'm currently using
<Tooniis[m]>
it exposes the hardware sensors directly
<Tooniis[m]>
there are several other services for software-based sensors like orientation and compass
<Tooniis[m]>
I don't think these could be integrated with iio anyway so I guess if they were ever to be implemented they would fit in userspace
<z3ntu>
For some reason on msm8974 the following commit breaks boot pretty badly. Most of the time the phone is rebooting basically instantly, without any trace of what's going wrong. When exactly it reboots depends a bit on ignore_loglevel, CONFIG_DEBUG_DRIVER and friends
<z3ntu>
Very seldom it stays alive for around 20 or 30 seconds but then also reboots without any trace. Anybody got a clue how to even start debugging this?
<z3ntu>
For now I'm carrying a revert of this in my tree but this is hardly a long-term solution