05:26 <_florent_> zyp: not sure we have numbers for LiteScope over Wishbone Bridge, but it's indeed a bit slow and there is a bottleneck that needs to be investigated. I could have a look, but using Etherbone will indeed be a lot faster.

18:01 <john_k[m]> trying to write my first module, and running into issues with tests - I'm trying to use the write() funciton of CSRStorage from my test, like `yield dut.bitbang.write(value)` but it's erroring out with "ValueError: ('Invalid simulator exec/eval request', <generator object CSRStorage.write at 0x7f7bb3186f90>)". Documentation for write suggests that it's meant to be used in simulation

18:11 <somlo> _florent_: turns out, I don't have to worry about padding after all :) https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L3466

18:11 <tpb> Title: linux/spi.c at master · torvalds/linux · GitHub (at github.com)

19:04 <_florent_> john_k[m]: your issue is probably that you have to use "yield from" and not "yield"

19:05 <john_k[m]> florent: thanks will try that

19:06 <john_k[m]> magic, many thanks

20:26 <somlo> _florent_: do you know if anyone (successfully) uses 16 or 32 bpw with SPI and Linux?

20:27 <somlo> I built LiteX with SPI data width 16 for the sdcard, and 1. the bios doesn't work anymore for booting (which is to be expected, as it's hardcoded for 8)

20:27 <somlo> but 2. all the transfers linux tries to initiate are still only 8 bits, even though (via DT) I told the driver that the max. bpw is now 16

20:29 <somlo> and the result is that "it doesn't work" in Linux either (at least because I suspect LiteX is trying to send 16 bits, but linux only expects 8 at a time in the driver (it can't do mixed 8-bit MOSI with 16bit MISO)

20:30 <somlo> so I'm wondering if at this point it's realistic to expect it to work with 16 or 32 bits (whenever this happens, it tends to be because I missed something :)

21:04 <somlo> _florent_: I guess the "impedance mismatch" comes from Linux assuming that a max-bpw allows falling back to a lower bpw value (e.g., if we support *up to* 16 we can *still* do 8-bit-at-a-time transmissions)

21:05 <somlo> and I somehow don't think that's how litespi works if one selects a data width greater than 8 for SPIMaster (https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/spi.py#L20)

21:05 <tpb> Title: litex/spi.py at master · enjoy-digital/litex · GitHub (at github.com)

21:15 <somlo> ... unless there's a way to tell the gateware that a given transfer is less than data_width, via the control register...

21:18 <_florent_> somlo: yes you can program the length for each transfer

21:19 <_florent_> with the length field: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/spi.py#L129

21:19 <tpb> Title: litex/spi.py at master · enjoy-digital/litex · GitHub (at github.com)

21:25 <somlo> I wanted to test 16bit transfers, but that looks like it won't happen: https://github.com/torvalds/linux/blob/master/drivers/mmc/host/mmc_spi.c#L1305

21:25 <tpb> Title: linux/mmc_spi.c at master · torvalds/linux · GitHub (at github.com)

21:25 <somlo> but at least I can ensure the driver can handle fallback to lower bpw than the max. width of the gateware (which wasn't in the original linux-on-litex-vexriscv driver)

21:47 <somlo> hmmm... so I'm writing `8` to the MSB of the control register before starting each individual transfer (on a 16-bit wide litespi gateware), but no luck...

21:48 <somlo> also, if I start with the working 8bit driver and data width, and only change 8 -> 16 here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1156

21:48 <tpb> Title: litex/soc.py at master · enjoy-digital/litex · GitHub (at github.com)

21:49 <somlo> ... but leave the DT node set to 8bit max-bpw, it *should* work (since the driver will set the upper half of the control bit to 8), but still doesn't