06:21 <st-gourichon-fid> _florent_, thank you for your answer.

08:12 <_florent_> st-gourichon-fid: This should fix your issue: https://github.com/enjoy-digital/litex/commit/ece90059493f820b0a3a6693d1df9e7b869f4a8d

08:20 <_florent_> st-gourichon-fid: Also with FPGA designs, it's generally better to keep a bit of margin on resources to avoid too much troubles while maintaining a project and allow adding features (even small ones) or integrating bug fixes (that can sometimes use resources)

08:21 <_florent_> st-gourichon-fid: This is also useful to be able to integrate some debug probes.

08:23 <_florent_> st-gourichon-fid: I would not recommend using more than 75% on a project that will continue to evolve

08:25 <_florent_> st-gourichon-fid: Also saying that since it relaxes things for open source project maintainers: We generally try to do the best, but sometimes there can be variations dues to bug fixes, portability, etc... and having some margin is always nice :)

09:02 <geertu> rozpruwacz: 8d885998822bb625aa854b52e6627ab42f03bfb9 looks good to me

09:13 <rozpruwacz> geertu: thanks, and what about https://github.com/mczerski/litex (commit c234d1b54ce73950614e270b26e29b5e84f4c7cf) ? changes in kernel driver depend on it.

09:13 <geertu> rozpruwacz: For 444d3dae2e78f8e89ed9c1788f30d2cf574aebe3, do you need litex_irq_domain_translate() and the chained_irq_*() stuff?

09:13 <geertu> (I'm comparing with drivers/gpio/gpio-rcar.c as a reference)

09:14 <geertu> rozpruwacz: Sorry, I have to defer to the experts for the litex change

09:31 <rozpruwacz> my opinion. If GPIOIn would allow to controll the IRQ_TYPE then litex_irq_domain_translate would be not needed

09:31 <rozpruwacz> geertu: I think that litex_irq_domain_translate is required because if it is not supplied then it defaults to litex_irq_domain_tranirq_domain_translate_twocellslate which in turn call irq_domain_translate_twocell which requires two cells in device tree part that describes gpio interrupt pin (pin number and IRQ_TYPE). In litex-gpio the IRQ_TYPE is fixed by the gpio controller (GPIOIn) so allowing to specify IRQ_TYPE would be misleading in

09:31 <rozpruwacz> typo: litex_irq_domain_tranirq_domain_translate_twocellslate -> irq_domain_translate_twocellslate

09:32 <rozpruwacz> ehh, litex_irq_domain_tranirq_domain_translate_twocellslate -> gpiochip_hierarchy_irq_domain_translate

09:33 <rozpruwacz> and I based my implementation on gpio/gpio-tegra186.c

09:34 <geertu> rozpruwacz: So you cannot specify the interrupt polarity when using the GPIOs as IRQs?

09:36 <rozpruwacz> Geertu: the polarity is defined at HDL level look at: litex/soc/cores/gpio.py. And I just remembered one other thing. The driver works only with falling edge, because rising edge causes the GPIOIn interrupt lines works as level trigger instead of edge trigger.

09:38 <rozpruwacz> So with rising edge trigger adter gpio goes high the interrupt is called over and over until gpio line goes low.

09:44 <rozpruwacz> geertu: and regarding the chained_irq_enter/chained_irq_exit. As mentioned, I based my changes on gpio/gpio-tegra186.c, and to my understanding litex_gpio_irq is attached as chained interrupt in gpio/gpiolib.c using irq_set_chained_handler_and_data call. So to my understanding if it is chained interrupt it mus use chained_irq_* - but I'm not an expert in linux drivers :) I wrote only few in my life.

09:47 <geertu> rozpruwacz: OK, let's see what the other reviewers will say when you submit it or upstream inclusion

09:53 <rozpruwacz> geertu: is https://github.com/litex-hub/linux the correct place to do pull request ?

10:23 <st-gourichon-fid> _florent_, oh yes I fully agree with you. We often include only part of the design, to have a quick and easy build cycle. Sometimes, we have to test the whole design, though. We also strive to help reduce unnecessary weight (I've heard there's some room for improvement in the UART implementation in LiteX, we used to have 6 of them and they appear to consume much more resources than expected.)

10:24 <_florent_> rozpruwacz: We should fix the rising edge IRQ generation, I could look at that

10:25 <geertu> rozpruwacz: rozpruwacz: I think the correct process is documented in Documentation/process/submitting-patches.rst

10:25 <geertu> unless litex-hub wants to accept PRs? But who'll be in charge to get them upstream?

10:25 <geertu> _florent_: ^

10:25 <_florent_> rozpruwacz: We could also make the polarity configurable by a register, but in this case we should probably remove the polarity parameter at the SoC level

10:26 <_florent_> rozpruwacz: And maybe just have a with_irq parameter to GPIOIn that would add IRQ capability to all the Input pins of this GPIO + a register to configure the level

10:26 <geertu> _florent_: That sounds like the better option. You don't always know what will be the use case for the GPIO.

10:27 <_florent_> geertu: Indeed, I just merged rozpruwacz's initial IRQ support, but this is indeed maybe not generic enough

10:27 <geertu> In particular, I'm thinking about adding support for plugging in random FeatherWings on the OrangeCrab.

10:28 <_florent_> And this would in fact simplify the code in the SoC

10:28 <geertu> (which is what I'm working on)

10:28 <rozpruwacz> _florent_: Agree to all. I did not wanted to change the HDL behaviour so I match the driver to suite the HDL. But I think that Your suggestions for HDL changes are perfectly reasonable.

10:29 <_florent_> rozpruwacz: Good, I was going to ask you if it was OK that I do the changes to go in this direction

10:31 <geertu> Adafruit 0.54" Quad Alphanumeric FeatherWing Display (https://www.adafruit.com/product/3130) is working fine, scrolling messages. need to clean up the rather large code changes before submitting them upstream.

10:31 <tpb> Title: Adafruit 0.54 Quad Alphanumeric FeatherWing Display - Red ID: 3130 - $9.95 : Adafruit Industries, Unique & fun DIY electronics and kits (at www.adafruit.com)

10:31 <_florent_> Otherwise for the Linux drivers, this can probably be discussed here, somlo is maintaining a branch in https://github.com/litex-hub/linux (litex-rebase) with all the recent work

10:31 <geertu> tpb: yep, that one ;-)

10:32 <_florent_> This allow us to test the drivers with the different Linux projects (VexRiscv, Rocket, Mor1kx mostly)

10:33 <geertu> For Adafruit FeatherWing OLED - 128x32 OLED (https://www.adafruit.com/product/2900), the display works, but I'll have to look into GPIOs for the buttons.

10:33 <tpb> Title: Adafruit FeatherWing OLED - 128x32 OLED Add-on For Feather ID: 2900 - $14.95 : Adafruit Industries, Unique & fun DIY electronics and kits (at www.adafruit.com)

10:34 <_florent_> And when the drivers are validated, Antmicro/shorne/shenki try to push the drivers upstream through the mor1kx port

10:39 <_florent_> geertu, rozpruwacz: https://github.com/enjoy-digital/litex/issues/842, I'll try to look at this today

10:40 <geertu> _florent_: thx

10:41 <_florent_> geertu: For you case where various featherwing are plugged, this indeed makes sense to be able to configure interrupt polarity dynamically

10:43 <_florent_> geertu: this would also make sense to add it to GPIOTristate, this way you could just create a GPIOTristate on all featherwing IO and dynamically reconfigure them as Input/Output and use IRQs on Inputs

10:48 <geertu> _florent_: And the next step will be adding pinmuxing, as some wings may want to use e.g. the RX/TX pins as GPIOs ;-)

13:01 <_florent_> rozpruwacz, geertu: The GPIOIn IRQ rework should be done with https://github.com/enjoy-digital/litex/commit/0d8b6f8fbbedca5e3e2a84bfaf15684e825cca08 and https://github.com/enjoy-digital/litex/commit/0e7d8219ead8226013b75f3e15116e7e43fa5c71

13:05 <rozpruwacz> _florent_: ok, I test it when I have time (not so much lately ... :()

13:06 <geertu> _franck_: thx, that was quick

13:09 <_florent_> rozpruwacz: ok no problem, just took the time to did it while waiting for a design to compile :) (I think it should be ok, but I only verified the compilation and produced .h/.v, haven't tested it on sim or hardware)

14:52 <somlo> _florent_, rozpruwacz: let me know when the dust settles on the gpio irq linux driver updates, and we can certainly add a few extra patches to the litex-rebase branch for testing. (I haven't had a chance yet to come up to speed on Linux IRQ handling in general, although I'll probably have to do that once we figure out the current litesdcard bug -- I think adding IRQ support *there* could be one way to make it faster)

18:47 <nats`> Finally I have time to send the code that doesn't generate clock constraint in UCF, Spoiler Alert: I certainly do something stupid

18:47 <nats`> https://pastebin.com/Z6GjDVUV

18:47 <tpb> Title: LiteX no clock constraint - Pastebin.com (at pastebin.com)

18:47 <nats`> And second link is the resulting UCF

18:47 <nats`> https://pastebin.com/CWuwiHF4

18:47 <tpb> Title: LiteX generated constraint - Pastebin.com (at pastebin.com)