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
<Xogium> here's the boot log
<Xogium> I compared to what st did with their yocto image which shows they initially start with simple fb then switch over to drm_stm
<Xogium> I have these stm_drm module loaded here but… nothing seems to use it
<Xogium> this is the boot on yocto in case it helps
<Xogium> I just didn't bother with that *cough* mess of galcore out of tree module
<Xogium> and yeah why I stick to st kernel is because I need low power modes
<Xogium> until this gets merged to mainline that is
<javierm> Xogium: your boot log shows that only the etnaviv-gpu DRM driver is probed indeed. Which as jn said is render only
<javierm> Xogium: can you share the output of tree /sys/firmware/devicetree/ ?
<Xogium> oh damn I don't have the tree command
<jn> the stm-dsi driver doesn't seem to announce success in its _probe function
<jn> so it wound succeed silently
<javierm> Xogium: and the output of lsmod ?
<javierm> because jn is correct that maybe probed but silently
<Xogium> I'm also unsure why I'd need etnaviv… I mean I see the drm on my side is etnaviv, but on st's side is drm_stm
<Xogium> but that could be because they use galcore and I don't
<Xogium> lsmod, coming right up :D
<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?
sakman has joined #armlinux
matthias_bgg has quit [Quit: Leaving]
shailangsa has joined #armlinux
apritzel_ has quit [Ping timeout: 256 seconds]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Amit_T has quit [Remote host closed the connection]
nsaenz has quit [Quit: Leaving]
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
apritzel has joined #armlinux
prabhakarlad has quit [Ping timeout: 256 seconds]
headless has quit [Quit: Konversation terminated!]
<mwalle> broonie: no that i'm aware of. its for spi-nor, to get some insights into the discovered flash paramters and such
darkapex has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
amitk has quit [Ping timeout: 260 seconds]
darkapex has joined #armlinux
djrscally has joined #armlinux
darkapex has quit [Read error: Connection reset by peer]
darkapex has joined #armlinux
iivanov has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
djrscally has quit [Quit: Konversation terminated!]
djrscally has joined #armlinux
<broonie> mwalle: ah, right. Sometimes that’s a good place to put the decode.