<tzimmermann>
specififcally the final two sections
<tzimmermann>
i'd simply define iosys_map helpers for the interfaces/structs your driver needs
<tzimmermann>
and add this patch to the drm-tip fixups
<tzimmermann>
it has to be removed at some point
<tzimmermann>
danvet ^
<danvet>
yeah put a fixup into drm-tip
<danvet>
and the part to make sure all maintainers are aware is already done
<danvet>
well ping jani and rodrigovivi too so they're aware
<danvet>
in case of the next -misc-next happening before the next -intel-next or so
<tzimmermann>
javierm, you could also add a fixup that replaces dma_buf_map with iosys_map in your driver
<danvet>
javierm, and yeah if a specific driver needs something we tend to just push it through that tree
<danvet>
usually it works out
<javierm>
tzimmermann: yes, I was about to mention that. The patch I shared in that thread should be enough as a fixup
<javierm>
since will only be in drm-tip and not drm-misc-next
<javierm>
and then at some point go through drm-misc-next-fixes ?
<tzimmermann>
javierm, lucas already added the fix, apparently. demarchi ^
<tzimmermann>
javierm, next time the merge window happens, the intel tree will get merged into drm-next and from there back into drm-misc-next. somewhere along that process, the fixup will probably conflict and maintainers clean it up
<tzimmermann>
worst case is that someone will get back to you about how to clean this up
<javierm>
tzimmermann: where the fix was added? Sorry, -ETOOMANYTREES
<tzimmermann>
javierm, drm-rerere, i think. dim applies that fixup patch each time it rebuilds drm-tip
<javierm>
ah, cool. So no action is needed from me
<javierm>
dim is a god sent really since it hides all this complexity to contributors
<tzimmermann>
javierm , it's committed already. you don't have to do anything
<javierm>
tzimmermann: yeah, thanks for pointing it out
pcercuei has joined #dri-devel
<tzimmermann>
please don't assume i really understand any of this. i'm only telling you what i did last time this happend to me :)
rgallaispou has joined #dri-devel
<demarchi>
tzimmermann: javierm yes, I replied in the thread... I added it as a fixup in dim
<tzimmermann>
demarchi, thanks a lot
<javierm>
demarchi: thanks a lot and sorry for missing that your patches landed in drm-intel
<demarchi>
added maintainers there to give a heads up that when there is the drm-intel-next -> drm-next -> ..... -> drm-misc-next propagation, this would need to be in the merge
<HdkR>
New DRM release coming up? Any new ioctls added to care about since the last release?
<demarchi>
I think we may have a few more... since I did the rename I will try to watch for possible conflicts
rasterman has joined #dri-devel
ppascher has joined #dri-devel
<javierm>
tzimmermann, demarchi: great comments on the format-conversion helpers and drivers avoding to access the struct iosys_map .vaddr directly
<javierm>
I guess this means that the format helpers currently won't work for some devices/platforms that would require memcpy_{from,to}io() ?
macromorgan is now known as Guest59
macromorgan has joined #dri-devel
Guest59 has quit [Read error: Connection reset by peer]
<tzimmermann>
javierm, in the cases with I/O memory, the helper is written specifically for this scenario. most drivers know the type of memory they operate on, so they can call the right function
robertfo1 is now known as robertfoss
<tzimmermann>
and there's fbdev emulation, which uses iosys_map_memcpy_to() IIRC for copying into the GEM buffer
<tzimmermann>
javierm, an update on the simpledrm issue:
<tzimmermann>
several users have video= in ther kernel command line
<tzimmermann>
but simpledrm only supports the given resolution. fbdev setup fails if video= is anything else
<tzimmermann>
i think fbdev emulation should somehow be able to ignore video= for simpledrm
<javierm>
tzimmermann: ah, so it was "video=" after all to blame. Yes, fbdev emulation ignoring that param makes sense
LexSfX has quit []
<javierm>
tzimmermann: do the real drm drivers honour video= ? I can't remember
<tzimmermann>
javierm, there might be something else, but video= is one of the causes
<tzimmermann>
javierm, they do
<tzimmermann>
for the most part
<javierm>
tzimmermann: ah Ok, so then worst case users will get a native resolution that they don't like and that will be mode switched when the KMS driver takes over
<javierm>
tzimmermann: about the helpers, I meant that many just do memcpy() so assume is just load/store in system memory and not I/O memory
<tzimmermann>
that worked for my tests. but some users had to remove video= entirely
<tzimmermann>
idk why
<javierm>
but I guess the drivers memcpy_{from,to}io() before calling the helpers
JohnnyonFlame has joined #dri-devel
<javierm>
tzimmermann: hmm, weird. Maybe depend on the firmware somehow ?
<tzimmermann>
generic fbdev emulation parse the video= argument, but if simpledrm does not have that resolution, console setup fails and the display remains off/static/frozen until another driver initializes it
<javierm>
tzimmermann: what I don't understand is why that would cause issues to the real DRM driver when it takes over
<javierm>
I also wonder why it worked with efifb but doesn't with simpledrm
<tzimmermann>
javierm, i don't thing mayn drivers to memcpy_from_io
<tzimmermann>
do you have an example?
<HdkR>
Ack, three new i915 ioctls
<tzimmermann>
that it worked with efifb ison if the mysteries
<HdkR>
Oh wait, wrong order, I already support the new ones. Whew
<tzimmermann>
javierm, although it doesn't really affect you: the nvidia module needs console emulation
<javierm>
tzimmermann: but my point was that the helpers just do memcpy() so I wondered if that could be a problem for drivers that expect one of the buffers to be I/O memory
<javierm>
tzimmermann: ah, that's why they don't have VT then
<javierm>
tzimmermann: also puzzled how that worked with efifb
<javierm>
it seems the nvidia driver is a mine field :/
<tzimmermann>
javierm, better not call these helpers from drivers that expect i/o memory. the format helpers are not *there* yet, and quiet a bit of patchwork
<javierm>
tzimmermann: agreed. But your suggestion and demarchi of using a struct iosys_map and helpers should solve that
<javierm>
since the correct copies will be made when necessary
<emersion>
pq, fyi, you've reviewed an already-pushed patch
<tzimmermann>
javierm, i also had a patchset that adds caching information to iosys_map. some helpers use a temporary buffer for CMA helpers, as CMA can be uncached (i.e., slow). adding caching information to iosys_map would allow us to detect this case easily
LexSfX has joined #dri-devel
<javierm>
tzimmermann: indeed. Dropping those CMA buffers copies and letting iosys_map handle that would be great
<javierm>
I had to add to the helper because the repaper driver uses CMA and plan to port to it
kts has joined #dri-devel
<tzimmermann>
maybe i can undust these patches in the near future. IIRC gud has code that makes some questionaly assumptions about caching. it would also benefit, i guess
<tzimmermann>
'questionable'
<pq>
emersion, there was no reply to the patch email, so I cannot know.
<emersion>
why does my client group both in the same thread
<emersion>
anyways, sorry for the fuss!
<pq>
that one I did not reply to :-)
<emersion>
my bad
<pq>
funnily enough, now I noticed the patch title has a typo: it fails to spell the wrong spelling right
Lucretia has joined #dri-devel
<emersion>
lol
<pq>
or wrong spelling wrong?
<pq>
my client does not group these two patches in the same thread, FWIW
<emersion>
i'd say "fails to spell [it] right" or "spells [it] wrong", with it = the wrong spelling
<pq>
good luck making that english
<pq>
:-D
<emersion>
:P
<vsyrjala>
everything is wrogn
<pq>
but does two wrongs make a left?
<pcercuei>
am I the only one to notice that s/palette/palette/ is a no-op?
<pcercuei>
< pq> funnily enough, now I noticed the patch title has a typo: it fails to spell the wrong spelling right
<pq>
pcercuei, that's what I meant with the failed to spell wrong (right?)
<pcercuei>
nevermind, I am not
kts_ has joined #dri-devel
MrCooper has quit [Quit: Leaving]
<vsyrjala>
i'm still a bit sad jani noticed my recent "watermarm" typo. to me that sounds like a cute semi-aquatic animal so would have been nice to leave in the commit msg
<pq>
aaaw
Haaninjo has joined #dri-devel
kts_ has quit []
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
<mlankhorst>
Can't beat spellcheck!
<ccr>
:)
<ccr>
watermarmot!
itoral has quit [Remote host closed the connection]
<jani>
vsyrjala: sorry about that... should've bikeshedded the title though. "Polish ilk+ wm register bits". there were no Polish bits in the patch.
<ccr>
"Finnish the Polish on the ilk+ wm register bits"?
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
nchery is now known as Guest64
nchery has joined #dri-devel
camus1 has joined #dri-devel
Guest64 has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
<mlankhorst>
Perkele!
MajorBiscuit has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
<pq>
mlankhorst, wow, that worked? :-o
MajorBiscuit has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
mclasen has joined #dri-devel
maxzor has quit [Quit: Leaving]
nchery has quit [Read error: Connection reset by peer]
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
co1umbarius has quit [Remote host closed the connection]
columbarius has joined #dri-devel
columbarius has quit [Quit: columbarius]
columbarius has joined #dri-devel
jewins has joined #dri-devel
sdutt has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
<pq>
MrCooper, I had to ask, who knows what weird stuff old fb hardware had. :-)
<MrCooper>
heh, yeah it's plausible that there's HW with reverse numbering of bits, but that's not related to endianness
<pq>
no, but if the CPU arch is reversed vs. memory bus...
<pq>
Unrelated to endianess, I'm a little worried one might need Rx vs. Rx_REV and Cx vs. Cx_REV formats, because some stuff does msb-to-lsb and some lsb-to-msb pixels in a byte.
<pq>
order of pixels in a byte could also be orthogonal to the order of bits in pixel
<MrCooper>
indeed
JohnnyonFlame has joined #dri-devel
<pq>
preparing for the worst ;-)
kevinx has joined #dri-devel
<javierm>
pq: worst case I guess the driver could swap before sending to the HW
<javierm>
MrCooper: what's the name of endianess but for bits in a byte ?
<javierm>
because lsb and msb also don't seem to apply here since every bit is a separate unit/pixel
<pq>
javierm, not if it's direct scanout
<pq>
i.e. point hw at memory address & go
<javierm>
pq: right
<pq>
javierm, if the only way to access bits in a byte is via arithmetic on u8, then the order of the bits in a byte is irrelevant.
<pq>
The pixman case is probably because someone had the idea of using CPU endianess for something unrelated.
<javierm>
pq: I see. That makes sense
maxzor has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
<pcercuei>
narmstrong: friendly reminder, to review the dw-hdmi.c patch :)
<narmstrong>
pcercuei: on Monday, ping me again if I forget
<marex>
mripard: oh, oh, someone needs review of DSI stuff ? how very exciting :)
pjakobsson_ has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
maxzor has quit [Remote host closed the connection]
<danylo>
I have a question about VK_AMD_device_coherent_memory, does VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD imply that any write to such memory from GPU goes through all GPU caches? For example if I have a color attachment in such memory, would I get an up-to-date result of a draw to it without any additional synchronizations (or the result of write to such memory by any other means)?
mbrost has joined #dri-devel
kevinx has quit [Quit: Connection closed for inactivity]
ybogdano has quit [Ping timeout: 480 seconds]
guru_ has joined #dri-devel
tlwoerner_ has joined #dri-devel
anarsoul|2 has joined #dri-devel
ZeZu has quit [Read error: Connection reset by peer]
ZeZu has joined #dri-devel
sh-zam has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
tlwoerner has quit [Remote host closed the connection]
SolarAquarion has quit []
sumits has quit [Remote host closed the connection]
anarsoul has quit [Read error: Connection reset by peer]
sh_zam has quit [Remote host closed the connection]
sumits has joined #dri-devel
mbrost_ has joined #dri-devel
frieder has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
SolarAquarion has joined #dri-devel
guru_ has quit []
oneforall2 has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
anarsoul|2 has quit []
anarsoul has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
mvlad has quit [Quit: Leaving]
gouchi has joined #dri-devel
iive has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
devilhorns has quit []
tlwoerner_ has quit []
tlwoerner has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<tlwoerner>
i'm itching to get more involved, technically, with X.Org/fd.o
<tlwoerner>
i mostly do a lot of embedded work, so a project in that area would be great
<tlwoerner>
i have dozens and dozens of dev boards with some version of most GPUs ;-)
<marex>
tlwoerner: that's great !
<tlwoerner>
one thing that is popular in embedded is to do boot logos, splash screens, ettc
<tlwoerner>
but many (most?) are based around fbdev
<tlwoerner>
marex: hey!
<marex>
tlwoerner: it would be really great if there was some way to hand off boot splash from bootloader to Linux without flickering
<tlwoerner>
yes!
<marex>
tlwoerner: see
<marex>
tlwoerner: that's one way to get involved , and useful for embedded too :-)
<tlwoerner>
precisely :-D
<emersion>
tlwoerner: another nice embedded-related task would be to convert fbdev drivers to drm
<marex>
tlwoerner: it is also the kind of task nobody wants to tackle (probably for good reason too :) )
<tlwoerner>
i was thinking maybe something based on... DRM? KMS?
<marex>
emersion: or drm drivers to fbdev, since we now have fbdev maintainer again ?
<emersion>
lol
<tlwoerner>
and i could test on so many boards
<tlwoerner>
the recent talk of fbdev is what got me thinking about it again
<emersion>
just when we were finally egtting rid of fbdev support in weston
<marex>
emersion: I probably had a bit too much suger tonight, sorry :)
<marex>
*sugar
<tlwoerner>
also, back in the 90s i wrote a lot of X programs in Xlib, in fact last weekend i was goofing around with some Xlib stuff again
<marex>
tlwoerner: like, you know, kernel, or weston, or whatever it is that you enjoy
<tlwoerner>
yes, but i wanted to pitch it to the community to get their angle on it
<tlwoerner>
i *could* work on fbdev stuff, but maybe the community would be better off if i worked on a DRM replacement instead?
<marex>
tlwoerner: I cant speak for the community, but uh ... why, just, do it ? :)
<marex>
tlwoerner: yes, the fbdev stuff was just a joke, sorry if that confused you
<tlwoerner>
marex: well, for example, i don't know if i should be looking at DRM or KMS
<marex>
tlwoerner: from what I can tell, there is a ton of stuff to be improved in bridges/panels in the kernel
<marex>
scanout engine drivers too
<tlwoerner>
i might start learning all about DRM only to find that what i really want is KMS
<marex>
tlwoerner: isn't there something which actually pains you already ?
<marex>
like some driver or bridge or whatever ?
<marex>
tlwoerner: or something in userspace that sucks ?
<tlwoerner>
marex: no, everything works perfectly!
* tlwoerner
laughs at length
<marex>
tlwoerner: I saw that coming
<marex>
tlwoerner: btw which embedded hardware do you use , I recall Beth (?) mentioned something (?) but it has been a long time
<tlwoerner>
anyway, i thought i'd put this out there in case someone wants to chime in and say "here's a project that sounds like what you're looking for"
<marex>
automated testing would also be nice to expand (which btw might require leveraging some functional safety features in scanout engines or bridges, like crc calculation of the pushed out image ... that could be interesting)