f_ changed the topic of ##raspberrypi-internals to: The inner workings of the Raspberry Pi (Low level VPU/HW) -- for general queries please visit #raspberrypi -- open firmware: https://librerpi.github.io/ -- VC4 VPU Programmers Manual: https://github.com/hermanhermitage/videocoreiv/wiki -- chat logs: https://libera.irclog.whitequark.org/~h~raspberrypi-internals -- bridged to matrix and discord
<clever> its sort of like vtables
<clever> and then hdmi_get_func_table, as expected
<clever> ok, i can see a device_open(), that calls hdmi_open()
<clever> and i can see it rigging up some dma irq's, for iec61937 (hdmi audio i believe)
<clever> and thats related to hdmi_num_dma_blocks= in config.txt
<clever> along with hdmi_dma_waits=
<clever> hdcp_initialize() can also call hdmi_open()
<clever> oh, hdmi_boot() !
<Guest92> :D
<clever> it copies a pair of 0x14 byte arrays of nuls, onto some stack variables
<clever> then copies them into a global variable
<clever> then calls a bunch more functions....
<clever> hdmi_control_gpio function table....
<Guest92> sounds important
<clever> ah, all it does is rig up the hotplug pin
<clever> gpio 46
<clever> wow
<clever> an entire class, with 6 functions, to do just 1 task
<clever> read a pin, and adjust for active-low vs active-high
<clever> its not even a thread, its something you call
<clever> complete with a constructor, destructor, and info function, as is typical
<Guest92> for speedy boot-up
<Ad0> argh
<Ad0> https://pastebin.com/sM7sEmA3 why is gpio30 still out lo ACTIVE LOW
<Ad0> I mean why are the other ones active out hi ?
<Ad0> what does lo mean anyway
<clever> the actual state, when treating the pin as an input
<Ad0> well it's a CS , is there something messing with GPIO30?
<Ad0> should I care about it ?
<clever> the debug says the spi0 driver is managng that pin
<clever> so normally, linux shouldnt let anything else mess with it
<Ad0> why is it lo when the others are hi ? they are all managed by SPI
<clever> try adding print statements to the spi driver, around its chip-select code?
<Ad0> that will take me 100 years hehe
<clever> what is the compatible= for spi0?
<Ad0> I am not sure how to just replace the kernel driver
<Ad0> there is no compatible for spi0 itself
<Ad0> do you mean the devices on spi0 ?
<clever> there must be
<clever> spi0 cant work without a compatible
<clever> your looking at an overlay, you want to look at the base dts, or the final dts
<Ad0> ok
<clever> run `dtc /proc/device-tree | less`, and scroll down to that area, to see the final dts
<Ad0> you mean &spi0 root ? or the sub nodes
<clever> for the spi0 node
<Ad0> there's nothing in the working one , it doesn't render like that either
<Ad0> no compatible on the spi0 itself
<clever> thats still an overlay
<clever> run `dtc /proc/device-tree > foo.dts` and gist that
<Ad0> I don't use overlay myself though. I use my own bcm2710-rpi-cm3.dts
<clever> Ad0: just run that command, and pastebin the output file
<Ad0> I will do it from the working dts on the working kernel from the producer
<clever> that wont make a difference
<clever> the compatible will be the same in either case
<Ad0> ok this is the result
<clever> and look at line 844
<clever> there is the answer
<clever> that is the final dts, after all overlays have been applied to the base dts
<clever> that final dts, is what linux is acting on
<Ad0> yeah
<clever> drivers/spi/spi-bcm2835.c: { .compatible = "brcm,bcm2835-spi", },
<Ad0> I will see what my dts looks like
<clever> so that tells linux to load this driver, to manage the spi controller
<clever> drivers/spi/Makefile:obj-$(CONFIG_SPI_BCM2835) += spi-bcm2835.o
<clever> what is that .config flag set to?
<Ad0> CONFIG_SPI_BCM2835=y
<Ad0> CONFIG_SPI_BCM2835AUX=y
<clever> then its baked into the kernel, and you cant just replace the driver
<clever> youll need to build the entire kernel whenever you make changes for debug
<Ad0> do you think the compatible will work
<clever> i see no reason why it wouldnt
<clever> i think the spi driver is using spi_get_csgpiod to handle chip-selects
<Ad0> I know it uses gpio to set cs or else it wouldn't show up right
<Ad0> in the debug gpio
<clever> the old way of chip-select, was to use the native cs for the controller
<clever> but that limited you to certain pins
<clever> the new way, just uses regular gpio to set the cs lines
<Ad0> yeah the driver checks
<Ad0> I saw the source
<Ad0> so it should work
<Ad0> [ 4.991536] spi_dac7512: loading out-of-tree module taints kernel.
<Ad0> so that SPI driver works
<Ad0> but that is reg 0
<Ad0> if it didn't use cs_gpiod it would say "setup: only two native chip-selects are supported"
<clever> yeah
<Ad0> I removed the gpio handle and it said that so that works
<clever> so now cs_gpiod, will be a reference to the pins the dts pointed to
<clever> and what about BCM2835_SPI_NUM_CS on line 1291?
<Ad0> that's 24
<Ad0> way over the 4 I use
<clever> damn! :D
<Ad0> that was a problem in kernel 5.4
<Ad0> it was 3 there...
<clever> static void spi_set_cs(struct spi_device *spi, bool enable, bool force)
<clever> that looks like a relevant function!
<Ad0> yeah but like the other driver in the tree works though
<clever> add some printk statements to that, rebuild the kernel, and see what happens
<Ad0> yeah maybe I should try, I just have a feeling something is wrong with that CS since it's not a user GPIO
<Ad0> so I think something should be disabled that is screwing around with that
<Ad0> bluetooth messes with it
<clever> where does bt mess with it?
<clever> are you sure that gpio is exposed on a header?
<Ad0> not on the pi3 but on the CM3
<clever> where does bt mess with it?
<Ad0> uart1 bluetooth I think hold on
<Ad0> hm maybe that was PI4
<clever> on the pi3, gpio 32/33 are the bt uart
<Ad0> yeah correct, sorry
<clever> on the pi4, gpio 30-33 are bt uart, with hw flow control
<clever> but if you dont have bt in the device-tree, that wont matter
<Ad0> yeah
<Ad0> cam0_reg might have 30
<Ad0> but I don't have that either I think
<clever> its disabled, so linux will ignore that
<Ad0> yeah it's disabled in the functioning dts
<clever> and in the broken dts?
<Ad0> arch/arm/boot/dts/bcm270x.dtsi: cam0_regulator: cam0_regulator {
<clever> you want to look at the final dts
<clever> there are many overlays, and it can be very confusing to figure it out manually
<Ad0> yeah I don't have DTC on my own device :/
<clever> you can do it with cp as well
<Ad0> I have 0 overlays because I use a base dts with everything in it
<clever> what does `find /sys -name fdt` report?
<Ad0> but it includes the dtsi
<Ad0> it reports /sys/firmware/fdt
<clever> now copy that file to a machine that does have dtc
<clever> and run dtc on it
<clever> it can even be an x86 machine
<Ad0> ok
Guest92 has quit [Quit: Client closed]
<Ad0> the pins declaration is not used unless it's used by something right
<clever> correct
<Ad0> pcm_gpio28 and uart0_ctsrts_gpio30
<Ad0> 0x1e
<clever> yep, thats unused
<Ad0> the working config.txt on the working device has dtparam=audio=on
<Ad0> but there is no audio, maybe it's to activate something related to that GPIO ? I dunno
<clever> audio is pwm based
<clever> gotta run, somethings come up
<Ad0> ok thank you so far and good night!
<Ad0> I will run cat /sys/kernel/debug/gpio on the working image
Guest92 has joined ##raspberrypi-internals
HerculeP has joined ##raspberrypi-internals
srk_ has joined ##raspberrypi-internals
snuck has joined ##raspberrypi-internals
sneak has quit [Ping timeout: 264 seconds]
Herc has quit [Ping timeout: 264 seconds]
srk has quit [Ping timeout: 264 seconds]
srk_ is now known as srk
HerculeP is now known as Herc
<Guest92> Update on 700+ns GPIO stall. It was caused by an interrupt handler. Not sure which handler yet, or exactly what it is doing to stall the GPIO bus, but disabling IRQs gave me reliable sub-200ns GPIO read latency.
<Guest92> ie, not bus-hogging by VC4 VPU as I had originally thought
<clever> Guest92: try to find the irq handler, and add some printfs to it, so you can see when it fires, and what its doing
<clever> Guest92: oh!, i found an hdmi_power_on and hdmi_power_off!
<clever> but not much in them
f_ has quit [Read error: Connection reset by peer]
f_ has joined ##raspberrypi-internals
Guest92 has quit [Quit: Client closed]
jcea has quit [Ping timeout: 246 seconds]
HerculeP has joined ##raspberrypi-internals
snuck has quit [Ping timeout: 255 seconds]
Herc has quit [Ping timeout: 255 seconds]
sneak has joined ##raspberrypi-internals
angerisagift has quit [Ping timeout: 268 seconds]
angerisagift has joined ##raspberrypi-internals
jcea has joined ##raspberrypi-internals
jcea has quit [Ping timeout: 268 seconds]
<Ad0> clever, the issue with "lo" was that probing failed. so it is in that state
HerculeP is now known as Herc
jcea has joined ##raspberrypi-internals
angerisagift has quit [Ping timeout: 264 seconds]
angerisagift has joined ##raspberrypi-internals
angerisagift has quit [Ping timeout: 255 seconds]
angerisagift has joined ##raspberrypi-internals
f_[xmpp] has quit [Ping timeout: 264 seconds]
angerisagift has quit [Read error: Connection reset by peer]
angerisagift has joined ##raspberrypi-internals