• Content Count

  • Joined

  • Last visited

  1. I've applied the patch on the sunxi spidev page (very much at the end, look for "HIGH on SCK line right before transfer") and this now never raises clock before beginning the transfer. The respecitive screenshot: So you might want to check if armbian has that patch. It's working for me now, so my devicetree foo seems to have been ok all the time.
  2. @martinayotte thanks for the patch. I'm getting the same results with and without the patch. I've now set up measurement. The results measured (oscilloscope) are the same with and without the patch. So this might already be fixed in latest kernels. The reason why it doesn't work seems to be that the chipselect comes too early, at a time when the clock is still high (the default setup is that miso is sampled at the rising edge and/or the client should sample mosi at the rising edge). Now it seems that the tpm chip cannot handle the case where the cs is asserted before clock is low. I've taken pictures: this shows CS1 in yellow, clock in blue: This shows the same for the (working) native cs0: So it seems the driver is asserting cs too early in the process. I'll try a patch on the sunxi spi page and report back.
  3. @martinayotte in your August 19, 2018 post you write that the sunxi spi drivers don't provide a proper setup function with the result that additional chip-selects are not initialized properly. Did you patch those drivers? If yes, are these patches only in armbian and can you maybe point me to them? So far I haven't found a problem in my cs config and it *does* work when using the built-in cs pin.
  4. I think the pinctrl is right, see above in my initial quote of the &pio, I'm adding a second pinctrl for the chipselect 1 (the one I want to add). The full dtb when disassembling looks as follows: spi@1c69000 { compatible = "allwinner,sun8i-h3-spi"; reg = < 0x1c69000 0x1000 >; interrupts = < 0x00 0x42 0x04 >; clocks = < 0x03 0x1f 0x03 0x53 >; clock-names = "ahb\0mod"; dmas = < 0x14 0x18 0x14 0x18 >; dma-names = "rx\0tx"; pinctrl-names = "default\0default"; pinctrl-0 = < 0x16 >; resets = < 0x03 0x10 >; status = "okay"; #address-cells = < 0x01 >; #size-cells = < 0x00 >; pinctrl-1 = < 0x17 >; cs-gpios = < 0x00 0x0a 0x00 0x0a 0x00 >; slb9670@0 { compatible = "infineon,slb9670"; reg = < 0x00 >; spi-max-frequency = < 0xf4240 >; status = "okay"; }; }; Note that this has two pinctrl specs, the 0th is the default one: spi1 { pins = "PA15\0PA16\0PA14\0PA13"; function = "spi1"; phandle = < 0x16 >; }; while the 1st is the one I added: spi1_cs1 { pins = "PA10"; function = "gpio_out"; output-high; phandle = < 0x17 >; }; When grepping for spi during boot I'm only getting the message of the NOR flash on the spi0 bus, nothing for spi1. If I use cs0 for my TPM module (I now have one module soldered for cs0, one for cs1) *and* load the driver by hand (it doesn't autoload) I'm getting: root@sun8i:~# modprobe tpm_tis_spi [ 48.731922] tpm_tis_spi spi1.0: 2.0 TPM (device-id 0x1B, rev-id 16) [ 48.741840] tpm tpm0: A TPM error (256) occurred attempting the self test [ 48.748632] tpm tpm0: starting up the TPM manually [ 48.767135] tpm tpm0: A TPM error (2314) occurred attempting the self test dmesg | grep spi [ 0.889509] m25p80 spi0.0: mx25l1606e (2048 Kbytes) [ 48.731922] tpm_tis_spi spi1.0: 2.0 TPM (device-id 0x1B, rev-id 16) Please note that I'm currently not using an armbian-provided kernel, so it may well be that armbian has a patch that I'm missing. I'm also irritated by the fact that my cs-gpios that is specified as a tuple in the source: cs-gpios = <0>, <&pio 0 10 GPIO_ACTIVE_HIGH> /* PA10 */; ends up as a five-integer sequence in the disassembled dts: cs-gpios = < 0x00 0x0a 0x00 0x0a 0x00 >;
  5. Is there any news on this? I'm seeing the same with an Infineon TPM Module for the Raspberrypi -- I'm using it on the Orange-Pi and by default it is wired for the second SPI Chip select. If I rewire for the first, it works fine. But so far I was unsuccessful using the second chip-select as follows (see below). Note that I'm using a mainline kernel (4.20.5 gregkh stable series), so it may well be that armbian has a patch that didn't make it to mainline yet? &pio { spi1_cs1: spi1_cs1 { pins = "PA10"; function = "gpio_out"; output-high; }; }; &spi1 { status = "okay"; pinctrl-names = "default", "default"; pinctrl-1 = <&spi1_cs1>; cs-gpios = <0>, <&pio 0 10 GPIO_ACTIVE_HIGH> /* PA10 */; slb9670: slb9670@1 { compatible = "infineon,slb9670"; reg = <1>; spi-max-frequency = <1000000>; status = "okay"; }; };