07:12 <jevinskie[m]> Does litepcie expose raw LTP packets (or the ability to code this) via MMIO?

07:13 <jevinskie[m]> I’m looking to race my friend doing a hand written verilog version of a TLP bridge for qemu passthrough and device emulation

08:14 <_florent_> tnt: The bitsy arrived this weekend, thanks!

08:24 <tnt> _florent_: Ah nice :) Watchout for the reset button on the pmod adapter, it's a bit stiff, I think it didn't like the ultrasonic wash too much but that was my last pushbutton.

08:28 <_florent_> jevinskie[m]: not really with LitePCIe directly, but you could probably reuse all this: https://github.com/enjoy-digital/litepcie/tree/master/litepcie/tlp with the Packetizer/Depacketizer and connect it to your own logic

08:29 <_florent_> jevinskie[m]: otherwise, this could be of interest: https://github.com/enjoy-digital/pcie_screamer

08:30 <_florent_> jevinskie[m]: the aim was to redirect the TLP to an external PC and let it handle the TLPs & respond

08:34 <_florent_> tnt: ok thanks, I'll have a look

13:09 <geertu> a3f: The jh7100 clock/reset definitions have arrived in upstream Linux

14:14 <r4d10n[m]1> With this https://github.com/litex-hub/litex-boards/pull/321 , I am able to get Led chaser running on Pynq Z1.... Litex Bios is not showing up using litex_term... any hints ??

16:40 <SpaceCoaster> _florent_: I rigged up an upduino v2 with psram, same FPGA as bitsy. After a disk failure on my Mac I am restarting my psram stuff. Couldn’t get it to play with QSPI so just SPI for now.

17:34 <somlo> _florent_: would it be fair to say that the LiteSDCard gateware doesn't concern itself with the voltage provided to the SD card in any way? (I dug through the migen sources and didn't find anything related to LiteSDCard attempting to manage or control that anywhere)

17:35 <somlo> so the voltage is something handled in physical hardware by the dev board or pmod adapter, directly?

17:35 <somlo> or am I getting that wrong in some way ?

17:48 <geertu> somlo: I think that's correct.

17:50 <geertu> On boards with SoCs, you typically have a regulator that can be switched between 1.8V and 3.3V using a GPIO.

17:52 <geertu> See e.g. what the vmmc-supply and vqmmc-supply properties point to.

18:30 <somlo> geertu: thanks! I'm trying to convince Ulf Hansson to let me get away without adding another (fragile, in my experience) dependency on some sort of voltage-regulator infrastructure, not sure how that's going to go :)

18:31 <somlo> I think I'm running into the same issue shorne was with clocks, I'd have to add a depends-on <some-sort-of-kernel-vcc-regulator-thing> to avoid probe getting auto-deferred in its absence, if I'm to do it via DT

18:43 <geertu> Without a regulator, you're probably doing mmc at 3.3V, but that depends on the board.

18:43 <geertu> at fixed 3.3V.

18:45 <geertu> This is something LiteX is not yet aware of

18:45 <geertu> So litex_json2dts.py doesn't know.

18:47 <geertu> For an mmc bus with suitable voltages, you need both a switchable regulator (controlled by gpio), and switchable pin voltages (through pin control, see pinctrl-names = "default", "state_uhs")

18:53 <geertu> I doubt LiteX supports switching a pin's IOStandard from LVCMOS33 to LVCMOS18 and vice versa at runtime?

18:53 <geertu> _florent_: ^

22:10 <_florent_> geertu: You need a specific chip or dynamic VIO on the SDCard bank for this, the FPGA can't do it directly.

22:12 <_florent_> geertu: it was supported in the first version of LiteSDCard, but it has been simplified and removed (can be implemented on design requiring it, which are not very common in fact)

22:24 <somlo> _florent_, geertu: if I won't be allowed to hard-code the mmc voltage in the driver probe() and will have to grab it from DTS instead (by adding a dummy voltage regulator set to 3.3v), I'll also have to make the driver depend on REGULATOR_FIXED_VOLTAGE in Kconfig

22:25 <somlo> I figured out how to do it, I'm just still not convinced it's worth the added bloat :)