ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
djrscally has quit [Ping timeout: 256 seconds]
apritzel has quit [Ping timeout: 250 seconds]
XV8 has joined #armlinux
amitk has joined #armlinux
XV9 has joined #armlinux
XV8 has quit [Ping timeout: 250 seconds]
guillaume_g has joined #armlinux
frieder has joined #armlinux
frieder has quit [Remote host closed the connection]
frieder has joined #armlinux
frieder has quit [Client Quit]
guillaume_g has quit [Ping timeout: 250 seconds]
guillaume_g has joined #armlinux
apritzel has joined #armlinux
iivanov has joined #armlinux
sszy has joined #armlinux
headless has joined #armlinux
mcoquelin has joined #armlinux
NishanthMenon has quit [Ping timeout: 268 seconds]
NishanthMenon has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #armlinux
headless_ has joined #armlinux
headless is now known as Guest9818
headless_ is now known as headless
Guest9818 has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
russ has quit [Ping timeout: 252 seconds]
russ has joined #armlinux
alexels has joined #armlinux
nsaenz has joined #armlinux
apritzel_ has joined #armlinux
NishanthMenon has quit [Ping timeout: 252 seconds]
NishanthMenon has joined #armlinux
narmstrong has quit [Ping timeout: 252 seconds]
jamestperk has quit [Ping timeout: 252 seconds]
narmstrong has joined #armlinux
jamestperk has joined #armlinux
suzukikp has quit [Ping timeout: 256 seconds]
headless has quit [Quit: Konversation terminated!]
Amit_T has joined #armlinux
flowriser has quit [Remote host closed the connection]
gpiccoli_ is now known as gpiccoli
gpiccoli has quit [Quit: Quit...]
gpiccoli has joined #armlinux
XV9 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
matthias_bgg has quit [Read error: Connection reset by peer]
XV8 has joined #armlinux
matthias_bgg has joined #armlinux
ravan_ has quit [Ping timeout: 245 seconds]
darkapex has quit [Read error: Connection reset by peer]
darkapex has joined #armlinux
ravan has joined #armlinux
ravan has quit [Changing host]
ravan has joined #armlinux
Tokamak has joined #armlinux
headless has joined #armlinux
sudeepholla has joined #armlinux
jlinton has quit [Quit: Client closed]
<mwalle>
regarding flags in debugfs, are there any preferences (or maybe best practices) between dumping just the raw value and decoding em?
psydroid has joined #armlinux
mvaittin has joined #armlinux
shoragan[m] has joined #armlinux
amstan has joined #armlinux
a3f has joined #armlinux
<broonie>
mwalle: It's a free for all really.
<broonie>
Whatever makes sense for use in the expected circumstance, given how hard it is to implement.
<mwalle>
broonie: ok, I'm still undecided, because as you said, efforts for implementation vs just a debugfs_create_x32(). but OTOH it might be tedious to look up the flags in the sources. mhh
<broonie>
Is it likely that someone will want a helper program to look at the debugfs state?
<Xogium>
hmm… what could cause linux to not register the fb_simple kernel driver ? Do I even need this to make use of the etnaviv gpu kernel driver later on?
<Xogium>
I've been struggling with graphics for a while now… /dev/fb0 is never created
<jn>
in debugfs/clk, for example, there are both raw values in separate files and a summary file with a visually-nice table
<Xogium>
yeah doing graphics when you can't see == bad idea, probably… I'm just trying to launch weston :)
<jn>
Xogium: etnaviv is a DRM driver primarily, i think. so /dev/fb0 might be missing because etnaviv doesn't go through the fbdev subsystem. i'm not completely sure about the details though, and drm drivers can also create /dev/fb0 somehow, i think
<Xogium>
I have every driver required for the hardware enabled, everything setup in the device tree yet no framebuffer ever appear
<Xogium>
hmm
<jn>
(my debugfs/clk example was in reference to mwalle's question, not related to the etnaviv discussion)
<javierm>
Xogium: do you have CONFIG_DRM_FBDEV_EMULATION=y enabled ?
<Xogium>
hmm let me see
<javierm>
because fbcon still needs fbdevs
<Xogium>
yeah that's enabled
<javierm>
Xogium: answering your question about the simplefb, you need to have a "simple-framebuffer" DT node
<Xogium>
on kernel side or bootloader side?
<javierm>
Xogium: there's also a simpledrm driver now that also uses the firmware/bootloader setup framebuffer
<jn>
oh, i missed a detail: the Vivante hardware is only a GPU, it doesn't include a display controller, and thus it probably doesn't make sense for it to provide a framebuffer at all
<jn>
Xogium: which hardware is this?
<Xogium>
stm32mp157f-dk2 board
<jn>
ok, the display controller is going to be the "st,stm32-dsi" node in the devicetree
<javierm>
Xogium: it depends. If your bootloader supports it, can add the simple-framebuffer DT node, otherwise you need to add to the DTS
<jn>
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
<jn>
if you use the full STM32-DSI driver rather than the simple-framebuffer driver, you'll probably need to hook the dsi node up to a display, in the DT
<Xogium>
currently weston complains about not finding any drm device then fails to setup the compositor
<Xogium>
yeah they did that in the dk2 dev kit
<jn>
hm
<jn>
what do you find in /dev/dri/?
<javierm>
Xogium: can you share your boot log ?
<Xogium>
yeah sure
<Xogium>
let me just boot this beauty up :)
<Xogium>
so I get uh a card0 chardev and a renderD128 device
<javierm>
Xogium: hmm, so stm_drm is there. Do you have modetest ?
<Xogium>
the last time something like this happened it was incredibly dumb, so it wouldn't surprise me at all if it also was for this case
<Xogium>
I wanted to use the cs42l51 sound codec onboard, but aplay -l kept returnning no sound card found. It took me 2 days to figure out that snd_soc_cs42l51 was loaded but for whatever totally crazy reason snd_soc_cs42l51_i2c was not
<Xogium>
I am not sure why that is, and had to resort to a modules-load.d drop-in to load it
<javierm>
Xogium: yeah, probably some modalias missing in the driver
<Xogium>
hmm no but it is easy to add I reckon
<Xogium>
if I find tree command I'll also add it
<javierm>
Xogium: if I would be a guess person, I would say that you have compatible = "cs42l51" instead of compatible = "cirrus,cs42l51" in your DT node
<Xogium>
hmm it could be
<javierm>
anyway, back to your gfx issue. Try to install modetest and check the available encoders, connectors, etc
<javierm>
make sure that everything looks correctly before attempting to start a wayland compositor
<Xogium>
ok I found tree at least :D
<Xogium>
alright doing a fast build to add modetest frol libdrm
<Xogium>
er from libdrm, rather
<Xogium>
hadn't seen it was a submenu
<Xogium>
at last st's kernel and such are sane unlike a ton of other vendors
<Xogium>
*least
<Xogium>
what in the…
<Xogium>
I'm uh not sure what happened here but the stm_drm now shows up
<Xogium>
I uh… think that etnaviv is in conflict with the stm_drm driver
<Xogium>
I somehow blacklisted it earlier, but it didn't seem to impact anything. But now if I diable it entirely from the kernel build, stm_drm gets used ?
<Xogium>
I'm afraid I kind of don't understand
alexels has quit [Quit: WeeChat 3.4]
<Xogium>
it appears to be either one or the other… not both
<Xogium>
and in my case I might need to disabme the stm_drm driver because mesa fails to load it… obviously
<Xogium>
but… yeah it seems like you can enable both driver in the kernel and they get loaded, both of them… but vivante has priority
<Xogium>
sounds like it shouldn't too possible to enable both of these drivers at the same time… if its to have such side effects?