<tzimmermann>
javierm, can we reduce sysf_disable() to a simple "disabled = true" ?
Haaninjo has joined #dri-devel
<javierm>
tzimmermann: maybe it's a left over from the time when we haven't moved that unregister logic to the aperture helper ?
<tzimmermann>
i think so.
<tzimmermann>
it must be from when sysfb_disable() was still called from within fbdev
<tzimmermann>
can we clean it up?
<javierm>
tzimmermann: yeah, if everything is handled by aperture now I agree that simply disabled = true should be enough (since that's protected by the disable_lock)
<tzimmermann>
damnit, i know!
<tzimmermann>
there's this gap between registering the device and probing the driver
<javierm>
tzimmermann: ah, right
<tzimmermann>
apologies for bothering :/
<javierm>
tzimmermann: no worries, it's confusing :) I remember we added that to fix a bug but didn't know if still applied after the refactor made for aperture
<tzimmermann>
javierm, i do have a few patches for sysfb. i'll post them in a bit
<javierm>
tzimmermann: great
<javierm>
tzimmermann: maybe include one to the comment to clarify why the remove is needed ?
<javierm>
now it only says "It also unregisters a device if this was already registered by sysfb_init()"
<tzimmermann>
they also improve resource handling for screen_info. at some point, sysfb will then be able to register apertures by itself without driver
<javierm>
tzimmermann: that's cool
<tzimmermann>
but it's not there yet
<tzimmermann>
anyway, you'll see
mvlad has joined #dri-devel
<javierm>
tzimmermann: Ok, thanks
<javierm>
tzimmermann: speaking of sysfb, I think you mentioned that wanted to post a patch to move sysfb_init() to device_initcall() ?
<mripard>
sima: I'm not entirely sure how to handle the Broadcast RGB stuff (and the larger HDMI rework). There's been some feedback that we should just merge the thing as it is because it's an improvement already, and some that we should document it even further. What's your opinion there?
<tzimmermann>
javierm, i did
<tzimmermann>
i can add it to the patchset
<javierm>
tzimmermann: great, thanks
pcercuei has joined #dri-devel
tursulin has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
Haaninjo has quit [Quit: Ex-Chat]
flynnjiang has quit [Quit: flynnjiang]
kts has joined #dri-devel
cmarcelo has joined #dri-devel
sumoon has joined #dri-devel
mainiomano has joined #dri-devel
ifreund has joined #dri-devel
kuruczgy has joined #dri-devel
pitust has joined #dri-devel
rpigott has joined #dri-devel
ella-0 has joined #dri-devel
kennylevinsen has joined #dri-devel
kchibisov_ has joined #dri-devel
rosefromthedead has joined #dri-devel
jfalempe has joined #dri-devel
bmodem has joined #dri-devel
cmichael has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
neniagh has quit [Read error: No route to host]
rasterman has joined #dri-devel
neniagh has joined #dri-devel
dsrt^ has quit [Remote host closed the connection]
<mripard>
jani: ok, you convinced me. We need an eBPF panel
<jani>
mripard: :D
bmodem has quit [Ping timeout: 480 seconds]
<jani>
mripard: I think it boils down to what the goal really is. you think it's overcomplicated already, and I think it's going to be incredibly more complicated to do all the stuff that's mentioned in the cover letter :o
<mripard>
I think expecting the DSI controller driver to handle two panels in the overcomplicated part
neniagh has quit [Read error: No route to host]
<mripard>
everybody will get it wrong, you won't test the same code path than the "production" one, etc.
<mripard>
so I think we should just have a proper driver panel for it
neniagh has joined #dri-devel
<mripard>
but you're probably right that that driver would be quite complicated
<jani>
and, in the end, a lot of the DSI panels are really fussy about configuration and the exact order and timing of things... I'm not convinced a simulated panel is going to get us very far
sima is now known as Guest14417
sima has joined #dri-devel
<jani>
and yet I get where the series comes from. DSI is hard, even with the panels, and changes without real panels are going to bitrot fairly easily
<javierm>
he mentions DSI as something that he wants to explore in the future
Guest14417 has quit [Read error: Connection reset by peer]
<mripard>
javierm: I think jani's point is that while it would allow to test some setup of the DSI controller, there's so many variations that we would still get a lot wrong
<mripard>
I guess it's a matter of whether we want to test to catch most regressions, or to prove correctness
sima is now known as Guest14418
sima has joined #dri-devel
<javierm>
right. And I guess it also boils down on whether one wants to test regressions for the controller but not the panels (because as he said, for that the only option is to test with the real panel)
Guest14418 has quit [Ping timeout: 480 seconds]
neniagh has quit []
neniagh has joined #dri-devel
kchibisov has quit [Remote host closed the connection]
bmodem has joined #dri-devel
<jani>
boils down to what the goal here is, really
<javierm>
jani: yeah
<jani>
seems to me marek's goal is completely different
<jani>
and for what he's doing, DSI is probably going to be an order of magnitude more difficult than DPI or LVDS, but let's not tell him so maybe something good comes out of it ;)
<javierm>
:D
kchibisov_ is now known as kchibisov
bmodem has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
itoral_ has joined #dri-devel
bmodem has joined #dri-devel
kts has joined #dri-devel
itoral__ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<MrCooper>
kusma: no cookie for you from Marge :)
<kusma>
Yeah, I'm ashamed!
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
heat has joined #dri-devel
mclasen has joined #dri-devel
kts has joined #dri-devel
AnuthaDev has quit []
Leopold_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
bmodem has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
jfalempe has quit [Remote host closed the connection]
yyds_ has quit [Remote host closed the connection]
<tomeu>
I still had drivers/gpu/drm/ci/gitlab-ci.yml in the repo config :)
djbw has joined #dri-devel
neniagh has quit []
Duke`` has joined #dri-devel
ondracka_ has quit [Ping timeout: 480 seconds]
ondracka_ has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
cheako has joined #dri-devel
ADS_Sr has joined #dri-devel
Mangix has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
Company has joined #dri-devel
jewins has quit [Quit: jewins]
simondnnsn has quit [Read error: Connection reset by peer]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
glennk has joined #dri-devel
Leopold has joined #dri-devel
kts has quit [Quit: Leaving]
vliaskov has joined #dri-devel
<DavidHeidelberg>
tomeu: you combining mine gfx-ci/linux commit for CI with drm-ci CI :D
<DavidHeidelberg>
the .gitlab-ci folder is unexpected in the Linux kernel tree managed by drm-ci (in drivers/gpu/drm/ci) since it just copy everything from the mesa tar INCLUDING the .gitlab-ci there
<DavidHeidelberg>
optimal solution would be to omit copying .gitlab-ci, since it has no added value anyway, but dropping my CI commit is the right thing to do 78b99a84ad1d4863eba012a7af7744a56fad4e7c
<DavidHeidelberg>
I should read all the messages you wrote.
jfalempe has quit [Remote host closed the connection]
kts has joined #dri-devel
AnuthaDev has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
frieder has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
kts has quit [Quit: Leaving]
bmodem has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
neobrain has quit [Remote host closed the connection]
gouchi has joined #dri-devel
hansg has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
tursulin has quit [Ping timeout: 480 seconds]
<HdkR>
nir_constant_expressions.py creates a typedef that conflicts with natively declared float16_t on some platforms. What would be the viable workaround?
<HdkR>
arm_neon.h in particular declares it, so it conflicts pretty heavily
fab has quit [Quit: fab]
<HdkR>
src/util/half_float.h also declares a type for cpp which conflicts with the definition a bit. That has 16-bit storage where the nir_constant_expressions is just a typedef for 32-bit float.
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
sima has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
checkfoc_us has joined #dri-devel
Mangix has joined #dri-devel
iive has joined #dri-devel
mszyprow has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kzd has joined #dri-devel
ngcortes has joined #dri-devel
<karolherbst>
kinda a shame that the C standard didn't cleaned up the float types as well, but apparently float/double were well defined contrary to the int types 🙃