04:24 <set_> docs!

04:24 <set_> You guys? Way to go!

04:41 <set_> bbl!

08:07 <mvaittin> for 3 days I

08:07 <mvaittin> sorry - message escaped :)

08:08 <mvaittin> for 3 days I've been trying to get my accelerometer driver working on beagle bone black SPI using the upstream v6.0-rc7 kernel.

08:09 <mvaittin> I just put the accel DT node directly in am335x-boneblack.dts. Tried both SPI0 and SPI1.

08:10 <mvaittin> configured spi-D0 as input (fore MISO) - AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_INPUT, MUX_MODE0)

08:11 <mvaittin> I can see correct-looking traffic in wires (, CS pulled low, clk, 8 bits register address in MOSI and 8 bit data reply in MISO)

08:11 <mvaittin> but the BBB spi driver always reads 0x0 :/

08:13 <mvaittin> Any good guesses what I am missing(?) I've used SPI on BBB previously with some temperature-sensor but don't remember if it used 4 or 3 wires.

08:38 <set_> Um...

08:38 <set_> I tried SPI recently too. The location of the file(s) may be located elsewhere.

08:38 <set_> So, one may need a .dts file or config-pin (either/or).

08:39 <set_> But...my spi device was not reading well either.

08:39 <set_> maybe /dev/bone/spi/?

08:42 <set_> I was trying CS1 w/ spidev1.0 but I think there are symlinks to spidev1.0 from /dev/bone/spi for now?

08:48 <mvaittin> set_: thanks :) I don't use spidev - I've done a kernel driver for the accelerometer. It has quite a lot of layers as I used regmap - but I added prints to the spi-omap2-mcspi.c pio_rx/tx just to ensure I don't lose data somewhere on the higher layers. It seems rx is all zeros already in the spi-omap2-mcspi.c

08:48 <mvaittin> and I did try setting the pinconf/mux from the dts

08:50 <mvaittin> pin 85 (PIN85) 3:gpio-96-127 44e10954 00000028 pinctrl-single - looks correct for SPI0 d0 to me.

08:50 <mvaittin> 0x28 being receiver enabled, no pull and mode 0

08:51 <mvaittin> (I guess the clk, MOSI and CS are fine as the data logged from wires look good).

08:52 <mvaittin> also the MISO data looks good, voltage levels being ~3.4V and data being what I expect to be read from the register. I just don't really know why the data in the driver is 0. I must be missing something obvious...

08:53 <mvaittin> driver being the spi-omap2-mcspi.c already

08:54 <mvaittin> (eg, not just the data from the regmap at my driver but already before the regmap layer).

09:01 <zmatt> mvaittin: check that your pinmux has the clock pin configured as input-enabled

09:01 <zmatt> i.e. PIN_INPUT

09:02 <zmatt> hmm actually if that weren't the case you also wouldn't have data out

09:03 <set_> Oh.

09:04 <zmatt> mvaittin: can you try running my show-pins utility and grep for spi: https://github.com/mvduin/bbb-pin-utils/#show-pins (hopefully it still works for kernel 6.0)

09:05 <zmatt> and share your DT fragment just in case

09:12 <mvaittin> zmatt: I don't think I have INPUT enabled for spi-clk

09:12 <mvaittin> let me see..

09:13 <zmatt> mvaittin: I'm pretty sure you wouldn't have any data out on mosi if you didn't

09:13 <mvaittin> AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_OUTPUT, MUX_MODE0)

09:14 <zmatt> well that definitely needs to be PIN_INPUT

09:14 <zmatt> even though it drives the clock pin, it also reads it back via the input receiver to get better timing specs

09:14 <mvaittin> zmatt: hmm. out of the curiosity - why is that? I think master (beagle bone) drivers the clock, right? Well, I'll change this and see what happens - Thanks!

09:15 <mvaittin> zmatt: thanks!

09:15 <zmatt> so it's the signal from the input buffer that's actually used to clock the shift register

09:16 <zmatt> so you shouldn't be able to get address bits on MOSI if sclk is input-disabled, that's the part that confuses me here

09:23 <mvaittin> zmatt: I owe you a beer :)

09:23 <mvaittin> [ 58.069897] Test read ret 0xc8 0x20 0x20 0x0

09:23 <mvaittin> I got valid data now. Unfortunately I can't help with the MOSI data.

09:24 <mvaittin> I think I saved a screenshot from the saleae capture yesterday - I can recheck or even upload the image :)

09:24 <mvaittin> but I am pretty sure the address was correctly output on MOSI

09:25 <zmatt> maybe I'm just wrong, maybe it uses the internal clock for MOSI and retimed clock for MISO

09:26 <mvaittin> zmatt: maybe :) But you definitely were right on the clock needing to be input!

09:27 <zmatt> in general just use PIN_INPUT... there's negligible benefit to using PIN_OUTPUT other than some tiny power savings, and sometimes using PIN_OUTPUT for a seemingly output-only pin breaks things :)

09:27 <zmatt> PIN_INPUT is always safe

09:27 <mvaittin> zmatt: Thanks for the tip :)

09:28 <zmatt> it doesn't help that the names are just terrible

09:28 <zmatt> since it's not input vs output, it's input-enabled vs input-disabled without having any impact on the output driver

09:28 <mvaittin> Well - pinmuxes are hard...

09:30 <mvaittin> zmatt: yes - the reference manual says 'receiver enable' which is better. But the typical GPIO programming model just uses of terms input/output

09:30 <zmatt> this has nothing to do with the gpio programming model though :)

09:30 <mvaittin> Still, it never came to my mind that the clk driven by BBB should also be received by BBB

09:30 <zmatt> (nor with the gpio controllers for that matter)

09:31 <mvaittin> well, pin c0nf/-control is probably influenced by people used to work with GPIOs

09:31 <mvaittin> s/c0nf/conf

09:33 <mvaittin> but ... BIG thanks :) It seems my driver works also on SPI - so next week I can proceed sending v2 to upstream - without RFC tag :)

09:34 <mvaittin> now I'll back my backpack and head to the wilderness :] - offline till the Monday - but matrix should log messages in case you guys want to ping me. Enjoy the weekend!

09:40 <set_> all is well again!

23:39 <set_> @zmatt: Thank you for making the subartic pins diagram.

23:39 <set_> You saved me 500 hrs. of work.

23:41 <set_> It is all about deducing time into nano amounts!